Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

241–250 of 301 posts

Re: The three pillars of JavaScript bloat

#241
post #216
post #141

Earlier quoted context omitted.

Why? Being able to redefine anything is table stakes in dynamic languages.

So? Does being able to do something means you should?

I didn’t say you should. The comment I’m replying to expressed surprise that redefining something is even possible.

Re: The three pillars of JavaScript bloat

#242
> Atomic architecture

> [...]

> Each of these having only one consumer means they’re equivalent of inline code but cost us more to acquire (npm requests, tar extraction, bandwidth, etc.).

It costs FAR more than dep install time. It has a runtime cost too, especially if in frontend code using bundlers where it also costs extra bundlespace and extra build time.

Re: The three pillars of JavaScript bloat

#243

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

> It's like talking to antivaxers

This is not helpful.

Re: The three pillars of JavaScript bloat

#244
post #169

Earlier quoted context omitted.

Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?

Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.

And yet npm install [package with 1000 recursieve dependencies] is not considered a supply chain risk at all to those security/compliance jarls.

Let alone having to check all licenses...

Re: The three pillars of JavaScript bloat

#245
post #186

“Alternatively, what’d be really nice is if they upgraded“ Easy enough for y’all with techie salaries, but as one of the millions of poor folks whose paychecks barely (or don’t even) pay the bills, it’d be really nice if we didn't have to junkheap our backbreakingly expensive hardware every few years just cuz y’all are anorexically obsessed with lean code, and find complex dependancies too confusing/bothersome to mai…

They're talking about people still running ES3 browser engines, like IE8, which was released 15+ years ago and went EOL 10+ years ago. The author could have done a better job clarifying this, but they're not pushing for a world with 2y device lifetimes.

Indeed, they're talking about the opposite extreme from the usual problem we all bemoan in here, which is JS devs being determined to use the newest shiniest thing as soon as it's been announced, instead of being willing to continue to use what they've always used and to wait until the new stuff works across all browsers. This article really surprised me, in how far some are apparently going in the opposite direction. I'm very surprised the baseline mentioned is ES3 rather than ES5 or 6.

The GP's comment - that we have to upgrade our hardware because devs are "anorexically obsessed with lean code, and find complex dependancies too confusing/bothersome" - is surely the exact opposite of reality? We have to upgrade to faster hardware because the bloat slows everything down!

Re: The three pillars of JavaScript bloat

#246

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

Somehow I doubt they use it to access another Next.js app created by some startup from SV.

Re: The three pillars of JavaScript bloat

#247

Earlier quoted context omitted.

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

String.splitRight, for one. (As an example: "www.a.north.website.com".splitRight(".", 3) == ["www.a.north", "website", "com"].)

Python and Rust have such a thing, but not e.g. Java, Go, C#. And I can't find any libraries on npm which do this. That seems like a very niche need, not actually the sort of thing whose absence causes people to have lots of npm dependencies.

Re: The three pillars of JavaScript bloat

#248
post #211

Earlier quoted context omitted.

Is there no room for describing the setting? Must every utterance that sets the atmosphere also advance the plot or reveal character? Is there no room for mood?

What is the purpose of the setting if not to reveal character or advance the plot? I don’t need to know the color of the walls if it does neither.

Framed that way you could characterize anything as ultimately serving the characters or plot.

Re: The three pillars of JavaScript bloat

#249
post #211

Earlier quoted context omitted.

What is the purpose of the setting if not to reveal character or advance the plot? I don’t need to know the color of the walls if it does neither.

Framed that way you could characterize anything as ultimately serving the characters or plot.

Not really. There are infinite insignificant details that could be included that should not be included because they do neither in any meaningful way.

Re: The three pillars of JavaScript bloat

#250

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

Yeah I've been doing this more and more. The friction of keeping dependencies updated has gotten worse than the friction of just maintaining the (often times) 20 or so lines you need to write yourself. Not to mention the pain you'll eventually find yourself when a bug isn't patched fast enough, or when you need to make a small change, or when a transitive dependency you've never heard of gets compromised...
Post reply on HN