8 ms·

The three pillars of JavaScript bloat

489 points by onlyspaceghost 7mo ago

irenetusuq 6mo ago
[dead]
turtleyacht 7mo ago
It would be interesting to extend this project where opt-in folks submit a "telemetry of diffs," to track how certain dependencies needed to be extended, adapted, or patched; those special cases would be incorporated as future features and new regression tests. Someday, packages may just be "utility-shaped holes" in which are filled in and published on the fly. Package adoption could come from 80/20 agents [1] exploring these edges (security notwithstanding). However, as long as new packages inherit dependencies according to a human author's whims, that "voting" cycle has not yet been replaced. [1] https://news.ycombinator.com/item?id=47472694 https://news.ycombinator.com/item?id=47472694
skydhash 7mo ago
Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.
- cute_boi 7mo ago
  Rust is different as there is no runtime.
  - onlyspaceghost 7mo ago
    but it still increases compile time, attack surface area, bandwidth use, etc.
  - b00ty4breakfast 6mo ago
    I'm not very familiar with rust but I'm pretty sure it has a runtime. Even C has a runtime. Unless you're talking about an "environment" eg Node or the like
    - embedding-shape 6mo ago
      Indeed Rust has a runtime, I'm not sure why the whole "Rust has no runtime" comes from, I keep seeing it repeated from time to time, but can't find the origin of this, I don't think it's ever been true?
      - b00ty4breakfast 6mo ago
        The only thing I can think is that folks are getting confused by stuff like the JRE and Node being called "runtime environments".
  - vsgherzi 6mo ago
    I’m assuming you’re referring to an async runtime like tokio. In my option the dependency problem exists with or without tokio. Tokio is probably one of the best dependencies
  - wiseowise 6mo ago
    Yes, instead we pay with requiring supercomputers and 10 hour compile times to process billion of those “atomic architecture”.
- CoderLuii 6mo ago
  the docker side of this is painful too. every extra dependency in any language means a bigger image, more layers to cache, more things that can break during a multi-arch build. ive been building images that are 4GB because of all the node and python tooling bundled in. micro packages make it worse because each one adds metadata overhead on top of the actual code.
- vsgherzi 6mo ago
  Yeah I’m in the same boat here I really don’t like the dependency sprawl of rust. I understand there’s tradeoffs but I really wanna make sure we don’t end up like npm
- chrismorgan 6mo ago
  Rust is not going down the same path, and it’s ludicrous to suggest it is. Almost none of the first and third pillars are even possible in Rust, and to the extent they are, they’re not a problem in practice. As for the second, “atomic architecture”, it’s not taken anywhere near the extreme it frequently is with npm. There are not many micro-packages that get used, and where they are, they mostly make more sense than they did in npm, and they don’t have anywhere near the cost they do in npm, and can have some concrete advantages.
sheept 7mo ago
I wonder this means there could be a faster npm install tool that pulls from a registry of small utility packages that can be replaced with modern JS features, to skip installing them.
- seniorsassycat 7mo ago
  Not sure about faster, but you could do something with overrides, especially pnpm overrides since they can be configured with plugins. Build a list of packages that can be replaced with modern stubs. It couldn't inine them, but it could replace ponyfils with wrappers for native impls, and drop the fallback. It could provide simple modern implementations of is-string, and dedupe multiple major versions, tho that begs the question what breaking change lead to a new mv and why?
burntoutgray 7mo ago
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.
- deleted 6mo ago
  [deleted]
- GianFabien 6mo ago
  Keeping it simple usually saves the day.
- yurishimo 6mo ago
  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.
zdc1 7mo ago
A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc. Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5 https://caniuse.com/es5).
- userbinator 7mo ago
  The newer version is often even more bloated. This whole article just reinforces my opinion of "WTF is wrong with JS developers" in general: a lot of mostly mindless trendchasing and reinventing wheels by making them square. Meanwhile, I look back at what was possible 2 decades ago with very little JS and see just how far things have degraded.
  - michaelchisari 7mo ago
    A standard library can help, but js culture is not built in a way that lends to it the way a language like Go is. It would take a well-respected org pushing a standard library that has clear benefits over "package shopping."
  - halapro 6mo ago
    > WTF is wrong with JS developers Don't confuse "one idiot who wants to support Node 0.4 in 2026" with "JS developers". Everybody hates this guy and he puts his hands into the most popular packages, introducing his junk dependencies everywhere.
    - Maxion 6mo ago
      The other problem is that this is a bit of a circular path, with deps being so crap and numerous, upgrading existing old projects become a pain. There are A LOT of old projects out there that haven't been updated simply because the burden to do so is so high.
    - userbinator 6mo ago
      Then I wish there were more of these "idiots who want to support Node 0.4 in 2026". Maybe they're the ones with the common sense to value stability and backwards compatibility over constantly trendchasing the new and shiny and wanting to break what was previously working in the misguided name of "progress".
