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

191–200 of 301 posts

Re: The three pillars of JavaScript bloat

#191

Post by Defenestresque »

cwnyth wrote: post #26
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'…

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

For the curious, the rest of the types:

Use the time of a total stranger in such a way that he or she will not feel the time was wasted.

Give the reader at least one character he or she can root for.

Every character should want something, even if it is only a glass of water.

Every sentence must do one of two things—reveal character or advance the action.

Start as close to the end as possible.

Be a sadist. No matter how sweet and innocent your leading characters, make awful things happen to them—in order that the reader may see what they are made of.

Write to please just one person. If you open a window and make love to the world, so to speak, your story will get pneumonia.

Give your readers as much information as possible as soon as possible. To heck with suspense. Readers should have such complete understanding of what is going on, where and why, that they could finish the story themselves, should cockroaches eat the last few pages.

The greatest American short story writer of my generation was Flannery O'Connor (1925-1964). She broke practically every one of my rules but the first. Great writers tend to do that.

Re: The three pillars of JavaScript bloat

#192

Post by grishka »

panstromek wrote: post #84
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, somethi…

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.

Re: The three pillars of JavaScript bloat

#193

Post by jgilias »

AltruisticGapHN wrote: post #170

"some people apparently exist who need to support ES3 - think IE6/7, or extremely early versions of Node.js" Seriously what kind of business today needs to support ES3 browsers? Even banking sites should refuse to run on such old devices out of security concerns.

I remember reading somewhere that Deutsche Bahn is running Windows 3.1 for something still?

Re: The three pillars of JavaScript bloat

#194

Post by simonw »

josephg wrote: post #190
simonw wrote: post #182

Earlier quoted context omitted.

Those aren't a standard library for the language itself - they're not showing up in browsers, for example.

Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?

What standard library? Do you mean the built-in Array.x etc methods you get in the core language spec?

Re: The three pillars of JavaScript bloat

#195

Post by RadiozRadioz »

padjo wrote: post #188
RadiozRadioz wrote: post #171

Earlier quoted context omitted.

Interesting how you decided to switch to hyperbole instead of providing evidence for your claim. Backing up your viewpoint would have easily shut me down, putting the ball in my court to do the same. Instead you gave a knee-jerk childish response.

Interesting that rather than try to bolster your claim you resorted to a logical fallacy to justify it.

Hypocritical; you did the same with the hyperbole. Why are you stooping to my level instead of being the better person?

Re: The three pillars of JavaScript bloat

#196

Post by [deleted] »

stevoski wrote: post #107

Well-written article, manages not to sound rant-y while describing the problem well. I feel like part of the blame for the situation is that JavaScript has always lacked a standard library which contains the "atomic architecture" style packages. (A standard library wouldn't solve everything, of course.)

[deleted]

Re: The three pillars of JavaScript bloat

#198

Post by grishka »

wiseowise wrote: post #119
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://…

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.

Re: The three pillars of JavaScript bloat

#199

Post by grishka »

padjo wrote: post #112
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.

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.

Re: The three pillars of JavaScript bloat

#200

Post by tankenmate »

Maxion wrote: post #59
anematode wrote: post #51

Earlier quoted context omitted.

Honestly, Vite is all you need. :) It's super flexible compared to the status quo of require vs. import etc. For example, I recently wanted to ship a WASM binary along with the JS rather than making it a separate download (to avoid having to deal with the failure case of the JS code loading and the WASM not fetching). All I had to do was import `a.wasm?url` and it did the base64 embedding and loading automatically.

This sentiment is all well and good, but when you end up in a new-to-you JS codebase with a list of deps longer than a Costco receipt using some ancient Webpack with it's config split into 5 or so files, then no-one is letting you upgrade to vite unless the site is completely down.

It's almost like Churchill's quip "He has all the virtues I dislike and none of the vices I admire". In other words, in some ways the JS ecosystem rushes to all the tech debt inducing "shiny shiny" and avoids all the tech debt reducing "hard work of refactoring and wisdom". It's almost like a large chunks of the JS ecosystem thrives on "the dopamine hit". Santayana's wisdom whispers behind every import.
Post reply on HN