This is really awesome, and at its core a powerful concept. After checking the diva out, a thought occurred to me: any new language revision should come with an officially supported tool from the authors to translate changes backwards.
Counter to the logic of tools like Python's 2to3, I think the more important need is to start writing new code, not porting old code. If you can run new code on the old runtime / interpreter / whatever, you get all the good feels. Porting sucks. New features rock. It just seems like a far superior experience for everyone involved. If happiness is how infomemes spread, assuaging the porting woes couldn't hurt.
I realize there could be concerns involving performance, changes to semantics, etc. that may make back-transliterated (transpiled?) code inherently worse. But if language designers took design of a backwards compiler into consideration when writing the new grammar and semantics, we might see smaller changes brought about in an overall faster pace of iteration.
I agree entirely. One of the biggest mistakes (for me) that Python made was releasing 2to3 but not a 3to2. This meant if you wanted to keep a python2 and python3 compatable codebase, the obvious thing to do what to keep it in python2.
It doesn't. Module syntax is translated to CommonJS syntax. There's a Browserify plugin available though which will include and compile your modules into a bundle. https://github.com/sebmck/6to5-browserify
I think that your benchmarks are a bit off: instead of comparing 5to6 with Traceur + Runtime, you should compare 5to6 + <polyfills> versus Traceur + Runtime (or 5to6 vs vanilla Traceur).
Same, the Op/Sec doesn't tell us much about how much time is actually required to compile a significant codebase.
Anyway, I really like these projects (especially since I'm working on an ES6 library), so good luck ! Is it possible to live-compile ES6 scripts, like with Traceur + ES6-Module-Loader ?
Finally, I note that 5to6 doesn't use ES6 itself (when the Traceur build process self-compile, for example).
> I think that your benchmarks are a bit off: instead of comparing 5to6 with Traceur + Runtime, you should compare 5to6 + <polyfills> versus Traceur + Runtime (or 5to6 vs vanilla Traceur).
The only polyfill that is required is Symbol/Symbol.iterator and that's only required if you use a for-of loop. I included the runtimes in the stats specifically to show the disadvantages to having them. I agree with you that it is slightly off and I'll work to improve it.
> Same, the Op/Sec doesn't tell us much about how much time is actually required to compile a significant codebase.
I struggled to find a significant ES6 codebase to test against. If you know of one please let me know!
> Anyway, I really like these projects (especially since I'm working on an ES6 library), so good luck ! Is it possible to live-compile ES6 scripts, like with Traceur + ES6-Module-Loader ?
I'm not familiar with that behaviour. Do you mean automatically watching and compiling on changes?
> Finally, I note that 5to6 doesn't use ES6 itself (when the Traceur build process self-compile, for example).
I may move to bootstrapping eventually although it seems like a hassle when I'm more than complacent to just write ES5.
"Modern - Virtjs has been made with the full power of ES6, the next iteration of the Javascript programming language. It gives us a pretty simple source code. We're one of the very first libraries to jump aboard!"
> I'm not familiar with that behaviour. Do you mean automatically watching and compiling on changes?
I mean that a javascript library would act as a gate to live-compile Javascript files on-the-fly.
For example, with ES6-Module-Loader[1], you can do something like this in your browser :
<script>
System.import('mymodule').then(function(m) {
new m.q();
}).catch(console.error.bind(console));
</script>
'mymodule' can be an uncompiled ES6 module, the code will still work fine, because ES6-Module-Loader will get its content (XHR), resolve its dependencies, then pass everything to Traceur.
Obviously its main use is for debug purpose (since it does a request for each source file, which won't be great until HTTP 2), but it allows to have a full ES6 workflow, without any visible compilation pass.
This is fantastic. Thanks! I had problems getting Traceur to work with our codebase (and was unhappy about the fact that it added about 100KB to our JS bundle), but this one just slotted right in.
18 comments
[ 4.3 ms ] story [ 51.8 ms ] threadCounter to the logic of tools like Python's 2to3, I think the more important need is to start writing new code, not porting old code. If you can run new code on the old runtime / interpreter / whatever, you get all the good feels. Porting sucks. New features rock. It just seems like a far superior experience for everyone involved. If happiness is how infomemes spread, assuaging the porting woes couldn't hurt.
I realize there could be concerns involving performance, changes to semantics, etc. that may make back-transliterated (transpiled?) code inherently worse. But if language designers took design of a backwards compiler into consideration when writing the new grammar and semantics, we might see smaller changes brought about in an overall faster pace of iteration.
Just a thought.
This tool is neat. :)
https://wiki.python.org/moin/3to2
http://python-future.org/
At some point I could imagine building stuff purely inline in ES6 for the evergreen browsers and transpiling to ES5 for IE.
Same, the Op/Sec doesn't tell us much about how much time is actually required to compile a significant codebase.
Anyway, I really like these projects (especially since I'm working on an ES6 library), so good luck ! Is it possible to live-compile ES6 scripts, like with Traceur + ES6-Module-Loader ?
Finally, I note that 5to6 doesn't use ES6 itself (when the Traceur build process self-compile, for example).
The only polyfill that is required is Symbol/Symbol.iterator and that's only required if you use a for-of loop. I included the runtimes in the stats specifically to show the disadvantages to having them. I agree with you that it is slightly off and I'll work to improve it.
> Same, the Op/Sec doesn't tell us much about how much time is actually required to compile a significant codebase.
I struggled to find a significant ES6 codebase to test against. If you know of one please let me know!
> Anyway, I really like these projects (especially since I'm working on an ES6 library), so good luck ! Is it possible to live-compile ES6 scripts, like with Traceur + ES6-Module-Loader ?
I'm not familiar with that behaviour. Do you mean automatically watching and compiling on changes?
> Finally, I note that 5to6 doesn't use ES6 itself (when the Traceur build process self-compile, for example).
I may move to bootstrapping eventually although it seems like a hassle when I'm more than complacent to just write ES5.
One was just posted yesterday and made it to the front page:
http://virtjs.com/
"Modern - Virtjs has been made with the full power of ES6, the next iteration of the Javascript programming language. It gives us a pretty simple source code. We're one of the very first libraries to jump aboard!"
I mean that a javascript library would act as a gate to live-compile Javascript files on-the-fly.
For example, with ES6-Module-Loader[1], you can do something like this in your browser :
'mymodule' can be an uncompiled ES6 module, the code will still work fine, because ES6-Module-Loader will get its content (XHR), resolve its dependencies, then pass everything to Traceur.Obviously its main use is for debug purpose (since it does a request for each source file, which won't be great until HTTP 2), but it allows to have a full ES6 workflow, without any visible compilation pass.
[1] https://github.com/ModuleLoader/es6-module-loader
I think you mean 6to5.