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

71–80 of 301 posts

Re: The three pillars of JavaScript bloat

#71

Post by serial_dev »

rtpg wrote: post #65
technion wrote: post #63

Earlier quoted context omitted.

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

I think the fact that everyone cites the same is-number package when saying this is indicative of something though. Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this. I also dislike things li…

Have you heard of the left pad incident?

The problem is not imagined.

Re: The three pillars of JavaScript bloat

#72

Post by casey2 »

There is a clear and widespread cultural problem with javascript. Sites should think seriously hard about server side rendering, both for user privacy (can't port the site to i2p if you drop 5MB every time they load a page) and freedom. Even this antibloat site smacks you with ~100KB and links to one that smacks you with ~200KB. At this rate if you follow 20 links you'll hit a site with 104 GB of JS.

Re: The three pillars of JavaScript bloat

#73

Post by b00ty4breakfast »

cute_boi wrote: post #19
skydhash wrote: post #3

Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.

Rust is different as there is no runtime.

I'm not very familiar with rust but I'm pretty sure it has a runtime. Even C has a runtime.

Unless you're talking about an "environment" eg Node or the like

Re: The three pillars of JavaScript bloat

#74

Post by saghm »

technion wrote: post #63
rtpg wrote: post #27

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account Like seriously... at 50 million downloads maybe you should vendor some shit in. Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger…

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

The point isn't that everyone needs to write the same code manually necessarily. It's that an author could easily just combine the entire tree of seven line packages into the one package the create-react-app uses directly. There's no reason to have a dozen or so package downloads each with seven lines of code instead of one that that's still under under a hundred lines; that's still a pretty small network request, and it's not like dead code analysis to prune unused functions isn't a thing. If you somehow find yourself in a scenario where you would be happy to download seven lines of code, but downloading a few dozen more would be an issue, that's when you might want to consider pasting the seven lines of code manually, but I honestly can't imagine when that would be.

Re: The three pillars of JavaScript bloat

#75

Post by saghm »

stephenr wrote: post #64
zahlman wrote: post #53

Earlier quoted context omitted.

To be fair, prototypal inheritance is relatively uncommon language design. I'd rank it as considerably harder to understand than the % operator.

That's a good point, it's only been around for 30 years, and used on 95% of websites. It's not really popular enough for a developer to take an hour or two to read how it works.

The word "used" is doing some heavy lifting there. Not all usage is equal, and the fact that it's involved under the hood isn't enough to imply anything significant. Subatomic physics is used by 100% of websites and has been around for billions of years, but that's not a reason to expect every web developer to have a working knowledge of electron fields.

Re: The three pillars of JavaScript bloat

#76

Post by Griffinsauce »

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

You wouldn't if you look more deeply at this. He doesn't push for simplicity but for horrible complexity with an enormous stack of polyfills, ignoring language features that would greatly reduce all that bloat. .

Re: The three pillars of JavaScript bloat

#77

Post by hrmtst93837 »

zdc1 wrote: post #6

A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc. Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5 ).

[flagged]

Re: The three pillars of JavaScript bloat

#79

Post by saghm »

halapro wrote: post #56
userbinator wrote: post #7

Earlier quoted context omitted.

The newer version is often even more bloated. This whole article just reinforces my opinion of "WTF is wrong with JS developers" in general: a lot of mostly mindless trendchasing and reinventing wheels by making them square. Meanwhile, I look back at what was possible 2 decades ago with very little JS and see just how far things have degraded.

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

If everyone hates him and thinks his dependencies are junk, why would anyone let him introduce them to popular packages? Clearly there are at least some people who are indifferent enough if the dependencies are getting added elsewhere

Re: The three pillars of JavaScript bloat

#80

Post by sheept »

andai wrote: post #17

Great article, but I think these are all marginal. The main cause of bloat is not polyfills or atomic packages. The cause of bloat is bloat! I love this quote by Antoine de Saint-Exupéry (author of the Little Prince): "Perfection is achieved, not when there is nothing left to add, but nothing to take away." Most software is not written like that. It's not asking "how can we make this more elegant?" It's asking "what'…

All software has bloat, but npm packages and web apps are notorious for it. Do you think it could be inherent to the language?

JavaScript seems to be unique in that you want your code to work in browsers of the past and future—so a lot of bloat could come from compatibility, as mentioned in the article—and it's a language for UIs, so a lot of bloat in apps and frameworks could come from support for accessibility, internationalization, mobile, etc.

Post reply on HN