Top
Best
New

Posted by onlyspaceghost 17 hours ago

The three pillars of JavaScript bloat(43081j.com)
419 points | 243 commentspage 5
hknzerodark1 7 hours ago||
[dead]
hknzerodark1 10 hours ago||
[dead]
grishka 13 hours ago||
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 frameworks". Especially React.

First of all, why would you want to abstract away the only platform your app runs on? What for? That just changes the shape of your code but it ends up doing the same thing as if you were calling browser APIs directly, just less efficiently.

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?

Seriously, I don't understand modern web development. Neither does this guy who spent an hour and some to try to figure out React from the first principles using much the same approach I myself apply to new technologies: https://www.youtube.com/watch?v=XAGCULPO_DE

padjo 10 hours ago||
> 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.

grishka 7 hours ago||
You imply that you somehow get a visibly different end result if you touch DOM directly. Except to me, using React instead of a simple assignment to e.g. update the text on a button feels like taking several long flights that complete a lap around the world just to get from LA to SF, instead of the 1-hour direct flight.
padjo 5 hours ago|||
It's a case of Chesterton's fence. Having built complex apps pre-react, I wouldn't be in a hurry to go back to that approach because I have first hand experience of running into the problems it solves.
skydhash 6 hours ago|||
React is a paradigm change (from imperative to functional) that makes sense in a large UI project. React itself is fairly small in terms of deps.

The main issue is the tooling. JSX is nice enough (not required though) to want a transpiler that will also bundle you app. It’s from that point things get crazy. They want the transpiler to also be a bundler so that it manages their css as well. They also want it to do minification and dead code elimination. They want it to support npm dependencies,etc…

This is how you get weird ecosystems.

ascorbic 11 hours ago|||
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.

srdjanr 10 hours ago|||
Regarding tiny packages, I don't think they affect the size of shipped bundle at all. They only bloat your local dev environment.
wiseowise 10 hours ago|||
> 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?

grishka 7 hours ago|||
Yes, I don't understand "declarative" approach at all, it seems too wasteful and roundabout to me. You want to change something? You go and change it. That simple. I hate it when callbacks are abstracted away from me. Abstractions over callbacks always feel like they're getting in the way, not helping me.

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

Anyone can read a MySQL data file. IIRC the format is pretty straightforward. The whole point of doing it through the real MySQL server is to make use of indexes, the query optimizer, and proper handling of concurrency, at least. Sure you can reimplement those things, but at this point congrats, you've just reimplemented the very database system you were trying to avoid, just worse.

thomasikzelf 9 hours ago|||
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.
panstromek 11 hours ago||
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.

grishka 7 hours ago||
One of my projects does have a complex UI and is built with zero runtime dependencies on the front end. It doesn't require JS at all for most of its functionality.

I just render as much as possible on the server and return commands like "hide the element with that ID" or "insert this HTML after element with that ID" in response to some ajax requests. Outside of some very specific interactive components, I avoid client-side rendering.

panstromek 6 hours ago|||
That's good and arguably the right default for most websites.
skydhash 6 hours ago|||
I agree with you. It’s baffling to see websites (not web apps) refusing to show anything if you disable JS. And a lot of such web apps don’t need to be SPA (GitHub,…)

SPA was mean for UI that relies on the client state mostly, not on the server data (figma and other kind of online editors).

krmbzds 14 hours ago||
JavaScript bloat is downstream of low FED interest rates.
general_reveal 9 hours ago||
Anyone want to tell him programming languages don’t matter anymore?
embedding-shape 9 hours ago||
What do you use to build programs then? Or maybe you're not a software developer, then maybe I understand not fully knowing how a program gets built, but otherwise, languages will be needed for as long as we need programs.
grey-area 6 hours ago|||
Were you this excited about crypto and NFTs as well?
g947o 6 hours ago|||
No. They matter.

Show me a website where client side interaction is implemented in perl.

miranaproarrow 9 hours ago|||
there are people that still likes to understand what their language is doing and not offload all their thought to LLM
Zopieux 9 hours ago||
[dead]
pjmlp 12 hours ago||
What about only writing JavaScript when it is actually required, instead of SPAs for any kind of content?

There will be almost no bloat to worry about.

deanc 9 hours ago||
I can't help but think that whenever we have these discussions about dependency hell in the JS ecosystem that the language moves too slowly to add things to stdlib. For me, this is where bun fills the gap and they continue to pump out core stdlib packages that replace widely used dependencies. I'd really like to see Node at least do this more.
onion2k 11 hours ago|
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 why devs don't.

The other two, atomic architecture and ponyfills, are simply developer inexperience (or laziness). If you're not looking at the source of a package and considering if you actually need it then you're not working well enough. And if you've added code in the past that the metrics about what browsers your visitors are using show isn't needed any more, then you're not actively maintaining and removing things when you can. That's not putting the user first, so you suck.

srdjanr 10 hours ago|
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.