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

The three pillars of JavaScript bloat

43081j.com

Post reply on HN
Print view View original

181–190 of 301 posts

Re: The three pillars of JavaScript bloat

#181

Post by jefftk »

josephg wrote: post #174
stevoski wrote: post #107

Well-written article, manages not to sound rant-y while describing the problem well. I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve everything, of course.)

What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.

We're talking about JS in browsers: many fewer options there, plus needing to support old devices.

Re: The three pillars of JavaScript bloat

#182

Post by simonw »

josephg wrote: post #174
stevoski wrote: post #107

Well-written article, manages not to sound rant-y while describing the problem well. I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve everything, of course.)

What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.

Those aren't a standard library for the language itself - they're not showing up in browsers, for example.

Re: The three pillars of JavaScript bloat

#183

Post by josephg »

userbinator wrote: post #66
halapro wrote: post #56

Earlier quoted context omitted.

> WTF is wrong with JS developers Don't confuse "one idiot who wants to support Node 0.4 in 2026" with "JS developers". Everybody hates this guy and he puts his hands into the most popular packages, introducing his junk dependencies everywhere.

Then I wish there were more of these "idiots who want to support Node 0.4 in 2026". Maybe they're the ones with the common sense to value stability and backwards compatibility over constantly trendchasing the new and shiny and wanting to break what was previously working in the misguided name of "progress".

NodeJS has a clear support schedule for releases. Once a version of nodejs is EOL, the node team stops backporting security fixes. And you should really stop using it. Here's the calendar:

https://nodejs.org/en/about/previous-releases

Here's a list of known security vulnerabilities affecting old versions of nodejs:

https://nodejs.org/en/about/eol

In my opinion, npm packages should only support maintained versions of nodejs. If you want to run an ancient, unsupported version of nodejs with security vulnerabilities, you're on your own.

Re: The three pillars of JavaScript bloat

#184

Post by theandrewbailey »

assimpleaspossi wrote: post #176
auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

CSS has a standard library? I stopped doing web dev just three years ago and am not aware of such a thing. Do you mean the CSS standard?

It wouldn't surprise me if CSS has a standard library. It is Turing complete, after all.

Re: The three pillars of JavaScript bloat

#185

Post by alt187 »

cobbzilla wrote: post #44
cwnyth wrote: post #26

Earlier quoted context omitted.

Cf. Vonnegut's rule #4 of good writing: > Every sentence must do one of two things—reveal character or advance the action. Or Quintilian's praise of Demosthenes and Cicero: "To Demosthenes nothing can be added, but from Cicero nothing can be taken away."

Is there no room for describing the setting? Must every utterance that sets the atmosphere also advance the plot or reveal character? Is there no room for mood?

describing the setting should (ideally) be done through a character's interaction with the setting.

if you're developing some sort of dystopia where everyone is heavily medicated, better to show a character casually take the medication rather than describe it.

of course, that's not a rule set in stone. you can do whatever the fuck you want.

Re: The three pillars of JavaScript bloat

#186

Post by jefftk »

wheattoast wrote: post #173

“Alternatively, what’d be really nice is if they upgraded“ Easy enough for y’all with techie salaries, but as one of the millions of poor folks whose paychecks barely (or don’t even) pay the bills, it’d be really nice if we didn't have to junkheap our backbreakingly expensive hardware every few years just cuz y’all are anorexically obsessed with lean code, and find complex dependancies too confusing/bothersome to mai…

They're talking about people still running ES3 browser engines, like IE8, which was released 15+ years ago and went EOL 10+ years ago. The author could have done a better job clarifying this, but they're not pushing for a world with 2y device lifetimes.

Re: The three pillars of JavaScript bloat

#187

Post by josephg »

vkou wrote: post #99
Slothrop99 wrote: post #94

Earlier quoted context omitted.

Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx". Also, there has been a huge amount of churn on the tooling side, and if you have a legacy app, you probably don't wanna touch whatever build program was cool that year. I've got a react app which is almost 10 years old, there has to be tons of stuff which is even older.

> Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx". There is. Break compatibility for it, and whatever poor bastard that is still maintaining software that is targeting a PalmPilot is free to either pin to an older version of your library, or fork it. Yes, that's a lot of pain for him, but it makes life a little easier for everyone else.

This is my philosophy too. If the nodejs project doesn't support node 18, why on earth should I?

Here's the schedule, if anyone hasn't seen it. Node 18 is EOL. Node 20 goes EOL in a bit over a month.

https://nodejs.org/en/about/previous-releases

Re: The three pillars of JavaScript bloat

#188

Post by padjo »

RadiozRadioz wrote: post #171
padjo wrote: post #148

Earlier quoted context omitted.

A third argument is that it was because of aliens from the planet Blotrox Prime. But I suppose without evidence we'll just have to accept that all three theories are equally probable.

Interesting how you decided to switch to hyperbole instead of providing evidence for your claim. Backing up your viewpoint would have easily shut me down, putting the ball in my court to do the same. Instead you gave a knee-jerk childish response.

Interesting that rather than try to bolster your claim you resorted to a logical fallacy to justify it.

Re: The three pillars of JavaScript bloat

#189

Post by Sharlin »

josephg wrote: post #174
stevoski wrote: post #107

Well-written article, manages not to sound rant-y while describing the problem well. I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve everything, of course.)

What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.

It's not standard unless it's in the actual standard.

Re: The three pillars of JavaScript bloat

#190

Post by josephg »

simonw wrote: post #182
josephg wrote: post #174

Earlier quoted context omitted.

What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.

Those aren't a standard library for the language itself - they're not showing up in browsers, for example.

Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?
Post reply on HN