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

111–120 of 301 posts

Re: The three pillars of JavaScript bloat

#111

Post by Slothrop99 »

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.

[dead]

Re: The three pillars of JavaScript bloat

#112

Post by padjo »

grishka wrote: post #60

Yes, of course the tiny packages cause some of the bloat. As mainly a Java developer being pretty paranoid about my dependency tree (I'm responsible for every byte of code I ship to my users, whether I wrote it or not), I'm always blown away by JS dependency trees. Why would you reach for a library for this three-line function? Just write it yourself, ffs. But the real cause of JS bloat is the so-called "front-end fr…

> you could just modify your real DOM straight from your networking code

You can also use your underparts as a hat. It doesn't mean its a good idea.

Re: The three pillars of JavaScript bloat

#113

Post by IsTom »

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?

He's very efficient with prose and I find it a joy to read (well, given what he's writing about it's not always joy, but still). I'm not sure he's following that rule 100% of the time, but it's close. Depending on the setting, you can often describe it through characters' actions or how it shapes them.

Re: The three pillars of JavaScript bloat

#115

Post by RadiozRadioz »

procaryote wrote: post #87

The most frustrating thing with the "Atomic architecture" bit with tiny packages is how obviously stupid it is. Any borderline sane person should look at isOdd/isEven and see that it's an awful idea Instead they've elevated it to a cultural pillar and think they've come up with a great innovation. It's like talking to antivaxers

It's because it has a smart-sounding name. Some people are shallow and performative; some nice-looking blog post says they can have "atomic architecture", then the trend starts and everybody wants to show how enlightened they are.

Re: The three pillars of JavaScript bloat

#116

Post by padjo »

procaryote wrote: post #87

The most frustrating thing with the "Atomic architecture" bit with tiny packages is how obviously stupid it is. Any borderline sane person should look at isOdd/isEven and see that it's an awful idea Instead they've elevated it to a cultural pillar and think they've come up with a great innovation. It's like talking to antivaxers

The philosophy was kinda refreshing in the early days. There was a really low barrier to publishing and people were encouraged to build and share tools rather than hoard things. It was probably somewhat responsible for the success of npm and the node ecosystem, especially given the paltry standard lib.

Of course, like most things, when taken to an extreme it becomes absurd and you end up with isOdd.

Re: The three pillars of JavaScript bloat

#119

Post by wiseowise »

grishka wrote: post #60

Yes, of course the tiny packages cause some of the bloat. As mainly a Java developer being pretty paranoid about my dependency tree (I'm responsible for every byte of code I ship to my users, whether I wrote it or not), I'm always blown away by JS dependency trees. Why would you reach for a library for this three-line function? Just write it yourself, ffs. But the real cause of JS bloat is the so-called "front-end fr…

> Second of all, what's this deal with mutating some model object, discarding the exact change that was made, and then making the "framework" diff the old object with the new one, call your code to render the "virtual DOM", then diff that, and only then update the real DOM tree? This is such an utterly bonkers idea to me. Like, you could just modify your real DOM straight from your networking code, you know?

https://youtu.be/Q9MtlmmN4Q0?t=519&is=Wt3IzexiOX4vMPZf

Also, why do you use SQL and databases? Couldn’t you just modify files on the filesystem?

Re: The three pillars of JavaScript bloat

#120

Post by srdjanr »

onion2k wrote: post #98

Fallback support is a legitimate reason for additional code being in the bundle, but it's not 'bloat' because it's necessary. In an ideal world every website would generate ES5, ES6, and ES2025 bundles and serve the smallest one that's necessary for the app to run based on the browser capabilities, but that is genuinely quite hard to get right and the cost of getting it wrong is a broken app so it's understandable wh…

Bloat is mostly added by package authors, not website authors. And they can't know who's running it and can't look at the metrics. I doubt many website authors directly use isEven or polyfills.
Post reply on HN