As a general comparison, when it comes to building server-side web apps Rails is preferable to Clojure. But for the web stacks / ecosystems as a whole Clojure wins by about 10x. The main reason for this is ClojureScript. For those who aren't familiar ClojureScript is a Clojure->Javascript compiler that lets you write your UI code in Clojure and drastically simplifies Javascript codebases. Given how much time is consumed writing UI code in modern web app development, the benefits that ClojureScript gives you over the turbolinks/js framework of your choice approach that Rails emphasizes cannot be overstated.
I've found that writing web-apps/api's in Clojure, using ClojureScript on the front-end, then using Rails to write small services where you want to take advantage of some of the great Ruby libraries is the way to go. You get the best of both worlds.
> As a general comparison, when it comes to building
> server-side web apps Rails is preferable to Clojure.
Do you generally prefer a Rails-style framework over microframeworks?
I went from full-time Rails to full-time Clojure, and I would use Clojure over Rails these days for the same reason I'd use Express/Koa (Node) or Flask (Python) over Rails.
I'm curious (as someone who's only dabbled in Clojure): could you write an Ember app in ClojureScript (or Angular/React/Knockout)? Is it like Coffeescript---i.e. just a compiler? If you wanted to build a SPA in ClojureScript, how would you approach it?
You can write Ember/Angular/Knockout etc... in ClojureScript (I've done it before) but it comes out feeling weird and unnatural. You always feel like you're trying to fit a square peg into a round hole.
The preferred solution is to use a ClojureScript wrapper around ReactJS and write your own event handling logic. I'm a big fan of the Reagent library which wraps React with a dead simple API. I believe it's the best UI library ever created and I wish more people knew about it.
The big idea is that you store your UI state as one single Clojure data structure. A Reagent component is just a Clojure function that takes the necessary sub-section of the UI state as an argument and returns a Clojure data structure that represents the HTML code that it wants to render. An example of this would be the following component that displays a list of items.
Then whenever you change the state of 'items', the component will automatically re-render and inject the new DOM as necessary using React's diffing algorithm for high performance. The key thing here is that there is no Javascript framework to learn. All you do is manipulate Clojure data with Clojure functions and use React to render it. There's no 'Ember.component.extend' or 'ng-repeat' to worry about. You spend very little time looking through documentation. The Clojure langauge IS your framework, it's really incredible.
This is the strongest argument for Clojure in web programming. HTML (and all XML-based UI frameworks) are just tree data structures, so it's trivial to represent them as s-expressions and manipulate them using normal Clojure code, then render them to HTML at the last moment, instead of having to use different syntax to inject code into templates. Lisp/Scheme languages are uniquely well-suited to the problem domain.
But lisp/Clojure actually holds no real advantage in this area. Javascript, Ruby, Perl, Python, etc. all have built in lists and list-of-lists (ie, trees). They all have map, filter, etc. to manipulate their native lists and hashes/objects/maps in similar ways to lisp/Clojure.
http://jsml.org is just one example (Javascript). I know similar things exist in Perl and I'm sure Ruby and Python have them as well. If not, it's literally something you can write in a couple hours.
Thanks for the link, that is interesting. While I don't doubt that it's possible to create something similar to https://github.com/weavejester/hiccup in Ruby and Python as well, I am not aware of existing libraries for it and it's definitely not considered the "idiomatic" way to generate HTML in those languages. They both skew heavily toward template languages that are some variation on <div>{{foo.bar}}</div> and require special syntax, which in turn requires editor support for syntax highlighting and such. And Javascript has been the same way until recently--Angular and Ember are template-based by default. And while JSML looks pretty good, I think the other alternative Javascript is trending toward is the JSX approach taken by React, which is basically just backwards templating, and requires a precompiler pass.
Meanwhile with Clojure, because it's homoiconic (code is data and data is code), all you need to implement a DSL for generating HTML is basic functions and macros (which are just functions that process your source code), no special new syntax is necessary. In fact if browsers used Clojure (or any other Lisp/Scheme dialect) as their native scripting language, there'd be no reason for HTML, XML, JSON, or CSS to exist at all in the first place. They could all just be code.
You'd use a React wrapper such as Om[1] or Reagent[2]. These take advantage of React's DOM diffing and pair it with ClojureScript's immutable data structures.
As a general comparison, when it comes to building server-side web apps Rails is preferable to Clojure. But for the web stacks / ecosystems as a whole Clojure wins by about 10x. The main reason for this is ClojureScript. For those who aren't familiar ClojureScript is a Clojure->Javascript compiler that lets you write your UI code in Clojure and drastically simplifies Javascript codebases. Given how much time is consumed writing UI code in modern web app development, the benefits that ClojureScript gives you over the turbolinks/js framework of your choice approach that Rails emphasizes cannot be overstated.
I've found that writing web-apps/api's in Clojure, using ClojureScript on the front-end, then using Rails to write small services where you want to take advantage of some of the great Ruby libraries is the way to go. You get the best of both worlds.