React is hostile to the outside world

I do feel as though a lot of the initial conditions that existed around the time of React’s release are mostly no longer relevant and many of the assumptions that it was built around are no longer true.

It never cared much about the gaps that started to develop between “the React way” and the underlying web platform and now it’s off in its own weird self contained ecosystem and doesn’t play particularly well with anything else.

It also is one of those frameworks that starts forcing you to extend the same broken abstractions further and further into the rest of your stack up into your backends and data models. That isn’t a healthy sign at all.

To me, React has been the most... predictable? framework since the beginning. This is has been incredibly valuable.

Yes it has tradeoffs. It is aimed at engineers. It assumes you know what you are doing in the way you model state, in the way you treat data.

Overall a very poor article, was this brigaded to the front page?

The single state example the author provides in React seems more like a poor choice of data structure, if anything. I was expecting something more concrete or intricate, like "I want to interface with something that bangs on objects and mutates state in subtle ways that is incompatible with React". I can easily think of some interesting examples (e.g. attempting to use a CodeMirror view as a controlled form input), but I wouldn't say React "is hostile" to CodeMirror.

I've heard of Svelte but the only remarkable thing I hear about it is code-splitting, but I already have that together with live reloading and precise redefinition in modules when I use ClojureScript and React. So I don't know what I gain by changing tooling here. I guess it'd be nice to finally get a taste of what its like to not use Google Closure Compiler... but I do not want ever want to hard refresh a page or lose state simply because I changed the definition of a single variable.

The article doesn't really make any kind of argument that is about React itself. React doesn't require immutability of state, though in most cases it is a very good idea to have immutable state as it'll allow you to easily avoid rerendering by comparing objects. And even with immutable state, I'm pretty sure that isn't the bottleneck in most slow React applications. The author didn't measure anything, but recreating a small ToDo array on removing an element is unlikely to cause any performance issues. And the data structure seems fundamentally flawed anyway, if you have two ToDos with the same text it would remove both. In a real case you'd access them by index/id anyway

Interfacing with imperative libraries in React can be a bit daunting at first. But that is kind of an unavoidable problem unless you want to make everything imperative again.

So your thesis is that, because not all react code is written perfectly, react is bad for the web and we should rewrite everything in svelte?

React has flaws. Performance isn’t really one of them. When you have hot paths in your app, you will/should be looking at those like an engineer looks at the high stress points in the item they just designed: extra work that covers those exact points.

The example you gave is weird. Comparing lists and strings in a setter is fine for most of reacts use cases even if its performance could be better, because it isn’t slow. It’s only slow when you hold it up against, say, comparing numbers, but the reality is your bottleneck will be elsewhere, such as in web requests or some such.

And if you’re writing anything beyond a small component anyway you’d be using ids in your scenario. Especially if you’re writing a library.

> So I actually think I want React to die and we all use Svelte, lol.

This is the article for you.

React is a non-zero-overhead abstraction which in itself is fine. If you have different requirements or simply don't like this abstraction, pick another. Write software, not hateful (hostile) articles.

Want mutation in your React? `npm i Mobx` and be on your way.