PR that converts the TypeScript repo from namespaces to modules
1–10 of 204 posts
Re: PR that converts the TypeScript repo from namespaces to modules
#2> TL;DR: The TypeScript compiler is now implemented internally with modules, not namespaces. The compiler is now 10-25% faster. tsc is now 30% faster to start. Our npm package is now 43% smaller. More improvements are in the works.
Re: PR that converts the TypeScript repo from namespaces to modules
#3No post body was provided.
Re: PR that converts the TypeScript repo from namespaces to modules
#4Quoted post unavailable.
thats pretty harsh. I dont even like TypeScript/JavaScript, but these are some pretty good numbers:
> The compiler is now 10-25% faster. `tsc` is now 30% faster to start. Our npm package is now 43% smaller. More improvements are in the works.
Re: PR that converts the TypeScript repo from namespaces to modules
#5Quoted post unavailable.
In every single one of these cases, it begs the question whether "JS" is the problem or "backwards compatibility". There are a huge number of inefficiencies that can be fixed with a full rewrite.
There was a recent conversation over ViteJS (a pure JS bundler) vs rust-based tooling, and when you dig into the numbers the real difference is SWC vs Babel. It raises the question whether a new transpiler written in JS can be competitive with Rust, but it's unclear if anyone tried.
Re: PR that converts the TypeScript repo from namespaces to modules
#6Quoted post unavailable.
I think tooling of one programming language should be written in the programming language. Otherwise the community will hardly be involved.
All these rust tools may be slight faster, but typescript developers will not learn rust to improve the typescript compiler.
Re: PR that converts the TypeScript repo from namespaces to modules
#7Quoted post unavailable.
In every single one of these cases, it begs the question whether "JS" is the problem or "backwards compatibility". There are a huge number of inefficiencies that can be fixed with a full rewrite. There was a recent conversation over ViteJS (a pure JS bundler) vs rust-based tooling, and when you dig into the numbers the real difference is SWC vs Babel. It raises the question whether a new transpiler written in JS can…
SWC is written in rust, and Babel is written in javascript, so you've proven the OP's point. Vite can be configured to use SWC.
The recent conversation was about Vercel benchmarking a tuned Turbopack+SWC vs. a default Vite+Babel, not really an apples to apples comparison. When Vite is configured to use SWC as a compiler, Vite's HMR gets faster; but it's not the default for compatibility reasons.
Re: PR that converts the TypeScript repo from namespaces to modules
#8Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this.
Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as it is being spent to rewrite it in Rust, I have no doubt that it can become faster. Perhaps it'll require some big changes but it won't create compatibility concerns and it won't be a cat-and-mouse race between the Rust version and the TS version.
I don't think "Write it in Rust" is always the solution to fast programs. Rust itself can be pretty damn slow if you don't keep performance in mind. That is why you have to optimize and profile and optimize over and over again. Can't the same be done for TSC?
I think the biggest reason devs don't do this is because no one likes profiling and optimizing since it is a slow and boring task. Rewriting is so exciting! It's the thing you do when you are tired of maintaining the old codebase. So just ditch it and rewrite it in Rust.
I have nothing against Rust, mind you. I love what it has done but I don't think rewriting everything is either feasible or even the solution. And waiting for that to happen for every slow tool out there is utter foolishness.
Re: PR that converts the TypeScript repo from namespaces to modules
#9Quoted post unavailable.
I think a performance improvement in anything existing is great. Especially for something as big as TSC. It has such a large amount of usage that many people will appreciate. While it would be great to have it reimplemented effectively in something inherently faster, not improving what we have while it's clearly still the best option wouldn't be helpful.
Re: PR that converts the TypeScript repo from namespaces to modules
#10Quoted post unavailable.
I think tooling of one programming language should be written in the programming language. Otherwise the community will hardly be involved. All these rust tools may be slight faster, but typescript developers will not learn rust to improve the typescript compiler.
What's the conversion rate on that though?
For smaller languages that are much less supported that makes much more sense.
For bigger languages we treat it much more as a black box.