Honestly this is the part I hate most about Clojure. The tooling is always so convoluted to setup and by the time you start your next project something has changed again, requiring more changes which might break your tool chain. ClojureScript is especially guilty of this right now with all the recent repl changes.

I appreciate the The CS team trying to work with 3rd party repl developers right now, but it doesn't seem to be helping much. It's pushed me back to simple gulp based es6 dev using ramda, rxjs, immutablejs, etc - basically the parts of clojurescript I like. The only thing I sort of miss from Clojure are macros and homoiconicity - it sure is nice to look so uniform, but the tooling just drives me away.

I can agree with that with clojurescript, but I disagree that clojure itself has this problem.

Clojurescript -should- be calming down soon. It is in a stage of changing constantly ATM but that should calm down once some of the underlying tech is stabilized (like clojurescript bootstrapped from clojurescript).

I get the same impressions. Even working with ClojureScript professionally for ~3 years, contributing to the compiler (a tiny, tiny bit), and diving deep into a lot of the libraries... the tooling story is way too chaotic for me.

But I'm somewhat OK with it, as the changes generally seem to be positive, and I have hope that the stability will coalesce around a good, rather than rotten-but-papered-over, core.

I feel the same way. The ClojureScript compiler routinely makes the conceptually sound choices even in the face of breakage. This leads to unstable tooling but the quality of the underlying code allows for bigger and better conceptual improvements.

Have you looked into Mozilla's SweetJS? I haven't had enough Clojure experience to get into something where macros would prove useful, so I'm wondering if utilizing macros in Javascript (which I'm much more comfortable in) would be worthwhile.

> I've been thinking a lot about how to bring this back into the JS world. I have yet to find any good literature on it, but I will be exploring this area more.

The JS equivalent of figwheel is React Hot Loader[1]. There's a port of core.async[2] but I've also seen people using Babelized ES7 async/await for avoiding callbacks. The reloaded workflow is just a pattern around building objects with a topological sort for order initialization. I expect you could build a JS version in ~200 lines of code.

[1] https://github.com/gaearon/react-hot-loader [2] https://github.com/ubolonton/js-csp

I'm unaware of editor integration between an editor and browser runtime a la slime/nrepl. I think LightTable had a basic implementation but it's been a while and I could be remembering it incorrectly.