leontloveless 7mo ago
[dead]
sipsi 7mo ago
i suggess jpeg.news dot com
SachitRafa 7mo ago
The cross-realm argument for packages like is-string is the one I find hardest to dismiss, but even there the math doesn't add up. The number of projects actually passing values across realms is tiny, and those projects should be the ones pulling in cross-realm-safe utilities, not every downstream consumer of every package that ever considered it. The deeper problem with Pillar 2 is that atomic packages made sense as a philosophical argument but broke down the moment npm made it trivially easy to publish. The incentive was "publish everything, let consumers pick what they need" but the reality is consumers never audit their trees,they just install and forget. So the cost that was supposed to be opt-in became opt-out by default. The ponyfill problem feels most tractable to me. A simple automated check "does every LTS version of Node support this natively?" could catch most of these. The e18e CLI is a good start but it still requires someone to run it intentionally. I wonder if something like a Renovate-style bot that opens PRs to remove outdated ponyfills would move the needle faster than waiting for maintainers to notice.
andai 7mo ago
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's the easiest way to add more stuff?" The answer is `npm i more-stuff`.
- cwnyth 7mo ago
  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."
  - cobbzilla 6mo ago
    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?
    - hombre_fatal 6mo ago
      > Is there no room for describing the setting? Is there no room for mood? You mean the character of a place?
      - cobbzilla 6mo ago
        sure, setting and character are the same thing
        bryanrasmussen 6mo ago
        the implication is that if mood is the character of the place then those sentences that set mood are advancing character.
auxiliarymoose 7mo ago
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 dependency-heavy projects.
- CoderLuii 6mo ago
  been doing something similar. the projects ive been building recently use as few dependencies as possible and honestly the maintenance burden dropped significantly. when something breaks you actually know where to look instead of digging through 15 layers of node_modules. people said the same thing to me about it not scaling but the opposite turned out to be true.
  - auxiliarymoose 6mo ago
    yeah, plus stack traces, debuggers, and profiling tools are easier to use when all of the non-essential complexity is stripped out. which in turn means it's possible to work productively on software that solves more complex problems. that's in contrast with the sort of stuff that invariably shows up when something falls over somewhere in a dependency: cannot access property "apply" of null at forEach() at setTimeout() at digest() at callback() at then() ... it's not fun to step through or profile that sort of code either...
- anematode 6mo ago
  This is absolutely the way to go
  - k__ 6mo ago
    Doesn't this go against the credo of not building your own crypto?
    - 6mo ago
est 7mo ago
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.
- kennywinker 6mo ago
  You’ve traded supply chain vulnerability for slop vulnerability.
  - yurishimo 6mo ago
    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.
il-b 7mo ago
The elephants in the room are react and webpack.
rtpg 7mo ago
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 than the minified version of this code! At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully. https://www.npmjs.com/package/has-symbols https://www.npmjs.com/package/has-symbols https://www.npmjs.com/package/is-string https://www.npmjs.com/package/is-string https://github.com/ljharb https://github.com/ljharb
- hinkley 7mo ago
  Hat tip to Sindre who has fifty bagillion packages but few of them depend on more than one of his other packages.
- h4ch1 7mo ago
  I remember seeing this one guy who infiltrated some gh org, and then started adding his own packages to their dependencies or something to pad up his resume/star count. Really escapes me who it was.
  - g947o 6mo ago
    https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/aria-query/pull/497 https://github.com/A11yance/aria-query/pull/497
    - h4ch1 6mo ago
      yes! this.
    - eudamoniac 6mo ago
stephenr 7mo ago
The primary cause of JS bloat is assuming you need JS or that customers want whatever you're using it to provide. For $client we've taken a very minimal approach to JavaScript, particularly on customer facing pages. An upcoming feature finally replaces the last jquery (+ plugin) dependent component on the sales page, with a custom implementation. That change shaved off ~100K (jquery plus a plugin removed) and for most projects now that probably seems like nothing. The sales page after the change is now just 160K of JS. The combination of not relying on JS for everything and preferring use-case-specific implementations where we do, means we aren't loading 5 libraries and using 1% of each. I'm aware that telling most js community "developers" to "write your own code" is tantamount to telling fish to "just breathe air".
- CoderLuii 6mo ago
  160K total is impressive. most landing pages i see are shipping 2-3MB of js before the first paint. the "write your own code" approach gets laughed at but when you actually do it the result is faster, easier to debug, and you dont wake up one morning to find out one of your 200 dependencies got compromised.
  - stephenr 6mo ago
    Wait till I tell those people we keep all our dependencies (js and backend) in our own git repo. Updating dependencies is a task a person does, followed by committing the changes to the repo. I am aware a lot of these ideas are heretical to a lot of software developers these days.
skrtskrt 7mo ago
the fact that you can just redefine Map in a script is mind boggling
- xigoi 6mo ago
  Why? Being able to redefine anything is table stakes in dynamic languages.
  - g947o 6mo ago
    So? Does being able to do something means you should?
    - xigoi 6mo ago
      I didn’t say you should. The comment I’m replying to expressed surprise that redefining something is even possible.
  - fragmede 6mo ago
    You can't assign a value to false, for example, so "anything" isn't everything (Node v22.17.0). > false = 4 false = 4 ^^^^^ Uncaught SyntaxError: Invalid left-hand side in assignment Fascinatingly enough though, you can assign a value to NaN. It doesn't stick tho. > NaN NaN > NaN = 42 42 > NaN NaN > (map behaves as described.)
deleted 7mo ago
[deleted]
krmbzds 7mo ago
JavaScript bloat is downstream of low FED interest rates.
IAmLiterallyAB 6mo ago
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
- Griffinsauce 6mo ago
  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?
  - sgbeal 6mo ago
    > 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.
- ascorbic 6mo ago
  It'll still install the dependencies, which is what this is about
- sgbeal 6mo ago
  > 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)).
