Skeptical of rewriting JavaScript tools in "faster" languages

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.