This is really cool. I understand why all the front end tooling is written in JS but it really is a pain to deal with in my experience, especially when it comes to building and deploying. Since they're essentially just scripts you have to also install the right versions of node and npm and use npm to install the dependencies (and watch out for native extensions!). It's fairly tedious to get it all right, whenever I try it, since I'm not a pure frontend dev, and things have always changed since the last time I did it. But the promise of this is just dropping in a binary and having it all work!<p>I actually like JS as a programming language for the web, I just don't like scripting languages in general for command line tools.
I've been working on a very similar tool, interesting to see some competition. :-)<p><a href="https://github.com/alangpierce/sucrase" rel="nofollow">https://github.com/alangpierce/sucrase</a><p>In my case, it's still running as JS, but rearchitected to solve the more straightforward problem where you don't need to compile to ES5. I've thought about rewriting it in Rust to see how much faster it gets, though currently I'm trying to get it running in WebAssembly via AssemblyScript ( <a href="https://github.com/AssemblyScript/assemblyscript" rel="nofollow">https://github.com/AssemblyScript/assemblyscript</a> ), which has been promising.<p>I'm curious about the about the Babel performance comparison. Benchmarking JS is tricky because, from my observations, the performance improves by a factor of ~20 if you give it 5-10 seconds for the JIT to fully optimize everything. <a href="https://github.com/alangpierce/sucrase/issues/216" rel="nofollow">https://github.com/alangpierce/sucrase/issues/216</a> . Rust and WebAssembly both have a significant advantage in that sense when running on small datasets.
Where are the test cases?<p>Babel's parser alone has quite a formidable suite of fixtures (a few thousand as I recall): <a href="https://github.com/babel/babel/tree/master/packages/babel-parser/test/fixtures" rel="nofollow">https://github.com/babel/babel/tree/master/packages/babel-pa...</a><p>The nice thing about implementing a JS-JS compiler is that there is already a huge number of tests out there, like these, that you can use to TDD your compiler's edge-cases.<p>SWC's CONTRIBUTING mentions this:<p>> Include tests that cover all non-trivial code. The existing tests in test/ provide templates on how to test swc's behavior in a sandbox-environment. The internal crate testing provides a vast amount of helpers to minimize boilerplate. See [testing/lib.rs] for an introduction to writing tests.<p>But I cannot find a `/test` directory, and it does not appear in the .gitignore either.<p>EDIT: Ah, the tests are in `/tests.rs` with JS embedded inside rust code. This makes it a bit harder to compare directly with babel's suite, but claims to be lifted from test262, which babel also based many of their tests on (albeit recategorized). hzoo's comment here has details: <a href="https://news.ycombinator.com/item?id=18746905" rel="nofollow">https://news.ycombinator.com/item?id=18746905</a>
Seems like transcompilation is an area where you really DON'T want be overfocusing on performance. Correctness is king here. I mean, compiler bugs are hard. Really hard. Deep voodoo hard. No one who's ever dealt with a significant code generation bug on a large project ever wants to repeat that experience.<p>That's not to say that babel isn't too slow or that this project isn't correct, just that it would scare me to try to work with it. Does babel have a regression suite? Does this pass it?
for me these kinds of tools are only as good as the time spent debugging when something goes awry. as such, the biggest risk i see is that it isn't built in javascript. i simply don't see myself debugging rust while trying to compile javascript. i really don't.<p>this being said, i do wish this project (and any others like it) great success. we definitely do need something faster when compiling js.<p>(this tool reminds me of a similar project for a small client. they required a fast js compiler. the project was a failure because no-one wanted to debug non-js code when the build failed)
Perhaps the best thing about Babel is its plugin-based architecture. As of Babel 7, even its parser accepts plugins.<p>This not only makes it easy to keep up to the latest of ECMA's standards and extensions like JSX, Flow, TypeScript – it also makes it surprisingly easy to implement your own syntax extensions to JS (eg; <a href="https://wcjohnson.github.io/lightscript/" rel="nofollow">https://wcjohnson.github.io/lightscript/</a>, which I have worked on).<p>Curious how this project is thinking about plugins and staying up-to-date sustainably.
There's also Pax [1], also written in Rust. Pax however is only a bundler, I don't think it actually transpiles code.<p>[1] <a href="https://github.com/nathan/pax" rel="nofollow">https://github.com/nathan/pax</a>
Closure Compiler is a poorly specified pile of edge cases and bugs. (Embarassingly poor quality for something Google relies on so much.) Is this attempting to support its type system, minification moded, or what? I'd be impressed if it managed a significant subset.
Those interested in fast JS parsers may also be interested in cherow – <a href="https://github.com/cherow/cherow" rel="nofollow">https://github.com/cherow/cherow</a> – though it does not provide compilation.
I never had any problems with Babel's performance to be honest...<p>Also a quick check with google trends does seem to support that feeling.<p><a href="https://trends.google.com/trends/explore?cat=31&date=all&q=Swift%20slow,Babel%20slow" rel="nofollow">https://trends.google.com/trends/explore?cat=31&date=all&q=S...</a><p>Swift is probably used a lot less than Babel but it yields a lot more spikes...
Honestly I don't think Babel is the performance bottleneck in most dev setups. Most slow frontend dev setups are because of webpack and it's core architecture. Even the ts compiler is quite fast.
Does this work with JSX and TypeScript/Flow? These language extensions, when enabled, have nontrivial performance impact.<p>On that note, they don't say what plugins/presets were used in the Babel comparison. Was it the same set of features that are supported in swc?