Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

Post reply on HN
Print view View original

271–280 of 301 posts

Re: The three pillars of JavaScript bloat

#271

Post by auxiliarymoose »

assimpleaspossi wrote: post #176
auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

CSS has a standard library? I stopped doing web dev just three years ago and am not aware of such a thing. Do you mean the CSS standard?

Sure it's not officially called the "standard library," more precisely it would be "the parts of the ECMAScript and CSS standards implemented by all popular evergreen browsers," but "standard library" expresses this in the way people usually talk about programming languages.

Re: The three pillars of JavaScript bloat

#272

Post by teaearlgraycold »

jsmith99 wrote: post #164
Maxion wrote: post #58

Earlier quoted context omitted.

Did this for a project in 2022. Haven't had any drama related to CVEs, hadn't had any issues related to migration from some version of something to another. The client has not had to pay a cent for any sort of migration work.

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?

Well there's probably far less attack surface.

Re: The three pillars of JavaScript bloat

#273

Post by albedoa »

halapro wrote: post #56
userbinator wrote: post #7

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

[flagged]

Re: The three pillars of JavaScript bloat

#274

Post by userbinator »

Griffinsauce wrote: post #76
userbinator wrote: post #66

Earlier quoted context omitted.

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

You wouldn't if you look more deeply at this. He doesn't push for simplicity but for horrible complexity with an enormous stack of polyfills, ignoring language features that would greatly reduce all that bloat. .

That's also a problem. I've written JS that would work on any browser from the latest ones all the way back to IE5, and I'm not even a professional JS developer. It's not hard.

Maybe "professional" is the problem: they're incentivised to make work for themselves so they deliberately add this fragility and complexity, and ignore the fact that there's no need to change.

Re: The three pillars of JavaScript bloat

#275

Post by userbinator »

josephg wrote: post #183
userbinator wrote: post #66

Earlier quoted context omitted.

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

NodeJS has a clear support schedule for releases. Once a version of nodejs is EOL, the node team stops backporting security fixes. And you should really stop using it. Here's the calendar: https://nodejs.org/en/about/previous-releases Here's a list of known security vulnerabilities affecting old versions of nodejs: https://nodejs.org/en/about/eol In my opinion, npm packages should only support maintained versions of…

"support" and "works" are two different things.

Re: The three pillars of JavaScript bloat

#276

Post by saghm »

stephenr wrote: post #106
saghm wrote: post #75

Earlier quoted context omitted.

The word "used" is doing some heavy lifting there. Not all usage is equal, and the fact that it's involved under the hood isn't enough to imply anything significant. Subatomic physics is used by 100% of websites and has been around for billions of years, but that's not a reason to expect every web developer to have a working knowledge of electron fields.

Fair point. Let's compromise and say that whoever is responsible for involving (javascript|electron fields) in the display of a website, should each understand their respective field. I don't expect a physicist or even an electrical engineer or cpu designer to necessarily understand JavaScript. I don't expect a JavaScript developer to understand electron fields. I do expect a developer who is writing JavaScript to un…

The issue with this framing is that understanding something isn't a binary; you don't need to be an expert in every feature of a programming language to be able to write useful programs in it. The comment above describing prototypical inheritance as esoteric was making the point that you conflated the modulus operator with it as if they're equally easy to understand. Your responses don't seem to indicate you agree with this.

It sounds like you expect everyone to understand 100% of a language before they ever write any code in it, and that strikes me as silly; not everyone learns the same way, and some people learn better through practice than by reading about thinks without practice. People sometimes have the perception that anyone who prefers a different way of learning than them is just lazy or stupid for not being able to learn in the way that they happen to prefer, and I think that's both reductive and harmful.

Re: The three pillars of JavaScript bloat

#277

Post by kigiri »

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.

Re: The three pillars of JavaScript bloat

#278

Post by streptomycin »

zdc1 wrote: post #6

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

In practice there's this one guy who likes to support ancient JS engines, and this one other guy who likes making lots of tiny packages which depend on his other tiny packages. They both see what they're doing as features, not bugs. And they are both very prominent devs with a lot of popular packages.

So unlikely to change unless everyone stops using their popular packages.

Every now and again people get worked up and try to bully them about it, which is unfortunate because they seem like generally good people, and their arguments in favor of their positions are pretty well documented.

Re: The three pillars of JavaScript bloat

#279

Post by userbinator »

jazzypants wrote: post #230
userbinator wrote: post #7

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

Literally nothing has degraded. What in the world are you talking about? All of this stuff is optional.

Looking at the state of things, it sure doesn't seem that way.

Literally nothing has degraded

Trying to gaslight others into thinking everything is just fine is not working anymore.

Re: The three pillars of JavaScript bloat

#280

Post by stevage »

auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

It depends a lot what kind of thing you're building. If it's a simple marketing website, sure. But any application that does stuff is likely using dependencies that provide a lot of functionality.

I make a lot of sites with maps. There's no real alternative to mapbox/maplibre/openlayers.

Post reply on HN