Why I'm skeptical of rewriting JavaScript tools in "faster" languages

It is.

Brilliant engineers have spent decades making it faster than you might expect, subject to many caveats, and after the JIT has had plenty of time to warm up, and if you're careful to write your code in such a way that it doesn't fall off the JITs optimization paths, etc.

Meanwhile, any typical statically typed language with a rudimentary ahead of time compiler will generally be faster than a JS VM will ever approach. And you don't have to wait for the JIT to warm up.

There are a lot of good things about dynamically typed languages, but if you're writing a large program that must startup quickly and where performance is critical, I think the right answer is a sound typed language.

I wonder if the author would feel differently if they spent more time writing in more languages on tooling like this. My life got a lot easier when I stopped trying to write TypeScript everywhere and leveraged other languages for their strengths where it made sense. I really wanted to stick to one language I felt most capable with, but seeing how much easier it could be made me change my mind in an instant.

The desire for stronger duck typing is confusing to me, but to each their own. I find Rust allows me to feel far, far more confident in tooling specifically because of its type system. I love that about it. I wish Go’s was a bit more sane, but there are tons of people who disagree with me.

The "more difficult" in this quote makes me somewhat angry.

`This breaks down if JavaScript library authors are using languages that are different (and more difficult!) than JavaScript.`

JS is absolutely not easy!

It is not class oriented but uses funky prototypes, it has classes slapped on PHP-Style.

Types are bonkers, so someone bolted on TypeScript.

It has a dual wield footgun in the form of null/undefined, a repeat of the billion dollar mistake but twice!

The whole Javascript tooling and ecosystem is a giant mess with no fix in sight (hence all the rewrites).

The whole JavaScript ecosystem is ludicrously complicated with lots of opinions on everything.

Tooling is especially bad because you need a VM to run stuff (so lots of rewrites).

This is why Java never got much traction in that space too.

Go for example is way easier to learn than Javascript.

Here i mean to a level of proficiency which goes beyond making some buttons blink or load a bit of stuff from some database.

Tooling just works. There is no thought to spend on how to format stuff or which tool to use to run things.

And even somewhat difficult (and in my opinion useless) features like classes are a absent.

Want to do concurrency? Just to `go func whatever()`. Want it to communicate across threads? Use a channel it makes stuff go from A -> B.

Try this in JS you have to know concepts like Promises, WebWorkers and a VM which is not really multithreaded to begin with.

I've worked on multiple rewrites of existing systems in both JS and PHP to Go and those projects were usually re-written strictly 1:1 (bugs becoming features and all that). It was pretty typical to see an 8-10x performance improvement by just switching language.

So yes, you can do clever tricks with ArrayBuffers, and the JS VMs will do incredibly clever optimizations for you, but as long as your code is running on one core you cannot be competitive. (Unless your problem is inherently serial, but very few "tool"-type problems are.)

Really though, my entire career has taught me to never ever talk about performance with other developers... especially JavaScript developers or other developers working on the web. Everybody seems to want performance but only within the most narrow confines of their comfort zone, otherwise cowardice is the giant in the room and everything goes off the rails.

The bottom line is that if you want to go faster then you need to step outside your comfort zone, and most developers are hostile to such. For example if you want to drive faster than 20 miles per hour you have to be willing to take some risks. You can easily drive 120 miles per hour, but even the mere mention of increased speed sends most people into anxiety apocalypse chaos.

The reactions about performance from other developers tend to be so absolutely over the top extreme that I switched careers. I just got tired of all the crying from such extremely insecure people who claim to want something when they clearly want something entirely different. You cannot reasonably claim to want to go faster and simultaneously expect an adult to hold your hand the entire way through it.

Is it though? Rust/Zig/Go programs are pretty much all incredibly easy to checkout and compile, it's one of the big selling points of those languages. And at the end of the day how often are javascript developers fixing the tooling they use even when it's written in javascript?

I've always felt learning new languages give me not only new tools to use but shapes the way I think about solving problems.

Exhausting is very exhausting, so at a fraction of that effort you could build on better foundations

Anecdotally I have had to do this in js a few times. I have never had to do this in Rust. Probably because Rust projects are likely to ship with fewer bugs.

Also Rust is harder to pick up but what are you going to do, use the most accessible tool to solve every problem, regardless of its' efficacy? I am not a Rust expert by any means, but just reading the Rust book and doing a couple projects made me a better programmer in my daily driver languages (js and Python).

