Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

Post reply on HN
Print view View original

11–20 of 204 posts

Re: PR that converts the TypeScript repo from namespaces to modules

#11

Post by longrod »

ppseafield wrote: post #7
TAForObvReasons wrote: post #5

Earlier quoted context omitted.

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.

Sucrase is faster or really close to SWC (see rhe benchmarks https://github.com/alangpierce/sucrase). Everyone still uses Babel because of the transforms.

And yes, Babel can also be made faster if enough effort is dedicated into it. it's not an impossible feat.

Re: PR that converts the TypeScript repo from namespaces to modules

#13

Post by RyanCavanaugh »

TAForObvReasons wrote: post #5
KingOfCoders wrote: post #3

Quoted 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…

Sucrase is written in JS and boasts the highest line throughput of any competing transpiler

https://github.com/alangpierce/sucrase

            Time            Speed
Sucrase 0.57 seconds 636975 lines per second

swc 1.19 seconds 304526 lines per second

esbuild 1.45 seconds 248692 lines per second

TypeScript 8.98 seconds 40240 lines per second

Babel 9.18 seconds 39366 lines per second

Re: PR that converts the TypeScript repo from namespaces to modules

#14

Post by RyanCavanaugh »

simlevesque wrote: post #12

The headline is pretty misleading. The TypeScript compiler isn't implemented with modules. This is an open pull request which would make it that way.

It's a PR that will be merged within the next week or so, and has been scheduled in the TS roadmap for quite a while. It's happening.

Re: PR that converts the TypeScript repo from namespaces to modules

#15

Post by simlevesque »

RyanCavanaugh wrote: post #14
simlevesque wrote: post #12

The headline is pretty misleading. The TypeScript compiler isn't implemented with modules. This is an open pull request which would make it that way.

It's a PR that will be merged within the next week or so, and has been scheduled in the TS roadmap for quite a while. It's happening.

Hi Ryan, thanks for chiming in ! I just wanted to make it clear that the current HEAD doesn't implement this but maybe I'm just nitpicking.

Re: PR that converts the TypeScript repo from namespaces to modules

#17

Post by simlevesque »

Kyza wrote: post #16
simlevesque wrote: post #12

The headline is pretty misleading. The TypeScript compiler isn't implemented with modules. This is an open pull request which would make it that way.

Oops, I didn't mean to mislead. I updated the title to be more clear.

Thank you

Re: PR that converts the TypeScript repo from namespaces to modules

#18

Post by merb »

RyanCavanaugh wrote: post #13
TAForObvReasons wrote: post #5

Earlier quoted context omitted.

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…

Sucrase is written in JS and boasts the highest line throughput of any competing transpiler https://github.com/alangpierce/sucrase Time Speed Sucrase 0.57 seconds 636975 lines per second swc 1.19 seconds 304526 lines per second esbuild 1.45 seconds 248692 lines per second TypeScript 8.98 seconds 40240 lines per second Babel 9.18 seconds 39366 lines per second

but the benchmark is stupid: https://github.com/alangpierce/sucrase/blob/main/benchmark/b...

> Like all JavaScript code run in V8, Sucrase runs more slowly at first, then gets faster as the just-in-time compiler applies more optimizations. From a rough measurement, Sucrase is about 2x faster after running for 3 seconds than after running for 1 second. swc (written in Rust) and esbuild (written in Go) don't have this effect because they're pre-compiled, so comparing them with Sucrase gets significantly different results depending on how large of a codebase is being tested and whether each compiler is allowed a "warm up" period before the benchmark is run.

(worse it disables esbuild and swc's multi-threading... https://github.com/alangpierce/sucrase/blob/main/benchmark/b... https://github.com/alangpierce/sucrase/blob/main/benchmark/b...)

fake it till ya make it.

it's like saying "if I disable everything and wait for 5 minutes it's faster"

Re: PR that converts the TypeScript repo from namespaces to modules

#19

Post by Analemma_ »

longrod wrote: post #8

Sucrase 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…

Sucrase consciously and deliberately breaks compatibility. Which, to be clear, isn't necessarily a bad thing for some use cases. But you can't really generalize from that to a tool like tsc where this isn't an option. There might be a performance ceiling here that can only be surpassed with a different language.

Re: PR that converts the TypeScript repo from namespaces to modules

#20

Post by ppseafield »

longrod wrote: post #11
ppseafield wrote: post #7

Earlier quoted context omitted.

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.

Sucrase is faster or really close to SWC (see rhe benchmarks https://github.com/alangpierce/sucrase ). Everyone still uses Babel because of the transforms. And yes, Babel can also be made faster if enough effort is dedicated into it. it's not an impossible feat.

For single core benchmarks only, correct?
Post reply on HN