Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

141–150 of 301 posts

Re: The three pillars of JavaScript bloat

#142

Earlier quoted context omitted.

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.

That’s not how we started down this path. See snark-free sibling comment from padjo.

[deleted]

Re: The three pillars of JavaScript bloat

#143
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 ).

Sometimes it's a result of unforeseen consequences of design decisions.

All pre-signal Angular code must be compiled down to JS which replaces native async with Promise.

Why is that so? For a long time Angular's change detection worked by overriding native functions like setTimeout, addEventListener etc. to track these calls and react accordingly. `async` is a keyword, so it's not possible to override it like that.

Signals don't require such trickery and also allow to significantly decrease the surface area of change detection, but to take advantage of all of that one has to essentially rewrite the entire application.

Re: The three pillars of JavaScript bloat

#144

Earlier quoted context omitted.

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.

That’s not how we started down this path. See snark-free sibling comment from padjo.

Both my claim and theirs are unsupported by evidence, therefore they are equally valid.

Re: The three pillars of JavaScript bloat

#145
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://…

The declarative vs imperative example is strange here. Why is the imperative example so convoluted? This is what one could write in js:

  badge.textContent = count > 99? '99+' : count
  badge.classList.toggle('show', count > 0)
  paper.classList.toggle('show', count > 0)
  fire.classList.toggle('show', count > 99)
The declarative example also misses the 99+ case. I don't think this example describes the difference between imperative and declarative well.

Re: The three pillars of JavaScript bloat

#147
post #80

Earlier quoted context omitted.

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…

Every cargo install (rust) I've down downloads 300 to 700 packages Every C++ app I install in linux requires 250 packages Every python app I install and then pip install requirements uses 150 packages.

I wouldn't say every Rust app does, but I do think it has become more normal for Rust apps to have 200-600 dependencies. However when I look at the list, they usually all make sense, unlike with NPM. There are rarely any one-line crates. Actually I haven't seen any yet (except joke ones of course).

There's no way the average C++ app uses 250 packages though. It's usually more like 5. C++ packaging is a huge pain so people tend to use them only when absolutely necessary, and you get huge libraries like Boost primarily because of the packaging difficulty.

I would say Python varies but 150 sounds high. Something more like 50-100 is typical in my experience.

Re: The three pillars of JavaScript bloat

#148

Earlier quoted context omitted.

That’s not how we started down this path. See snark-free sibling comment from padjo.

Both my claim and theirs are unsupported by evidence, therefore they are equally valid.

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.

Re: The three pillars of JavaScript bloat

#149
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 ).

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.

I believe if you read this article https://www.artmann.co/articles/30-years-of-br-tags your "wtf is wrong with js developers" question will be answered.
Post reply on HN