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

81–90 of 301 posts

Re: The three pillars of JavaScript bloat

#81

Post by Griffinsauce »

IAmLiterallyAB wrote: post #50

For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed

Two problems: - people would need to know how to effectively include dependencies in a way that allows them to be tree shaken, that's a fragile setup - polyfills often have quirks and extra behaviours (eg. the extra functions on early promise libraries come to mind ) that they start relying on, making the switch to build-in not so easy

Also, how is this going to look over time with multiple ES versions?

Re: The three pillars of JavaScript bloat

#82

Post by bigstrat2003 »

sheept wrote: post #80
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, in…

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

It sure seems like it is because JS devs, by and large, suck at programming. C has a pretty sparse standard library, but you don't see C programmers creating shared libraries to determine if a number is odd, or to add whitespace to a string.

Re: The three pillars of JavaScript bloat

#83

Post by lukan »

sheept wrote: post #80
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, in…

"Do you think it could be inherent to the language?"

Not to the language but its users. Not to bash them, but most of them did not study IT on a university, did not learn about the KISS principle etc.

They just followed some tutorials to hack together stuff, now automated via LLM's.

So in a way the cause is the language as it is so easy to use. And the ecosystem grew organically from users like this - and yes, the ecosystem is full of bloat.

(I think claude nowdays is a bit smarter, but when building standalone html files without agents, I remember having to always tell chatgpt to explicitely NOT pull in yet another libary, but use plain vanilla js for a standard task, which usually works better and cleaner with the same lines of code or maybe 2 or 3 more for most cases. The standard was to use libaries for every new functionality )

Re: The three pillars of JavaScript bloat

#84

Post by panstromek »

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…

Yea, honestly you probably just don't understand. FE frameworks solve a specific problem and they don't make sense unless you understand that problem. That TSoding video is a prime example of that - it chooses a trivial instance of that problem and then acts like the whole problem space is trivial.

To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, something like Solid makes a lot more sense.

It's much easier to appreciate that problem if you actually try to build complex interactive UI with vanilla JS (or something like jQuery). Once you have complex state dependency graph and DOM state to preserve between rerenders, it becomes pretty clear.

Re: The three pillars of JavaScript bloat

#85

Post by ascorbic »

IAmLiterallyAB wrote: post #50

For the old version support. Why not do some compile time #ifdef SUPPORT_ES3? That way library writers can support it and if the user doesn't need it they can disable it at compile time and all the legacy code will be removed

It'll still install the dependencies, which is what this is about

Re: The three pillars of JavaScript bloat

#86

Post by bryanrasmussen »

cobbzilla wrote: post #61
hombre_fatal wrote: post #48

Earlier quoted context omitted.

> Is there no room for describing the setting? Is there no room for mood? You mean the character of a place?

sure, setting and character are the same thing

the implication is that if mood is the character of the place then those sentences that set mood are advancing character.

Re: The three pillars of JavaScript bloat

#87

Post by procaryote »

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

Re: The three pillars of JavaScript bloat

#89

Post by oflebbe »

kennywinker wrote: post #43
dfabulich wrote: post #21

Earlier quoted context omitted.

Android phones update to the latest version of Chrome for 7 years. As long as you're using browser features that are Baseline: Widely Available, you'll be using features that were working on the latest browsers in 2023; those features will work on Android 7.0 Nougat phones, released in 2016. Android Studio has a nifty little tool that tells you what percentage of users are on what versions of Android. 99.2% of users…

3.9 billion android users, means that 0.8% is 31 million people - and for a very small number of developers most of their users will be from that slice. For most of them… yeah go ahead an assume your audience is running a reasonably up to date os

Websites built with tons of polyfills are likely not run on these devices anyway, since they will run out of RAM before, let alone after they will only load after sone minutes because of CPU limitations on top of not being loaded because their x509 certs are outdated as well as the bandwith they support is not suitable to load MB sited pages

Re: The three pillars of JavaScript bloat

#90

Post by ascorbic »

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…

That's like asking "why would you use Swing when you can use Graphics2D". Sometimes you want something higher level. The DOM is great and very powerful, but when you're building a highly interactive web app you don't want to be manually mutating the DOM every time state changes.

I am a core maintainer of Astro, which is largely based around the idea that you don't need to always reach for something like React and can mostly use the web platform. However even I will use something like React (or Solid or Svelte or Vue etc) if I need interactivity that goes beyond attaching some event listeners. I don't agree with all of its design decisions, but I can still see its value.

Post reply on HN