Live data from Hacker News

The Shocking Immaturity of JavaScript

dev.to

31–40 of 78 posts

Re: The Shocking Immaturity of JavaScript

#31
post #7

IMHO, JS is has more mature parts than any other language. It's fast, stable, portable, practical and for every problem you could imagine, there's an answer on Stack Overflow, immense community, easy to learn (while hard to master, like the English language). The problem is, the popularity also brings huge amount of immaturity. So, it also has more immature parts than every other language too! People keep adding new…

I try not to use any libraries that were introduced less than 5-6 years ago. Thanks to this I don't experience much library churn and don't have to rewrite the same thing every few months. For example, I didn't pick up React until 2020. Let the kids play with their shiny toys if that's what they want.

Re: The Shocking Immaturity of JavaScript

#32
post #22

> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production! I think the issue is clear from this first sentence. Why are there any of these things in javascript ? The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.

Why should they not be?

Javascript for most of its life was essentially a DSL for the browser. That, in 2021, we're talking about build tools written in it, should give us pause for thought.

> "Why are my devops tools written in this browser DSL immature?"

Well, where to begin?

Re: The Shocking Immaturity of JavaScript

#34

It's was my take in 2015, when saying it then got you bashed to death. Now you can say it, since people have been burnt enough to admit it, but ironically it's actually less true. Yes, the JS language is always hackish. The stdlib sucks and the ecosystem is a Jenga tower. A lot of JS projects are still what I call "disposable code bases". But. Modern JS is tolerable. Functions are now decent, you have let/const, map/…

And I think the article is largely correct even though I don't dread developing Javascript-based applications.

One of our Nuxt applications with default build configuration sometimes builds successfully and sometimes fails miserably for reasons not understood. So we just run the process until it succeeds. I would never tolerate this in Python or take it as lightly as I do here, but like a frog in hot water I've been conditioned to almost expect it or at least not get too bothered by it.

I think Javascript the language is fine. But the rest of ecosystem feels enormously creative, myopic and too often fragile.

Re: The Shocking Immaturity of JavaScript

#35
post #19

The ecosystem of JavaScript frameworks is almost unbelievably unstable. Popularity isn't a measure of quality of course, but if you're going to make a statement like "JavaScript frameworks are almost unbelievably unstable" you probably ought to cite some sort of evidence for that because reality is very much against you. There are about 10,000,000 React websites[1] compared to 95,000 Rails[2] websites. There are 325,…

That's like saying there are X million humans driving therefore humans can't be that bad at driving. There is really not much of a connection between those dots

Re: The Shocking Immaturity of JavaScript

#36

> From backend ORMs and headless APIs to frontend site generators, package managers, and build tools—it's a miracle any of it actually works properly in production! I think the issue is clear from this first sentence. Why are there any of these things in javascript ? The marvel is that in 2021 such a sentence can be written -- that these things are immature seems both obvious and to miss the point.

So engineers only have one language to absolutely master. This really hit home: Trying to recruit a Java + SpringBoot + Angular engineer is 1 order of magnitude harder than a NodeJS + Angular engineer.

Why not generalise SQL with classes, loops (, etc.) and truly single-language the world? And an SQL configuration language ("UPDATE aws.ec2.config ...") ?

Typescript is a testament to the extreme amount of work needed to normalize a scrappy browser-lang for robust use.

The issue is precisely that a community of "SQL developers" are not going to build you robust tools, merely by having generalised SQL. And likewise, a community of browser developers aren't going to either.

Single-languaging down to effectively a DSL produces a particular type of community (, language, domain of competence, ...), which is exactly what OP is complaining about.

Re: The Shocking Immaturity of JavaScript

#37

It is a lost cause to rationally try and sort out what if anything is chronically wrong with js, ruby, haskell, c (or any language of choice). They each have their pros and cons, and have evolved differently for different reasons. Since programming languages many times (seemingly) are like a dear spouse to its disciples such discussions generally devolve into endless and meaningless comparisons, if not worse. The art…

I think the big difference with JS is that if you're doing just about anything in Web Dev these days, you MUST use JS (with a few exceptions).

Don't like PHP? Try Python. Why not Go, Scala or Rust? Don't like Ruby? Move to Elixir (no really, do it! you won't regret it)

But with JS you're stuck with JS - at least Typescript makes things a bit more sane.

So until the browser monopoly ends and something supplants JS as one of the only ways to make a dynamic website, it will have to take the heat.

The best experience I've encountered is with LiveView in the Elixir/Phoenix world. It still needs JS for the plumbing (websockets) but I no longer have to write JS. Happy days!

Re: The Shocking Immaturity of JavaScript

#38
post #6

I did web dev for a few years using Angular + various other tools, and yes, it was nightmarish. I had to come back to it briefly recently. But using "boring" Typescript, esbuild and preact, I have to say the experience was an immeasurable improvement. Verging on pleasant even. Everything was well-documented with strong Stackoverflow coverage. So, boring > shiny

Typescript, esbuild and preact are hardly boring, since most JS dev don't even have tried it yet.

React is just starting to become "boring", and I mean that in the JS sense of the world. Because it's lifetime would be considered "modern" and any other language.

Re: The Shocking Immaturity of JavaScript

#39
post #7

IMHO, JS is has more mature parts than any other language. It's fast, stable, portable, practical and for every problem you could imagine, there's an answer on Stack Overflow, immense community, easy to learn (while hard to master, like the English language). The problem is, the popularity also brings huge amount of immaturity. So, it also has more immature parts than every other language too! People keep adding new…

I try not to use any libraries that were introduced less than 5-6 years ago. Thanks to this I don't experience much library churn and don't have to rewrite the same thing every few months. For example, I didn't pick up React until 2020. Let the kids play with their shiny toys if that's what they want.

I think this is a smart heuristic if you optimize for stability. Incidentally, you started to learn React when it's API's got drastically simplified over the previous class based approach. You joined at the right time so to speak.

But I want to add that play isn't just for kids. For me, it is an important part of my life and work. Deliberate, free play gets you in a different mode, it's fun and worth doing without some external reward. Does it have to be new, "shiny" toys? Not at all! That's the nice thing about it.

Re: The Shocking Immaturity of JavaScript

#40
post #6

I did web dev for a few years using Angular + various other tools, and yes, it was nightmarish. I had to come back to it briefly recently. But using "boring" Typescript, esbuild and preact, I have to say the experience was an immeasurable improvement. Verging on pleasant even. Everything was well-documented with strong Stackoverflow coverage. So, boring > shiny

You probably already know this, but for anyone wanting to do this: esbuild does not do any type checking, so TypeScript with pure esbuild (without a separate tsc step) is only half useful (it gives you better autocompletion, but not much else). https://esbuild.github.io/content-types/#typescript

You IDE should check the types for you.
Post reply on HN