I guess since this at the top of HN, I'll just plug that we (the TypeScript team) are looking for broader feedback of the native previews before our stable release, whether that's:
We're using it pretty extensively at my team in the huge front-end monorepo the company we work for has via the extension, just purely for better IDE perf. It's been excellent so far, though it does still choke on the sheer scale of said monorepo sometimes
We've been using tsgo for a few months in our team and it just works (10x faster). We bumped into some small differences in behavior with tsc but it was always because we were doing something weird in our code, and it was easy to fix.
Mad props to the team, it's an amazing achievement
We're using tsgo only on the command line btw, we're not using the vscode plugin yet
Can you post links to where exactly one should provide feedback for each release?
We have several extremely heavy projects (mostly in the functional programming/effect space where you easily get union explosion) that make working even on an M3 max with 8gb per process limit impossible and we get OOM fast (besides compilation times).
I cannot understand the idea of using JavaScript that compiles into "native code".
At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
You want something that can compile into a binary with multiple architectures, multithreading, types, etc? Please use a different language that's built from the ground up to achieve that.
You want something that was designed to add some sugar onto a website? Then yes JavaScript is probably best there.
Not everything needs to be written in this one language that's not designed for it. Just because you can, doesn't mean you should.
Actually TypeScript is an excellent language (in my view) for targeting native code. It reads cleaner than Java, C# and even golang in many cases - at least to me.
For example, JS/TS's file-path based imports are more intuitive; several languages do it via explicit namespaces when well-written code is already organized into directories. Of course, all of these design choices are subjective. In fact, disagreement with a few people in the C# user community is one of the reasons I started this project.
Another example - top level functions, being able to export them trivially etc.
> At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
The comment was especially about TypeScript. Unlike the ancient JavaScript versions best used for web sugar you're possibly thinking of, it's a highly pragmatic and well designed general purpose programming language with an unique and very powerful type system.
> Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases with thousands of dependencies, complex module graphs, and extensive build pipelines.
This has been true for at least a decade.
The very next paragraph:
> JavaScript-based tools that were once "good enough" now struggle to keep up, leading to sluggish build times, laggy editor experiences, and frustratingly slow feedback loops.
The tools really weren't "good enough", even back then, by these metrics. JavaScript tooling has been slow and bloated on large codebases for just as long.
Keep the huge, complex business logic on the server whenever possible.
That doesn't work for webapps that are effectively entirely based on client side reactivity like Figma, though the list of projects that need to work like that is extremely low. Even for those style of apps I do wonder how far something like Phoenix LiveView might go towards the end goal.
On a related note (but with Python), I recently tried uv instead of pip and was impressed by both its speed and dependency resolution. I was attempting to upgrade an internal project from Python 3.9, and pip was frustratingly slow, sometimes it would just get stuck with no output and no errors...
There’s growing consensus that with uv python tooling finally became good enough in terms of both speed and functionality, no need to choose one or the other (like, poetry had functionality but was extra slow).
I have noticed a trend with newer JS tooling beyond performance. Indeed, builds are quicker. The cold starts decrease. That’s great. ~
However, the feedback duration is the actual behavior modifier.
My perception map.
Speed test, compilation time benchmarks.
Loop tightness refers to how fast you notice a mistake.
Cognitive load refers to the amount of context you maintain in memory while waiting.
Most developers don't make use of max throughput. They strive to avoid distractions. Tools that are written in faster languages matter mainly because they shrink the gap between action and signal.
Some "quick" weapons stick, that is why. Problems of today often relate to mystery, not slowness.
The rule I abide by now is that if a tool feels calming while debugging, it wins.
Inquisitive.
What tools have made an impact on your daily workflow?
When has hype about performance not translated into adoption?
I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go).
Speaking of Go, Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go, with hot reloading etc. Full control over your build process, plugins are compiled with the builder so you don't pay the JS -> Go cost, it's really great stuff. I love Esbuild, thank you Evan :)
I think it's mainly that JS has a terrible developer experience when it comes to parallelism and shared data, which these other languages don't need to worry about. Most build tools are pretty amenable to being parallelized but with JS you end up either being constrained to process-level parallelism (e.g split the filesystem into chunks and just run the program multiple times) or you have a bunch of inefficient message passing between processes. Even worker threads are unable to share memory except through the weird and awkward-to-use SharedArrayBuffer and Atomics APIs.
On top of this, a lot of JS tools have crazy plugin systems that let you hook into performance-sensitive places and run arbitrary code. This is slow and also makes parallelism tricky. For example, babel plugins can make arbitrary changes to the AST. Ordering them is already kinda tricky; many plugins just give up and run their entire logic as a callback against the root AST node. The fact that swc, esbuild, etc. come batteries-included with transforms for module syntax, Typescript, etc. actually helps with performance; you can leverage assumptions about these fixed sets of transforms to run them all at once and avoid multiple passes over the entire AST.
So rewriting in a language with better ergonomics and being able to ditch some excessive flexibility is what gets you the massive speedup, it's not just magical Rust dust
Vite is currently working on a rollup rewrite in Rust, called rolldown[1], that will provide dramatic speed improvements. It’s a drop-in replacement for the most part, and slashed our built times down to 12%.
You can replace eslint and prettier with Biome or Oxlint + Oxfmt. Vite and Node.js are still the modern safe choices, though if you actually want to play with new things you can replace Node.js with bun.
The upside is huge. The only downside that I can see is that the tools become less hackable. You cannot simply patch ts or eslint via pnpm if you want to. Now you need to build your own version.
Is it just me or this article has been written or at least heavily processed with LLM? My AI slop radar triggered immediately (overly verbose, fluff, bland). Don’t get me wrong, it has valuable information but that style smells LLM from a distance.
Reality bites. JS devs have tried to use JS for everything and found limits. It isn't a one language to rule the all. Welcome back to the world of needing the right tools for the job.
Don't underestimate prototyping nature of js that allowed for exporing design space at higher speed throughout the years.
Reminds me when I was working on distributed filesystem at LiveDrive more than 10 years ago, wrote working prototype and few iterations in Ruby before rewriting it in C - somebody said "(you did it) because Ruby was slow/crap?", I said "no, because Ruby was essential (to do it quick)".
Also interop with those tools (though wasm) is relatively new.
Js/ts ecosystem is actually quite nice now with this option to use wasm for performance - while still keeping "works on the server and in the browser" intact.
> JS devs have tried to use JS for everything and found limits
Yeah, seems NodeJS kind of made some people into JS-zealots, while us web developers have thought of separation of concerns from the beginning, hence the holy trinity of HTML, JS and CSS. Glad others are catching up with web developers for once :)
“Native performance” in this context means compared to scripting languages, not low-level languages like C. Of course, Go offers native performance relative to JavaScript. Your comment seems to assume the author was comparing Go to more systems-level languages like Rust or C. In those cases, Go may lag behind, but it still qualifies as native performance.
The "script" is compiled all the way down to machine code by the runtime, for heavily used paths. The black/white distinction of "scripted" vs. "compiled" does not exist, has not for many years.
Too many of these discussions and arguments seem to be stuck in the 1990s technology level. It is much more mixed and complex now.
"Script" PLs tend to be interpreted, dynamic, and handwave various machine-level details. In contrast, "compiled" PLs usually provide you the constructs to manipulate native machine-level features directly.
Realistically, communities around "script" languages aren't going to talk much about memory layout or syscall. Instead, getting the job done fast (devtime-wise) is their main focus.
On the other hand, "compiled" languages tend to draw people who like squeezing every bit of computing power from their computer, even though it tends to raise the complexity.
For tools devs use, performance is important, so we will do anything and everything we can to squeeze out those few extra seconds of delay, they all add up.
For tools users use, developer experience is important, so they get whatever React and Electron slop we hurl over the fence.
So? Are we all supposed to be using your machine? Performance can vary a lot depending on system, filesystem, and workflow. Something feeling “instantaneous” for you doesn’t mean it isn’t sluggish for others, especially when tasks like compiling TypeScript are done frequently, where even small delays add up over time.
nvm it's a bash script they only installs node using curl and sets paths and links. I don't yet find where it is sluggish.
What I recognise as problematic it's the support for Windows if you are using WSL, and because of this, I'm thinking of giving a try to mise. I work on a pure Linux dev box, but my team mates work on Windows 11 (some people are masochistic...) and this would help when they need to mess with the frontend code.
I can't recommend mise highly enough, it's so good at all of the things it does that within about a week of trying it out I started using it everywhere. A year later and I'm finding it absolutely indispensable.
I guess since this at the top of HN, I'll just plug that we (the TypeScript team) are looking for broader feedback of the native previews before our stable release, whether that's:
- through builds (https://www.npmjs.com/package/@typescript/native-preview), or
- through the editor extension (https://marketplace.visualstudio.com/items?itemName=TypeScri...)
We're using it pretty extensively at my team in the huge front-end monorepo the company we work for has via the extension, just purely for better IDE perf. It's been excellent so far, though it does still choke on the sheer scale of said monorepo sometimes
We've been using tsgo for a few months in our team and it just works (10x faster). We bumped into some small differences in behavior with tsc but it was always because we were doing something weird in our code, and it was easy to fix.
Mad props to the team, it's an amazing achievement
We're using tsgo only on the command line btw, we're not using the vscode plugin yet
Can you post links to where exactly one should provide feedback for each release?
We have several extremely heavy projects (mostly in the functional programming/effect space where you easily get union explosion) that make working even on an M3 max with 8gb per process limit impossible and we get OOM fast (besides compilation times).
Been using experimental tsgo in VSCode for several weeks and it's night and day, can't wait enough for TS7 to ship everywhere. Awesome job, guys!
Any idea how close TS7 is?
Yes performance is a big issue, and so is security (or the lack of it). I'm attacking this from another angle: https://github.com/tsoniclang/tsonic
Write TypeScript, compile to native code via CLR's NativeAOT. We're almost there, you can see some examples here: https://github.com/tsoniclang/proof-is-in-the-pudding
You get everything; real multithreading, stack allocated types, single binary output (x64, ARM64 for Linux/MacOS) etc.
I cannot understand the idea of using JavaScript that compiles into "native code".
At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
You want something that can compile into a binary with multiple architectures, multithreading, types, etc? Please use a different language that's built from the ground up to achieve that.
You want something that was designed to add some sugar onto a website? Then yes JavaScript is probably best there.
Not everything needs to be written in this one language that's not designed for it. Just because you can, doesn't mean you should.
Actually TypeScript is an excellent language (in my view) for targeting native code. It reads cleaner than Java, C# and even golang in many cases - at least to me.
For example, JS/TS's file-path based imports are more intuitive; several languages do it via explicit namespaces when well-written code is already organized into directories. Of course, all of these design choices are subjective. In fact, disagreement with a few people in the C# user community is one of the reasons I started this project.
Another example - top level functions, being able to export them trivially etc.
> At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.
I'd like to know what makes TS convoluted. Here's an example of multi-threading: https://github.com/tsoniclang/proof-is-in-the-pudding/blob/m...
The comment was especially about TypeScript. Unlike the ancient JavaScript versions best used for web sugar you're possibly thinking of, it's a highly pragmatic and well designed general purpose programming language with an unique and very powerful type system.
I guess it's because of the already available packages
Typescript is an excellent language, though. I don't blame people for wanting to hang on to it.
Some nitpicking.
> Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases with thousands of dependencies, complex module graphs, and extensive build pipelines.
This has been true for at least a decade.
The very next paragraph:
> JavaScript-based tools that were once "good enough" now struggle to keep up, leading to sluggish build times, laggy editor experiences, and frustratingly slow feedback loops.
The tools really weren't "good enough", even back then, by these metrics. JavaScript tooling has been slow and bloated on large codebases for just as long.
Just as the modern Javascript applications. What if - and hear me out on this one - Javascript just is a poor choice for huge complex codebases?
What else should you use for huge complex web apps?
Keep the huge, complex business logic on the server whenever possible.
That doesn't work for webapps that are effectively entirely based on client side reactivity like Figma, though the list of projects that need to work like that is extremely low. Even for those style of apps I do wonder how far something like Phoenix LiveView might go towards the end goal.
maybe, just maybe, the browser is not always the best tool for the job
I think that there are more apps that are better off as web apps (cross platform and sandboxed) than not.
But I hired the whole react dev, so I’ll use the whole react dev!
/s
<3 if I don't see 15 new node modules and 3 CVEs by EOB today I'll replace you with a css architect and vibe-coding nft monkey by next week!
On a related note (but with Python), I recently tried uv instead of pip and was impressed by both its speed and dependency resolution. I was attempting to upgrade an internal project from Python 3.9, and pip was frustratingly slow, sometimes it would just get stuck with no output and no errors...
There’s growing consensus that with uv python tooling finally became good enough in terms of both speed and functionality, no need to choose one or the other (like, poetry had functionality but was extra slow).
I have noticed a trend with newer JS tooling beyond performance. Indeed, builds are quicker. The cold starts decrease. That’s great. ~
However, the feedback duration is the actual behavior modifier.
My perception map.
Speed test, compilation time benchmarks.
Loop tightness refers to how fast you notice a mistake.
Cognitive load refers to the amount of context you maintain in memory while waiting.
Most developers don't make use of max throughput. They strive to avoid distractions. Tools that are written in faster languages matter mainly because they shrink the gap between action and signal.
Some "quick" weapons stick, that is why. Problems of today often relate to mystery, not slowness.
The rule I abide by now is that if a tool feels calming while debugging, it wins.
Inquisitive.
What tools have made an impact on your daily workflow?
When has hype about performance not translated into adoption?
What is the next bottleneck after speed?
> What is the next bottleneck after speed?
Movable parts / dependencies
LLMs can get you just the functions you need in place of a whole package with 200 dependencies
I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go).
Speaking of Go, Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go, with hot reloading etc. Full control over your build process, plugins are compiled with the builder so you don't pay the JS -> Go cost, it's really great stuff. I love Esbuild, thank you Evan :)
I think it's mainly that JS has a terrible developer experience when it comes to parallelism and shared data, which these other languages don't need to worry about. Most build tools are pretty amenable to being parallelized but with JS you end up either being constrained to process-level parallelism (e.g split the filesystem into chunks and just run the program multiple times) or you have a bunch of inefficient message passing between processes. Even worker threads are unable to share memory except through the weird and awkward-to-use SharedArrayBuffer and Atomics APIs.
On top of this, a lot of JS tools have crazy plugin systems that let you hook into performance-sensitive places and run arbitrary code. This is slow and also makes parallelism tricky. For example, babel plugins can make arbitrary changes to the AST. Ordering them is already kinda tricky; many plugins just give up and run their entire logic as a callback against the root AST node. The fact that swc, esbuild, etc. come batteries-included with transforms for module syntax, Typescript, etc. actually helps with performance; you can leverage assumptions about these fixed sets of transforms to run them all at once and avoid multiple passes over the entire AST.
So rewriting in a language with better ergonomics and being able to ditch some excessive flexibility is what gets you the massive speedup, it's not just magical Rust dust
I have a "forever project" written in TS and Svelte that uses vite, eslint, prettier, and Node.js. I love playing with new things.
What would be the fastest new combo? TS+Svelte+deno? Is there something that replaces vite?
Vite is currently working on a rollup rewrite in Rust, called rolldown[1], that will provide dramatic speed improvements. It’s a drop-in replacement for the most part, and slashed our built times down to 12%.
[1] https://vite.dev/guide/rolldown
You can replace eslint and prettier with Biome or Oxlint + Oxfmt. Vite and Node.js are still the modern safe choices, though if you actually want to play with new things you can replace Node.js with bun.
Bun is great with Sveltekit
Mentioning SWC and ESBuild but missing Rolldown (https://rolldown.rs/) here seems like a miss.
Or Rspack (https://rspack.rs/) which is intended to be a drop-in Webpack replacement
I consider JavaScript in this regard extremely similar to Python.
Python is a beautiful beast and its main language is C if you want.
JavaScript has a coming of age. It is not a language anymore but a universal tool to build mainly web apps.
I rarely see any JavaScript die hard fans anymore, we are talking about JAVA like variations like the predominant TypeScript.
And production critical apps need professional treatment and so it goes.
The upside is huge. The only downside that I can see is that the tools become less hackable. You cannot simply patch ts or eslint via pnpm if you want to. Now you need to build your own version.
So yah, no free lunch.
Is it just me or this article has been written or at least heavily processed with LLM? My AI slop radar triggered immediately (overly verbose, fluff, bland). Don’t get me wrong, it has valuable information but that style smells LLM from a distance.
Especially because they mention unmaintained software (volta) in the same breadth as maintained software (fnm/mise)
Triggered mine too, especially “Modern JavaScript applications aren't just a few scripts anymore — they're sprawling codebases”
Reality bites. JS devs have tried to use JS for everything and found limits. It isn't a one language to rule the all. Welcome back to the world of needing the right tools for the job.
Don't underestimate prototyping nature of js that allowed for exporing design space at higher speed throughout the years.
Reminds me when I was working on distributed filesystem at LiveDrive more than 10 years ago, wrote working prototype and few iterations in Ruby before rewriting it in C - somebody said "(you did it) because Ruby was slow/crap?", I said "no, because Ruby was essential (to do it quick)".
Also interop with those tools (though wasm) is relatively new.
Js/ts ecosystem is actually quite nice now with this option to use wasm for performance - while still keeping "works on the server and in the browser" intact.
> JS devs have tried to use JS for everything and found limits
Yeah, seems NodeJS kind of made some people into JS-zealots, while us web developers have thought of separation of concerns from the beginning, hence the holy trinity of HTML, JS and CSS. Glad others are catching up with web developers for once :)
I'm still waiting for JavaScript tooling revolution where node_modules dependencies become smaller or disappear at all.
OT doesn't this really feel AI authored?
I was expecting to read about Bun and Zed...
>>That's where languages like Rust and Go come in. They offer native performance,
I'm not sure Go can offer native performance.
“Native performance” in this context means compared to scripting languages, not low-level languages like C. Of course, Go offers native performance relative to JavaScript. Your comment seems to assume the author was comparing Go to more systems-level languages like Rust or C. In those cases, Go may lag behind, but it still qualifies as native performance.
> scripting languages
The "script" is compiled all the way down to machine code by the runtime, for heavily used paths. The black/white distinction of "scripted" vs. "compiled" does not exist, has not for many years.
Too many of these discussions and arguments seem to be stuck in the 1990s technology level. It is much more mixed and complex now.
It's still a useful distinction IMO.
"Script" PLs tend to be interpreted, dynamic, and handwave various machine-level details. In contrast, "compiled" PLs usually provide you the constructs to manipulate native machine-level features directly.
Realistically, communities around "script" languages aren't going to talk much about memory layout or syscall. Instead, getting the job done fast (devtime-wise) is their main focus.
On the other hand, "compiled" languages tend to draw people who like squeezing every bit of computing power from their computer, even though it tends to raise the complexity.
I think the author puts Rust and Go in the same basket, and it is something that I can't agree.
A fair notice. In terms of performance, Go is similar to Java. Sth between scripting and native.
For tools devs use, performance is important, so we will do anything and everything we can to squeeze out those few extra seconds of delay, they all add up.
For tools users use, developer experience is important, so they get whatever React and Electron slop we hurl over the fence.
Tale as old as the web.
NVM sluggish ?
WTF! it's instantaneous on my system. I think that could be called "slow" if you are continuously installing different versions of node.
I'm going to guess that you haven't played with any of these newer tools.
> […] it's instantaneous on my system […]
So? Are we all supposed to be using your machine? Performance can vary a lot depending on system, filesystem, and workflow. Something feeling “instantaneous” for you doesn’t mean it isn’t sluggish for others, especially when tasks like compiling TypeScript are done frequently, where even small delays add up over time.
nvm it's a bash script they only installs node using curl and sets paths and links. I don't yet find where it is sluggish.
What I recognise as problematic it's the support for Windows if you are using WSL, and because of this, I'm thinking of giving a try to mise. I work on a pure Linux dev box, but my team mates work on Windows 11 (some people are masochistic...) and this would help when they need to mess with the frontend code.
I can't recommend mise highly enough, it's so good at all of the things it does that within about a week of trying it out I started using it everywhere. A year later and I'm finding it absolutely indispensable.