
ClojureScript - icey
https://github.com/clojure/clojurescript
======
funcall
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.

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

~~~
felideon
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.

~~~
gfodor
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.

~~~
Tiomaidh
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.

~~~
icey
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.

~~~
gfodor
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.

~~~
spullara
Java via GWT runs on the JVM and in JavaScript.

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

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

~~~
semperos
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.

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

Nice surprise Rich !

~~~
felideon
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/>

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

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

~~~
abi
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.

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

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

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

~~~
redline6561
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...](https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure)

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.

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

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

~~~
devin
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.

~~~
ThisIBereave
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.

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

~~~
frou_dh
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>

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

~~~
lukev
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.

~~~
azakai
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.

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

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

------
aidenn0
"Numbers: Currently ClojureScript numbers are just JavaScript numbers"

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

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