I think speed is less important here than correctness. Every time you ship a buggy library you are wasting the time of every single end user. The correctness alone probably saves more time in total than any performance gains.

I lost you here. JavaScript doesn't work around type issues, no language really can. It just pushes the type issues to a later time.

I think people often overlook this factor when doing rewrites and making big claims about the results.

Chances are if you’d done the rewrite in the same language you’d get similar results.

I don’t know if it’d be possible to empirically prove that. I’ve only seen it happen a few times.

The very notion of "fast and slow languages" is nonsense. A language is just an interface for a compiler, translator, or interpreter of some sort. A language is only steer wheel and pedals, not the whole car, so the whole arguments which one is faster is stupid.

In our case, AOT compilation backfired. We used (contractually had to) support older architectures and our Eigen built with meager SSE2 support couldn't possibly outrun Numpy built with AVX-512.

So we stopped rewriting. And then Numba (built on the same LLVM as clang) came up. And then not one but several AOT Python compilers. And now JIT compiler is in the standard Python.

In my work, it’s hard to justify using something other than JS/TS — incredible type system, fast, unified code base for server/mobile/web/desktop, world’s biggest package ecosystem for anything you need, biggest hiring pool from being the best known language, etc.

It’s just such a joy to work with, ime. Full-stack JS has been such a superpower for me, especially on smaller teams.

The dissonance between how the silent majority feels about JS (see, e.g the SO yearly survey), vs the animus it receives on platforms like HN is sad. So here’s my attempt at bringing a little positivity and appreciation to the comments haha.

> ...it’s straightforward to modify JavaScript dependencies locally. I’ve often tweaked something in my local node_modules folder when I’m trying to track down a bug or work on a feature in a library I depend on. Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.

I too often find myself inserting `console.log` inside node_modules to figure out why the toolchain doesn't work as I'm expecting it to. It has gotten me out of some very nasty situations when StackOverflow/Google/GPT didn't help at all.

Had it been written in Rust, I wouldn't have had a chance.

I didn't know about this before, I wonder how much overhead?

The reason I am reluctant to rely on JS tools for anything CLI is because of Node.js instability due to version sensitivity and impossible-to-fix-without-reinstalling-the-os low level LibC errors.

Compared to go, rust, or python, the odds that any given CLI.js program will run across my (small) fleet of machines is very low, by factor or 10x or more compared to alternatives. Some boxes I don't want to reinstall from scratch every 4 years, they're not public facing and life is too short.

I’m sure you could get something with similar performance in JS. I’ve messed around with JS daemons, so you don’t care about startup time for programs like tsc and whatnot. The problem is that it’s just a pain in the ass to get any of this to work, whereas ESBuild is just fast.

Maybe these problems with JS will get solved at some point, because we haven’t exhausted all of the possibilities for making JS faster (like the author says). However, when you write the tools in Rust or Go or whatever, you get a fast tool without trying very hard.

You can benefit from 1000x (!) speed ups just rewriting sync Python in sync Rust, in my measured experience, because the compiler helps exponentially more the more abstract your code is, and Rust can absolutely do high level systems.

The main blocker is when you’re missing some library because it doesn’t exist in Rust, but that’s almost always a big opportunity for open source innovation

> Rather than empowering the next generation of web developers to achieve more, we might be training them for a career of learned helplessness. Imagine what it will feel like for the average junior developer to face a segfault rather than a familiar JavaScript Error.

I feel this slightly misses the point. We should be making sure that the next generation of Software Engineers have a solid grounding in programing machines that aren't just google's V8 Javascript Engine, so that they are empowered to do more, and make better software.

We should be pushing people to be more than just Chrome developers.

Also, while I understand what the author is getting at, referring to lower level developers as demigods is a little unhelpful. As someone who switched careers from high-level languages to a C++ engineer, I can attest to the fact that this stuff is learnable if you are willing to put the time and effort in to learning it. It's not magic knowledge. It just takes time to learn.

Webpack has an enormous community of third-party plugins, it would be very hard to do something similar with e.g. Go or Zig.

