Throwing out frameworks is throwing out the baby with the bath water. Frameworks manage component lifecycle in a way the browser by itself doesn't.
The author seems to misunderstand why upgrades are forced on you by frameworks. It is not the framework that forces the upgrade, it's the build tools. If you compile JS or CSS anywhere in the pipeline, you need build tools (webpack, sass, babel, typescript, ng cli, ...) that support your current OS and node version, and that support the latest javascript and css syntax. While browsers have perfect backwards compatibility and would support using new javascript and css features on old codebases, the build tools won't allow it. Sooner or later you have to upgrade them, and this forces framework upgrades, which forces application codebase rework. You can delay this a bit by dockerizing the build tools, but I find this imposes more costs than benefits.
You can either embrace the build tools and the upgrade treadmill they force on us, or you can choose a no build tools route. You can do the no build tools approach without a framework, but you don't have to. For example, back in 2008 I ported a PHP server-side rendered application to ExtJS 3 as an SPA. I maintained it until 2015 and then another team took it over which has kept it in active development to this day, and it's still on the exact same version of ExtJS 3. They've never had a good enough reason to upgrade it to another framework (mobile UI is done using native apps). You could never do this with an angular application, because the build tools would force an upgrade long before that time.
If you want to follow this no build tools approach using a more modern framework, I made a version of Create React App that requires no build tools. It's just a cobbling together of a bunch of libraries floating out there that enable using react in this way, but it works. If you build your web app with that you will never have to upgrade the framework if you don't want to, which means you will never forcibly have to rework the application's codebase either, even if like that ExtJS app you continuously develop it for 15 years. https://github.com/jsebrech/create-react-app-zero
Unless the framework backports fixes (both bugs and CVEs) to the major version line you're using, you're forced to upgrade the framework to a newer major version line for the framework's sake, not the "build tools". And that upgrade will bring in all the other API changes that have happened in the new major version line.
The ExtJS codebase suffered from this problem, and this was solved by patching the ExtJS version ourselves to fix bugs as they were found (security issues and browser bugs). At first we would do minor upgrades of ExtJS and bring the patch file along to the new version, stripping out the fixes no longer needed, but when ExtJS 3 stopped getting new releases we just kept fixing the last 3.x version.
Of course, it would be better if this were solved at the framework level by having them ship LTS releases that could keep getting fixes at the framework level for many years and had no build tool dependencies. But this is not a hard requirement to going this route.
> Frameworks manage component lifecycle in a way the browser by itself doesn't.
Which raises the question, what the heck has browser been doing after all these years? To replace jQuery we now have querySelector, but what's preventing browser's native support of "component lifecycle"?
Anytime you have multiple independent companies who are competitive with each other collaborating on a shared standard, progress is going to be slow.
This is especially exacerbated in web browsers when a participant with a large market share intentionally stalls progress for competitive reasons (Safari, when web browser functionality gets too close to native apps).
I love ExtJs. In my opinion, their framework and backward compatibility is something other frameworks should strive to achieve. Currently, React, Vue, Svelte etc. are still at what I consider to be at ExtJs 3 level, where each component was defined in a single file. I wish they would open source their framework and really only on support subscriptions rather than the ridiculous license that they have, although I think that ship has long sailed. I just wish there was something even somewhat close to ExtJs in the open source world. Sadly, hardly any front end developers are even aware of it.
It has been a long time since I looked at it, but (price aside) I seem to recall not being too interested in it because the actually complicated components (tables and such) had too many design and functionality constraints.
Partly, this was due to designers living in their own dream worlds prior to development, partly to functionality limitations.
When you have a green field to play in, buying into Extjs felt like sitting in a tiny pen, even if the grass was very nice.
The author seems to misunderstand why upgrades are forced on you by frameworks. It is not the framework that forces the upgrade, it's the build tools. If you compile JS or CSS anywhere in the pipeline, you need build tools (webpack, sass, babel, typescript, ng cli, ...) that support your current OS and node version, and that support the latest javascript and css syntax. While browsers have perfect backwards compatibility and would support using new javascript and css features on old codebases, the build tools won't allow it. Sooner or later you have to upgrade them, and this forces framework upgrades, which forces application codebase rework. You can delay this a bit by dockerizing the build tools, but I find this imposes more costs than benefits.
You can either embrace the build tools and the upgrade treadmill they force on us, or you can choose a no build tools route. You can do the no build tools approach without a framework, but you don't have to. For example, back in 2008 I ported a PHP server-side rendered application to ExtJS 3 as an SPA. I maintained it until 2015 and then another team took it over which has kept it in active development to this day, and it's still on the exact same version of ExtJS 3. They've never had a good enough reason to upgrade it to another framework (mobile UI is done using native apps). You could never do this with an angular application, because the build tools would force an upgrade long before that time.
If you want to follow this no build tools approach using a more modern framework, I made a version of Create React App that requires no build tools. It's just a cobbling together of a bunch of libraries floating out there that enable using react in this way, but it works. If you build your web app with that you will never have to upgrade the framework if you don't want to, which means you will never forcibly have to rework the application's codebase either, even if like that ExtJS app you continuously develop it for 15 years. https://github.com/jsebrech/create-react-app-zero