It's partly a reflection of the web and web browsers. Yes, the goal is "don't break the web," but with each new release the odds that a website from "decades in

It's partly a reflection of the web and web browsers. Yes, the goal is "don't break the web," but with each new release the odds that a website from "decades in the past" will continue to work today are slim. I don't mean that a simple HTML page won't work, but rather that HTML and other web standards are living - and compatibility often breaks when it's noticed that public web pages don't use features (low adoption) or when features are removed for security or privacy reasons. When you get used to re-learning everything on a monthly basis, it's easy to adopt new approaches. In fact, the Web Components movement, including lit-element, is basically built on the idea that you should write code for the browser, and thus your codebase must evolve as the browser does. If you look at it from the perspective of "this code must work forever," well, I'm not sure the browser is the right place to be. Have you considered shipping an old and outdated copy of a browser, such as Electron? ;-) Edit: That said, I do agree there's a lot of reinvent-the-wheel in NPM-land, but I don't think the best possible wheel has been invented yet, so I appreciate having options. TypeScript is a great example: they're continuing to rapidly evolve the language with each point release yet they also centrally maintain DefinitelyTyped to be backwards compatible to previous releases. This means maintainers don't have to manually update their types for each point-release of TypeScript. If you look for that, you'll see a lot of "automatic backwards compatibility" in places. JS Codemods for example, can automatically update minor and sometimes major versions of React. Not everything is pre-1.0 and experimental, but the new stuff is definitely shinier.