> leads me to a point where I can see that the issue is a simple fix with a couple lines of code.

If you can see the problem, know how to fix it, and still ask spicy autocomplete to do it for you, that isn't "using a tool", it's cargo culting.

It's called a calendar entry. Not every life experience is some giant challenge waiting for a tech bro to create a dedicated fucking app.

With the way modern development often goes this essentially means using spicy autocomplete for code is a just a fast track to the cargo culted solutions of whatever day the model was trained.

> In reality someone made a mistake.

It's never just one mistake. It's usually a chain of mistakes and bad decisions that make the final mistake possible.

I'd estimate that there were likely 77,168,458 mistakes/bad decisions made by individuals before this mistake could happen.

The problem I think is that the js community somehow thinks that being on npm is some bastion of good quality.

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.

I'm completely apathetic about spicy autocomplete for coding tasks and even I wonder which terrible code would be worse.

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.

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 related "improvement" was adding the class keyword because apparently the same people who don't understand "% 2" also don't understand prototypal inheritance.

To be fair, prototypal inheritance is relatively uncommon language design. I'd rank it as considerably harder to understand than the % operator.

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 understand JavaScript. Similarly I would expect the physicist/etc to understand how electrons work.

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.

Given that they literally changed the language to support the class keyword, I think we can safely assume it isn't just the beginners who never bothered to learn how prototypical inheritance works.

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

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.

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.

It's been known for a while - at least 2024 - that its react.

Yeah, I know about that and I'm a Mac / Linux guy.