Hey, it makes more sense now, sorry I couldn’t understand the first time around.
So, I’m not the most expert, so a maintainer of ClojureScript would know better. But this is my understanding.
The ClojureScript’s compiler only requirement is to emit Google Closure compatible JavaScript.
So in most cases, that means ES3, but it doesn’t have to be strictly, since Google Closure support has extended beyond that, and can take ES5 as well as some ES6 compatible JavaScript code as an input, and output ES3 compatible code from it.
ClojureScript does want to make it that the end JavaScript, from the Source -> ClojureScript -> Google Closure -> Output JavaScript pipeline, if specified by the user, be ES3 compatible.
Thus it will not venture in territories which would break this requirement. That said, I don’t believe that currently any trade offs are made due to this, since Google Closure is awesome, and has kept pace with the JavaScript world.
You can see some of this in the source code: https://github.com/clojure/clojurescript/commit/b14eda36ca7249983f5c8f05b97e79bb45623a0e
Now, from my understanding, it is actually harder to optimize the more modern es-next variants, which is why VMs, like V8, are still lagging behind. This is also true for the optimizations that Google Closure performs, and why it restricts the input JavaScript to only a subset of its features.
As I understand it also, no new version of ECMA, have added any new primitives, or changed the memory model. So all the new features are higher level, either syntactic, or added higher constructs which might be more optimized, like its new data-structures. By higher level, I mean that no new VM level support was needed.
ClojureScript though, has always made use of highly optimized higher level constructs from the Google Closure library such as StringBuffers, Google Arrays, Google crypto, etc. When it make sense.
In this regard, I’m not sure it needs any of the ES6 ones. You might even wonder who’s are more optimized, the es-next standard ones, or the Google ones. Anyhow, they probably get close in performance.
Finally, could the compiler emit more efficient code. Probably in some places, but I think that’s possible even with keeping to ES3 code, its just about being smart in how it converts the code to JavaScript. I don’t feel there’s anything in es-next that would change that. Only underlying VM changes would, so new primitive types, support for unboxed values, or contiguous memory blocks, or a change in the memory model, etc. None of that has happened to my knowledge since ES3.
You can geek out even more on this by exploring the source. This is the magic for the compiler in terms of what it emits: https://github.com/clojure/clojurescript/blob/3a6e71e4bb01f97c7a86f46bfed003a602ed5ad3/src/main/clojure/cljs/compiler.cljc#L176
This multi-method, for each thing the analyzer returns, as it walks through the AST of the ClojureScript source, this multi-method is called to emit JavaScript, which is mostly emitting a string of JS code to be concatenated all together into the resulting JS output.
This https://github.com/clojure/clojurescript/tree/3a6e71e4bb01f97c7a86f46bfed003a602ed5ad3/src/main/cljs is where the standard ClojureScript library is implemented. If you inspect it, and believe certain things would be faster if they used es6 constructs, like a WeakMap, or a Proxy, etc. I think you could make a patch to the JIRA, if its compatible with Google Closure compiler, I think it would get merged in.
That’s my 2 cents.
David Nolen would obviously know better then poor me