This afternoon, I will put up a better version (this one won't work for you due to some figuration stuff), but this takes in your google analytics data and maps it a bit better than the normal set up.
I would also like to point some of the commenters to (fluxus) http://www.pawfal.org/fluxus/. It is a very nice example of this concept of the same thing, only using racket/plt scheme.
Live coding/reactive code are fantastic little ideas which I wish had been exposed to me earlier in my career.
There is your advantage, if it was self-hosting then this wouldn't be an issue.
Also you haven't mentioned eval anywhere in your argument. Don't you think a lisp should have an eval?
As for closure compiler, uglify-js is an obvious replacement, it does all the optimizations, dead code elimination. It only falls short with inlining.
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.
"I can run my dev environment on the web."
"There IS no dev environment."
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 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 and that's a bad thing. An in-browser version of Clojurescript would reduce the time and effort needed to get there.
: 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.
: I assume he's using something fairly newish, and my own experience agrees with this.
Looks like today is the day that I learn clojure! ^^
It seems to me that if what he had built was a real editor (i.e. could be used for more than just his Braid demo game), there would be immense value in releasing/selling it.
I came up with this basic UI concept: http://livecoding.staticloud.com/
But anyone has any idea how to do something like that on iOS/Xcode?
java -jar live-cljs.jar
also, in the talk the player's path was projected into the future, iirc, not just showing the past