Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Shocking Immaturity of JavaScript

dev.to

Post reply on HN
Print view View original

41–50 of 78 posts

Re: The Shocking Immaturity of JavaScript

#41

Post by tjpnz »

laurent92 wrote: post #16
mjburgess wrote: post #4

> 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.

Languages aren't hard to learn once you've got 1-2 under your belt.

FWIW I wouldn't consider myself to have "absolute mastery" in any language, there are some I'm more comfortable with than others but even when I'm not I can still be productive.

Re: The Shocking Immaturity of JavaScript

#42

Post by nkohari »

mjburgess wrote: post #32
qubyte wrote: post #22

Earlier quoted context omitted.

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?

I'm not aware of any ops tooling that's built in JavaScript. (I'm sure it exists, but it's not popular.) When the article is referring to build tools, they likely mean transpilation/bundling systems like Babel and Webpack, which are fairly reasonable uses of JavaScript.

Re: The Shocking Immaturity of JavaScript

#43

Post by dotancohen »

awestroke wrote: post #20
laurent92 wrote: post #10

Earlier quoted context omitted.

Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?

I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is

  > React is not the performance bottleneck, the DOM is.
I think that's pushing the blame just a layer too deep. It's like saying that engines are not holding up hypersonic missile development, the thick atmosphere is.

Re: The Shocking Immaturity of JavaScript

#44

Post by heipei »

tjpnz wrote: post #41
laurent92 wrote: post #16

Earlier quoted context omitted.

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.

Languages aren't hard to learn once you've got 1-2 under your belt. FWIW I wouldn't consider myself to have "absolute mastery" in any language, there are some I'm more comfortable with than others but even when I'm not I can still be productive.

They might not be hard to learn, but it's still a considerable mental overhead to switch between writing JS on the frontend and anything but JS on the backend. I frequently mix up the simplest things, like len(list) vs list.length, or how that you can't use obj.property on Python dicts, or list.append() vs array.push(), etc. And then you might have a great tooling library in one ecosystem (like lodash in JS) and try to replicate the things in your backend language. That sort of context-switching simply isn't worth it in my opinion.

Re: The Shocking Immaturity of JavaScript

#45

Post by pansa2 »

laurent92 wrote: post #16
mjburgess wrote: post #4

> 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.

> So engineers only have one language to absolutely master.

I'm always amazed at the reluctance of developers to learn and use multiple languages. To use an old analogy: they're like carpenters who are unwilling to learn how to use a saw because they have a perfectly good hammer.

Re: The Shocking Immaturity of JavaScript

#47

Post by johnnypangs »

BiteCode_dev wrote: post #40
5e92cb50239222b wrote: post #27

Earlier quoted context omitted.

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.

This might worked on solo projects but if you’re working with people, I’d highly recommend enforcing type checking of some sort. People will ignore the IDE error messages.

Re: The Shocking Immaturity of JavaScript

#48

Post by austincheney »

awestroke wrote: post #20
laurent92 wrote: post #10

Earlier quoted context omitted.

Isn’t React slow, only able to manage tables of a few dozen rows before slowing down to hell, hence starting the trend of tables paginated by 10 rows only? Isn’t that the cost of hooks?

I've written code that would have been incredibly hard be made performant without React. With React, vittualizing rendering to only render visible elements is a breeze thanks to the inherent composability of react components, and now also hooks. React is not the performance bottleneck, the DOM is

That isn’t just disagreeable, it’s measurably wrong. The DOM is insanely fast when you aren’t lazy, such as using query selectors.

https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

A trillion unnecessary and never removed event listeners will also destroy your performance. Event listeners are an extra layer of abstraction that you can live without if you know what you are doing. That’s a big unlikely if.

React is not really a performance bottleneck either but it also certainly isn’t a performance benefit. This is that immaturity the article speaks to.

Re: The Shocking Immaturity of JavaScript

#49

Post by andybak »

onion2k wrote: 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,…

I don't understand how the numbers you've posted here support your argument. You said it yourself "Popularity isn't a measure of quality" and then go on to imply that it does.

Re: The Shocking Immaturity of JavaScript

#50

Post by zengargoyle »

BiteCode_dev wrote: post #25

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/…

The thing with Javascript is that it sucks so bad that there are what a dozen or so languages built on top of it that get transpiled to JS to run in a browser or on V8. It sucked so bad that nobody really wanted to use it, they'd rather build a compiler and write in something else and tranpile into JS. How can a language be "good" when there are so many attempts that take such effort just trying to avoid it.
Post reply on HN