Absolutely agree. If a JS developer doesn't know Rust, Go, Zig, or something, then they probably aren't going to do a good job at maintaining critical infrastructure, even if it were written in JS.

Why are people writing "critical" infrastructure in JS anyway, it is the wrong tool for the job.

When did the love of learning disappear from this field? I remember when everyone i talked to was learning something new just to better themselves?

Or just write faster JS using it's lower-level language features. Nothing about whatever collection of build tools the JS ecosystem uses "requires" rust/zig/c++/go for performance. It's a closed text transform problem.

The native languages are easier to get decent performance for sure but, braking the entire ecosystem and a generation of future contributors, for what should realistically be single or low double digit percent gains is not worth it.

I think there's a huge spectrum between "pokes around in source code occasionally" and "maintains critical infrastructure." Learning to read and understand the open source software that powers a lot of the toolchain is a big part of the development of a lot of engineers, and said toolchain mostly not being written in a language you're familiar with is a barrier to that (not an insurmountable barrier, but still a barrier, to be clear).

I agree with you that the juice is worth the squeeze here, but I don't think it's right to pretend that there's absolutely zero cost in terms of the learning pathway for the next generation of open source contributors and maintainers.

I had to laugh about the Tiger Beetle history when hearing about it on one of my podcast feeds.

Although it is now famously one of the Zig written production deployments, the founders thought JavaScript would be a great option to write a database server, like really?!?

1) Google Sheets use case

Long story short they are comparing the performance of server-side Java to client-side JS (Java transpiled through GWT/J2CL). So something like: Java -> Hotspot -> native vs Java -> GWT/J2CL -> JS -> V8 (in Chrome) -> native

Apples to oranges.

They then used J2CL (I presume, not clear from the article) to port Java to Wasm and eventually got around 66% of the server-side Java performance. The Wasm performance story also was nowhere near straightforward - hence the immense efforts spent on optimizing WasmGC and validating the transpiler output.

The root of the problem is likely the GWT/J2CL transpiler output. There shouldn't be that much of a peformance drop off between to high-level languages if you're transpiling with speed in mind. I bet there are probably lots of expense runtime checks in the generated output, among others things.

2) Amazon Prime Video use case

Blog seems mostly fine on the surface. But my complaints are always the claims about the limits of performance one could get from a JS-based system - especially in environments where you can call out into native audio/visual libraries.

"In those experiments, code written in Rust and compiled to Wasm was 10 to 25 times as fast as JavaScript."

What does the JS versus Rust code look like? Are they using the similar libraries/graphics apis/techniques? Did they exhaust every possible low-level tool in JS (Worker Threads, SharedMemory, etc). I feel there are a also rainbow of optimization opportunities available if one controls V8 and the underlying C++ stack.

Not that their eventual Wasm architecture is bad per se, it's just layering Rust+JS -> Wasm/C++ is much more complex than simply JS -> C++ back and forth.

As a side note, it very annoying that SIMD was taken out of development for JS. Big TC39 wants wants JS to fail.

https://github.com/tc39/ecmascript_simd

It's late for me. I've commented plenty on this thread but I'll revisit this particular comment tomorrow with my assessment of these two blog posts.

Just skimming the Google Sheets wasm one, looks like pure technical debt chaos so I'm already plenty suspicious.

Suffice it to say that all these pseudo-technical but actually marketing blog posts should be taken with a truckload of salt. Apples-to-oranges unless proven otherwise.

Javascript only becomes fast because most of the CPU time is spent in native code rather than actual compiled or interpreted javascript.

The big diff between scripted and compiled languages is the former dispatches by name and the later dispatches by index. No surprises which is faster and which can be compiled in the faster native code.

It's mostly fast enough for most apps and that definitely helps. It's not as consistently fast as some languages that don't rely on an JIT. That matters more for tooling than your average website.

There's no need to even contextualize your argument, it is the reality. The whole point of spending such heroic efforts on a fast VM implementation is so that even faster peformance becomes a niche use cases.

But alas, many unskilled programmers use Javascript to make useful things - sometimes beyond their ability. Even a state-of-the-art virtual machine like V8 cannot hope to fix that class of peformance problems.

I will withhold my opinion on the "faster than compiled languages" part though. ;)

From experience... It was really amazing to share TypeScript protocol definitions between the server and client. The client side would get all the autocomplete and intellisense and typed goodies, the server side used a compiler extension called typescript-is to validate the request bodies in one go, using the types as the source of truth. I loved not having to duplicate the validation logic in a separate way and manually maintain it to be consistent with the types. To this day I think that was the most natural way I've ever written a server-client pair and to this day nothing's compared, even supposedly cross-language things like protobuf. Ugh, TypeScript is so good at what it does. Sometimes I hate the lack of nominal types, but it really is up there with Rust as one of my favorite languages.

A programmer that can write a small efficient weather app in assembly can also easily do so in JS. Especially writing it in a c-style imperative way.

Modern Javascript has many low-level facilities and a great VM. You're conflating the low, average skill of the JS community to what the language is capable of.

Exactly!

In todays of multi processors, its seems completely backward to adopt a runtime that is limited to a single thread.

come on, you can do better than hurl insults at fellow programmers