I work on high-performance stuff as a C++ engineer, currently working on an ultra fast JSON Schema validator. We are benchmarking against AJV (https://ajv.js.org), a project with a TON of VERY crazy optimisations to squeeze out as much performance as possible (REALLY well optimised compared to other JavaScript libraries), and we still get numbers like 200x faster than it with C++.

Rewriting in more performant languages spares you from the pain of optimization. These tools written in Rust are somehow 100× as fast despite not being optimized at all.

JavaScript is so slow that you have to optimize stuff, with Rust (and other performant languages) you don't even need to because performance just doesn't bubble up as a problem at all, letting you focus on building the actual tool.

Yeah, JavaScript is sloppy, but you can always monkey-patch it by modifying tool-controlled files. Great idea. Not.

JS is just not a good language. The JIT and the web of packages made it slightly more usable, but it's still Not Good. There's no real way to do real parallel processing, async/await are hellish to debug, etc.

It's unavoidable in browsers, but we _can_ avoid using it for tools. Look at Python, a native PIP replacement improved build times for HomeAssistant by an order of magnitude: https://developers.home-assistant.io/blog/2024/04/03/build-i...

It's true, it has some really bad parts but you can avoid them.

If I could design the perfect language for myself, it would have the syntax of JavaScript and the portability of JavaScript but it would use Python's strong duck typing approach.

For example, if you install psycopg you'll get a pure Python implementation which is easy to debug and hack. But you can also install psycopg[binary] to obtain a faster, compiled version of the library. https://www.psycopg.org/psycopg3/docs/basic/install.html

I would blame numpy for Python's popularity today. Writing coffee as fast as c or fortran in Python is awesome (and keeps me employed).

I also think there is an element of, "rewrite in rust" is just easy to say, where changing data structures or whatever requires analysis of the problem at hand.

It's not that hard to do the same for a less terrible language. Choose something markedly different, i.e. a low level language like rust, and you will learn a lot in the process. More so because now you can see and understand the programming world from two different vantage points. Plus, it never hurts to understand what's going on on a lower level, without an interpreter and eco-system abstracting things away so much. This can then feed back into your skills and understanding of JS.

>"JavaScript is, in my opinion, a working-class language. It’s very forgiving of types (this is one reason I’m not a huge TypeScript fan)."

Being "forgiving of types" is not a good thing. There's a reason most "type-less" languages have added type hints and the like (Python, Typescript, etc) and it's because the job of a programming language is to make it easier for me to tell the CPU what to do. Not having types is detrimental to that.

You wouldn't conflate Windows development with "C" (and completely discount UNIX along the way) just because of Win32. But that's about how bonkers it is when it comes to JS and people do the same with its relationship to Node—not only was JS not created to serve the Node ecosystem, the prescriptions that NPM and Node programmers insist on often cut against the grain of the language. And that's just when we're focused on convention and haven't even gotten to the outright incompatibilities between Node and the language standard (or Node's proprietary APIs).

node_modules, for example? That has fuck-all to do with ECMA262/JS. Tailwind, Rollup, Prettier, all this other stuff—even the misleadingly named ESLint? Same. You're having a terrible experience because you're interacting with terrible software. It doesn't matter that it's written in JS (or quasi-JS). Rewrite these implementations all in other languages, and the terrible experience will remain.

Besides, anyone who's staking out a position that a language is slow, and that JS is one of them is wrong two ways, and you don't have to listen to or legitimize them.

Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.

As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.

> I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster

and then

> Sometimes I look at truly perf-focused JavaScript, such as the recent improvements to the Chromium DevTools using mind-blowing techniques like using Uint8Arrays as bit vectors, and I feel that we’ve barely scratched the surface.

Bit vectors are trivial?

I think the author is too ignorant about those "faster languages". Sure, maybe you can optimize javascript code, but the space of optimizations is only a small subset of what is possible in those other languages (e.g. control over allocations, struct layout, SIMD, ...)

That said, I don't think the author understands performance when it comes to language details. There are several layers of untapped performance, all which JS makes hard to access - optimal vectorization, multi-threading, memory/cache usage, etc.

On top of that some languages don't have support for SIMD/NEON and parallel libraries or GPU processing libraries - those things can significantly improve performance

It's incredible how I don't need tooling at all, except for a basic IDE integrated language server. No package manager, no transpiler, no linter/formatter, no extensive configuration files. Need to add a dependency? Just copy paste the code you need from a github repo. It's still readable and editable if you need since it's the source code, not some transpiled/minified/optimized mess.

Ever had ESM/CommonJS dependencies conflicting with your tsconfig.json, right when you need to deploy an urgent hotfix? Forget about that madness. It is such a great and simple DX compared to JS.

Edit: Before I'm dismissed, I'll add that my Odin project is becoming as complex as any other JS website I've worked on and it can run in a browser thanks to wasm compilation. So I'm not even comparing apples and oranges.