> The idea of reactivity came from or was popularized by Angular.js

No, spreadsheets popularized reactivity. And the general point is incredibly weak.

Don't use frameworks and make your own? Sure, have your fun. But then try teaching your framework to your company of 1000 and see how quickly you realize your view of the "problems" are only a slice of the pie.

How many companies have 1000 frontend developers?

Do they need 1000 frontend developers?

Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-common-denominator slurry.

Between JS/ECMAscript being abandonware for a decade and CSS' historical immaturity (cross-browser layout, custom properties, more pseudoclasses, etc) the Web was more of a wild west "whatever you we can cobble together" place. So of course we built an entire toolchain ecosystem for all the cool new tools we would reinvent from scratch.

but Things Are Pretty Good these days. We even have the world's only fully system portable assembly language: WASM! And the browser's Web APIs are becoming something like the missing Standard Library (shoutout to Deno).

The author's point seems to be that we are past a tipping point where we need all that additional complexity. You don't _need_ a separate system of reactivity these days, you can write a (closer to pre-hooks React, even!) React-style component library with Web Components now.

Personally I would need for Type Annotations to be a fully supported part of the spec before I made the point to "use the platform" professionally. Until some market force causes the core web technologies to truly fork my skills are useful for life. It's like a pale shadow of how UNIX users must feel :')