Speedy Web Compiler – A Rust port of Babel and Closure Compiler

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&#x27;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&#x27;s fairly tedious to get it all right, whenever I try it, since I&#x27;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&#x27;t like scripting languages in general for command line tools.

I&#x27;ve been working on a very similar tool, interesting to see some competition. :-)<p><a href="https:&#x2F;&#x2F;github.com&#x2F;alangpierce&#x2F;sucrase" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alangpierce&#x2F;sucrase</a><p>In my case, it&#x27;s still running as JS, but rearchitected to solve the more straightforward problem where you don&#x27;t need to compile to ES5. I&#x27;ve thought about rewriting it in Rust to see how much faster it gets, though currently I&#x27;m trying to get it running in WebAssembly via AssemblyScript ( <a href="https:&#x2F;&#x2F;github.com&#x2F;AssemblyScript&#x2F;assemblyscript" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;AssemblyScript&#x2F;assemblyscript</a> ), which has been promising.<p>I&#x27;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:&#x2F;&#x2F;github.com&#x2F;alangpierce&#x2F;sucrase&#x2F;issues&#x2F;216" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alangpierce&#x2F;sucrase&#x2F;issues&#x2F;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&#x27;s parser alone has quite a formidable suite of fixtures (a few thousand as I recall): <a href="https:&#x2F;&#x2F;github.com&#x2F;babel&#x2F;babel&#x2F;tree&#x2F;master&#x2F;packages&#x2F;babel-parser&#x2F;test&#x2F;fixtures" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;babel&#x2F;babel&#x2F;tree&#x2F;master&#x2F;packages&#x2F;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&#x27;s edge-cases.<p>SWC&#x27;s CONTRIBUTING mentions this:<p>&gt; Include tests that cover all non-trivial code. The existing tests in test&#x2F; provide templates on how to test swc&#x27;s behavior in a sandbox-environment. The internal crate testing provides a vast amount of helpers to minimize boilerplate. See [testing&#x2F;lib.rs] for an introduction to writing tests.<p>But I cannot find a `&#x2F;test` directory, and it does not appear in the .gitignore either.<p>EDIT: Ah, the tests are in `&#x2F;tests.rs` with JS embedded inside rust code. This makes it a bit harder to compare directly with babel&#x27;s suite, but claims to be lifted from test262, which babel also based many of their tests on (albeit recategorized). hzoo&#x27;s comment here has details: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18746905" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18746905</a>

Seems like transcompilation is an area where you really DON&#x27;T want be overfocusing on performance. Correctness is king here. I mean, compiler bugs are hard. Really hard. Deep voodoo hard. No one who&#x27;s ever dealt with a significant code generation bug on a large project ever wants to repeat that experience.<p>That&#x27;s not to say that babel isn&#x27;t too slow or that this project isn&#x27;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&#x27;t built in javascript. i simply don&#x27;t see myself debugging rust while trying to compile javascript. i really don&#x27;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&#x27;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:&#x2F;&#x2F;wcjohnson.github.io&#x2F;lightscript&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wcjohnson.github.io&#x2F;lightscript&#x2F;</a>, which I have worked on).<p>Curious how this project is thinking about plugins and staying up-to-date sustainably.

There&#x27;s also Pax [1], also written in Rust. Pax however is only a bundler, I don&#x27;t think it actually transpiles code.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;nathan&#x2F;pax" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nathan&#x2F;pax</a>

How is it so much faster exactly? Is it due to parallelization or being written in a compiled language or something entirely different?

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&#x27;d be impressed if it managed a significant subset.

Those interested in fast JS parsers may also be interested in cherow – <a href="https:&#x2F;&#x2F;github.com&#x2F;cherow&#x2F;cherow" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cherow&#x2F;cherow</a> – though it does not provide compilation.

I never had any problems with Babel&#x27;s performance to be honest...<p>Also a quick check with google trends does seem to support that feeling.<p><a href="https:&#x2F;&#x2F;trends.google.com&#x2F;trends&#x2F;explore?cat=31&amp;date=all&amp;q=Swift%20slow,Babel%20slow" rel="nofollow">https:&#x2F;&#x2F;trends.google.com&#x2F;trends&#x2F;explore?cat=31&amp;date=all&amp;q=S...</a><p>Swift is probably used a lot less than Babel but it yields a lot more spikes...

Honestly I don&#x27;t think Babel is the performance bottleneck in most dev setups. Most slow frontend dev setups are because of webpack and it&#x27;s core architecture. Even the ts compiler is quite fast.

Does this work with JSX and TypeScript&#x2F;Flow? These language extensions, when enabled, have nontrivial performance impact.<p>On that note, they don&#x27;t say what plugins&#x2F;presets were used in the Babel comparison. Was it the same set of features that are supported in swc?

How is it Rust project if it&#x27;s installed via Node?