> We grabbed a string out of CodeMirror, read it via tools.reader into persistent data structures, passed it into the ClojureScript analyzer, constructed an immutable AST, passed that AST to the compiler, and generated JavaScript source with inline source maps and eval'ed the result. All of this happened inside of your web browser.
This is just fantastic! As David himself mentions - this might not be extremely pragmatic but it sure as hell as cool. For me it means that I can get back to writing my web-based Clojure book without being dependent on Himera[0], which although great, is really hard to work with.
It horrifies me that anyone would have been dependent on Himera to do real work. While I'm proud that it filled a gap for a few years and consider it a successful experiment, I'm happy to know that it's effectively unnecessary now.
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?
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.
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.
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.
This is just fantastic! As David himself mentions - this might not be extremely pragmatic but it sure as hell as cool. For me it means that I can get back to writing my web-based Clojure book without being dependent on Himera[0], which although great, is really hard to work with.
Awesome work by @swannodette and team!
[0] - https://himera.herokuapp.com/index.html