We're not innovating, we're just forgetting slower

> Software has followed the same trajectory, piling abstraction upon abstraction until we’ve created a tower of dependencies so precarious that updating a single package can break an entire application.

This is like saying old software is so simple that updating a line of code can break an entire application. It's a silly thing to say. No matter how complex or how simple a piece of software is, you can easily break it. If you have a program that prints out "hello world", guess what? Updating a single character can break the entire application!

The world is more complex now. We've stood on the shoulders of giants who stood on the shoulders of giants. A few centuries ago a renaissance man could make advances in multiple fields. Now people are specialized. It's the same thing with software. Of course, people take it to an extreme. However, you go ahead and write your own crypto library, I'll use a vetted one created by experts.

If I break some source code by messing with it, I know what happened. I might even learn from it.

Now if npm breaks it, or Claude breaks it, a developer might not even know what was broken.

He's talking about that kind of thing, not the resilience of code to take random character deletions.

IT is very much non-specialized compared to older disciplines. It's so young. Every single one of us is still a jack of all trades in some degree.

You're relying on the "don't roll your own crypto" popular quote to drop the mic. That's misguided. This advice comes from an argument of strength by numbers, not anything related to abstractions. It tells me you don't understand it.

Doesn't it mean more that some packages aren't conforming to common sense like semver?

This is exactly my take on folks bemoaning the evolution of complexity in software (and hardware) worldwide.

To lend some credence to other folks points of view, there are arguments I can agree with that are adjacent:

- "We don't need that complex framework for our needs, we stick to a simpler, older library."

- "We decided to not use <shiniest_new_toolkit> it had performance issues that the maintainers are still sorting out."

- "Working with the new framework showed a lot of promise, but there is still a lot of instability in the API since it's so new. We couldn't commit to using a toolkit that hasn't been nailed down yet."

These are actual concerns and shows caution towards adopting new things until they match your use-case, dev-timelines, and performance requirements.

A complex software much much easier to break accidentally. While one character can break "hello world" is not something one would do while trying hard not to break it. And potential bugs in a simple application much more likely will be cough during a review. For a complex application no-one have a good mental model to predict what a given change would do reliably. For a simple one it's possible.

I’d add “The DOM api probably already has everything you need and has zero dependencies.” That applies to many lower-level APIs which have gotten smarter and better over the years—often in response to the needs of fancy frameworks, but now they are pretty rich by themselves.

“I don’t have time to learn a new framework, I have things to do.” Everybody’s cool new abstraction is a cognitive burden for someone else.

A crypto library is "essential complexity" and running a node.js runtime inside a container in kubernetes node in a virtual machine on a server owned by a hyperscalar cloudprovider is "accidental complexity". I'll take the crypto library any day of the week but if I get to decide how to host a webapplication I'll stay away from that fragile tower of abstractions. As it happens I currently make a living from that "accidental complexity" so it is not a matter of skill, I just see it as unnecessary.