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

131–140 of 301 posts

Re: The three pillars of JavaScript bloat

#131

Post by yurishimo »

burntoutgray wrote: post #5

I have a single pillar, admittedly for in-house PWAs: Upgrade to the current version of Chrome then if your problem persists, we'll look into it.

This is how it should be for internal stuff! Corporate IT wants everyone to update anyway so there really isn’t a downside.

One thing I kinda understand is users who want to use a more performant browser (safari really does sip memory I’ve found compared to chrome) but that’s kind of a side point. But if your company decides this is the browser(s) we support, then it makes sense and is the right way to go about it.

Re: The three pillars of JavaScript bloat

#132

Post by auxiliarymoose »

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.

There are certainly security benefits to keeping things in-house. Less exposure to supply-chain attacks (e.g. shai-hulud malware) and widespread security bugs (e.g. react server components server-side RCE). Plus it's much easier to do a complete audit and threat model of the application when you built and understand everything soup-to-nuts.

Of course, it also means you have to be cautious about problems that dependencies promise to solve (e.g. XSS), but at the same time, bringing in a bunch of third-party code isn't a substitute for fully understanding your own system.

Re: The three pillars of JavaScript bloat

#133

Post by bell-cot »

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.

> The client has not had to pay a cent for ...

From human society's PoV, you sound like a 10X engineer and wonderful person.

But from the C-suite's PoV ...yeah. You might want to keep quite about this.

Re: The three pillars of JavaScript bloat

#134

Post by yurishimo »

kennywinker wrote: post #47
est wrote: post #24

More like a nodejs bloat rather than JS bloat. For personal objects I always prompt the AI to write JS directly, never introduce nodejs stack unless absolutely have to. Turns out you don't always need Nodejs/Reactto make a functional SPA.

You’ve traded supply chain vulnerability for slop vulnerability.

Except your supply chain could also be slop and you have no idea (unless you’re auditing your dependencies, right?).

I’d take vibe coded vanilla js slop over npm dependency hell every day of the week.

Re: The three pillars of JavaScript bloat

#135

Post by robpalmer »

rtpg wrote: post #27

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account Like seriously... at 50 million downloads maybe you should vendor some shit in. Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger…

The article and (overall) this comments section has thankfully focused on the problem domain, rather than individuals.

As the article points out, there are competing philosophies. James does a great job of outlining his vision.

Education on this domain is positive. Encouraging naming of dissenters, or assigning intent, is not. Folks in e18e who want to advance a particular set of goals are already acting constructively to progress towards those goals.

Re: The three pillars of JavaScript bloat

#136

Post by egeozcan »

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

The philosophy was kinda refreshing in the early days. There was a really low barrier to publishing and people were encouraged to build and share tools rather than hoard things. It was probably somewhat responsible for the success of npm and the node ecosystem, especially given the paltry standard lib. Of course, like most things, when taken to an extreme it becomes absurd and you end up with isOdd.

I think the issue is that the JavaScript ecosystem is so large that even the strangest extremes manage to survive. Even if they resonate with just 0.1% of developers, that’s still a lot of developers.

The added problem with the atomic approach is that it makes it very easy for these fringes to spread throughout the ecosystem. Mostly through carelessness, and transitive dependencies.

Re: The three pillars of JavaScript bloat

#137

Post by k__ »

anematode wrote: post #52
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…

This is absolutely the way to go

Doesn't this go against the credo of not building your own crypto?

Re: The three pillars of JavaScript bloat

#138

Post by stingraycharles »

socalgal2 wrote: post #91
sheept wrote: 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.

This is not true at all.

Re: The three pillars of JavaScript bloat

#139

Post by deanc »

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.

Re: The three pillars of JavaScript bloat

#140

Post by Tade0 »

socalgal2 wrote: post #91
sheept wrote: 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.

A while ago I started a game project in Rust using one of the popular engines.

10GB of build artifacts for the debug target.

Post reply on HN