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

51–60 of 78 posts

Re: The Shocking Immaturity of JavaScript

#51

Post by BiteCode_dev »

zengargoyle wrote: post #50
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.

Note I never said it was good.

Half of the popular projects around JS are indeed created to workaround its deficiencies, or the JS DOM API limitations.

But working with JS, thanks to those efforts, is now much more agreeable. And the language itself has evolved in the right direction.

Re: The Shocking Immaturity of JavaScript

#52

Post by worrycue »

pansa2 wrote: post #45
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.

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

Still learning a language (or a carpentry tool for the matter) is a cost no matter how easy.

It would be great if we could have a unicorn language that can do it all optimally - or at least adequately. Then we can fully focus and master that one language.

Nevertheless I think most will agree that JavaScript isn’t that language.

Re: The Shocking Immaturity of JavaScript

#53

Post by awestroke »

dotancohen wrote: post #43
awestroke wrote: post #20

Earlier quoted context omitted.

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.

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

Re: The Shocking Immaturity of JavaScript

#54

Post by awestroke »

austincheney wrote: post #48
awestroke wrote: post #20

Earlier quoted context omitted.

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

Re: The Shocking Immaturity of JavaScript

#55

Post by singularity2001 »

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())

Re: The Shocking Immaturity of JavaScript

#56

Post by emerged »

BiteCode_dev wrote: post #26
sam_goody wrote: post #2

When a language becomes stable, it also begins to lose popularity. (This is widely discussed). Javascript is the only language that has continued to grow forever without becoming an "old" language in dev mindset. One reason is the constant churn of tooling, another is the immaturity of everything, so every generation of devs have a place to add something. Overall JS gains more than it loses. This is similar to the co…

Well having a monopoly on the most popular and power programming platform of the planet, the web browser, will do that. In fact, remove the browser monopoly, and give it to Visual Basic, and in 3 years, VB will be the most popular language of the world.

That’s the thing about JS. It’s popular because it was first and grew into a monopoly. The language itself is horrific. We are permanently stuck with a poorly designed language because it has momentum which can’t be overcome.

Re: The Shocking Immaturity of JavaScript

#57

Post by kitd »

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.

Yup. Vscode has built-in Typescript support so that does all the type checking as you go.

Re: The Shocking Immaturity of JavaScript

#58

Post by laurent92 »

awestroke wrote: post #53
dotancohen wrote: post #43

Earlier quoted context omitted.

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

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.

Re: The Shocking Immaturity of JavaScript

#59

Post by skinkestek »

johnnypangs wrote: post #47
BiteCode_dev wrote: post #40

Earlier quoted context omitted.

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.

> People will ignore the IDE error messages.

Then they get caught in code review at least in any team I work.

No way I accept any unnecessary "disable lint" statement in a PR.

Also (of course, since it is default) the CI build system breaks if they commit and push without ignores, so no, trying to slide it past me doesn't work either.

Re: The Shocking Immaturity of JavaScript

#60

Post by barbarbar »

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 does not seem fast in this benchmark https://krausest.github.io/js-framework-benchmark/2021/table...
Post reply on HN