The best thing with the introduction of ClojureScript, at least for web applications, is that we can now write the whole application in Clojure without context switches. Gaka for CSS, ClojureScript for JavaScript, Hiccup for HTML and Clojure for everything else. Possibly someone could design a form validation library that validates both server side and client side with the same code. Love the possibility being presented here.

Sandbar has form validation in it,though not sure if it would work for clojurescript. And personally I'd still use enlive for HTML so can buy prebuilt templates and just tweak my code to work within those, but that could just be me :)

the enlive vs hiccup battle is not really changed by ClojureScript. I am glad that we have enlive, hiccup and fleet so everybody can take whatever he wants.

Don't even know Fleet, but Hiccup certainly has a place for when you WANT code as HTML. I'd never want it but I can understand why some would.

The idea of passing around Clojure Data instead of JSON is very nice too.

Great Introduction! It is nice how this project makes the point that "JS is Assembly Language for the Web"[1][2]

[1] http://news.ycombinator.com/item?id=2783060

[2] http://www.hanselman.com/blog/JavaScriptisAssemblyLanguagefo...

Unless I'm doing something wrong, they need to do some optimizations to code size if this is going to be used client side nearly 30k is a lot of overhead for a function that returns "Hello, world!"

http://pastebin.com/P5MTvP5Q

I didn't read either the article or what you did carefully, but I do wonder if either (a) you're supposed to run the output of their compiler through Google Closure's compiler which removes most of the code (which is probably library functions unused by your little function), or (b) the 30K is a pretty much one time cost, and if your code grows the output increases moderately.

I believe it's already going through Google Closure. That's what {:optimizations :advanced} does.

I'm certain it's a one time cost. Though I suspect that given that Closure [optimizes out unused code](http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascr...) the more I use of the goog namespace, the larger that baseline will become.

That being said, 30k is the size of minified jQuery, so folks that are alright with building apps on jQuery won't find 30k to be that terrible.

It's a one-time cost, but we're also not done improving Closure Compiler's ability to minify core.

There's a lot of Closure Compiler-specific metadata we're not leveraging yet, and our goal is to reduce the baseline to much, much less.

You should try it on a larger code base before jumping to any conclusions, you'll see that 30k grows quite slowly.

EDIT: sorry, I meant larger pure ClojureScript code base.

Given that Google Closure optimizes out unused code, I'm going to guess that the more that the Google Closure library is used, the more of it will be added to the minified source.

As a point of reference, their sample twitterbuzz app which uses the Google Closure library is 100k minified.

That being said, this is alpha software so it's hard to criticizes it's lack of output optimization at this point.

I guess I don't see how this is any different from the kind of expected bloat that say jQuery UI adds to a project.

"""ClojureScript also makes use of the Google Closure library for capabilities such as event handling, DOM manipulation, and user interface widgets."""

Kinda wished they had stopped at the language and left the DOM out of it.

Still, very cool.

Your understanding this wrong. You can use all java script libs (with sometimes more sometimes less work) but the google closure library is really easy to use. This DOM library has nothing to do with clojurescript itself its just there and easy to use.