I noticed Clojurescript in Github before the big announcement and thought it was an interesting idea. I am a big fan in general about having a Clojure syntax that compiles to Javascript. As a platform it is even more ubiquitous than Java and it would be a great way of simplifying Javascript’s closure and function syntax.
However in practice Clojurescript has been desperately disappointing for me. Firstly there is the weird decision to not have the code run on OpenJDK. This really limits its utility: I don’t seem to have a machine with a compatible setup at the moment despite having various flavours of Javascript interpreters available.
Then while looking for an answer as to how soon this problem is likely to be resolved I discovered this thread which was another level of disappointment. The original post is undiplomatic, perhaps even inflammatory, however the response indicates a level of befuddling clueless-ness.
If you want something to compile into Javascript I think you actually do want it to compile into good idiomatic Javascript unless you have a really good reason not to. You also do want to be able to use really good existing frameworks like jQuery (which really is the defacto standard right now).
The reason I think these are reasonable requests is that Coffeescript seems to manage to do both. Before Coffeescript maybe Clojurescript’s idiosyncrasies would have been forgiveable but being late to the party as well as being less well-mannered makes the defiance in the response seem poorly judged.
I am not sure what Clojurescript is really for (apparently it is aimed at a future community of people that don’t exist yet, which is … helpful). I don’t feel that it is really simpatico with the existing Javascript code that works in the browser and I am not sure it really has a place in the server-side world of Node.js where it might have been a better fit.
I remain open-minded though and would be willing to give Clojurescript a second go once the dust has settled a bit.
Echo One 
> I noticed Clojurescript in Github before the big announcement and thought it was an interesting idea.
Just a quick point. The previously named ClojureScript was a different project by Chris Houser. To add to the confusion, Chouser is also a key contributor to the new ClojureScript. 🙂
> decision not have the code run on OpenJDK
I’m not sure that “decision” describes the reason. I think “bug” would be more accurate. I am not intimately aware of the problem(s) preventing its use on OpenJDK, but I think that someone has already solved this and it is not likely to be a persistent problem.
> a level of befuddling clueless-ness
I would be interested to know your basis for this characterization.
> compile into good idiomatic Javascript unless you have a really good reason not to
I doubt you will be happy with the answers, but I can think of two:
1. ClojureScript is not Coffeescript. Its semantics do not map directly onto the JavaScript runtime. In some cases there is no way to reconcile the differences between ClojureScript and idiomatic js.
2. The emitted js is definitely closer to idiomatic Google Closure JavaScript. The reason for this is to facilitate minimalization.
> You also do want to be able to use really good existing frameworks like jQuery
I believe that JQuery libraries are accessible via ClojureScript. Do you instead mean that ClojureScript should have used JQuery as its target runtime?
> Before Coffeescript
Coffeescript is awesome and in many ways blazed the trail for ClojureScript, but they are very different languages and what is kosher for one may not apply to the other.
In answer to your two questions: “befuddling clueless-ness”, “clueless-ness” because I think it is (or at least the view is coming from a point so far from what I see as the point of Clojurescript that I must be completely failing to understand the purpose of Clojurescript); “befuddling” because what I see is smart people acting foolishly in an unexpected way.
As regards the use of jQuery as a target runtime, I’m not really sure what the purpose and relationship of Google Closure is to Clojurescript. Looking at the examples it seemed to be joined at the hip, but if I can, for example, treat a jQuery selector as a lazy sequence I would be happy. The use of Google Closure in the examples is, for me, is highly unattractive compared to my existing jQuery/Coffeescript code.
Realistically I suspect that my use of Clojurescript will most probably be to do client-side computation rather than DOM manipulation.
> understand the purpose of Clojurescript
I apologize if I’m being dense here, but what other purpose would you expect other than providing a strong language for developing applications in the same environments that JavaScript is found?
> what I see is smart people acting foolishly in an unexpected way
I’ve tried to follow that thread but lost track over the past few days. It became apparent early on that it wasn’t going well however, so for better or worse I’ve abstained from engaging. It’s unfortunate that the dialogue on the Clojure group has turned you off to ClojureScript itself.
> purpose and relationship of Google Closure is to Clojurescript
The Rationale and Closure pages try to outline that relationship. Maybe they would help clarify? https://github.com/clojure/clojurescript/wiki/Rationale and https://github.com/clojure/clojurescript/wiki/Google-Closure
> unattractive compared to my existing jQuery/Coffeescript code.
JQuery integration is not a priority of ClojureScript, but that’s not to say that some brilliant soul will not solve it. As far as I can tell there is no reason that JQuery and ClojureScript cannot co-exist, it’s just that it hasn’t been done yet. But honestly, ClojureScript is not attempting to oust JQuery nor Coffeescript. If they work well for your needs then it would be hard to present a case that you should change.
:F
So if the purpose of Clojurescript is to replace my day-to-day use of Javascript client-side then having a jQuery interaction story is a must. If it is to provide an alternative dialect for something like Node then fair enough the Closure discussion is a red herring, I eagerly await the NPM module. If it is to produce an entire replacement for Javascript and the niche it occupies then more power to you but there are many ships wrecked on that shore.
Nothing I have read (including these comments) tell me which one of these options (or something else) Clojurescript is shooting for.
Thanks for the links. I had read them but I tried to closely read them again to see if I had not been skim reading first time round. I have to say that they don’t help me personally. And that the documentation generally around Clojurescript has also been underwhelming.
As you say if it’s not floating my boat then maybe I’m just not the target audience despite being a Clojure fan in general.
I really don’t understand the point of jQuery here. ClojureScript is a “Language”, not a DSL for DOM API. Google Closure is a suitable target to build language and related abstractions and API, because it gives a robust low-level SDK to do that stuff.
If you like jQuery so much, feel free to build a library/wrapper on the top of ClojureScript+jQuery. Why want ClojureScript to be piggy-backed on jQuery?
I don’t really understand your comment but on the basis of what I understand your comment to be I think my issue is that if Clojurescript is a language then why mention Closure at all? Clojurescript would generate Javascript and allow forward references to library variables, that would be fine.
Closure is being presented as a necessary part of Clojurescript though (I might be right or wrong in this perception but it is the way I am understanding the proposal). Why do I prefer jQuery over Closure? Because for me jQuery-based code is simpler and more elegant than Closure code. There are aspects of Closure that I like, obviously, but the way the library is generally presented is as a non-modular lump of many, many things makes it unappealing.
You’re right that I could do the bridge myself but as the post points out, why would I do that when I already having a working environment that gives me compact functional-like code?
> Why do I prefer jQuery over Closure? Because for me jQuery-based code is simpler and more elegant than Closure code.
I do agree, however this point is not really relevant.
I am excited about ClojureScript because with it I don’t *have* to look at CloSure code, or javascript in general. I only have to look at Clojure code. That is the point that the guy in that thread didn’t seem to either understand or accept (I am not sure which one). If you refuse to give up jQuery for whatever reason that is ok, and ClojureScript may not be for you. Many of us, however, would LOVE an environment where we dont have to use jQuery or other DOM manipulation libraries when developing an app that runs in the browser. This is what the strength of ClojureScript really is: allow you to write an app in clojure that runs in a browser. I am hoping never to even look at the JS that is created because it is – frankly – unimportant to me, just like the java byte code that is created is unimportant to me. This is what Rich means when he says that Google Closure is an implementation detail.
I use jQuery every day and love it, but to me the day that I can do everything I need to do in ClojureScript and not *have* to use jQuery or any js library will be a great day!
I’m not a huge fan of DOM(HTML)-less apps so I can see that I’m not necessarily in the demographic for this.
I think that having a good intermediate stage of Javascript would be helpful for tracking down bugs. The only way the Javascript becomes an “implementation detail” for me is when runtime errors can be easily traced to the source code. However this isn’t impossible so I happy to reserve judgement.
The difference between Google Closure and jQuery is that Closure provides fundamental building blocks to work with JavaScript (that ClojureScript leverages). Closure is to ClojureScript what JDK is to Clojure. There is nothing in jQuery that can be used to build ClojureScript — in this case jQuery is more dissimilar to Closure rather than an overlap.
“Why not jQuery for ClojureScript? I hate Closure!” is same as saying “Why not SWT for Clojure? I hate Swing!”.
My feeling is that Javascript needs a JDK like it needs a hole in the head. Not that I’m defending the core JS functionality but that is the right place to tackle the problems not an unsympathetic layer on top of the language.
Personally, ClojureScript allows me to:
1.) Write powerful scripts on portable devices (for example, using SL4A on Android)
2.) Write quick scripts in Clojure that can run fast via node.js
3.) Deliver powerful client-side functionality to drive an application
4.) Brings Clojure into a realm where I can use it to develop next-generation applications on HTML5/JS
I’d like to discuss points 3 and 4 more.
I love jQuery and I use it often (you’re foolish not to use it if you’re building consumer-web stuff). I don’t see myself doing jQuery based stuff in ClojureScript, but it is very easy to do so (https://gist.github.com/1098417). What I see is using ClojureScript to enhance the overall client-side experience, deliver client side templates, and handle most of my data marshaling. I plan on still using jQuery for UI effects and complex DOM manipulation, but I’d still like to give the goog.ui pieces a try.
I’m less concerned with the JS that ClojureScript generates. In production websites, javascript files need to be concatenated, optimized, minified, and compressed, then tossed onto a CDN. Google’s Closure compiler has always been my tool of choice, but admittedly, I almost never used advanced compilation (because it is difficult to write javascript in that style). ClojureScript offers me a much shorter and more effective path to achieving this end goal.
For what it’s worth though, the JS that gets generated is more or less canonical: it follows the module pattern, the namespace pattern, uses closures to block access, etc.
When it makes sense, I’ll still hand-write JavaScript, and I’ll do so in a clean, functional style. I’ll do my best to make it as compatible for Closure, but I’m not going to go out of my way (that ClojureScript’s job via the compiler).
Additionally, I’m working on a library to marry Closure’s HTML5 support and the rest of HTML5 spec for ClojureScript. With such a library, next generation apps will be a breeze and will be as optimized as possible.
To follow on:
1.) I really do see JavaScript as the assembly language of the web. CoffeeScript, to some degree, was like a really solid pre-processor. ClojureScript has the ability to do very meaningful compilation (and furthermore produces highly optimized results via Closure Compiler).
2.) The inclusion of the Closure library is to create a performant, complete/rich/deep, ecosystem of library support in a single package. This results in very little effort of porting things from Clojure to ClojureScript, and makes the experience in both dialects uniform.
Because of these abilities, all of ClojureScript compiles down (after compression) to 4 Kb. This is the same size as a memory-mapped file (file descriptor) on your operating system. That’s what the toolchain buys you.
The goal of ClojureScript is that you write all your JavaScript code in ClojureScript. Ideally, you would never use Google Closure. It is the foundation just like Java is the foundation for Clojure. Many Clojure programmers would never be caught dead using Java but that doesn’t stop them from loving Clojure. In the same way, you may not like Google Closure but once ClojureScript is mature, you will hardly know it’s there. No Clojure programmer likes doing a lot of Java interop. When it needs to be done, a Clojure library is often created to hide all the ugliness. The same thing will happen with ClojureScript.
For now, if you don’t want to deal with Google Closure you don’t have to. You can use it with jQuery. People are already doing this. The only thing that you can’t do if you use jQuery is optimize your code. Since you are already happy not doing this with CoffeeScript and jQuery then it shouldn’t be a problem for you.
The Google Closure library is prominent now because ClojureScript has been released very early. This was done so that others could get involved. Explaining the use and purpose of Google Closure is essential at this early stage. Early adopters will start to build libraries on top of it so that people like you won’t have to deal with it some day.
Personally, I love jQuery. I use it in every project. My first question when I heard about ClojureScript was “How do I use it with jQuery?”. Now I am thinking about how I can build something in ClojureScript to replace it. Others are as well.
The promise of ClojureScript for web development is that people who like Clojure will be able to use one language to do everything. They will even be able to run the same source code on the server and client.
Thanks for giving me a clear answer to my questions. I haven’t been able to find this kind of mission statement elsewhere in the documentation.
To me the biggest reason to generate javascript even if it is non-idiomatic is to interface with other languages and libraries running on JS. ClojureScript should an emit idiomatic stub layer so one can write ClojureScript and have it be consumable by CoffeeScript, regular JS or what not. Requiring Google Closure is a small mistake that should get fixed.
I certainly came to this thinking that ClojureScript would be just one of many collaborators on a Javascript platform rather than the “one true way”. But I can appreciate this is quite different to the creators’ goals. I’m glad that as part of this discussion I’m clearer about the purpose of Clojurescript now.
ClojureScript is Clojure for the browser, not “a Clojure syntax for JavaScript”. It’s for Lisp programmers who want a modern browser implementation, more than a extension or improvement of JavaScript. To me this alone was awesome because it meant I could use a modern and frequently changing Lisp not only on the JVM but also on node or browser, which I would much prefer than JavaScript. (BiwaScheme is good to, just not really something I would use on a large-scale project.)
Pingback: Clojurescript: is it any better yet? | Echo One