I think we’re reading too far into the authors impostor syndrome.

He’s making contributions in Rust already. His opinion isn’t invalid just because he has a bias, he opens by acknowledging his bias.

Hopefully the lot includes that writing stuff in low level languages isn't worth the pain most of the time.

Curious what you mean by "most" (I'm agnostic/unlearned on the statistics tbh). I "feel" like it doesn't happen too often when it's not either already low-level or the supposed extra performance is likely worth it.

Like, I can't imagine most people using Javascript would want to rewrite in Rust without some decent reason.

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.

> 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

> It's not that hard to do the same for a less terrible language.

I miss that brief era when coding culture had a moment of trying to be nice, of not crudely shooting out mouths off at each other's stuff crudely.

JS, particularly with typescript, is a pretty fine language. There's a lot of bad developers and many bad organizations not doing their part to enable & tend to their codebases, but any very popular language will likely have that problem & it's not the languages fault.

It's a weakness & a strength that JS is so flexible, can be so many different things to different people. Even though the language is so so much the same as it was a decade & even two ago, how we use it gone through multiple cycles of diversification & consolidation. Like perl, it is a post-modern language; adaptable & changing, not prescriptive. http://www.wall.org/~larry/pm.html

If you do have negative words to say, at least have the courage & ownership to say something distinct & specific, with some arguments about what it is you are feeling.

I’d normally agree with you, but JS is more or less designed to be terrible. It was hacked together by Brendan Eich in literally 10 days, who originally wanted to do something more Scheme-like. It was a quick and dirty hack that got stretched way beyond what it was even meant for.

It then literally had decades of ECMAscript committee effort to shape it into something more useable.

I could repeat the numerous criticisms, but there’s enough funny videos about it that make a much better job pointing out its shortcomings and, sometimes, downright craziness of it.

> but any very popular language will likely have that problem & it's not the languages fault.

No, sorry, just no. I get where you are coming from, but in the case of JavaScript, its history and idiosyncrasies alone set it apart from many (most?) other languages.

Perl for example was made with love and with purpose, I don’t think it’s comparable.

JS wasn’t created in 10 days. It was prototyped in 10 days, and the prototype contained very little of the stuff people complain about.

Hillel Wayne posted about this recently:

https://www.linkedin.com/posts/hillel-wayne_pet-peeve-people...

Okay, I stand corrected. So this prototype didn’t ship, or did it ship and evolve?

Brendan Eich himself calls JS a “rush job” and with many warts though, having had to add aspects that in retrospect he wouldn’t have. This snippet from your link is consistent with that:

    Also, most of JavaScript's modern flaws do *not* come from the prototyping phase. The prototype didn't have implicit type conversion (`"1" == 1`), which was added due to user feedback. And it didn't have `null`, which was added to 1.0 for better Java Interop.

   Like many people, I find JS super frustrating to use.

This anecdote about the double equality operator might have originated from Eich's chat with Lex Fridman where he states (at about 5 minutes and 26 seconds) that during the original 10 day sprint JavaScript didn't support loose equality between numbers and strings: https://www.youtube.com/watch?v=S0ZWtsYyX8E&t=326s

The type system was weakened after the 10 day prototyping phase when he was pressured by user feedback to allow implicit conversions for comparisons between numbers and serialized values from a database. So it wasn't because he was rushing, it was because he caved to some early user feedback.

The implicit type conversion is good for a very funny conference video ("wat") but man, it's just so overplayed as a weakness especially versus how much real world impact it has on anyone.

And with TypeScript or linting, many of the strange comparison/conversion issues go away.

I struggle to find any substantial arguments against the js language, in spite of a lot of strong & vocal disdainful attitudes against it.

The implicit coercion and its weird behavior is absolutely a major footgun, not just fodder for the “wat” video. It’s something that can get you into serious trouble quite easily if left unchecked, for example by just looking at a list wrong. For someone to say that it has never caused them surprising pain in plain JavaScript is probably disingenuous. This is something that most other languages plainly don’t have as a problem, at least not as baffling.

Other things worth mentioning are the unusual scoping (by default at least), prototypes, “undefined”, and its role versus "null"... the list goes on.

I give TypeScript a lot of credit for cleaning up at least some of that mess, maybe more. But TypeScript is effectively another language on top of JS, not everyone in the ecosystem has the luxury of only dealing with it, and across all layers and components.

Is my knowledge about JavaScript outdated and obsolete? Certainly. Is the above stuff deprecated and turned off by default now? Probably. I left web development more than 10 years ago and never looked back. I’m a bit of a programming language geek, so I’ve used quite a few languages productively, and looked at many more. But not many serious programming languages have left quite the impression that JavaScript and PHP have.

In the meantime, I have always remembered that one conversation I had with someone who was an ECMAscript committee member at that time: They were working really hard to shape this language into something that makes sense and compiles well. Maybe against its will.

EDIT: Dear god, I completely forgot about JavaScript’s non-integerness, and its choice of using IEEE 754 as its basic Number type. Is that still a thing?

> I struggle to find any substantial arguments against the js language

The biggest problem with JavaScript is that it's an extremely footgunny language. IMO, of the C++ variety, but probably worse.

1. The type system is unsound and complicated. Often times things "work" but silently do something unexpected. The implicit type conversion thing is just one example, but I know you've seen "NaN" on a page or "Object object" on a page. Things can pass through and produce zero errors, but give weird results.

2. JS has two NULLs - null and undefined. The error checking around these is fragile and inherently more complex than what you'd find in even C++.

3. JS has an awful standard library. This is footgunny because then basic functionality needs to be reimplemented, so now basic container types have bugs.

4. JS has no sane error handling. Exceptions are half-baked and barely used, which sounds good until you remember you can't reliably do errors-as-values because JS has no sane type system. So it's mostly the wild wild west of error handling.

5. The APIs for interacting with the DOM are verbose and footgunny. Again things can look as though they work but they won't quite. We develop tools like JSX to get around this, but that means we take all the downsides of that too.

6. Typescript is not a savior. Typescript has an okay-ish type system but it's overly complex. Languages with nominal typing like C# are often safer (no ducks slipping through), but they're also easier to work with. You don't need to do type Olympics for most languages that are statically typed, but you do in TS. This also doesn't address the problem of libraries not properly supporting typescript (footgun), so you often mix highly typed code with free-for-all code, and that's asking for trouble. And it will become trouble, because TS has no runtime constraints.