The problem is the frontend web application model is not great design. People are designing distributed systems when all they really want is to provide data to the user, or provide a user interface (which provides data from the user back to the system). You can do both those things without being stateful on the frontend.
There are multiple network protocols for synchronizing state, and they are annoying as hell. Necessary in some very specific/limited situations, but not for a broadband mobile or web application. Even when we were on 33.6k modems we didn't need it.
But then again if we were talking about native apps, we'd still be using HTTP APIs to transfer state data, because developers can't be arsed to do anything they're not used to. (Unless you show them something more technically complex, yet easier to use/think about; shit's catnip for coders)
Not quite, even a static HTTP form is "stateful" in the same way as a React frontend is. The value that the user typed in a field before hitting submit is also a "state", it's just abstracted away by the browser/DOM/HTML.
React is just reimplementing browser functionality.
The argument here is that those kinds of forms aren't state transfer similar to "subscribe to our newsletter" or "confirm payment", they're all just state-syncronization-on-top-of-state-transfer. Whether this is right or wrong, good or bad: I don't have a strong opinion.
> The value that the user typed in a field before hitting submit is also a "state"
I'm sorry but that's not what these terms mean. Stateful vs stateless has to do with a state machine holding a state across interactions. In order to be stateful it has to remember what the state was after it takes action. The fact that a text box can temporarily hold some text in it doesn't make it stateful. You would have to submit the form, the page would have to completely reload, and the browser would have to keep the text in the box. That would be a stateful form field. So the browser isn't doing anything stateful. As HTTP is a stateless protocol, the browser is also (traditionally) stateless. This changed with the introduction of JavaScript, and to a certain extent with HTTP caching conventions, and cookies.
From the article:
Using REST we can model this as a path, say /api/foo, that supports GET and POST methods to fetch or replace the text by a given value[..]. A React component that allows users to edit this piece of text will probably display a text input element, GET the initial value when the component is created and POST a new value when the text input loses focus. We show an error message with a retry button if a request failed, and we display a spinner while requests are in-flight.
Given that we just want to enable the user to edit one string in the database, there’s quite a lot of boilerplate here. Ideally, we’d just need to specify how to display the user interface and where to find the string in the database, but here we have to also deal with sending state back and forth, showing errors and displaying a spinner.
If they were both the same system then they'd have one state machine with distributed operation. This is technically possible now that there's a stateful TCP connection over HTTP (WebSockets) and cookies to retain the state. But in practice the backend applications function without the frontend, while the frontend doesn't function without the backend, so this is less of a distributed system and more of a traditional client-server model with independent client and server applications.
> The fact that a text box can temporarily hold some text in it doesn't make it stateful
And this is exactly what 90% of SPAs are doing, including the example in the article of doing a GET and then a POST request.
> The frontend code has a state and the backend code has a state, both of which may be different at any given time.
Same for a plain-HTML form.