ClojureScript is a fantastic piece of engineering. I'm the author of ClojureJS, one of the few Clojure libraries that implemented Clojure to JavaScript translation (with predictable scoping semantics). After having looked over the ClojureScript sources, I'm convinced this is a far more sophisticated compiler with a sound namespace strategy.
The namespace and compile time checks alone are worth the price of admission. Plus macros, which was the biggest motivator for building ClojureJS.
Suffice to say, if ClojureScript (in its current form) had existed 7 months ago, I'd never have considered building anything on my own. That's not to say I'm not proud of ClojureJS. It was born out of a real need that I had, and has been enhanced by some very valuable contributions by people who also shared my excitement for writing browser clients in Clojure.
I still need to understand the Google Closure integration impact, but from what Rich said at the ClojureNYC talk, it sounds worthy of study and adoption.
Node.js is the pragmatic choice for ClojureScript command line apps. One of Clojure's weaknesses was that the JVM was not a great choice for these types of scripts. ClojureScript + Node.js effectively solves this problem.
Web framework? Do you mean Google Closure? If so, bear in mind that the compilation phase will remove unused code, so you're not forced to carry any of it with you if you never use it in your code. As for Node, you do not need it I suppose, but I do not have experience using straight-up V8.
Right, I was talking about node. It sounds like perhaps node has had more people polishing the command-line tools? Stuff that probably belongs in V8, but goes in node because it's a more openly-developed project? The mention of node just seemed a little out of place at first glance.
I only mentioned Node because the parent post did, but as for the reason it was chosen for the target of the first round is because it's definitely got the polish as far as libs, installation experience, etc. go.
I'm no expert here but I think Node gives you the ability to convey command-line args to JavaScript out of the box. From the brief research I have done, it appears that you need to write a C wrapper to do this with V8. If the JavaScript does not require command-line args, it will run just fine with V8.
Oh I fully agree with that, and even if we got NOTHING else from this that would be cool. I just can't help from finding some humor in the idea as well.
I'm glad for the Clojure community if this didn't exist before, but I'm pretty sure Lispers (ie Common Lispers) have written "entire" web apps in Lisp for quite a while[1].
For example, Kenny Tilton wrote a Lisp wrapper to qooxdoo on top of his data-flow library (Cells). The only time we need to write JS code now is for additional glue for widgets or functionality we haven't wrapped yet. And since it wraps qooxdoo, this means not writing (or needing to know) a lick of HTML/CSS. We just write Lisp. And we persist data to a triple store that "shapes" the Lisp/qooxdoo code at runtime.
</smug>
[1] I want to say "years" but I'm not sure how many people have used CL to write "entire" web apps.
I notice you keep replying about Parenscript, but the difference here is important. The reason this is a bigger deal than you make it out to be is because Clojure is hosted on the JVM. That means it's generally had a chance to enter the enterprise, and beyond that, has access to the entire JVM library and interop.
What this means now is, for the first time, you can write Clojure code on the server, interop with legacy Java code or well-tested libraries, and then write Clojure code on the client, full stack. This, as far as I know, is a pretty big game changer since it allows you to write a full-stack web application that is part of the Java ecosystem in a single language that happens to not suck either.
Edit: To clarify, I'm sure there are other JVM lisps, and other Javascript lisps. But this is the first one that is both, I'd wager. This is important.
To play devil's advocate, wouldn't the exact same thing be possible with the above alternatives and Armed Bear Common Lisp? You can write full-stack in Common Lisp, it's just that different parts need to go through different compilers/interpreters/transformers/what-have-you. Just as it is with Clojure.
No, I think the thing to note here is that Clojure--for reasons I can only guess at--has a lot more sex appeal than CL.
I think if Parenscript were just announced today it would get a big reaction as well. Just like there's a big reaction any time a language comes out and says it can compile down to Javascript. There was a big reaction when a guy did it for C# / XNA, for example.
Just because people are excited about developments in the Clojure ecosystem doesn't mean they aren't excited you can do this elsewhere. It's interesting right now because it's new, and it opens up some new ways of development for people who enjoy writing software in Clojure.
I could be wrong, but I think this is different. Are there any other languages that are both hosted on the JVM and also in Javascript VMs? Beyond that, there almost certainly isn't a lisp that is.
Parenscript doesn't have a runtime beyond what the JS implementation provides, so it's not really a Common Lisp running on JS, more like a way to compile Common Lisp-based DSLs to JavaScript. Red Daly's PSOS (https://github.com/gonzojive/paren-psos) library provides most of the runtime stuff, and I guess counts as a sort of implementation of CL. I've been toying with the idea of extending PSOS to a full CL in JavaScript.
x86 emulation is the wrong solution to this problem because of the difficulty of interop. Compiling to bytecode at least lets you treat JS functions as FFI calls. The first project to do this was Clue in 2008 (http://cluecc.sourceforge.net/), now all the hype is about emscripten (https://github.com/kripken/emscripten) LLVM bytecode to JS compiler.
Doing compilation GWT/Clojurescript style is going to reduce integration overhead. So far I haven't seen anything that integrates as well as Parenscript.
This is probably missing the point, but JavaScript is hosted on both the JVM and JavaScript VMs (thanks to Rhino). By extension, everything that compiles to JS is hosted on both.
possible with the above alternatives and
Armed Bear Common Lisp?
Yes it is. I wish being possible was all that it took for it to be done. In the absence of ClojureScript I would love to write my web client code in Common Lisp. I love Common Lisp.
ParenScript (or CoffeeScript) is not the same as ClojureScript. ParenScript "transforms" a subset of CL to JS, while ClojureScript is a full-fledged target runtime for Clojure. For example, something like
(parenscript:ps (defun square (x) (* x n))) ;; [sic]
will compile fine to "incorrect" JS code. Try doing the same in ClojureScript, you'll get an error/warning from the compiler. This applies to CoffeeScript, etc. as well.
Update - To summarise, ClojureScript is to Clojure what ABCL is to Common Lisp.
What would you expect to be different? Your post says the important point: it's Clojure. For some an additonal point is that it's not JavaScript. There is nothing deeper than that.
If that's the most important point I fail to understand why it's #1 Hacker News, sorry. This makes HN no better than a "hype engine" as some say. If someone would at least mention that Google Closure makes it pretty neat, then I would have let it go, so to say.
Even worse, two other relevant Clojure libs are mentioned and the important point is still "it's Clojure"?
The other libraries are clojure libs that implement javascript analogies[1] as clojure macros and functions and generate javascript.
ClojureScript is a Clojure The Language compiler that implements Clojure (its datastructures, standard lib, protocols, deftypes etc etc) and is hosted[2] on javascript rather than the JVM.
In ClojureScript you are not writing reskinned javascript, you are writing Clojure.
> ClojureScript seeks to address the weak link in the client/embedded application development story by replacing JavaScript with Clojure, a robust, concise and powerful programming language. In its implementation, ClojureScript adopts the strategy of the Google Closure library and compiler, and is able to effectively leverage both tools, gaining a large, production-quality library and whole-program optimization. ClojureScript brings the rich data structure set, functional programming, macros, reader, destructuring, polymorphism constructs, state discipline and many other features of Clojure to every place JavaScript reaches.
I'm both curious and surprised by the lack of comments/questions about the quality of the generated JS. Can anyone who has played with it speak to the quality? How does the generated code stack up against say Coffeescript's?
It's purpose is not to compile down to vanilla, readable JavaScript, but rather to make it easy to write production-ready JavaScript applications that can easily leverage the "advanced mode" of the Google Closure compiler.
ClojureScript seeks to address the weak link in the client/embedded application development story by replacing JavaScript with Clojure, a robust, concise and powerful programming language. In its implementation, ClojureScript adopts the strategy of the Google Closure library and compiler, and is able to effectively leverage both tools, gaining a large, production-quality library and whole-program optimization. ClojureScript brings the rich data structure set, functional programming, macros, reader, destructuring, polymorphism constructs, state discipline and many other features of Clojure to every place JavaScript reaches.
That ClojureScript is actually a different project, and is a much less complete implementation. IIRC, it's not a true compiler like the new ClojureScript, but just uses macros to transform forms to Javascript. This announcement probably makes that one obsolete.
Presumably, you wouldn't have to look at the Javascript source because the Clojurescript should directly tell what's wrong when it's compiling to Javascript. This is different from Coffee because Coffee is only a compiler front-end (a lexer/parser) and thus, doesn't really provide any execution semantics.
No. The clojure compiler only complains about compilation errors, which doesn't help at all when you're debugging runtime errors.
For clojure to be usable for serious client side development, you would definitely need a browser extension that relates the location of runtime errors in the compiled JavaScript back to the clojure source code. Which is precisely what something like GWT gives you (and more).
That suggests to me that concerns over thread safety that are taken into account in the Java implementation, say of the core data structures, STM, etc, are not taken into account in the std. lib. of ClojureScript. That would make it unlikely for this code to be a useful origin or starting point for, say, an LLVM backend.
Rich is a very clever fellow and makes fascinating trade offs between pragmatism and idealism in his language design. He continues to build languages quite tied to some existing runtimes which embrace their advantages and drawbacks. Consequentially, it will be very important to keep the rationale in mind while evaluating the real impact of ClojureScript. https://github.com/clojure/clojurescript/wiki/Rationale As neat as it would be to see, it will be a long time before an x86 or ARM backend emerges.
As far as I know, the G1 Garbage Collector in the JVM is still the top of the crop of production GCs and even Haskell with GHC7 is still working towards something of similar potency. See http://hackage.haskell.org/trac/ghc/blog/new-gc-preview
Concurrent GCs and other aspects of runtimes geared towards heavy concurrency are insanely hard. Just something to keep in mind.
It's interesting how closely tied to Google Closure this is. I wonder if that will present issues in the future. Regardless, ClojureScript has definitely made really smart use of it.
False. We're not just talking about Closure. We're talking about Google Closure. They support millions of users with their apps and maintain cross-browser compatibility. Google is doing that huge block of work for ClojureScript in addition to whole-program optimization.
Google Closure is what I'm talking about too. However, it's important to know _which_ Google Closure, as there are a number of components. It seems that the component most used in ClojureScript is the JavaScript optimizer, which is most likely just run as a post-processing step.
Of course, ClojureScript could also be using the Closure Library within the code, which would integrate Closure deeper into the system.
I am a clojure intermediate-beginner who would like to use it to learn about web technologies, which I know almost nothing about. Would people recommend this as an entry point? If not what would you recommend instead?
I think it would be a bit too meta (and work in progress) to start with. Check out this article for standard Clojure (A Brief Overview of the Clojure Web Stack): http://brehaut.net/blog/2011/ring_introduction
I have been tinkering with Clojure off and on for the past year, and I only recently have started with Clojure's web technologies.
Currently the documentation is a mess. I've slowely been learning by looking at very basic examples, and then needing to read source code to fill in the details for the stuff I wanted to do.
While there's a great deal of excitment for ClojureScript, I feel that it as an entry point (at least for me) wouldn't have enough docs for me to learn quick enough so I wouldn't become frustrated. YMMV, of course, but I think you'd be better off looking at Compojure or Moustache, Enlive or Hiccup, and Ring , or even Noir: www.webnoir.com
Atoms are there. The others are not, but they would be pretty much meaningless in a Javascript engine anyway, since Javascript is specified to be single threaded.
Ack no transients either! I know it's early but not gonna lie that one makes me sad. I love being able to write stupid fast list/map builder functions that bash inline but then return something nice and immutable.
The biggest reason I've avoided Clojure in the past was because of the JVM. I know the interop is useful, but I really do not like Java, and the whole thing just stinks.
> ClojureScript seeks to address the weak link in the client/embedded application development story by replacing JavaScript with Clojure, a robust, concise and powerful programming language. In its implementation, ClojureScript adopts the strategy of the Google Closure library and compiler, and is able to effectively leverage both tools, gaining a large, production-quality library and whole-program optimization. ClojureScript brings the rich data structure set, functional programming, macros, reader, destructuring, polymorphism constructs, state discipline and many other features of Clojure to every place JavaScript reaches.
The namespace and compile time checks alone are worth the price of admission. Plus macros, which was the biggest motivator for building ClojureJS.
Suffice to say, if ClojureScript (in its current form) had existed 7 months ago, I'd never have considered building anything on my own. That's not to say I'm not proud of ClojureJS. It was born out of a real need that I had, and has been enhanced by some very valuable contributions by people who also shared my excitement for writing browser clients in Clojure.
I still need to understand the Google Closure integration impact, but from what Rich said at the ClojureNYC talk, it sounds worthy of study and adoption.
Kudos to Rich, and the Clojure.Core team.