I suppose the parent means that people will interpret it as the resulting code running 10x faster. Which is not a totally reasonable way of reading it.
you're faulting a headline for being precise and accurate. there is no sense in which TypeScript is a runtime. TypeScript is literally a complier (targeting JavaScript, which has runtimes) and nothing more and has always been as such.
I’m imagining a really, really, really rough ride for this. I don’t mean the compiler, tsc CLI, or VS support. I know the TypeScript team will have already competently done their side of the story.
I think that as usual, it’s going to be the hellscape ecosystem of Node that is going to be a complete pain here for devs just wanting to use TypeScript.
Somehow, the vast myriad of tools and their dependencies, find a way to make writing TS/JS worse while trying to make it better.
You’d expect a simple package change to be straightforward, but after ten years of dealing with web tooling ranging from before the webpack era to now, I am constantly amazed by the new ways these tools manage to fuck everything up.
I imagine for Deno the change to the new compiler will be seamless and not even noticeable.
It basically depends how deep the other tooling is sticking its claws into TS internals which won’t be accessible in the same way anymore.
I’ll bet the two most painless improvements will be:
- tsc just for type checking. (A lot of places run tsc just as a type checking step, and avoid type checking during the full build.)
- TS language server. By far the worst part of TS for large repos today — in my main monorepo, it consumes like 10GB of RAM and actions like “jump to definition” become so slow that it’s unusable.
Things that may be painful:
- Integration with 3rd party compilers like webpack which use TSC. Also unsure how tools like Rspack will need to consume tsc, given that they use a highly parallel rust architecture already.
- Integration with tools like Jest which need to transpile code before running TS.
- Integration with running Node directly — eg swchook or ts-node for bin scripts
13 comments
[ 4.6 ms ] story [ 45.2 ms ] threadI think that as usual, it’s going to be the hellscape ecosystem of Node that is going to be a complete pain here for devs just wanting to use TypeScript.
Somehow, the vast myriad of tools and their dependencies, find a way to make writing TS/JS worse while trying to make it better.
You’d expect a simple package change to be straightforward, but after ten years of dealing with web tooling ranging from before the webpack era to now, I am constantly amazed by the new ways these tools manage to fuck everything up.
I imagine for Deno the change to the new compiler will be seamless and not even noticeable.
I’ll bet the two most painless improvements will be:
- tsc just for type checking. (A lot of places run tsc just as a type checking step, and avoid type checking during the full build.)
- TS language server. By far the worst part of TS for large repos today — in my main monorepo, it consumes like 10GB of RAM and actions like “jump to definition” become so slow that it’s unusable.
Things that may be painful:
- Integration with 3rd party compilers like webpack which use TSC. Also unsure how tools like Rspack will need to consume tsc, given that they use a highly parallel rust architecture already.
- Integration with tools like Jest which need to transpile code before running TS.
- Integration with running Node directly — eg swchook or ts-node for bin scripts