Anyone want to tell him programming languages don’t matter anymore?
Were you this excited about crypto and NFTs as well?
The three pillars of JavaScript bloat
221–230 of 301 posts
Re: The three pillars of JavaScript bloat
#222I 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 constructive…
People aren't criticizing the development philosophy in this subthread. This has been done by the article itself and by several people before.
What people are criticizing is the approach in pushing this philosophy into the ecosystem for allegedly personal gain.
The fact that this philosophy has been pushed by a small number of individuals shows this is not a widespread belief in the ecosystem. That they are getting money out of the situation demonstrates that there is probably more to the philosophy than the technical merits of it.
This is a discussion that needs to happen.
Re: The three pillars of JavaScript bloat
#223Earlier quoted context omitted.
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, somethi…
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 clien…
I agree with you. It’s baffling to see websites (not web apps) refusing to show anything if you disable JS. And a lot of such web apps don’t need to be SPA (GitHub,…)
SPA was mean for UI that relies on the client state mostly, not on the server data (figma and other kind of online editors).
Re: The three pillars of JavaScript bloat
#224There 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
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?
Re: The three pillars of JavaScript bloat
#225Anyone want to tell him programming languages don’t matter anymore?
No. They matter.
Show me a website where client side interaction is implemented in perl.
Re: The three pillars of JavaScript bloat
#226[flagged]
Re: The three pillars of JavaScript bloat
#227Earlier 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?
I suppose we could quibble about what exactly “standard library” means, but I’m presuming we’re talking about the web (rather than, say, Node or Bun). And to me it’s fair to use it to refer to all web APIs that are widely available. Things like crypto, ArrayBuffer, TextEncoder, File and the File System Access API, Intl, the Streams API, Window.performance, etc.
Re: The three pillars of JavaScript bloat
#228Earlier quoted context omitted.
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."
For the curious, the rest of the types: Use the time of a total stranger in such a way that he or she will not feel the time was wasted. Give the reader at least one character he or she can root for. Every character should want something, even if it is only a glass of water. Every sentence must do one of two things—reveal character or advance the action. Start as close to the end as possible. Be a sadist. No matter h…
> Give the reader at least one character he or she can root for.
I've been noticing for a while now this is missing in most modern tv shows. It makes the show feel pointless.
Re: The three pillars of JavaScript bloat
#229https://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
A little more context since they scrubbed that PR.
https://news.ycombinator.com/item?id=45447390
or
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
Re: The three pillars of JavaScript bloat
#230A 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 ).
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.
Literally nothing has degraded. What in the world are you talking about? All of this stuff is optional.