The JavaScript Midlife Crisis

Klonoar

> Rewrite a bundler in Rust and you haven't only made it faster. You've also shrunk the pool of JavaScript developers who can maintain it. The new tool still looks like a duck and quacks like a duck, but it's a different beast altogether. Its internals retreat behind a black box that fewer people hold the keys to. The source may still be open, but the door to contributions is closing. Alternatively, there's a pool of JS developers who shouldn't be maintaining critical infrastructure to begin with. It's not a black box, those codebases are usually open and the only thing holding you or anyone back is learning anything outside of a small pond of JavaScript. Write non-browser-things in fast languages. It is not a complicated concept - even less so in an era where stuff is getting written for you.

sublinear

> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain... Found it.

nzoschke

> Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain... Large parts of the JavaScript application space too. Language consistency, ergonomics, standard library and performance matters, and JS has major warts here. I bet when these languages are 30+ years old like JS is, the software landscape isn't dominated nearly as much by JS. These days I intentionally start all projects with as little JS as possible, opting for Go and HTMX instead. Removing the layers of JS inconsistency and build tools makes my and my agents lives better. More thoughts on my JS-less stack here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

hackersnooze1

tldr: interpreted languages are still slower than compiled languages, surprising no one

tannerr_dev

i enjoyed learning go. not that far from js when i first started learning programming i thought it was super important to pick one language to be really good at and that could do everything but you dont have to pick just one. i honestly think learning it opened my mind to thinking about programming differently and is probably better in the end

cisc

> I start wondering what we're supposed to do with all those precious milliseconds it just handed us back Speed matters. WebAssembly is taking jobs from JavaScript precisely because it's faster. The calculation engine for Google Sheets became twice as fast with the switch to WebAssembly: https://web.dev/case-studies/google-sheets-wasmgc The Amazon Prime Video app became twice as fast with less variability in performance when they switched to WebAssembly: https://www.amazon.science/blog/how-prime-video-updates-its-... Compiling to WebAssembly enables every language to run in the browser. Google used Java and Amazon used Rust.

spankalee

I love JavaScript and TypeScript, but like all interpreted languages, they really do have a hard time fitting into certain environments where you can't get an enormously complicated VM or can't get by with a much slower version of the language. You can argue that high-throughput / low-latency dev tools are one of these environments. I'm not so sure. I think a lot of JS tooling is written in slow JS and gets fast with a rewrite to another language largely because of better structure. Some environments really are tougher though. I started using WebAssembly a lot a year ago and the story for JavaScript and Python is just pretty terrible. And for JS, the things that make it hard to run in Wasm aren't universally good things to have in the language in the first place. The extreme dynamism of JS is something that so much JS tooling tries to limit. But I think a lot of the language is quite good, and that there are possible variants of JS that are great even. I started one I hope will fit that one day ( https://zena-lang.dev ) and the first use cases for me are all tooling to try to make sure it's at least good for that: self-hosted compiler, formatter, regex engine, JSON parser, etc. It's quite a bit like JS/TS, but fixes a lot of things and runs forward with features that will take JS many years to get to, if it ever does (ie, pipelines, pattern matching). I'm hoping that WebAssembly can slowly continue to gain a place on the web so JS can give up its near monopoly there. We'll see!

msteffen

Heterodox argument: a big part of the reason JavaScript has been so successful is that interpreted languages actually can be extremely fast—competitive with, and in many cases, faster than compiled languages, with V8 arguably the fastest interpreter in existence. See this post by Mike Pall, author of LuaJIT (which is comparable to or faster than V8 performance-wise, despite being basically a single-developer project), which explains why: https://web.archive.org/web/20180603053407/http://article.gm... . Basically, it’s much easier to add high-quality runtime-trace-aware recompilation to a JIT interpreter, which a non-trace-aware compiled language will often not be able to beat.

Kuyawa

If you need a desktop app go with rust, zig or swift depending on your platform If you need a web app for CRUD, avoid frameworks, typescript, tailwind, nothing, just bare-naked node/html/css/js If you need games in the browser or stuff where every byte needs optimization go with WASM A programmer's life has become simpler

hn_submit

JavaScript is an abomination that never should've been left alive. And yes, I ask myself the question: "Who in his right mind would run JavaScript on the server and even write business logic in it?" Lots of idiots in this world it seems. JavaScript is the reason our text editors need 16GB of RAM to run these days and a simple weather app 1GB. In the ol' days assembly programmers probably could've written the weather app in a couple of KB (that's a MILLION times less memory people).

suplexer

To all reasonable software developers out there, please don't listen to the prevailing groupthink. Javascript (the language) has many semantic problems but speed (from the VM) is one of it's best features! Like, you have to be writing some questionable code in very questionable styles/dialects to have a 10x (or more!) slowdown vs native. Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them. It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true. In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust: https://zaplib.com/docs/blog_post_mortem.html This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.

jan_m_savage

i don't mean to be a snark, but honestly I can't get the point of the long essay. What's the main idea?

hexasquid

I'm interested to know why tsc (pre-go) would give me near-instant LSP diagnostics on a large typescript project, and rust-analyzer takes ages to produce diagnostics in a small rust project.

agentultra

You can wait for slow programs that use a ton of excess memory, sure. Or, you can have fast programs that use memory efficiently. You just can’t do it in JavaScript. You can get really performant with JavaScript with careful engineering for sure… but there’s a big wall of diminishing returns even with all of the JIT compilation and tracing garbage collection. Nothing stopping those same JS developers from learning some Zig or Rust or whatever. It might actually be easier to learn than memorizing all of JavaScript’s implicit coercion rules. But if that’s too much to ask then stay in JS land and make sure there are JS devs to write tools for!

prokopton

I've worked with Vue, React, Qwik, and Svelte over the last 10 years. I have never felt the hate that HN spews out over JavaScript.