Skeptical of rewriting JavaScript tools in "faster" languages

The sentiment of the article is 90% right. In all fairness there are opportunities for making tools faster by writing them in faster languages, but these tend to be extreme scenarios like whether you really need to send 10 million WebSocket messages in the fastest burst possible. Aside from arithmetic operations JavaScript is now as fast as Java and only 2-4x slower than C++ for several years now and it compiles almost instantly.

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.

But build tools in js land are quite slow. Especially when you start throwing behemoths like Nx in the mix.

Look at the performance gains in build tool land (esbuild specifically) and you’ll see the performance gains with native languages.

For most webservers and UIs it’s plenty fast though.

Java is very fast: https://github.com/gunnarmorling/1brc

So... about performance. Performance is the difference between two or more measures. When not compared against something everything is itself fast. Out of a list of 1 item that one item will always be the 100% fastest item in the list. So, what's really important is not whether something is fast, but whether that thing is faster than something else and by how much.

I suspect Java is fast. JavaScript is also fast. They are both fast. Without comparing measures the only significant distinction between the two is the time to compile. In that case Java is slow, or at least just substantially slower than JavaScript.

Fortunately there are comparative benchmarks: The Programming Benchmark Games. It is not always the best, but it is certainly better than naught.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It's maybe 90% right in general, but it's 10% right (90% wrong) for the workload of language processors in particular. Lots of tiny objects are terrible workloads for JavaScript and Python.

Related comments: https://news.ycombinator.com/item?id=35045520

Direct comparison I did between Python and C++ semantics - Oil's Parser is 160x to 200x Faster Than It Was 2 Years Ago - https://www.oilshell.org/blog/2020/01/parser-benchmarks.html

This is the same realistic program in both Python and C++ -- no amount of "optimizing Python" is going to get you C++ speed.

---

FWIW I agree with you about the debates -- many people can't seem to hold 2 ideas in their head at once.

Like that C++ unordered_map is atrociously slow, but C++ is a great language for writing hash tables.

And that Python was faster than Go for hash table based workloads when Go first came out, but also Python is slow for AST workloads.

Performance is extremely multi-dimensional, and nuanced, but especially with programming languages people often want to summarize/compress that info in inaccurate ways.

Much of esbuild's performance gains are in throwing out a lot of cruft. It definitely benefits from the "fresh rewrite can avoid the cruft of an organic project", including specifically benefiting a lot from ESM as the winning end goal format, and the hindsight of Webpack eventually a massive organic ecosystem of plugins towards a core set of "best practices" over a lot of versions and ecosystem churn.

esbuild versus webpack performance is never a fair fight. Most of the other behemoths are still "just" webpack configurations plus bundles of plugins. It will take a while for the build tools in that model to settle down/slim down.

(esbuild versus Typescript for "Typescript is the only build tool" workflows is a much more interesting fight. esbuild doesn't do type checking only type stripping so it is also not a fair fight, and you really most often want both, but "type strip-only" modes in Typescript are iterating to compete with esbuild in fun ways, so it is also good for the ecosystem to see the fight happening.)

I appreciate esbuild, but I also appreciate esbuild had so much of the benefit of a lot of hindsight and not developing in the open as an ecosystem of plugins like webpack did but rather baking in the known best practices as one core tool.

> Much of esbuild's performance gains are in throwing out a lot of cruft.

I don’t think there’s a great way to be sure of this. Parcel 2 (my personal favorite), for example, doesn’t include, by default, much of the cruft from mid-2010s JavaScript, but esbuild is still faster.

Theoretically, being able to use multiple cores would bring speed improvements to a lot of the tree manipulation tasks involved in building js projects.

> esbuild versus webpack performance is never a fair fight.

Yeah webpack is just the worst. Bloated from day 1

The build on my last large project took about 12 seconds total. That included installing self-signed certificates into the OS trust store, installing certificates into the browsers in Linux, compiling from TypeScript, via SWC, creating a universal command available from the command path, consolidating JS and CSS assets into single files, and some other things. I bet it could be faster, but I was happy with 12 seconds considering the project was quite large.

More than 90% of performance in JavaScript comes down to:

* comfort with events and callbacks

* avoiding string parsing: queryStrings, innerHTML, and so on

* a solid understanding of transmission and messaging. I wrote my own WebSocket library

None of that, except figuring out your own home grown WebSocket engine, is complicated, but it takes some trial and effort to get it right universally