Earlier quoted context omitted.
Why? Being able to redefine anything is table stakes in dynamic languages.
So? Does being able to do something means you should?
The three pillars of JavaScript bloat
241–250 of 301 posts
Re: The three pillars of JavaScript bloat
#242> [...]
> 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.
Re: The three pillars of JavaScript bloat
#243The 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
This is not helpful.
Re: The three pillars of JavaScript bloat
#244Earlier quoted context omitted.
Is the lack of CVE because the implementations you wrote are better written and safer than those in the standard libraries or because no one has checked?
Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.
Let alone having to check all licenses...
Re: The three pillars of JavaScript bloat
#245“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 mai…
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.
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!
Re: The three pillars of JavaScript bloat
#246"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.
I remember reading somewhere that Deutsche Bahn is running Windows 3.1 for something still?
Re: The three pillars of JavaScript bloat
#247Earlier quoted context omitted.
Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?
String.splitRight, for one. (As an example: "www.a.north.website.com".splitRight(".", 3) == ["www.a.north", "website", "com"].)
Re: The three pillars of JavaScript bloat
#248Earlier 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?
What is the purpose of the setting if not to reveal character or advance the plot? I don’t need to know the color of the walls if it does neither.
Re: The three pillars of JavaScript bloat
#249Earlier quoted context omitted.
What is the purpose of the setting if not to reveal character or advance the plot? I don’t need to know the color of the walls if it does neither.
Framed that way you could characterize anything as ultimately serving the characters or plot.
Re: The three pillars of JavaScript bloat
#250I 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…