Using the platform

This seems to be a new trend with Deno reusing native APIs as much as possible, Remix leaning on platform APIs to send and receive form data between server and client. This author also talks about how this term has become overloaded in recent times.

Form validation

Form validation in React is painful. In a recent project, I had to try four different form management libraries before deciding on one that worked best in that scenario. I totally empathize with the author about not wanting to deal with it. Native form handling, when it can be used, is a much better alternative because those skills transfer across projects – even ones that don’t use React.

To be fair to React, however, the native form validation APIs have not always been good.

Inflection point

I think React will hit an inflection point where the framework becomes a burden. Right now the big argument is you don’t worry about render, React will handle it for you. But there are so many footguns built into the framework and if you don’t pay attention, you’ll end up rendering your component more times than needed. Personally, I feel like having to know when to use useMemo or useCallback instead of simply using a basic construct is a lot of unnecessary cognitive load.

Web components

The promise of web components is great. You have a HTML bundle (with CSS and JS) that can import other prepackaged components with styling and behavior that doesn't leak or interfere but can interface really well. However, I haven't come across a native web component implementation that just clicks. Not yet.

Templating

IMO, templating is probably the single most important reason why React won. As mentioned above, the same idea of transferability of skills applies to templating as well. This is why I hated handlebars, Vue’s templating or Angular’s templating. Because they are domain specific and do not help you in any way other than learning that one framework.

JSX, on the other hand, helps you learn Javascript. To create a list of components, you don’t use a random @for construct. You use the native Array map functionality.

JSX is to JS what JSTL was to Java.

Elm follows the same idea and it's a pretty good one. Allowing templates the ability to use the entirety of the programming language is a huge game changer. That way the templating is not limited to a curated subset of constructs. Compare this with something like Mustache, that doesn’t have an else construct.

Scheduler

Building a scheduler is non-trivial. While I respect the author talking with their project in perspective, this is not the same as building complex UI applications. This comment resonated a lot with me.

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much.

There is truth to the fact that while popular frameworks are not a silver bullet for all scenarios, it is nice to have a large community of people using it in different contexts and testing things out compared to a home-grown solution.

Unless you have a dedicated team that will build and maintain this level of abstraction for you, it’s easier to use a common framework instead.

Dependencies that can be easily replaced

I wholeheartedly agree with this aspect of the post. In fact, I have come across people who use frameworks but also like it so much that they opt into every feature possible that the framework offers. This makes it so difficult to extricate and replace in the future. There is such a thing as leaning too much into a framework.