[eggy]

I don't pretend to know front end dev too much; I don't program for a living, but it seems the 'bazaar' model of layering, patching and piling things up is making that world unnecessarily complex. If I understand this thread correctly, you lose Google's Closure optimizations(?), you go round about AST->compiler->JavaScript and you can eval the result. Is the eval equivalent to Scheme or Common Lisp? What are its limitations? I like what I see of ClojureScript as a language syntax and some of the underlying concepts. I am playing with PicoLisp and PilOS (PicoLisp running on a VM - not really a Lisp Machine), and the simplicity and directness of it is refreshing. The layer of abstractions are minimal. I guess that's the same reason I like the J programming language. I am astounded by the amount of work and the accomplishment here, but I have to wonder if we can't see the forest for the trees any longer in computer science. Currently reading 'The Architecture of Symbolic Computers', studying Shen, PicoLisp, Racket and the J programming language. Perhaps my naivete of not having to work in this field, and the luxury of being able to dabble across languages and systems has shifted my perspective?

EDIT: How do you debug your work? What traces do you get back? Can you still do REPL (like Emacs/Slime) this way?

[ballpark]

One thing that's great about Clojure and Clojurescript is that they run on Java and Javascript platforms respectively, and are easy to interoperate with those platforms. For a business that wants to crank out some code, being able to use the libraries that others have created for those platforms makes the decision to use them for production systems much easier.

[weavejester]

ClojureScript isn't particularly different to how most other languages work. You have a parser (analyzer) that turns text into an AST, then a compiler that turns the AST into the target code. In this case it's Javascript, but the same principle applies if the target is assembly or bytecode.

ClojureScript is now self-hosting, which means that you can eval any valid ClojureScript, so yes, eval in ClojureScript is now equivalent to the eval in languages like Clojure, Racket or any other Lisp.

Usually when a language is bootstrapped, that becomes the new norm. For instance, Go was originally mostly written in C, but since 1.5 Go has been written in Go. However, the Java version of the ClojureScript compiler can leverage Google's Closure Tools, which include a rather useful Javascript optimizer. This means that we'll still want to use the Java version of ClojureScript in most cases.

[delluminatus]

ClojureScript is probably not the best language to use if you want few layers of abstraction. I personally love it, though.

The best way to think about this development is that it is a client-side compiler for ClojureScript. In client-side development, you are constrained by the limitation that all code must be in JavaScript to be executed by the Web browser, which is why this compiler "compiles to" JavaScript instead of machine code. JavaScript is the assembly of the Web, right now (until things like WebAssembly get more useful and popular). Once the ClojureScript is compiled to JavaScript, the JS can be executed by the browser (which of course involves an additional JIT compilation step). This might sound "dirty" if you are used to thinking about non-Javascript development, because it involves two separate compilation steps, but it is unavoidable, once again until something like WebAssembly becomes popular.

So, this is a client-side compiler for ClojureScript. A server-side compiler already exists, which is what you would use if you wanted Emacs/Slime support, or if you were developing a "real" Web application for deployment, because in that case you would want to pre-compile to JavaScript on the server, and distribute the compiled JS to the client.

It doesn't really make sense to talk about Emacs/Slime running on the client, until someone makes Web app for it. You could use a socket-based REPL to communicate from the client to the server but I don't really see the benefit, when you could just use the server-side compilation model and avoid the network overhead.