In search for a good programming language: JavaScript

I wouldn't claim that JavaScript is my favorite language (and I always deny it when I'm asked), but it's definitely my most invested one. I work on linters, compilers, and even the language documentation itself. I have my own style guide. I work on many production-level applications. So, it surely has a special place in my heart, and I have a say about its merits.

JavaScript suffers the same problems as PHP, C++, or Java: it has been around for too long, it has changed too much, and people who troll on it only know the parts that stuck since 20 years ago. It has happened to me too many times that, when I tell someone roasting JavaScript that "this is no longer a problem in 2025", the response is always "sorry I'm not very familiar with JavaScript". The problem of legacy baggage is especially cancerous in JavaScript. I need not repeat the cliché of "Don't Break the Web", which says "we can't remove bad things from the past; we can't add good things in the future, if it would break bad code in the past". At the same time, many features in JavaScript that are considered outside of the "good parts" are, IMO, what give the language its soul, and I would be sad to see them go in a hypothetical "JavaScript 2.0":

• this that is dynamic and can be rebound.
• Lenient argument passing: type coercion, default values, number normalization (flooring, normalizing NaN, etc.)
• Prototypal inheritance.
• Symbol.species
• Having "primitive methods" that define the core behavior of a class, overriding which can override all other objects. For example, overriding Map.prototype.set can change the behavior of the Map constructor.

In fact, many of these are already on their way out: while most can't be removed, newly-introduced features are designed to avoid these features, introducing an inconsistency. The latest normative conventions are formally documented by TC39, and one can notice how it departs from the initial principles of the language. I have written some snippets that demonstrate how you can use JavaScript to write totally cursed patterns that don't look like they should be possible in a "normal" language. I don't think you should ever need these IRL, but they make the language extremely fun to play with. (These are just a selected few; thanks to my position as the JavaScript documentation editor, I managed to sneak in a lot more abominations directly in MDN. Fear not; they are all clearly marked as "cursed", "not recommended", etc.) Whenever I think about "does a feature belong in JavaScript", I ask myself, "if I'm writing a snippet in HTML that performs validation on a form field, whose content is unknown and type is dubious (because I'm lazy and don't want to read documentation), would this feature make my life better?" and if the answer is "yes", then it should be in JavaScript. Sadly, strict argument validation is making that less and less possible.

"Backwards compatibility" is just one of the agendas pushed by "engine implementers" who actively take the fun from us: the other is called "performance". Countless proposals have been stalled, borked, or nerfed because of "performance concerns". The one people lament the most is probably pipelines, in which the more-favored F#-style x |> f1 |> f2 was rejected in favor of the more-awkward Hack-style x |> f1(^) |> f2(^), because the former "encourages more closures". Similarly, decorators are stalled at stage 3 for a long while, and the records and tuples proposal is completely dead because "engines don't want to slow down the fast path of ===". If there's one enemy to blame for why we can't have nice things in JavaScript, it's definitely the dominance of engine implementers in the design process and their misaligned incentives.

Speaking of incentives, we all know that there are four parties involved in language design (as many languages with a formal standard do): the standard committee, implementers, users of the language (developers), and users of the software (end users). End users are definitely the top priority—no one can deny that. But JavaScript is in a unique situation where the implementer caters directly to the end users without the developers mediating. In this world, the committee and implementers each have their own agenda (the committee wants to enforce their own aesthetics; implementers want to maximize performance and maintain compatibility, so the browser doesn't appear "broken" to the user), and the developers' interest is put at the bottom. I'm not saying that developers don't want things like strict type validation or a fast language, but the rest of us who occasionally want to have fun with the language are left with an uninteresting and rigid box with nothing to poke at. Given the heritage of JavaScript being flexible and dynamic, I think it's a huge loss to the ecosystem that this trend can't continue; after all, strictness can also be enforced in userland via linters and type checkers. A dynamic that prioritizes the developer needs would make the language as strict and lax as the user wants, instead of forcing the view of those in power on the entire ecosystem, assuming that the downstream developers don't know how to use the language properly.

Within the ecosystem, people who talk bad about JavaScript usually get far more attention than those namelessly working on or with the language on a 9-to-5 basis. Think about the last time you went on social media and saw brainrot like

0.1 + 0.2 === 0.3 is false!! Shockers!!

1 + "1" === "11" but 1 - "1" === 0!! Wacky!!

The holy trinity of "0", [], 0, and "\t"!! Madness!!

If people have tried to read the documentation for more than 5 minutes, none of these should be surprising. I don't know what got people into the mindset that they can start commenting on a language just based on what they know and expect from other languages (by the way, almost every single language has 0.1 + 0.2 != 0.3 because it's an IEEE-754 issue, but somehow people manage to frame it as a JavaScript problem).

And then there are people who say, "I don't care about JavaScript; I write in [my favorite language] and compile it to WebAssembly". I've seen far more usage of "WebAssembly" as a buzzword to flex on JavaScript than actual production use of it. I don't know what the state of the art Wasm execution is, but I've constantly heard problems with its performance, especially when crossing DOM boundaries. It's a problem being actively worked on, but until we get there, JavaScript is here to stay. Even with existing Wasm applications, we see Wasm as a backend that works with JavaScript, not instead of JavaScript.

Even if other languages become viable for web development, I don't consider JavaScript uncompetitive relative to any other language in terms of expressiveness and power. It has the richest paradigms of any language, and basically you can translate idioms in any language 1-to-1 into JavaScript (barring advanced FP things like pattern matching and records, which once again have been killed by the very hands of the implementers). TypeScript endows it with one of the most powerful type systems seen in production use¹ (with many research papers demonstrating how powerful it is) with top-notch tooling. Performance may be a problem, but usually DOM operations, network operations, and user gestures dominate, so optimizing out a few milliseconds isn't perceivable to the user. The success of Node.js, Electron, and Bun has proven to us that JavaScript isn't popular because of its monopoly in the browser, and people would happily write JavaScript for their own business scenarios given a viable environment.

There was a time when JavaScript was truly fun. ES6 brings us features that make it even more fun. But everything from there seems to go downhill, and while new features are exciting, the devil in the details make them look very un-JavaScript. I don't think this trend is reversible by Vox Populi (more people being employed by big corps who just want to do their job well and safely), and I don't think it's severe enough for me to lose passion, but I miss the feeling of being a ninja and being able to do everything in the language.