Think about where you would use CLJS - my use cases would not have an issue with extra 100kb of code - you don't use CLJS to do jQuery animations on your web page - you would use it to build complex single page apps or write server side code/scripts.

You don't use clojure for performance anyway, it's going to be slower by default (because of immutability/persistent data structures, and yeah I know about react benefits with immutability that's not my point - you're still going trough a lot more memory and stressing GC) - you use it to help you deal with your code because of it's semantics.

But in reality last time I tried CLJS I didn't really feel like it delivers on the productivity part and it's mostly because of implementation issues. IMO the decision to implement CLJS on top of Closure compiler and in Clojure (instead of going for a self hosting compiler) was a mistake - you can't overstate the value of REPL and fast iteration in a language like Clojure - and my last attempt to use CLJS the compiler/REPL environment far from what I would consider fast iteration : compiler took forever to start because of JVM and while it could run as a service it needed to be restarted frequently enough that it mattered, REPL was very unstable it would just die randomly - sometimes you'd need to refresh the page, sometimes you'd need to restart the server process. Oh and don't even get me started on the voodoo needed to get the damn thing running - install piggieback, then install austin and then add this weasel thingy then configure the server process all so you can get a halfworking repl and pray it doesn't break because good luck figuring out what's actually going on. Compare this to JS where I just go in to the devtools panel and test my code.

Things are progressing and I encourage you to have another look.

    $ lein new figwheel myproject
    $ cd myproject
    $ rlwrap lein figwheel

    Browse to http://localhost:3449

If you return to the terminal, you should have a connected REPL now running. Along with live code reloading on save of your cljs files.

Maybe, but things progressed way further outside of CLJS space. If you told me this 2 years ago when I was in to it I would be jumping right on it - back when people were saying coffescript fixed JS problems :D

Right now JS has persistent datastructure libraries and TypeScript is a huge productivity boost - tooling is top notch - it makes JS manageable, once it gets async/await (which it should in the next couple of months) I'll be pretty happy with JS development story.

I'll miss some niceties like collection operations, homoiconicity and macros but on the other hand I have working optional type checking, excellent tooling and I don't have to code in AST serialization format with macros :D

Interesting. Do you have a link to a very basic "get-started" in this space? Right now, figwheel / om or figwheel / reframe are very quick to get started with (although familiarity definitely plays a part..). Last time I looked at js there were 5 or 6 or so flux implementations competing for mindshare and I had to stumble my way through setting up a project with webpack / babel..

Oh wow, that's a lot nicer than the last time I played with Clojure/ClojureScript. This plus Om makes me really want to play with it now.

ClojureScript applications start smaller than jQuery so I'm not really sure what you mean. If you're already using jQuery then ClojureScript applications are not large in comparison.

As far as your experiences sounds like a lot of your problems didn't have anything to do with ClojureScript and everything to do with trying to getting overly complicated 3rd party setups going. I've only heard woes from people trying to get piggieback + Cider going. I now recommend that people avoid those entirely for ClojureScript anyway.

I admit ClojureScript did have startup time issues but these were addressed earlier this year. ClojureScript can now compile "Hello, world!" from cold JVM boot in ~1.5 seconds. Of course auto-building has be subsecond for ages. REPL sessions start similarly fast and can go for hours without encountering problems.

ClojureScript may still not be your cup of tea but your complaints are not the sort I hear from users much these days.

> compiler took forever to start because of JVM

No, because of Clojure itself. It is time for people to stop spreading this.

http://blog.ndk.io/2014/02/11/jvm-slow-startup.html

Not really. Advanced optimizations doesn't matter for server-side JS whether Node.js or Nashorn.

This needs to be stressed. Performance in mobile web is already bad enough. If a tool has an optional, manual "improve performance" step, that is bad, it needs to be the default case and it needs to be a good citizen within the environment.