fulcro VS ring

I definitely believe Clojure needs a rails. Not only will it help beginners get started, if it can help people get started faster and build fast like Django and rails do, I think it'll help more with adoption.

Biff and fulcro seems like they have a shot at this

Biff- https://github.com/jacobobryant/biff

Fulcro - https://github.com/fulcrologic/fulcro

A library that is a bit leaning towards a framework is Fulcro, a fullstack library to build SPAs http://fulcro.fulcrologic.com/

Fulcro (https://github.com/fulcrologic/fulcro) is my web framework of choice whenever I need to create any non-trivial web application thanks to its productivity. Its overarching design goal is sustainable development speed as time goes and code grows and it really shows up. It is developer friendly, with minimal boilerplate, and features you need for any serious application. And it is surprisingly flexible. Fulcro is based on a few simple ideas that combine powerfully to produce a multitude of capabilities, including its Rapid Application Development "add-on". Some people find Fulcro complicated and scary - but it doesn't need to be. Stop choosing "simpler" web frameworks - and ending up implementing half of Fulcro with much more effort and verbosity and much less value. I will present the minimalist way of learning Fulcro with its three corner stones and explain Fulcro's building blocks. After this talk, you will understand the design and value of Fulcro, be motivated to learn it, and equipped to do so quickly.

I am curious how this compares to Fulcro both from a conceptual and a usage perspective. Which advantages does this offer over Fulcro?

Fulcro has a complete "story" for data-driven UIs and backends. https://github.com/fulcrologic/fulcro

We do that via Fulcro: render the first frame in CLJ on JVM, then continue with CLJS in browser. The code is a bit dirty and probably won’t tell you much (because I can’t share the whole app), but you can definitely do that.

* HTTP: Ring is the de facto way to manage HTTP request (see https://github.com/ring-clojure/ring/wiki/Concepts). Jetty and Aleph are common web servers (and https://github.com/clj-commons/aleph) that implement Ring interface.

https://youtu.be/LcpbBth7FaQ (really cool live coding session with REPL-driven development for a ring web app)

> In the HTTP handlers it makes sense that you don't have return values, because: What would you do with that value exactly?

I think that approach used by clojure's ring shows an elegant way to represent http responses https://github.com/ring-clojure/ring/wiki/Concepts#responses. They are essentially structs with the following fields:

status := number

headers := map of string->string

body := stream | string | seq | inputstream

Request handlers are handed a request struct that is similar. The handler is a function that maps a request to a response (it doesn't actually write to streams itself).

I like this style for an http library for a couple of reasons:

1. HTTP resources can be viewed as functions whose domain is the request, and range is the response. Having the abstraction match that makes for really nice code.

While you won't find your Spring here, you will find that many of those web libraries will tend to use or produce Hiccup, return Ring maps or maybe have pipelines built using interceptors. Composing libraries together is usually not that hard, but it does require you to leave the comfort zone of the framework's abstractions to try to understand what is actually happening e.g. when someone makes an HTTP request and something is returned and displayed in the browser.

On that note, are you able to support everything required by the ring spec?

You can check out my example project in Clojure with using Ring.

It uses already mentioned ring api (https://github.com/ring-clojure/ring/wiki).

I've tried to pair down to the simplest example which shows the issue, and raised it here as I couldn't see one you'd already created or similar: https://github.com/ring-clojure/ring/issues/436 This is so that I have something to link to/follow from our side, hope you don't mind, and many thanks for the diagnosis!