Core-JS is holding the internet hostage?
onengineering.substack.com
onengineering.substack.com
For me the deal of open source software was I get the source for no payment, with no warranty. It seems some people get furious whenever devs stop wanting to give million/billion dollar companies high quality software for free.
The one thing I know we don't need, is another long-winded write up on the subject.
For that matter, even if someone is being paid to work on something today, they're not obligated to keep working on it forever.
When the world found out OpenSSL was maintained by one guy in a basement they rallied around him and supported him. From what it sounds like, the author of core-js is threatening to blow up the internet by deleting his package or weaponizing it with malware.
Supporting the project means supporting that it only has one maintainer. Which leaves bus risk for the future. Whether that is accurate is another question.
If someone had full control of BGP and demanded money, I guess you could say they are holding the internet hostage. This is very minor in comparison.
I'm not convinced trying to read between the lines and psychoanalyse what the maintainer is thinking is a great approach. English isn't their first language, nuance will be lost. Also culture will affect word choice and something that might be interpreted one way in the US would be taken differently in Russia.
I do agree that if you donate, you are back rolling an individual and not an organisation. But I don't see how that as a bad/good thing. Telling the guy he needs to stop writing code and instead manage people is pretty entitled.
Core-js going away probably isn't as big a deal as people make it out to be, as long as you aren't trying to use bleeding edge stuff. I suspect most projects are on an old frozen version of code-js anyway.
<team nods in understanding>
Over time I came to appreciate their "rudeness" for what it was, forthrightness, and a cultural tendency to call a spade a fucking spade.
The first few times I heard "Ja, natürlich?", it sounded sarcastic to this Kiwi.
Turns out, they were agreeing with me.
Clearly, the majority of the JS community don't know how the Internet existed before them because of their self-importance, and this article is a perfect example of that entitlement.
...wow. That's just mean.
I'd just abandon it and find something else to do in life. If Core-js is truly that important than some company would step in to fill in the void.
And maybe I overread it, but why did he start working on core-js fulltime when there was absolutely no financial compensation in sight? It's like investing all your time in a startup that you know will never pay off.
He should have just left the project as is. The state of JS is not his fault. He is not responsible for fixing it. Once the incompatibilities become too annoying, somebody will take care of the project.
Anyone who’s been around long enough to watch dependency culture rise has known that it’s built on a house of cards.
Open source development took root as a way to share cool work and receive some community recognition. Decades later, your code is the nth tier dependency silently sucked into 8 millions projects through some dependency manager CLI command, you’re not credited anywhere visible, and people are harassing you for not prioritizing their byzantine complaint over the day job work that actually makes sure your rent is paid.
We’re slowly on our way back to reasoned, respectful, collegial practices among developers but the road there is going to see a lot of these card-houses catastrophically tumble.
It's the churn-based-development attitude of Google et.al. (because change is their weapon of proliferating their monopoly) which is to blame for inventing the absurd oxymoron "living standard".
What's the need for a heartless article? The entire gist of it is that he could go rogue any day cause he is demanding money for his work. Why should this be allowed to happen in the first place? Why don't the browser vendors either sponsor him or maintain their own polyfill libraries?
The fact he refuses others to join as contributors is repeatedly mentioned as a bad thing. But why do all companies keep using it for all these years knowing this? What were their CSOs doing then? Was this not an issue before using it for so long?
Its infuriating to see that the first call to action is to asses this situation as a security risk and not to help the guy who is suffering. It's one thing to be indifferent to suffering but what's the need to be incredibly cruel?!
Nah, it’s not critical anymore, assuming it ever was. It’s a pest that finds its way into your code and you have to expend energy to get rid of it.
First off, it’s huge. Check this out: https://bundlephobia.com/package/core-js@3.28.0 How many copies of that do you have in your bundle?
Second, it’ll replace the native implementations of things like Promises and iterators with its own slower and bloated implementations in the name of compatibility, but is it even necessary anymore? IE11 is dead and the rest of the browsers get updated automatically. There might still be stragglers in the corporate world, but honestly I’d rather deal with any issues that come up over adding core-js “just in case”. I’ve also seen it cause issues due to said replacing of native functionality.
Maybe it’s time we moved on.
But I did find this neat phrase in the article:
>"Many projects consumed core-js, usually not directly, but rather, somewhere in the nether of the NPM dependency hellscape. Its code, at least indirectly through dependency poisoning, is used almost everywhere."
"Dependency Poisoning" -- Now, there's a term that is going into my 2023 lexicon...
To generalize (and define better), "Dependency Poisoning" is what happens when codebase A from one author or authors depends on codebase B from another author or authors, and codebase B has a problem or problems with it -- that "poison" or -- cause problems to codebase A.
"Dependency Poisoning" -- may be accidental, or it may be intentional.
It could also occur as part of a series of nested dependencies, for example, A depends on B which in turn depends on (and imports) C -- if C is "poisoned", typically so is A...
Use in a sentence: "If project A uses and depends on <xyz>SSH, and <xyz>SSH has a security bug, then project A has that same security bug by dependency poisoning..."
Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so!
But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies.
That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things.
Thankfully, we seem like we’re finally starting to find our way out of it.
It’s fantastic and exciting that you’re responding...
>The very idea of dynamically and blindly sucking third-party code into your project is insane.
Agreed -- but in some cases/situations/circumstances it may be necessary...
>Is it good to eschew NIH syndrome and rely on mature libraries from experienced maintainers? Often so!
Linux being the prime example of this...
>But the NPM-like dependency culture of libraries depending on libraries depending on libraries ad infinitum makes it effectively impossible to actually know what code is running in your project or who to holds responsible for its failures. No one performs code reviews on their nth-order dependencies, and hardly anyone even does so for their first-order dependencies.
Most Linux Package Managers -- with respect to the nested sub-dependencies that they import -- are the prime example of this...
>That’s not an engineering culture. That’s a “move fast and break things” culture, and what it leads to, by its own very explicit proclamation, is broken things.
Any technology where the people who must maintain it, can no longer understand it due to spiraling and out of control complexity, is broken by definition...
>Thankfully, we seem like we’re finally starting to find our way out of it.
You and other enlightened thinkers like yourself might indeed be starting to find your way out of it -- but if I have observed one persistent truth it is that as time evolves, technology becomes more complex (with more nested dependencies) and thus more difficult to understand/control -- albeit (again, over time) provides many more conveniences to end users...
But, the main point of my post was about linguistics...
Primarily it helped me understand that people in general do not understand what devs do, EVEN OTHER DEVS. The outcome of this is often petty, inane, and rude requests based on a feeling of selfish need.
I was happier once I moved on to other things and I hope Dennis will be too.
Two lessons about reality:
- "the community" is an instantaneous snapshot of individuals, not a single, proper individual that one could maim.
- Things that cannot co on forever, won't (Stein's Law) => https://en.m.wikipedia.org/wiki/Herbert_Stein
If someone truly felt that core-js was a significant risk and were actually willing to help, there IS A FORK BUTTON. Then you do the leg work of getting the major dependents to switch their dependencies.
The article speaks of a part of the spirit of open-source, but that spirit can never supercede what a person does with something they've freely contributed without malice.
The point of open source is not to be hosted hostage by one poor person.
If it is too much for a person to handle, something needs to happen to accumulate this.
But on the other hand it does bring up the question of, is it ethical to not help out a person obtain a safe and secure future while working on something so critical to the ecosystem?
Now again I think the author does a terrible job not coming of as looking down upon the core-js author, but at least there is something to bite into instead of a snarky remark.