grishka 6mo 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 https://www.youtube.com/watch?v=XAGCULPO_DE
- panstromek 6mo 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 6mo 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.
pjmlp 6mo 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.
casey2 6mo ago
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.
- sgbeal 6mo ago
  > 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.
- g947o 6mo ago
  > Sites should think seriously hard about server side rendering You think the average site owner plus wix/squarespace is going to spend a lot of money beefing up their CPU and RAM to marginally "improve user experience" when they could and have been offloading rendering client side all these years?
deleted 6mo ago
[deleted]
procaryote 6mo ago
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
- IsTom 6mo ago
  I've seen some juniors writing risoni code like that. They've heard that you shouldn't write big functions, so obviously they forcefully split things until they can't be split anymore.
- RadiozRadioz 6mo ago
  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.
  - williamcotton 6mo ago
    That’s not how we started down this path. See snark-free sibling comment from padjo.
    - deleted 6mo ago
      [deleted]
    - RadiozRadioz 6mo ago
      Both my claim and theirs are unsupported by evidence, therefore they are equally valid.
      - padjo 6mo ago
        A third argument is that it was because of aliens from the planet Blotrox Prime. But I suppose without evidence we'll just have to accept that all three theories are equally probable.
lerp-io 6mo ago
just make react native to browser and everything else thats a one off can be ai generated
deleted 6mo ago
[deleted]
deleted 6mo ago
[deleted]
steveharing1 6mo ago
So the guy who called JS, a weird language was not wrong huh?
- qayxc 6mo ago
  Look at Python - similar story. Once a reasonably usable global package registry exists, this is exactly what happens. Languages and standard libraries evolve, shipped code more often than not doesn't.
  - steveharing1 6mo ago
    [dead]
onion2k 6mo 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 6mo 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.
wonnage 6mo ago
An underappreciated source of bloat is module duplication stemming from code splitting. SPAs have a bad rep because you don't expect to download an entire app just to load one page on the web. You can solve this by code splitting. But if you just naively split your app by route, you'll end up with duplicate copies of every shared module. Bundlers handle this by automatically creating bundles for shared modules. But if you optimize to avoid all shared modules, you end up with hundreds of tiny files. So most bundlers enforce a minimum size limit. That's probably fine for a small app. But one or more of these things happens: 1. Over time everybody at the company tends to join one giant SPA because it's the easiest way to add a new page. 2. Code splitting works so well you decide to go ham and code split all of the things - modals, below-the-fold content, tracking scripts, etc. Now you'll run into situations where 20 different unrelated bundles happen to share a single module, but that module is too small for the bundler to split out, and so you end up downloading it N times.
deleted 6mo ago
[deleted]
stevoski 6mo ago
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.)
- couscouspie 6mo ago
  I like rants though. They help me understand, not only how people feel about stuff, but also why.
- josephg 6mo ago
  What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.
  - jefftk 6mo ago
    We're talking about JS in browsers: many fewer options there, plus needing to support old devices.
  - simonw 6mo ago
    Those aren't a standard library for the language itself - they're not showing up in browsers, for example.
    - josephg 6mo ago
      Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?
      - simonw 6mo ago
        What standard library? Do you mean the built-in Array.x etc methods you get in the core language spec?
deleted 6mo ago
[deleted]
hknzerodark1 6mo ago
[dead]
wiseowise 6mo ago
> Using the e18e CLI to detect replaceable dependencies https://github.com/e18e/cli https://github.com/e18e/cli That’s awesome. Could be hooked as a pre-commit for agents to do the grunt work of migration.
- gameroman 6mo ago
  e18e CLI is great
deanc 6mo 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.
general_reveal 6mo ago
Anyone want to tell him programming languages don’t matter anymore?
- Zopieux 6mo ago
  [dead]
- miranaproarrow 6mo ago
  there are people that still likes to understand what their language is doing and not offload all their thought to LLM
- embedding-shape 6mo 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 6mo ago
  Were you this excited about crypto and NFTs as well?
- g947o 6mo ago
  No. They matter. Show me a website where client side interaction is implemented in perl.
prinny_ 6mo ago
Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ignorance, not only of the topic at hand, but of an engineering mindset in general.
- KronisLV 6mo ago
  > “JS developers bad“ I found it to be a nice post that documents why things sometimes are bad. It didn’t feel accusatory at the developers themselves, but seemed to serve as a reasonable critique of the status quo?
  - n_e 6mo ago
    I assume they were talking about the comments here, not the post which I agree is great.
- n_e 6mo ago
  [dead]
- follie 6mo ago
  I find the mindset of trying to understand and accept bad fine in moderation but as defeatist when taken past the end of the block. It doesn't matter why JS is bad and will harm your future prospects if you approach it with too much acceptance. We always need to be examining the practice in front of us and the theory that would be a better replacement for it and trying to make the leaps at the right times to keep getting paid while not becoming part of the problem ourselves. Science advances one funeral at a time applies to software with things going at a faster pace so a good software engineer needs to fake a few funerals or really be senior at 4 years to be dead by 7.
algolint 6mo ago
[flagged]
- whstl 6mo ago
  I like to criticize React as much as the next person, but this is an JS ecosystem problem around third-party libraries, not a React problem per se. If you're using third-party NPM packages to do "Vanilla", you're will probably run into the same problem. If you import React directly from a CDN, you won't.
  - algolint 6mo ago
    [flagged]
    - whstl 6mo ago
      Yeah, I agree. Build systems (especially Babel and Webpack) were the first big culprits in terms of dependency bloat, and it was very rare to see React without them.
  - algolint 6mo ago
    [flagged]
