
Swc – Fast JavaScript to JavaScript compiler - bpierre
https://swc-project.github.io/blog/2019/02/08/Introducing-swc-1.0
======
bastawhiz
Two things go unanswered for me:

First, why is it faster? We had Buble back in the day, and deviation from the
spec turned out to mean that you were fine for a while until you weren't. Does
this project cut corners? It looks like the project is mostly Rust, is the
perf improvement simply because of that?

Second, it looks like it has its own parser for Typescript. That scares me.
What version of Typescript does it target? How are you testing that it
produces the same output as Typescript itself?

One of the biggest benefits to Typescript (in my opinion) is that a single
tool verifies the correctness of your code and compiles it (and in all
honesty, I've never been wanting when it came to tsc performance). You don't
need to worry about your production build output differing from your debug
version[0]. I'd be very hesitant to use this in production unless it was
running the full suite of tests baked into the TS repo—and passing.

[0] Yes, you probably use a minifier on your production build, but the
minifier operates on the ES code that you compile your Typescript down to.

~~~
iamleppert
Why don't you just run it on your target codebase and then run your test suite
to make sure nothing is broken?

~~~
underwater
One suggestion I like is that open source projects include a TRADEOFFS.md file
that details the technical decisions made on the project.

Hiding that information means that by default consumers don't have the
information they need to make an informed decision. This leads to better
marketing beating out better technology and, more importantly, fractures in
the community.

------
syspec
It’s suprisingly difficiult to use use these tools just to bundle your code,
but not transpile it down.

I’ve seen code that transpired down to Es3, yet used webgl

~~~
oatmealsnap
Why is it difficult? It's just a command line tool with a config file.

I'm not familiar with this tool, but with Babel, you wouldn't use it to bundle
your code. That's what Webpack/Rollup/Parcel is for.

If you don't care about targeting older browsers, you can use ES Modules today
without a bundler. Even dynamic imports work without transpiling or
polyfilling.

------
kiliancs
I'd love to see Sucrase
([https://github.com/alangpierce/sucrase](https://github.com/alangpierce/sucrase))
included in the performance comparison.

------
mikece
My first thought is this was a rehast of the js2js joke:
[https://eleks.github.io/js2js/](https://eleks.github.io/js2js/)

After looking over the website briefly I'm still trying to figure out if this
is a joke or not. It's only after reading more that it's clear this is a
transpiler. Not the clearest of communication.

~~~
acemarke
Why would it be a joke?

We've had compilers that compile from newer JS syntax to older JS syntax for
years (not to mention all the compilers that compile from another language
into JS). Traceur was the first reasonably well-known one I remember hearing
about, then Babel came out and took over the ecosystem.

Devs want to be able to use the latest JS syntax, but also have to target
older browsers. Compiling new syntax to equivalent older syntax is a perfectly
reasonable thing to do.

Effectively all JS build tools have been written in JS, but this looks like an
attempt to recreate some of that functionality in Rust.

I'm curious how much of an actual perf difference there is in practice, given
that Babel is usually just one part of the build pipeline.

------
Tade0
Checked this using Webpack and _swc-loader_ vs _ts-loader_ on a tiny(300LOC)
TypeScript project and got 4s vs 6s so maybe not 15-20x faster, but at least
50% faster, which is still an improvement.

------
edwinjm
But why? For IE11? A browser for which support will end next year?

All current browsers support ES2015 already. If you really want to support the
few users still using IE11, you can use Babel. Why invest many hours in a
project to make this faster? And that will be obsolete in two years?

~~~
bmichel
Tanspiling from ES2015 to ES5 is no longer the main usage of babel. For
example, there is transforming JSX to normal JS. And object rest/spread
proprerties (ES2018) is often used by front developers, even if it is not
supported by Edge. So, I don't think that babel and swc will be obsolete in 2
years. The most used transform plugins for those will change, but the parser
and engine will remain. And having fast and robust tool here is a good thing
for this field.

------
jugg1es
Every github repo should have the prefix 'super-fast'

------
SeriousM
> 15-20x times faster..

Compared to babel, big team, smart guys, using standards.... Sure

~~~
nicoburns
Babel actually doesn't have a big team. IIRC it's 3-4 developers who have
stated that they don't have enough time as they would like to focus on
performance.

That, plus this being written in Rust rather than JavaScript makes the claim
entirely plausible.

