ClojureScript | Hacker News Reader

ClojureScript

github.com

299 pointsicey85 comments

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.

Kudos to Rich, and the Clojure.Core team.

Node.js + clojurescript just came up in the Demo. Part of me says awesome, another part says "How many hipster programmer brains blew up" <_<.

Overall I'm excited about this and anxious to see how far it can be taken, because if you can write an ENTIRE webapp in clojure is thought provoking.

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.

I don't understand; why bring a web framework into it for command-line work? Is it just that straight-up V8 has a crappy CLI experience?

Node isn't a web framework, it's more of unixy, network oriented stdlib for v8.

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.

"Just because people are excited about developments in the Clojure ecosystem..."

Good point. My comment was more of a response to the "thought provoking" part rather than being excited about ClojureScript itself.

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.

Scheme has Scheme2JS (http://www-sop.inria.fr/indes/scheme2js/) and HOP (http://hop.inria.fr/), which uses Scheme2JS for some interesting RMI stuff.

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.

Theoretically almost any language that can run on x86 will now run in Javascript thanks to Fabrice Bellard: http://bellard.org/jslinux/

I don't think anyone has managed to get a JVM to run on his Linux port yet though.

More practically, Javascript itself runs fine on the JVM (via Rhino).

There are Ruby-on-JS[1] and Python-on-JS[2] efforts as well (both Ruby & Python run on the JVM)

[1] http://ejohn.org/blog/ruby-vm-in-javascript/

[2] http://pyjs.org/

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.

Yeah, I wasn't too serious about the x86 "solution". It's an impressive hack, but that's all ATM.

I forgot about the LLVM compiler - that's a very promising project.

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.

Java via GWT runs on the JVM and in JavaScript.

    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.

So the only reason it's a big deal is because it's Clojure? It was only a matter of time this library was written by somebody.

Edit: I guess this somebody also happens to be Rich Hickey. Indeed it would be a big deal if John McCarthy had written Parenscript. :D

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.

Thanks, it makes sense now also thanks to brehaut's comment. I hadn't realized it actually _is_ a Clojure implementation in JavaScript.

Edit: Actually that's not strictly true. "What ClojureScript is Not" https://github.com/clojure/clojurescript/wiki/Core-blog-post...

> (parenscript:ps (defun square (x) (* x n))) ;; [sic]

Why is this example incorrect? n might be a dynamic or global variable; there's no way to know during compilation.

Clojure has had things like Parenscript for a while, including scriptjure (~1.75 years old) and clojurejs.

What's new/exciting/different about ClojureScript? No one has really made it clear here.

Edit: Trimmed unnecessary banter as it's a genuine question.

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.

[1] simplified for the argument

[2] By outputting javascript

Aha! Great, this is definitely pretty awesome. I don't think anyone's written something like that in Common Lisp yet.

I made something that may give you the same reaction: https://github.com/cretz/gwt-node. It was fun to do, but not sure how practical it is.

https://github.com/clojure/clojurescript/wiki/Rationale

> 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?

To better understand how different ClojureScript is from CoffeeScript, read the last paragraph on the ClojureScript wiki's Rationale page: https://github.com/clojure/clojurescript/wiki/Rationale

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.

I'd say it's pretty good, http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascr...

Now we have a "solid" Lispy alternative to imperative languages that compile to JS.

Nice surprise Rich !

You mean other than Parenscript[1], which seems to have been written about 4 years ago?

Edit: Parenscript was just the first to come to mind, but check out http://www.cliki.net/JavaScript

[1] http://common-lisp.net/project/parenscript/

Version 0.1.0 came out in early 2005, so it's been around more than six years.

See this comment - http://news.ycombinator.com/item?id=2788849

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.

There are a LOT of in-browser scheme-like variants.

A few are listed here: https://github.com/jashkenas/coffee-script/wiki/List-of-lang... (which also includes Clojurescript)

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.

That ClojureScript is the (mostly experimental & now obsolete) work done by Chris Houser quite some time back. These two are not the same thing.

Thank both you and lukev for pointing it out.

Edit: Now they are both on the list. Gotta love Github's wiki.

Yes, but the folks that created this one have a high reputation, and this version goes to a far extent to maintain strong performance.

Given a radical departure from the JavaScript core (comparing to Coffeescript), I wonder how easy the debugging would be.

I suspect you'll get good line number info but you'll have to deal with limitations in terms of real-time debugging (beyond having access a repl)

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).

This is an itch that will be scratched. Today's announcement was for an alpha release, not a polished, production-ready one.

I havent look at the implementation yet, but the question that comes to mind is is this one step closer to "Clojure in Clojure"?

Yes, it's a big step in that direction. Rich said it should be easy to change JS target for another.

I would assume however that threading concerns have not been taken into account for the "Clojure-in-Clojure" on display in ClojureScript however, based on https://github.com/clojure/clojurescript/wiki/Differences-fr...

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.

You can use other javascript libraries in addition to Closure (i.e. jquery). https://gist.github.com/1096382

"It's interesting how closely tied to Google Closure this is. I wonder if that will present issues in the future."

It will definitely present issues to verbal communication.

"Yes, you see, Clojure uses Closure as part of it's implementation blah blah..."

"Wait, Clojure uses Clojure?"

"No, with-a-J-Clojure uses with-an-S-Closure..."

I presume Closure is only being used as a post-processing step to optimize the javascript that's produced.

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

I'm wondering if this has the refs, agents, and atoms that make concurrent clojure so awesome. If not, it would feel.... strange.

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.

JavaScript does have Web Workers, though, which are threads/processes.

They have no shared state though, not sure if that is a problem in this case or not.

The impression I got is the core syntax is all there, you just don't get access to the jvm libraries anymore.

All of the core syntax is not currently there, but you're right that ClojureScript only interops with js and not Java. For a more detailed differences list see https://github.com/clojure/clojurescript/wiki/Differences-fr...

Bear in mind that the wording is very careful. We took great pains to say things like "not currently implemented." ;-)

"ClojureScript does not currently support regular expression literals using #"" "

This one seems like a big deal, given how often I find myself using regexes in clojure. Is it on its way and is there a workaround currently?

I'm sure you can use the native RegExp class:

    (def pat (RegExp. "Some(.+)"))

There you go:

https://github.com/clojure/clojurescript/commit/a201e9d8dec8...

No STM, that'll be interesting.

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.

Atoms are available now. Agents might come soon. Refs and Vars are questionable.

> Vars are questionable.

Really? Without vars you don't even have defn. Or do you just mean that vars in clojurescript don't implement IRef?

I think stuff like defn is just a normal js function and does not have the semantics of a clojure var.

IIRC just atoms are available right now.

No agents yet

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.

This, on the other hand, I can get behind.

Yes, pile it up! Now we all need Coffeescript for Clojurescript. ^_^

"Numbers: Currently ClojureScript numbers are just JavaScript numbers"

Boo. I'm sure this is for performance reasons, but JS numbers really need an overhaul.

Reply on news.ycombinator.com