I'm working on a React+ES6 project professionally, and use Clojurescript+Reagent for all my hobby projects. I would gladly use cljs+reagent for everything if I could.

First off, cljs allows you to type less. Second, functionality provided by Immutable.JS is built into the language. Third, I can use paredit. I love paredit. Fourth, google closure has amazing code minification, dead code removal and a good standard library. Fifth, I've found figwheel to be better to react-hot-loader, the latter cannot always reload my application. Sixth, devcards. Seventh, incremental compile speed is faster. Eight, macros can greatly simplify code you're writing and allow new syntax to be exposed by libraries (core.async).

thank you for writing such a detailed reply.

But it seems that 4 out of your 8 points are covered by external libraries that are pretty good - Immutable is great... lodash is great... and google closure compiler is usable (https://github.com/mihaip/react-closure-compiler). I use systemjs/jspm as well as its hot reloader and it works great (unless a particular component is legacy JS.. which will be a problem anywhere).

Not really refuting your point, but ES6/ES7 (and from what I'm hearing.. Typescript) with all these libraries have sort of taken over the mindshare that clojurescript used to have.

IMHO the only reason for me would be the package manager. I mean Systemjs/jspm is okay.. but the whole AMD/global/cjs/webpack/requirejs/browserify crap is way too much. Nothing works anywhere in the javascript world .

Google Closure is usable, but only if you write your app in a way that is google closure compatible, the same goes for any dependencies you pull in. In clojurescript, all code you write, and any pure cljs library, is google closure compatible.

Immutable.js is great, but your libraries probably doesn't use it, and you have to make sure you use it everywhere as well. This can lead to subtle bugs that boils down to using .value instead of .get('value'), a problem you'll rarely encounter in cljs where everything is immutable by default.

I haven't used systemjs/jspm, so I can't say anything about that. I can only say that I have yet to encounter a case where figwheel doesn't successfully reload my code, whereas I encounter this in webpack/react-hot-loader all the time.

ES6/ES7/Typescript are great improvements over ES5. But you have to pair it with Immutable.js for it to be comparable to the offering that cljs provides. Even then, when you have a setup that gives many of the same benefits as cljs, you'll have written way more code, and you need to be a bit paranoid to make sure you're using the correct API at the correct place, and that you don't have any libraries that are incompatible with your setup.

In short. While you can have a setup that gives you all the advantages of cljs+om/reagent, it's just a lot easier to do it in clojurescript.

You are completely true. In fact I spent the last couple of days fixing some incompatibility issues with Handsontable - a very popular spreadsheet component.

But that's precisely my point. Is there value in a pure language when you will need to leverage tons of third party libraries...most of which are incompatible? To get anything meaningful done, you would need to write EVERYTHING in cljs...or you could use a component which will be in old js. So where's the tru value of cljs in a real life project.

Let's take Handsontable - to cover all the corner cases that a spreadsheet needs, it would take me an inordinate time. But it does not even play well with npm..forget cljs

I've done a fair bit of integration with handsontable from clojurescript. It has been excellent so far. Clojurescript isn't really a pure language, it just makes some types of purity the default. If you need to get dirty and mutable then that's simple, still simpler than plain js in my opinion.

Clojurescript and Clojure have very good interop with their host language, integrating 3rd party libs is very simple. To be fair, you will have to write the glue code more often than when working in js since there is a smaller user base.

Is your handsontable/cljs work open source? Would love to see it. I have given up on handsontable being usable in a modern js setup. I had to fall back to including it in a script tag and get it to work. Am quite interested to see if I can build it in cljs

Unfortunately it's not, but I find out if that is a possibility.

And now that you mention it you have jogged my memory about having to sidestep our build process in some unfortunate ways. We're certainly not passing it through Google Closure, we have to use the handsontable build scripts to remove unused features.

Getting it to co-exist with React was the real tricky part, but Rum was quite useful in providing the hooks to make handsontable act like a react component.

Yup! Thats precisely what I wanted to see.

Thanks for trying.

To clarify: the react aspect is the part you wanted to see?

The way you got handsontable to work in your setup. That would be awesome - that would be a good learning of how to integrate complex, legacy js packages in cljs.

Well, if you literally have to leverage TONS of third party libraries, most of which are incompatible, then I would at least be glad that my code, the ui framework, the date handling library, the routing library, the ajax and the validation library, was all written using compatible and immutable by default code.

It's better to have a problem with some dependencies, than to have an issue with your entire codebase. So yes, I would argue that clojurescript has value.

I was about to write a comment like Skinneys below, but he/she put it so well.

I found this joke on r/ProgrammerHumor and it strikes me that I've been falling into this trap for the majority of my career.

> You know what we need? Another mostly imperative garbage collected language, that's what. If we just tweak the syntax and feature set just right, it will change everything!"

As Skinney writes, the mix of libs and tools that you base your webapp on might not be what the libs you want to use the next months agree with.

Use of immutable collections are nearly pointless if only parts of your app use it, and you have to carefully maintain barriers that translate to/from them. Clojure(Script) makes their use succinct and natural, something I doubt yet another lib can make ES2015/TypeScript do.

I find ClojureScript to be far preferable. The language is much better designed in my opinion. It's simple and consistent, while being very flexible and expressive. from what I can tell it does everything ES6 does and more right now.

The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png).

I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving.

I also find tooling for ClojureScript is better in many areas. Instead of having to juggle things like npm, gulp, grunt, and so on. You can use a single build tool like Leiningen that handles all those things. You have a live coding environment with Figwheel, and you get an editor integrated REPL where you can inspect things easily at runtime.

I've been using ClojureScript in prod for about a year now without any issues. I simply wouldn't go back to using Js at this point.