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

201–210 of 301 posts

Re: The three pillars of JavaScript bloat

#201

Post by skydhash »

simonw wrote: post #194
josephg wrote: post #190

Earlier quoted context omitted.

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?

In the browser, Javascript’s role is to add interactivity to the web page, and the API has a good surface area (even if not really pretty). People talk about the lack of standard library, but they can never say what’s missing.

https://developer.mozilla.org/en-US/docs/Web/API

The above seems fairly expansive, even if we remove all the experimental ones in the list.

Re: The three pillars of JavaScript bloat

#202

Post by sgbeal »

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

> Why not do some compile time #ifdef SUPPORT_ES3?

Rather unfortunately, JS has no native precompiler. For the SQLite project we wrote our own preprocessor to deal with precisely that type of thing (not _specifically_ that thing, but filtering code based on, e.g., whether it's vanilla, ESM, or "bunlder-friendly" (which can't use dynamically-generated strings because of castrated tooling)).

Re: The three pillars of JavaScript bloat

#203

Post by sgbeal »

Griffinsauce wrote: post #81
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?

> people would need to know how to effectively include dependencies in a way that allows them to be tree shaken

Is the need for tree-shaking not 100% a side-effect of dependency-mania? Does it not completely disappear once one has ones dependencies reduced to their absolute minimum?

Maybe i'm misunderstanding what tree-shaking is really for.

Re: The three pillars of JavaScript bloat

#205

Post by sgbeal »

casey2 wrote: post #72

There is a clear and widespread cultural problem with javascript. Sites should think seriously hard about server side rendering, both for user privacy (can't port the site to i2p if you drop 5MB every time they load a page) and freedom. Even this antibloat site smacks you with ~100KB and links to one that smacks you with ~200KB. At this rate if you follow 20 links you'll hit a site with 104 GB of JS.

> Sites should think seriously hard about server side rendering...

The rise of AI crawlers makes that ever less appetizing. Moving the workloads to the client is, among other things, a form of DoS mitigation.

Re: The three pillars of JavaScript bloat

#206

Post by esprehn »

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.

No one really does, but there's one particular individual who keeps pushing to support things like node 0.3 and who also maintains all those low level intrinsic packages.

Re: The three pillars of JavaScript bloat

#207

Post by whstl »

RadiozRadioz wrote: post #115
procaryote wrote: post #87

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

It's not just the name or the smart explanation.

Atomic packages brings more money to the creators.

If you have two useful packages it's hard to ask for money, even if they're used by Babel or some popular React dependency.

If you have 900 packages that are transitive dependencies the same couple deps above, it's way easier to get sponsorship. This is a way to advertise themselves: "I maintain 1000 packages".

The first guy that did this in a not-nice way was a marketing/salesperson and has mentioned that they did on purpose to launch their dev career.

TLDR: This is just some weird ass pyramid thing to get Github sponsors or clout.

Re: The three pillars of JavaScript bloat

#208

Post by padjo »

RadiozRadioz wrote: post #195
padjo wrote: post #188

Earlier quoted context omitted.

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?

Nope. Just a reductio as absurdum that you decided to counter by asking that I maintain higher standards of debate than you.

The notion that atomic architecture came about because people are stupid and performative is not really useful. Its fairly misanthropic and begs the question why it became so prevalent in JS specifically.

Re: The three pillars of JavaScript bloat

#209

Post by zelphirkalt »

Maxion wrote: post #58
auxiliarymoose wrote: post #20

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…

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

Very laudable, though this is probably also part of the issue: If the client doesn't need any migration work, the dev doesn't get more money, which in turn might be phrased: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!" -- by someone other than me.

I have worked at employer, where one could have done the frontend easily in a traditional server side templating language since most of the pages where static information anyway and very little interactive. But instead of doing that and have 1 person do that, making an easily accessible and standard-conforming frontend, they decided to go with nextjs and required 3 people fulltime to maintain this, including all the usual churn and burn of updating dependencies and changing the "router" and stuff. Porting a menu from one instance of the frontend to another frontend took 3 weeks. Fixing a menu display bug after I reported it took 2 or 3 months.

Post reply on HN