self-hosting only gets you bragging rights and neat demos - it offers little advantage for real applications targeting JavaScript. That said, ClojureScript now implements most of Clojure - if someone wanted to bootstrap ClojureScript for fun it wouldn't be much work, go for it.
Advantage for a beautiful demo. If I'm going to actually build real applications in this way, I don't need to run my development environment on someone else's website.
This was beaten to death on the release of clojurescript. I think the consensus is it's not worthwhile, since there are real benefits to google's closure compiler, optimization, and dead code elimination. But there's nothing stopping you from implementing it?
If people want to code on the web that's great. If someone wants to provide a bootstrapped in-browser ClojureScript development experience, that's great too. I just don't buy your claim that ClojureScript's strategy is a disadvantage.
eval is fantastic - the power of connecting to server-side REPLs comes to mind. However given ClojureScript's clientside focus the lack of the compiler infrastructure on clients (to provide support for eval) is less problematic in my opinion. But you might disagree - and no one's stopping you from addressing the issue.
Advantage for a beautiful demo. If I'm going to actually build real
applications in this way, I don't need to run my development environment
on someone else's website.
The key benefit of having an in-browser implementation of something like Clojurescript isn't:
"I can run my dev environment on the web."
it's:
"There IS no dev environment."
Look at how absolutely trivial and frictionless it is to get started with LessCSS[1], and compare it to the morass of libraries, source file locations, command-line invocations, and extra compilation steps that Clojurescript requires[2].
You can introduce someone to LessCSS and have them working with it in five minutes. No cross-platform problems, no installation, no figuring out how to automatically compile code when it changes, or anything else like that.
Once you need the extra speed, sure, have a command line tool to precompile everything to vanilla JS. LessCSS has this exactly. Heck, sure, maybe even run it through the Closure compiler if you want crazy speed. But don't optimize the development process for huge apps at the expense of small ones, because even if you only care about those huge apps (which would be a mistake -- there are some really cool small apps out there) you need people writing smaller stuff first to learn how to use Clojurescript, create libraries for it, convince others to use it, and so on.
Before anyone screams at me that I'm caring too much about that filthy concept of "easy", let me say that I loved Rich's talk on Simple and Easy, but I feel like it may have actually done some harm to the Clojure community by giving them an excuse for making conceptually-simple but hard-to-get-started-with-and-use libraries and tools.
Simple is more important than easy, yes, but if you can make something easier without sacrificing simplicity then you should!
No one should say "I don't have to thoroughly document this because it's conceptually simple so you should just read the code", or "we're going to make something that has lots of uncomplected layers and who cares if it's performant enough for real world use", or "I don't feel like making this a single-step install, so if anyone complains I'll just say they care too much about ease of use".
In Clojurescript's case it actually seems like the combination of Clojurescript code calling Clojure macros and then being compiled by a compiler written in Clojure and then compiled again with the Closure compiler (aside: this naming is just hilarious) is really complex. There's a lot of mental effort required to say "Hmm, where do I put everything so all the different parts of my project can talk to each other?".
A lot of this can be solved in a few different ways:
- More mature tooling with sane defaults, so I don't need to know everything a library is doing to use it. The entire point of a tool/abstraction is to take care of this stuff for me. lein-cljsbuild is off to a good start, but as an example: don't make me specify where my .cljs files are when it can `find . -name '.cljs'` and figure it out for most people itself!
- Documentation. This is a problem with the Clojure community in general. Auto-generated API docs are worse than useless because they fool developers into thinking they've written actual documentation.
Another problem in my own experience is that the performance of all of these extra layers is just awful compared to something lighter weight.
If you saw Chris Granger's screencast about the Overtone controller webapp the other day, did you notice that he often had to refresh in the browser a bunch of times before his Clojurescript changes were compiled and took effect? It's a sub-100 line Clojurescript file and yet a several gigahertz machine[3] takes a noticeably long time to show us our changes? We have to mash the refresh button until we're pretty sure our changes have compiled?
I really, really want to love Clojurescript, because it's got some beautiful ideas, but it almost seems to have adopted Haskell's "avoid success at all costs" mantra. That's great if you're building an experiment in programming language theory, not so great if you want to save real live people's time and frustration.
TL;DR: Clojurescript makes it really complicated to get to a black triangle moment[4] and that's a bad thing. An in-browser version of Clojurescript would reduce the time and effort needed to get there.
[2]: Yes, I know about lein-cljsbuild. Compare the README at https://github.com/emezeske/lein-cljsbuild to the two lines required to use LessCSS. Yes, this is a matter of easiness, but easy is not a dirty word.
[3]: I assume he's using something fairly newish, and my own experience agrees with this.
