I personally like the article and I respect author deeply, as he's one of the people who did a lot for the web. Many developers have been raised on his articles and materials.
However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)
Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.
But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.
This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:
However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)