Comment by bastawhiz | Hacker News Reader

Comment by bastawhiz | Hacker News Reader

Parent Full thread

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.

You speak of Bublé as though it goes unused. It still gets plenty of use, not least because of how much faster it is than Babel, but also because of its focus on cheapness of its transformations at runtime—Babel focuses on being as close to correct as possible, but at quite a substantial runtime cost in code size and speed. (I understand Babel also has loose transformations, https://babeljs.io/docs/en/babel-preset-env#loose, that are like Bublé’s, but I have never compared the two; they definitely feel like they’re a second-class citizen in Babel.) The less-different code is also great for when you inevitably need to read the generated code without source maps, too, since it is made up of simple AST-guided source transformations rather than total rewrites of features.

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.

I’d be interested to see a hybrid approach that focused on loose transformations and used the faster AST-guided source transformation approach where feasible, and localised full AST rewrites where not feasible. In JavaScript the performance difference between a full AST rewrite (Babel) and AST-guided source transformation (Bublé) is stark; my feeling is that it will be less distinct, but still substantial, in Rust.

One of the cornerstones of TypeScript is that types do not not alter the semantics of the underlying JavaScript. You can compile TypeScript by just ignoring all the types and dealing with only the minimal syntax which it adds to ES6/7.

TypeScript does add features like enums and decorators, though, which are not present in the underlying JavaScript.

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

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.

I suppose I could, but then I'm running my tests twice (once against the actual compiler and once against swc). Compiling my code is necessary to run the tests anyway, so it seems a bit moot to go through the trouble. I could ditch "real" TypeScript compilation altogether, but then you're not building for TS anymore, you're building for the variant of TS that swc supports.

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.

Although it works 99% of the time, I'm not a huge fan of "Just run the tests" style of ... testing. Unit tests are important, but I feel slightly insecure if I don't think about the process mechanically rather than as a black box.

In this case your suggestion is a good one, obviously.

> project is mostly Rust, is the perf improvement simply because of that?

I would think so.

Reply on news.ycombinator.com