5 ms·

React is hostile to the outside world

18 points by sharno 4y ago

mhoad 4y ago
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.
- glenngillen 4y ago
  I get a vague sense that this comment resonates with me, but I don’t know exactly why (I only occasionally do front end stuff too so it’s not exactly my area of expertise). Could you elaborate on what assumptions are no longer true?
  - mhoad 4y ago
    The entire need and premise for virtual DOM stands out as a pretty big example for me here. Made a lot of sense at the time but is an actively bad choice in 2023. Similar argument on things like their synthetic events approach where you now have to pay a runtime cost now to just implement something in a worse fashion and much slower language that the browser already provides for you.
    - jitl 4y ago
      At least SyntheticEvent objects with their re-use pool and bounded lifetime are long gone and all the events are once again Native browser Event objects with no lifetime issues. Dealing with that event pooling shenanigans was annoying.
- scrollaway 4y ago
  > 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 Because react fixed those by showing the web frontend world that reactive UIs are easier to reason about, and showed how to implement those in a natural way. I remember writing a WoW talent calculator in jquery. Took me a month. I could write the same thing in react today in a few hours.
  - mhoad 4y ago
    I’m not saying it wasn’t helpful, we did learn a lot about UI development for the web but we learned a lot of new things that don’t work well too and a bunch of those things are very React specific these days. Furthermore compared to more modern takes on the problem and the evolution of the platform itself it’s probably not what you should be stating projects with these days without a good reason (I.e it’s no longer an obvious default choice)
    - scrollaway 4y ago
      Starting a project with NextJS today is an absolutely fine choice. It’s a great and living ecosystem, supported by loads of commercial players and with a huge talent pool to draw from.
poisonborz 4y ago
> So I actually think I want React to die and we all use Svelte, lol. This is the article for you.
qprofyeh 4y ago
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.
scrollaway 4y ago
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.
koito17 4y ago
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.
fabian2k 4y ago
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.
ht85 4y ago
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?
jitl 4y ago
Want mutation in your React? `npm i Mobx` and be on your way.

18 points by sharno 4y ago

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.

glenngillen 4y ago
I get a vague sense that this comment resonates with me, but I don’t know exactly why (I only occasionally do front end stuff too so it’s not exactly my area of expertise). Could you elaborate on what assumptions are no longer true?
- mhoad 4y ago
  The entire need and premise for virtual DOM stands out as a pretty big example for me here. Made a lot of sense at the time but is an actively bad choice in 2023. Similar argument on things like their synthetic events approach where you now have to pay a runtime cost now to just implement something in a worse fashion and much slower language that the browser already provides for you.
  - jitl 4y ago
    At least SyntheticEvent objects with their re-use pool and bounded lifetime are long gone and all the events are once again Native browser Event objects with no lifetime issues. Dealing with that event pooling shenanigans was annoying.
scrollaway 4y ago
> 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 Because react fixed those by showing the web frontend world that reactive UIs are easier to reason about, and showed how to implement those in a natural way. I remember writing a WoW talent calculator in jquery. Took me a month. I could write the same thing in react today in a few hours.
- mhoad 4y ago
  I’m not saying it wasn’t helpful, we did learn a lot about UI development for the web but we learned a lot of new things that don’t work well too and a bunch of those things are very React specific these days. Furthermore compared to more modern takes on the problem and the evolution of the platform itself it’s probably not what you should be stating projects with these days without a good reason (I.e it’s no longer an obvious default choice)
  - scrollaway 4y ago
    Starting a project with NextJS today is an absolutely fine choice. It’s a great and living ecosystem, supported by loads of commercial players and with a huge talent pool to draw from.

poisonborz 4y ago

> So I actually think I want React to die and we all use Svelte, lol. This is the article for you.

qprofyeh 4y ago

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.

scrollaway 4y ago

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.

koito17 4y ago

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.

fabian2k 4y ago

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.

ht85 4y ago

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?

jitl 4y ago

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