> Any application that can be written in JavaScript, will eventually be written in JavaScript. - Jeff Atwood (2007)

The game is changing with WebAssembly though. Large JavaScript applications are replacing JavaScript bits with wasm:

https://web.dev/case-studies/google-sheets-wasmgc

Any application that is written in JavaScript will have more and more of it replaced with WebAssembly.

> Any application that is written in JavaScript will have more and more of it replaced with WebAssembly.

Which is not a lot when it comes to web. Sure some algo heavy stuff like Figma will benefit from it, but GUI around it is still written in what?

Just do the whole thing in WebAssembly. Minimal dependencies and pixel perfect in all browsers. The distinction is applications versus documents.

Works for Dart with Flutter:

https://flutter.dev/

https://www.youtube.com/watch?v=Nkjc9r0WDNo

https://www.youtube.com/watch?v=qx42r29HhcM

https://wonderous.app/web/

Works for C# with Avalonia UI:

https://avaloniaui.net/

https://www.youtube.com/watch?v=6mwQDPlbF5Y

https://solitaire.xaml.live/

And so on.

Amazing, just awesome. Long standing applause.

Let’s regress to level of native apps without benefits of said native apps. No standardization, no performance, no unified integration. Let’s get rid of browser plugins that allow us to fight invasive ads and malicious JS scripts, let’s dump decades of expertise and optimizations, let’s undo all advancements of web just to be able to write same old <div> in C#. Nothing better than a single blob of <canvas>.

It’s ironic that some of people in this thread convict JS devs of using only JS and then you use those “frameworks” as an example of a good thing when they don’t even have a separation of presentation (like HTML and JS) that would allow other languages tap into it.

And all of this is with much worse performance and stability.*

* - for now

> No standardization, no performance, no unified integration.

WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed.

It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change.

> WebAssembly has all of these things.

Is that why Flutter demo you’ve linked takes 7 seconds to load on Firefox on iPhone 14 Pro and then barely works skipping frames?

I can’t even select text on the page, since it’s just a big canvas, lmao.

> WebAssembly has all of these things. WebAssembly already there, lurking your browser. That's why it will succeed.

You mean how every of those frameworks that you’ve listed have to reimplement a11y every team, since WASM is pure logic? How all of them have to reimplement OS shortcuts and OS integrations? Is that what you call “unified integration”?

> It's interesting how threatened you are by WebAssembly. But change is normal. Embrace the change.

Why did I even bother replying to you, sigh.

Ah, so what you want is Uno. It uses WebAssembly and the DOM: https://platform.uno/

> Why did I even bother replying to you, sigh.

I think it's because you're overwrought. Don't fear WebAssembly.

That’s actually good. If only it didn’t use XAML, but I guess you have to appeal to C# devs.

> I think it's because you're overwrought. Don't fear WebAssembly.

Not sure what’s you deal with these comments, as I’m not even a JS dev by trade, but okay.

I can only judge you by your actions. You have a lot of anxiety.

It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS? I guess not making tools for say, c# devs in c# would also be bad?

Presumably because, apart from Python (see Ruff, uv, etc) most languages aren’t running into such major issues with their own “self hosted” tooling that it’s worthwhile to rewrite several of them in a completely different language.

Yes I agree! And JavaScript also isn't really at that point yet. Python is really in a class of its own here... sadly enough.

Though I don't see an issue with tools for JS built without JS. It's just that I don't think that it's a bad thing for a JavaScript dev to want the ecosystem around JavaScript to be written in JS. JS is orders of magnitudes faster than python in any case.

God what I’d do if someone wrote build system in Rust for JVM and freed us from Maven and Gradle.

> It's usually the opposite. And the post is specifically about making JavaScript tools, why would you not expect them to be written in JS?

Take a look at rollup, vite, etc. These tools are essentially replacing webpack, which is written in JS. Modern Rollup (^4) uses SWC (Rust-based bundler), and vite is currently using a mix of esbuild (Go) and Rollup. I think they're switching to SWC in v6 though.

The point here is that for certain operations JS is not nearly as fast as lower-level languages like the aforementioned. Bundling is one of those performance-critical areas where every second counts.

That said, as a TypeScript developer I agree with the sentiment that JS tools should be written in JS, but this isn't a hard and fast rule. Sometimes performance matters more. I think the reasonable approach is to prefer JS – or TS, same difference – for writing JS tools. If that doesn't work, reach for something with more performance like Rust, Go, or C++. So far I've only had to do the latter for 2 use cases, one of which is hardware profiling.

It's funny you mention C# since VS Code is a perfect example of JS devs rewriting existing tools in JS.

i swear some non js devs will go to extreme lengths to demonstrate solutions that will never run on another machine instead of writing js

Why would they never run on another machine? It's not that hard to write portable code, and done very often. Nowadays for example, you rarely ever think about whether you're on arm or x86.

If you write non-portal code, there might be an important reason (like writing OS components, which you won't do in JS).

almost every time code doesn’t run on my machine, the root cause is a political disagreement with a c-compiler author three layers below my actual problem.

javascript doesn’t have a compiler is my main point.

Bit rich to complain about that when all the major browsers have just as significant differences, and that’s before we bring node into the equation, let alone talking about a good 30% of websites I visit with any quantity of JS in them are either perpetually broken in some way, or so jank as to be effectively broken.

totally agreed about all of the above and i take credit for none of that code

i write plaintext at uris, progressively enhance that to hypertext using a port with a deno service, a runtime that unifies browser js with non browser js.

that hypertext can optionally load javascript and at no point was a compiler required aside from the versioned browser i can ask my customers to inspect or a version of deno we get on freebsd using pkg install.

node is not javascript would be my biggest point if i had to conclude why i responded.

microsoft failed at killing the web with internet explorer and only switched to google’s engine after securing node’s package manager overtly through github and covertly through typescript.

microsoft is not javascript is my final point after circling back to my original point of microsoft is also one of the aforementioned reasoned c-compilers are politically fought over instead of things that just work.

I encounter far more issues compiling C code than JS issues in the web, just saying.

> I swear some JS devs will go out of their way to avoid learning anything else, whilst simultaneously and breathlessly espousing that we rewrite everything else in JS.

The JStockholm syndrome.

OP is a Servo contributor