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?
> Is there no room for describing the setting? Is there no room for mood? You mean the character of a place?
The three pillars of JavaScript bloat
61–70 of 301 posts
Re: The three pillars of JavaScript bloat
#62Earlier quoted context omitted.
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.
> 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.
Re: The three pillars of JavaScript bloat
#63I 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…
If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
Re: The three pillars of JavaScript bloat
#64Earlier quoted context omitted.
As usual, he's copying someone else who's been doing this for years: https://www.npmjs.com/package/is-number - and then look and see shit like is odd, is even (yes two separate packages because who can possibly remember how to get/compare the negated value of a boolean??) Honestly for how much attention JavaScript has gotten in the last 15 years it's ridiculous how shit it's type system really is. The only type relat…
To be fair, prototypal inheritance is relatively uncommon language design. I'd rank it as considerably harder to understand than the % operator.
Re: The three pillars of JavaScript bloat
#65I 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…
As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this.
I also dislike things like webpack making every plugin an external dep but at least I vaguely understand that.
Re: The three pillars of JavaScript bloat
#66Earlier quoted context omitted.
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.
> 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.
Re: The three pillars of JavaScript bloat
#67I 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…
> entirely for the purpose of getting high download counts on their github account Is this an ego thing or are people actually reaping benefits from this? Anthropic recently offered free Claude to open source maintainers of repositories with over X stars or over Y downloads on npm. I suppose it is entirely possible that these download statistics translate into financial gain...
The guy who wrote is even/odd was for ages using a specifically obscure method that made it slower than %2===0 because js engines were optimising that but not his arcane bullshit.
Re: The three pillars of JavaScript bloat
#68I 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…
As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".
Just as the cloud is simply someone else's computer, a package is just someone else's reinvented wheel.
The problem is half the wheels on npm are fucking square and apparently no one in the cult of JavaScript realises it.
Re: The three pillars of JavaScript bloat
#69There will be almost no bloat to worry about.
Re: The three pillars of JavaScript bloat
#70Earlier quoted context omitted.
Honestly, Vite is all you need. :) It's super flexible compared to the status quo of require vs. import etc. For example, I recently wanted to ship a WASM binary along with the JS rather than making it a separate download (to avoid having to deal with the failure case of the JS code loading and the WASM not fetching). All I had to do was import `a.wasm?url` and it did the base64 embedding and loading automatically.
This sentiment is all well and good, but when you end up in a new-to-you JS codebase with a list of deps longer than a Costco receipt using some ancient Webpack with it's config split into 5 or so files, then no-one is letting you upgrade to vite unless the site is completely down.