ctvdev 6mo ago
[dead]
AltruisticGapHN 6mo ago
"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.
- skrebbel 6mo ago
  This is 100% teams who set up their build tooling back in 2015 and haven't updated since. There's plenty widely used apps and libs that date this far back, and back then, IE8 compat was considered pretty important still, esp for products targeting enterprise/government customers. Upgrading eg Webpack and Babel and polyfill stacks and all that across multiple major versions is a serious mess. Lots of breaking changes all around. Much better to just ship features. If it ain't broke, don't fix it!
- jgilias 6mo ago
  I remember reading somewhere that Deutsche Bahn is running Windows 3.1 for something still?
  - szatkus 6mo ago
    Somehow I doubt they use it to access another Next.js app created by some startup from SV.
    - jgilias 6mo ago
      The point was - some people are running hugely outdated stacks for “reasons”.
- esprehn 6mo ago
  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.
wheattoast 6mo ago
“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 maintain.
- jefftk 6mo ago
  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.
  - abanana 6mo ago
    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!
    - wheattoast 6mo ago
      Fair, but personally I’d absolutely prefer slower bloated code with twice the lifespan to faster code that forces me to buy new hardware I can’t afford. But I’m a nearly extinct type of consumer who happily clings to pre-subscription-era software (e.g., Photoshop 7, Sketchup 2017). I understand and begrudgingly accept that businesses couldn’t survive by tending to the desires of folks like me.
hknzerodark1 6mo ago
[dead]
butILoveLife 6mo ago
[dead]
g947o 6mo ago
https://immich.app/cursed-knowledge https://immich.app/cursed-knowledge > There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them. > https://github.com/immich-app/immich/pull/10690 https://github.com/immich-app/immich/pull/10690
- 12345hn6789 6mo ago
  A little more context since they scrubbed that PR. https://news.ycombinator.com/item?id=45447390 https://news.ycombinator.com/item?id=45447390 or https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/axobject-query/pull/354 This user actively gets paid off of how many downloads their packages get, which makes sense why there are so many. As well as the attitude to change others repositories to use his packages
sylware 6mo ago
It is not javascript itself (until the interpreter is written in plain and simple C or similar), it is the abomination of the web engine, one of the 2.5 from the whatng cartel.
derodero24 6mo ago
[flagged]
huhulove1990 6mo ago
[dead]
DanielHB 6mo ago
> 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.
tylerchilds 6mo ago
I agree, but would also posit a parallel The Three Pillars of JavaScript Ecosystem Bloat for example, javascript runs in a browser or on microcontrollers. you can write code that work for both natively [1]. TypeScript-- a mechanism that needs to compile first into javascript React-- a mechanism that needs to compile first into javascript Configuration-de-jour-- Depending on how you need to string your TypeScript and React together, there's a thing you need to manage your javascript managers. Vite is the best option in this field, since it recognizes exposing tools to fine tune how to optimize your resulting javascript from your typescript and react is a terrible idea that leads to mass fragmentation on a global scale for what it even means to "spin up a js project" In conclusion, is javascript a compile target like assembly or a language that people can handcode to eek performance out of like assembly? [1]: https://github.com/bellard/mquickjs https://github.com/bellard/mquickjs
- tylerchilds 6mo ago
  To the downvote— you know JavaScript is the blitting engine for <company that pioneered the button on your remote to stream Hollywood to your living room on a shitty smart TV microcontroller>, right?
socalgal2 6mo ago
There was a time I'd use dependencies for trivial things like copying a file during building or running things in parallel. Now I just script those in js and call that js from my build. Even testing is now included in node so I stopped using a testing framework.
kigiri 6mo ago
I work on a ~9y old nodejs codebase, have none of those issues, we have 8 dependencies, this is fully resolved tree. One to generate zip files, one for markdown parsing, connecting to postgres, etc... most of them have no sub dependencies. We always reach out first to what nodejs lib have, try to glue ourself small specific piece of code when needed. The app is very stable and we have very few frustrations I used to have before. Note that we used to have way more but bit by bit removed them. Now I would whitelist anything from the deno std* lib, they did a great job with that, even if you don't use Deno, with what ever your runtime provide plus deno std you never need more than a few packages to build anything. JS is doing pretty good if you are mindful about it.
- g947o 6mo ago
  What do you use for testing? Built-in test runner? I have a few projects that use mocha, and I recently noticed that several vulnerabilities come from its transitive dependencies, and there is no easy fix today. The project hasn't seen updates for a while. Makes me wonder if I should just ditch mocha completely.
baubino 6mo ago
I feel vindicated by this recent turn back to vanilla js (which I never left).
Rithan 6mo ago
[dead]
nektro 6mo ago
> Atomic architecture this an artifact of dealing with a pre-esm ecosystem. before esm these small packages were the easiest way to help bundlers do better tree shaking
Levitating 6mo ago
The problem is that people prefer adding a shebang regex dependency, rather than just copy the regex into their codebase. If your dependency is less than 10 lines of code, you shouldn't depend on it. You can just copy those 10 lines of code.

489 points by onlyspaceghost 7mo ago

[dead]

