The life-cycle of the software underpinning what I build is as important or even more important than whether or not it is 'the best way' to do something today. Because that best way is the bleeding edge and the day after tomorrow (or even tomorrow) that will be something else.
I don't have the manpower nor the interest and time to keep rebuilding the stuff I put out there.
It's a lisp that, as opposed to Lisp and Scheme, is not fragmented and seems to have mostly a healthy, united community. I see amazingly smart people, and so many of them, pushing Clojure forward (Rich Hickey, Stuart Sierra, David Nolen, Chas Emerick to name a few) and yet it's more approachable than Haskell. And I think these people will eventually find good, standardized solutions for things like the awfully ugly stacktraces.
Clojure doesn't really have a 'framework', and I like it that it's really composable in that sense. But things like Ring and Compojure are lightweight no-brainers, much like Rails is a heavyweight no-brainer for Ruby. What I want to say is, unlike JavaScript, after having picked Clojure as the language, the choice of everything else is mostly always a no-brainer (e.g. leiningen, core.async, enlive/hiccup, maybe Om soon.) And that really pleases my choice-avert brain.
Thank you!
At first it felt like a very mixed bag. There are a number of reasonable if boring things that Rails provides that help make it easier to get your app production-ready––robust logging and asset compilation come to mind––that generally have to be hand-rolled in Compojure (as in microframeworks in other languages). More generally, there aren't many clear signposts from an architectural point of view––for example, there does not appear to be much community guidance over how to organize your namespaces, or how much code one should contain. We made some messes early on.
Once my partner and I got past the initial pain, however, we were extremely pleased with our choice. There are still times when I suspect Rails might have gotten us to market more quickly, but Clojure feels like a good ten-year choice. I certainly agree it's worth a second look.
* I believe that the incidental complexity in web development is rooted in state and in the interactions between various pieces of state in the app. Choosing tools and patterns that reduce state generally results in composable abstractions and more reliable systems. I don't have the solution to web development (FWIW, I use Clojure server side and React client side) but evaluating every new tool I come across against this criterion makes it easy to decide whether to adopt it or not.
If you have a Backbone app, replacing your Backbone views with React is a pretty substantial win. The Backbone app structure works best if you can just listen for a change event and run your model through template code and slap it into the DOM but that gets complicated if you want to nest views, the DOM you're replacing has state, or you have something like jQuery UI widgets. All these issues simply go away if your view code is React and everything just works. I don't find the Backbone abstractions too useful so I've only done this personally when consulting and wanting to make the minimal set of changes to the codebase.
I was using Angular for two years before I switched over to React. React basically replaces directives and for that use it's simpler, composes just as well, and scales better for both data size and dom node count. Replace the Angular DI stuff with browserify/webpack and Jest and there's not that much left. The main reason to use Angular would be if you want to take advantage of the Angular ecosystem or if you plan on focusing mainly on directives to support a bunch of designers since non-directive Angular is super simple.
For other stuff, the main benefit in a two way databinding framework (or virtual DOM diffing) is that you can isolate your business logic from the DOM. That's the major win and everything else is pretty much taste. The React approach results in the least amount of state in my code by a fairly significant margin so I consider it the best but having different preferences is completely reasonable.