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. 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.
 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.
In all, I much prefer Bublé to Babel for code I control, although sometimes I would like the extra transformations that you can do with Babel.
For my priorities, I would genuinely see switching to swc as a functional regression if it does not support such loose transformations.
Plus, I'm not writing unit tests that test the behavior of things like enums and decorators, I'm testing the business logic of my application. If the compiled code behaves strangely under abnormal conditions that wouldn't occur in the test environment, it's going to be a hell of a time for me to figure out what's going wrong.
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.
In this case your suggestion is a good one, obviously.
I would think so.
I’ve seen code that transpired down to Es3, yet used webgl
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.
Isn't that what Rollup is for?
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.
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.
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?
IE 11 is still relevant and large code bases can take a long time to compile with Babel.
Why invest time? Probably someone thought it would be fun to beat Babel's performance :)
Compared to babel, big team, smart guys, using standards.... Sure