It would be interesting to extend this project where opt-in folks submit a "telemetry of diffs," to track how certain dependencies needed to be extended, adapted, or patched; those special cases would be incorporated as future features and new regression tests. Someday, packages may just be "utility-shaped holes" in which are filled in and published on the fly. Package adoption could come from 80/20 agents [1] exploring these edges (security notwithstanding). However, as long as new packages inherit dependencies according to a human author's whims, that "voting" cycle has not yet been replaced. [1] https://news.ycombinator.com/item?id=47472694 https://news.ycombinator.com/item?id=47472694

skydhash 7mo ago

Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.

cute_boi 7mo ago
Rust is different as there is no runtime.
- onlyspaceghost 7mo ago
  but it still increases compile time, attack surface area, bandwidth use, etc.
- b00ty4breakfast 6mo ago
  I'm not very familiar with rust but I'm pretty sure it has a runtime. Even C has a runtime. Unless you're talking about an "environment" eg Node or the like
  - embedding-shape 6mo ago
    Indeed Rust has a runtime, I'm not sure why the whole "Rust has no runtime" comes from, I keep seeing it repeated from time to time, but can't find the origin of this, I don't think it's ever been true?
    - b00ty4breakfast 6mo ago
      The only thing I can think is that folks are getting confused by stuff like the JRE and Node being called "runtime environments".
- vsgherzi 6mo ago
  I’m assuming you’re referring to an async runtime like tokio. In my option the dependency problem exists with or without tokio. Tokio is probably one of the best dependencies
- wiseowise 6mo ago
  Yes, instead we pay with requiring supercomputers and 10 hour compile times to process billion of those “atomic architecture”.
CoderLuii 6mo ago
the docker side of this is painful too. every extra dependency in any language means a bigger image, more layers to cache, more things that can break during a multi-arch build. ive been building images that are 4GB because of all the node and python tooling bundled in. micro packages make it worse because each one adds metadata overhead on top of the actual code.
vsgherzi 6mo ago
Yeah I’m in the same boat here I really don’t like the dependency sprawl of rust. I understand there’s tradeoffs but I really wanna make sure we don’t end up like npm
chrismorgan 6mo ago
Rust is not going down the same path, and it’s ludicrous to suggest it is. Almost none of the first and third pillars are even possible in Rust, and to the extent they are, they’re not a problem in practice. As for the second, “atomic architecture”, it’s not taken anywhere near the extreme it frequently is with npm. There are not many micro-packages that get used, and where they are, they mostly make more sense than they did in npm, and they don’t have anywhere near the cost they do in npm, and can have some concrete advantages.

sheept 7mo ago

I wonder this means there could be a faster npm install tool that pulls from a registry of small utility packages that can be replaced with modern JS features, to skip installing them.

seniorsassycat 7mo ago
Not sure about faster, but you could do something with overrides, especially pnpm overrides since they can be configured with plugins. Build a list of packages that can be replaced with modern stubs. It couldn't inine them, but it could replace ponyfils with wrappers for native impls, and drop the fallback. It could provide simple modern implementations of is-string, and dedupe multiple major versions, tho that begs the question what breaking change lead to a new mv and why?

burntoutgray 7mo ago

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.

deleted 6mo ago
[deleted]
GianFabien 6mo ago
Keeping it simple usually saves the day.
yurishimo 6mo ago
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.

zdc1 7mo ago

A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc. Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5 https://caniuse.com/es5).

userbinator 7mo ago
The newer version is often even more bloated. This whole article just reinforces my opinion of "WTF is wrong with JS developers" in general: a lot of mostly mindless trendchasing and reinventing wheels by making them square. Meanwhile, I look back at what was possible 2 decades ago with very little JS and see just how far things have degraded.
- michaelchisari 7mo ago
  A standard library can help, but js culture is not built in a way that lends to it the way a language like Go is. It would take a well-respected org pushing a standard library that has clear benefits over "package shopping."
- halapro 6mo ago
  > WTF is wrong with JS developers Don't confuse "one idiot who wants to support Node 0.4 in 2026" with "JS developers". Everybody hates this guy and he puts his hands into the most popular packages, introducing his junk dependencies everywhere.
  - Maxion 6mo ago
    The other problem is that this is a bit of a circular path, with deps being so crap and numerous, upgrading existing old projects become a pain. There are A LOT of old projects out there that haven't been updated simply because the burden to do so is so high.
  - userbinator 6mo ago
    Then I wish there were more of these "idiots who want to support Node 0.4 in 2026". Maybe they're the ones with the common sense to value stability and backwards compatibility over constantly trendchasing the new and shiny and wanting to break what was previously working in the misguided name of "progress".

leontloveless 7mo ago

[dead]

sipsi 7mo ago

i suggess jpeg.news dot com

SachitRafa 7mo ago

The cross-realm argument for packages like is-string is the one I find hardest to dismiss, but even there the math doesn't add up. The number of projects actually passing values across realms is tiny, and those projects should be the ones pulling in cross-realm-safe utilities, not every downstream consumer of every package that ever considered it. The deeper problem with Pillar 2 is that atomic packages made sense as a philosophical argument but broke down the moment npm made it trivially easy to publish. The incentive was "publish everything, let consumers pick what they need" but the reality is consumers never audit their trees,they just install and forget. So the cost that was supposed to be opt-in became opt-out by default. The ponyfill problem feels most tractable to me. A simple automated check "does every LTS version of Node support this natively?" could catch most of these. The e18e CLI is a good start but it still requires someone to run it intentionally. I wonder if something like a Renovate-style bot that opens PRs to remove outdated ponyfills would move the needle faster than waiting for maintainers to notice.

