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

61–70 of 78 posts

Re: The Shocking Immaturity of JavaScript

#61

Post by onion2k »

andybak wrote: post #49
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.

I'm not suggesting JS is particularly high quality; I'm just saying that it's not completely broken. There's a middle-ground where it can be both good enough quality to be usable, and good enough to not be considered broken.

Given the fact JS is used by hundreds of thousands of developers it is obviously not totally broken, so if you're going to say it is you need some very strong evidence to back that up.

Half the time when I see "JS is so broken!" posts they're by Ruby devs. I can't help wonder why they're all so keen to move away from Ruby.

Re: The Shocking Immaturity of JavaScript

#62

Post by onion2k »

Havoc wrote: post #35
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,…

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

Humans are amazing at driving. Given how many billions of miles are driven every day, the number of accidents is mind-bogglingly tiny. You'd think there would be many, many more.

That is quite a good analogy to JS actually.

Re: The Shocking Immaturity of JavaScript

#63

Post by andybak »

onion2k wrote: post #61
andybak wrote: post #49

Earlier quoted context omitted.

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.

I'm not suggesting JS is particularly high quality; I'm just saying that it's not completely broken. There's a middle-ground where it can be both good enough quality to be usable, and good enough to not be considered broken. Given the fact JS is used by hundreds of thousands of developers it is obviously not totally broken, so if you're going to say it is you need some very strong evidence to back that up. Half the t…

I know we're not supposed to say "did you read the article" around here but there was a fair amount of nuance in it and you don't sound like you disagree with it in any huge sense.

> Half the time when I see "JS is so broken!" posts they're by Ruby devs. I can't help wonder why they're all so keen to move away from Ruby.

That's an interesting assumption. I would have started from the position that javascript is a mainly a front-end solution so one wouldn't "move away from Ruby" to use it because you would still use Ruby on the back end.

Re: The Shocking Immaturity of JavaScript

#64

Post by awestroke »

laurent92 wrote: post #58
awestroke wrote: post #53

Earlier quoted context omitted.

No, it's the truth. Whether you use react or vanilla js, creating 10 000 complex element trees is going to take a lot of time due to the DOM recalculating layout and redrawing between every DOM operation. React makes it easy to draw less through virtualization. Virtualization is very hard to implement in a non-declarative way

I can easily build a table in HTML with 70k cells (100 columns, 700 lines, it does happen, and users prefer that when getting an overview of their project), but in React, it takes 15s to render. Setting the innerHtml takes milliseconds.

Just use something like react-virtualized. Problem solved

Re: The Shocking Immaturity of JavaScript

#65

Post by arcanon »

Does anyone else think it’s weird that trivial syntax/typesystem frameworks get very popular whereas things that actually move tech forward, like new apis/webgpu dont get much hype? Maybe it just seems this way. I mean how many ways can we come up with to watch ppl struggle to build 2D form applications?

Re: The Shocking Immaturity of JavaScript

#66

Post by Nicksil »

singularity2001 wrote: post #55
egeozcan wrote: 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…

The often unmentioned killer feature part of js is that you can express tree data directly*: person={ name: "frank", address:{ city: "Berlin ", zip:12345 } } It's a different kind of "maturity" than discussed in the post, but a very important maturity nonetheless. * (without TreeDataFactoryImplementation treeDataFactoryImplementation=TreeDataFactory.newTreeDataFactoryImplementation())

>The often unmentioned killer feature part of js is that you can express tree data directly

This is the case in almost all well-used programming languages. Calling it a "killer feature" is a bit of a stretch; it's more an expectation.

Re: The Shocking Immaturity of JavaScript

#67

Post by singularity2001 »

Nicksil wrote: post #66
singularity2001 wrote: post #55

Earlier quoted context omitted.

The often unmentioned killer feature part of js is that you can express tree data directly*: person={ name: "frank", address:{ city: "Berlin ", zip:12345 } } It's a different kind of "maturity" than discussed in the post, but a very important maturity nonetheless. * (without TreeDataFactoryImplementation treeDataFactoryImplementation=TreeDataFactory.newTreeDataFactoryImplementation())

>The often unmentioned killer feature part of js is that you can express tree data directly This is the case in almost all well-used programming languages. Calling it a "killer feature" is a bit of a stretch; it's more an expectation.

You are right. I was thinking of Java, C, C++, and C# but my knowledge about the last ones was outdated (long ago)

https://stackoverflow.com/questions/138600/initializing-a-st...

https://stackoverflow.com/questions/15501202/c-sharp-nested-...

IF you are happy with some constraints or the syntax exploding with every level of tree depth added: public Dictionary> info = new Dictionary> ....

Re: The Shocking Immaturity of JavaScript

#68

Post by tored »

Best career choice I did in my life was quitting frontend dev, I was in deep as frontend architect and similar senior positions. I still need to do some pure JavaScript frontend occasionally and every time it is even more mad than before. Always reminds me what hellhole I managed to escape.

Re: The Shocking Immaturity of JavaScript

#69

Post by austincheney »

awestroke wrote: post #54
austincheney wrote: post #48

Earlier quoted context omitted.

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

I am talking about DOM manipulation operations such as creating and updating elements. See my other comment. React does not query the DOM at all (almost), so query speed is irrelevant

DOM operations are just a few common methods such as: appendChild, removeChild, setAttribute, getAttribute, removeAttribute, createElement, createTextNode. These were slow when injecting massive quantities of new nodes more than 12 years ago. Now they are fast.

If you are that concerned with speed then just produce everything in a document fragment and when ready inject the document fragment into the document. Bottleneck bypassed. React won't solve for that bottleneck because it is still JavaScript beholden to the DOM just the same.

Re: The Shocking Immaturity of JavaScript

#70

Post by tored »

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.

Languages are not that time consuming to learn, it is the development environment, frameworks, libraries, community, best practices, tooling etc that takes a lot of time.
Post reply on HN