[HN Gopher] The Performance Revolution in JavaScript Tooling
___________________________________________________________________
The Performance Revolution in JavaScript Tooling
Author : PaulHoule
Score : 58 points
Date : 2026-01-03 21:18 UTC (7 days ago)
(HTM) web link (blog.appsignal.com)
(TXT) w3m dump (blog.appsignal.com)
| pyridines wrote:
| 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.
| Blackarea wrote:
| 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?
| srdjanr wrote:
| What else should you use for huge complex web apps?
| vrighter wrote:
| maybe, just maybe, the browser is not always the best tool
| for the job
| DecoySalamander wrote:
| I think that there are more apps that are better off as
| web apps (cross platform and sandboxed) than not.
| FridgeSeal wrote:
| But I hired the whole react dev, so I'll use the whole
| react dev!
|
| /s
| Blackarea wrote:
| <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!
| _heimdall wrote:
| 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.
| Zardoz84 wrote:
| 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.
| guessmyname wrote:
| > _[...] 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.
| Zardoz84 wrote:
| 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.
| drcongo wrote:
| 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.
| bovermyer wrote:
| I'm going to guess that you haven't played with any of these
| newer tools.
| IronBacon wrote:
| 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...
| ansgri wrote:
| 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).
| h33t-l4x0r wrote:
| I was expecting to read about Bun and Zed...
| jeswin wrote:
| 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.
| intothemild wrote:
| 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.
| meekins wrote:
| 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.
| wolfi1 wrote:
| I guess it's because of the already available packages
| jeswin wrote:
| 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...
| girvo wrote:
| Typescript is an excellent language, though. I don't blame
| people for wanting to hang on to it.
| ku1ik wrote:
| 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.
| KempyKolibri wrote:
| Triggered mine too, especially "Modern JavaScript applications
| aren't just a few scripts anymore -- they're sprawling
| codebases"
| vinnymac wrote:
| Especially because they mention unmaintained software (volta)
| in the same breadth as maintained software (fnm/mise)
| llmslave3 wrote:
| 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 :)
| wonnage wrote:
| 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
| MORPHOICES wrote:
| 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?
| owebmaster wrote:
| > 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
| zoom6628 wrote:
| 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.
| embedding-shape wrote:
| > 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 :)
| mirekrusin wrote:
| 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.
| DanRosenwasser wrote:
| 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...)
| epolanski wrote:
| 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).
| Klaster_1 wrote:
| 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!
| solumunus wrote:
| Any idea how close TS7 is?
| loevborg wrote:
| 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
| girvo wrote:
| 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
| m00dy wrote:
| >>That's where languages like Rust and Go come in. They offer
| native performance,
|
| I'm not sure Go can offer native performance.
| guessmyname wrote:
| _"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.
| nosianu wrote:
| > _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.
| lock1 wrote:
| 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.
| m00dy wrote:
| I think the author puts Rust and Go in the same basket, and
| it is something that I can't agree.
| a-v-berezkin wrote:
| A fair notice. In terms of performance, Go is similar to Java.
| Sth between scripting and native.
| epolanski wrote:
| OT doesn't this really feel AI authored?
| bovermyer wrote:
| 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?
| magnio wrote:
| 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.
| braebo wrote:
| Bun is great with Sveltekit
| 9dev wrote:
| 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
| butz wrote:
| I'm still waiting for JavaScript tooling revolution where
| node_modules dependencies become smaller or disappear at all.
| Devasta wrote:
| 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.
| _pdp_ wrote:
| 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.
| _the_inflator wrote:
| 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.
| TheAlexLichter wrote:
| Mentioning SWC and ESBuild but missing Rolldown
| (https://rolldown.rs/) here seems like a miss.
| abejfehr wrote:
| Or Rspack (https://rspack.rs/) which is intended to be a drop-
| in Webpack replacement
___________________________________________________________________
(page generated 2026-01-10 23:01 UTC)