andai 7mo ago

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's the easiest way to add more stuff?" The answer is `npm i more-stuff`.

cwnyth 7mo ago
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."
- cobbzilla 6mo ago
  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?
  - hombre_fatal 6mo ago
    > Is there no room for describing the setting? Is there no room for mood? You mean the character of a place?
    - cobbzilla 6mo ago
      sure, setting and character are the same thing
      - bryanrasmussen 6mo ago
        the implication is that if mood is the character of the place then those sentences that set mood are advancing character.

auxiliarymoose 7mo ago

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 dependency-heavy projects.

CoderLuii 6mo ago
been doing something similar. the projects ive been building recently use as few dependencies as possible and honestly the maintenance burden dropped significantly. when something breaks you actually know where to look instead of digging through 15 layers of node_modules. people said the same thing to me about it not scaling but the opposite turned out to be true.
- auxiliarymoose 6mo ago
  yeah, plus stack traces, debuggers, and profiling tools are easier to use when all of the non-essential complexity is stripped out. which in turn means it's possible to work productively on software that solves more complex problems. that's in contrast with the sort of stuff that invariably shows up when something falls over somewhere in a dependency: cannot access property "apply" of null at forEach() at setTimeout() at digest() at callback() at then() ... it's not fun to step through or profile that sort of code either...
anematode 6mo ago
This is absolutely the way to go
- k__ 6mo ago
  Doesn't this go against the credo of not building your own crypto?
  - 6mo ago

est 7mo ago

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.

kennywinker 6mo ago
You’ve traded supply chain vulnerability for slop vulnerability.
- yurishimo 6mo ago
  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.

il-b 7mo ago

The elephants in the room are react and webpack.

rtpg 7mo ago

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 than the minified version of this code! At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully. https://www.npmjs.com/package/has-symbols https://www.npmjs.com/package/has-symbols https://www.npmjs.com/package/is-string https://www.npmjs.com/package/is-string https://github.com/ljharb https://github.com/ljharb

hinkley 7mo ago
Hat tip to Sindre who has fifty bagillion packages but few of them depend on more than one of his other packages.
h4ch1 7mo ago
I remember seeing this one guy who infiltrated some gh org, and then started adding his own packages to their dependencies or something to pad up his resume/star count. Really escapes me who it was.
- g947o 6mo ago
  https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/aria-query/pull/497 https://github.com/A11yance/aria-query/pull/497
  - h4ch1 6mo ago
    yes! this.
  - eudamoniac 6mo ago

stephenr 7mo ago

The primary cause of JS bloat is assuming you need JS or that customers want whatever you're using it to provide. For $client we've taken a very minimal approach to JavaScript, particularly on customer facing pages. An upcoming feature finally replaces the last jquery (+ plugin) dependent component on the sales page, with a custom implementation. That change shaved off ~100K (jquery plus a plugin removed) and for most projects now that probably seems like nothing. The sales page after the change is now just 160K of JS. The combination of not relying on JS for everything and preferring use-case-specific implementations where we do, means we aren't loading 5 libraries and using 1% of each. I'm aware that telling most js community "developers" to "write your own code" is tantamount to telling fish to "just breathe air".

CoderLuii 6mo ago
160K total is impressive. most landing pages i see are shipping 2-3MB of js before the first paint. the "write your own code" approach gets laughed at but when you actually do it the result is faster, easier to debug, and you dont wake up one morning to find out one of your 200 dependencies got compromised.
- stephenr 6mo ago
  Wait till I tell those people we keep all our dependencies (js and backend) in our own git repo. Updating dependencies is a task a person does, followed by committing the changes to the repo. I am aware a lot of these ideas are heretical to a lot of software developers these days.

skrtskrt 7mo ago

the fact that you can just redefine Map in a script is mind boggling

xigoi 6mo ago
Why? Being able to redefine anything is table stakes in dynamic languages.
- g947o 6mo ago
  So? Does being able to do something means you should?
  - xigoi 6mo ago
    I didn’t say you should. The comment I’m replying to expressed surprise that redefining something is even possible.
- fragmede 6mo ago
  You can't assign a value to false, for example, so "anything" isn't everything (Node v22.17.0). > false = 4 false = 4 ^^^^^ Uncaught SyntaxError: Invalid left-hand side in assignment Fascinatingly enough though, you can assign a value to NaN. It doesn't stick tho. > NaN NaN > NaN = 42 42 > NaN NaN > (map behaves as described.)

deleted 7mo ago

[deleted]

krmbzds 7mo ago

JavaScript bloat is downstream of low FED interest rates.

IAmLiterallyAB 6mo ago

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

Griffinsauce 6mo ago
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?
- sgbeal 6mo ago
  > 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.
ascorbic 6mo ago
It'll still install the dependencies, which is what this is about
sgbeal 6mo ago
> 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)).

grishka 6mo 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 https://www.youtube.com/watch?v=XAGCULPO_DE

panstromek 6mo 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 6mo 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.

pjmlp 6mo 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.

casey2 6mo ago

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.

sgbeal 6mo ago
> 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.
g947o 6mo ago
> Sites should think seriously hard about server side rendering You think the average site owner plus wix/squarespace is going to spend a lot of money beefing up their CPU and RAM to marginally "improve user experience" when they could and have been offloading rendering client side all these years?

deleted 6mo ago

[deleted]

procaryote 6mo ago

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

IsTom 6mo ago
I've seen some juniors writing risoni code like that. They've heard that you shouldn't write big functions, so obviously they forcefully split things until they can't be split anymore.
RadiozRadioz 6mo ago
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.
- williamcotton 6mo ago
  That’s not how we started down this path. See snark-free sibling comment from padjo.
  - deleted 6mo ago
    [deleted]
  - RadiozRadioz 6mo ago
    Both my claim and theirs are unsupported by evidence, therefore they are equally valid.
    - padjo 6mo ago
      A third argument is that it was because of aliens from the planet Blotrox Prime. But I suppose without evidence we'll just have to accept that all three theories are equally probable.

lerp-io 6mo ago

just make react native to browser and everything else thats a one off can be ai generated

deleted 6mo ago

[deleted]

deleted 6mo ago

[deleted]

steveharing1 6mo ago

So the guy who called JS, a weird language was not wrong huh?

qayxc 6mo ago
Look at Python - similar story. Once a reasonably usable global package registry exists, this is exactly what happens. Languages and standard libraries evolve, shipped code more often than not doesn't.
- steveharing1 6mo ago
  [dead]

onion2k 6mo 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 6mo 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.

wonnage 6mo ago

An underappreciated source of bloat is module duplication stemming from code splitting. SPAs have a bad rep because you don't expect to download an entire app just to load one page on the web. You can solve this by code splitting. But if you just naively split your app by route, you'll end up with duplicate copies of every shared module. Bundlers handle this by automatically creating bundles for shared modules. But if you optimize to avoid all shared modules, you end up with hundreds of tiny files. So most bundlers enforce a minimum size limit. That's probably fine for a small app. But one or more of these things happens: 1. Over time everybody at the company tends to join one giant SPA because it's the easiest way to add a new page. 2. Code splitting works so well you decide to go ham and code split all of the things - modals, below-the-fold content, tracking scripts, etc. Now you'll run into situations where 20 different unrelated bundles happen to share a single module, but that module is too small for the bundler to split out, and so you end up downloading it N times.

deleted 6mo ago

[deleted]

stevoski 6mo ago

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

couscouspie 6mo ago
I like rants though. They help me understand, not only how people feel about stuff, but also why.
josephg 6mo ago
What functionality is still missing from the JS standard library? The JS standard library seems massive these days. Edit: Removed a reference to node and bun.
- jefftk 6mo ago
  We're talking about JS in browsers: many fewer options there, plus needing to support old devices.
- simonw 6mo ago
  Those aren't a standard library for the language itself - they're not showing up in browsers, for example.
  - josephg 6mo ago
    Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?
    - simonw 6mo ago
      What standard library? Do you mean the built-in Array.x etc methods you get in the core language spec?

deleted 6mo ago

[deleted]

hknzerodark1 6mo ago

[dead]

wiseowise 6mo ago

> Using the e18e CLI to detect replaceable dependencies https://github.com/e18e/cli https://github.com/e18e/cli That’s awesome. Could be hooked as a pre-commit for agents to do the grunt work of migration.

gameroman 6mo ago
e18e CLI is great

deanc 6mo 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.

general_reveal 6mo ago

Anyone want to tell him programming languages don’t matter anymore?

Zopieux 6mo ago
[dead]
miranaproarrow 6mo ago
there are people that still likes to understand what their language is doing and not offload all their thought to LLM
embedding-shape 6mo 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 6mo ago
Were you this excited about crypto and NFTs as well?
g947o 6mo ago
No. They matter. Show me a website where client side interaction is implemented in perl.

prinny_ 6mo ago

Everyone trash talking the JS ecosystem without contributing the slightest to the conversation would benefit a lot if they read https://www.artmann.co/articles/30-years-of-br-tags https://www.artmann.co/articles/30-years-of-br-tags in order to understand the evolution of the language and its tooling. Nobody argues what we currently have is great and that we shouldn't look to improve it. Reducing it to "JS developers bad" is an embarrassing statement and just shows ignorance, not only of the topic at hand, but of an engineering mindset in general.

KronisLV 6mo ago
> “JS developers bad“ I found it to be a nice post that documents why things sometimes are bad. It didn’t feel accusatory at the developers themselves, but seemed to serve as a reasonable critique of the status quo?
- n_e 6mo ago
  I assume they were talking about the comments here, not the post which I agree is great.
n_e 6mo ago
[dead]
follie 6mo ago
I find the mindset of trying to understand and accept bad fine in moderation but as defeatist when taken past the end of the block. It doesn't matter why JS is bad and will harm your future prospects if you approach it with too much acceptance. We always need to be examining the practice in front of us and the theory that would be a better replacement for it and trying to make the leaps at the right times to keep getting paid while not becoming part of the problem ourselves. Science advances one funeral at a time applies to software with things going at a faster pace so a good software engineer needs to fake a few funerals or really be senior at 4 years to be dead by 7.

algolint 6mo ago

[flagged]

whstl 6mo ago
I like to criticize React as much as the next person, but this is an JS ecosystem problem around third-party libraries, not a React problem per se. If you're using third-party NPM packages to do "Vanilla", you're will probably run into the same problem. If you import React directly from a CDN, you won't.
- algolint 6mo ago
  [flagged]
  - whstl 6mo ago
    Yeah, I agree. Build systems (especially Babel and Webpack) were the first big culprits in terms of dependency bloat, and it was very rare to see React without them.
- algolint 6mo ago
  [flagged]

ctvdev 6mo ago

[dead]

AltruisticGapHN 6mo ago

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

skrebbel 6mo ago
This is 100% teams who set up their build tooling back in 2015 and haven't updated since. There's plenty widely used apps and libs that date this far back, and back then, IE8 compat was considered pretty important still, esp for products targeting enterprise/government customers. Upgrading eg Webpack and Babel and polyfill stacks and all that across multiple major versions is a serious mess. Lots of breaking changes all around. Much better to just ship features. If it ain't broke, don't fix it!
jgilias 6mo ago
I remember reading somewhere that Deutsche Bahn is running Windows 3.1 for something still?
- szatkus 6mo ago
  Somehow I doubt they use it to access another Next.js app created by some startup from SV.
  - jgilias 6mo ago
    The point was - some people are running hugely outdated stacks for “reasons”.
esprehn 6mo ago
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.

wheattoast 6mo ago

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

jefftk 6mo ago
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.
- abanana 6mo ago
  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!
  - wheattoast 6mo ago
    Fair, but personally I’d absolutely prefer slower bloated code with twice the lifespan to faster code that forces me to buy new hardware I can’t afford. But I’m a nearly extinct type of consumer who happily clings to pre-subscription-era software (e.g., Photoshop 7, Sketchup 2017). I understand and begrudgingly accept that businesses couldn’t survive by tending to the desires of folks like me.

hknzerodark1 6mo ago

[dead]

butILoveLife 6mo ago

[dead]

g947o 6mo ago

https://immich.app/cursed-knowledge https://immich.app/cursed-knowledge > There is a user in the JavaScript community who goes around adding "backwards compatibility" to projects. They do this by adding 50 extra package dependencies to your project, which are maintained by them. > https://github.com/immich-app/immich/pull/10690 https://github.com/immich-app/immich/pull/10690

12345hn6789 6mo ago
A little more context since they scrubbed that PR. https://news.ycombinator.com/item?id=45447390 https://news.ycombinator.com/item?id=45447390 or https://github.com/A11yance/axobject-query/pull/354 https://github.com/A11yance/axobject-query/pull/354 This user actively gets paid off of how many downloads their packages get, which makes sense why there are so many. As well as the attitude to change others repositories to use his packages

sylware 6mo ago

It is not javascript itself (until the interpreter is written in plain and simple C or similar), it is the abomination of the web engine, one of the 2.5 from the whatng cartel.

derodero24 6mo ago

[flagged]

huhulove1990 6mo ago

[dead]

DanielHB 6mo ago

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

tylerchilds 6mo ago

I agree, but would also posit a parallel The Three Pillars of JavaScript Ecosystem Bloat for example, javascript runs in a browser or on microcontrollers. you can write code that work for both natively [1]. TypeScript-- a mechanism that needs to compile first into javascript React-- a mechanism that needs to compile first into javascript Configuration-de-jour-- Depending on how you need to string your TypeScript and React together, there's a thing you need to manage your javascript managers. Vite is the best option in this field, since it recognizes exposing tools to fine tune how to optimize your resulting javascript from your typescript and react is a terrible idea that leads to mass fragmentation on a global scale for what it even means to "spin up a js project" In conclusion, is javascript a compile target like assembly or a language that people can handcode to eek performance out of like assembly? [1]: https://github.com/bellard/mquickjs https://github.com/bellard/mquickjs

tylerchilds 6mo ago
To the downvote— you know JavaScript is the blitting engine for <company that pioneered the button on your remote to stream Hollywood to your living room on a shitty smart TV microcontroller>, right?

socalgal2 6mo ago

There was a time I'd use dependencies for trivial things like copying a file during building or running things in parallel. Now I just script those in js and call that js from my build. Even testing is now included in node so I stopped using a testing framework.

kigiri 6mo ago

I work on a ~9y old nodejs codebase, have none of those issues, we have 8 dependencies, this is fully resolved tree. One to generate zip files, one for markdown parsing, connecting to postgres, etc... most of them have no sub dependencies. We always reach out first to what nodejs lib have, try to glue ourself small specific piece of code when needed. The app is very stable and we have very few frustrations I used to have before. Note that we used to have way more but bit by bit removed them. Now I would whitelist anything from the deno std* lib, they did a great job with that, even if you don't use Deno, with what ever your runtime provide plus deno std you never need more than a few packages to build anything. JS is doing pretty good if you are mindful about it.

g947o 6mo ago
What do you use for testing? Built-in test runner? I have a few projects that use mocha, and I recently noticed that several vulnerabilities come from its transitive dependencies, and there is no easy fix today. The project hasn't seen updates for a while. Makes me wonder if I should just ditch mocha completely.

baubino 6mo ago

I feel vindicated by this recent turn back to vanilla js (which I never left).

Rithan 6mo ago

[dead]

nektro 6mo ago

> Atomic architecture this an artifact of dealing with a pre-esm ecosystem. before esm these small packages were the easiest way to help bundlers do better tree shaking

Levitating 6mo ago

The problem is that people prefer adding a shebang regex dependency, rather than just copy the regex into their codebase. If your dependency is less than 10 lines of code, you shouldn't depend on it. You can just copy those 10 lines of code.