> I'm soooooo sick of React doing completely hostile things
This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
This isn't really React's fault. Avoiding the things you mention is entirely possible when using React. It's all up to the developer to handle such scenarios, just as it was without React.
You can choose to have higher latency for the initial request and just display static HTML. Or if you want to load content on demand, then you do have to deal with what happens before anything loads, but I don't think that's the fault of React. Any framework which does this is going to have the same problem that needs to be solved.
Similarly to React "breaking" the back button. If you want user interaction without another page load, you have to deal with the consequences such as needing to track page history more explicitly than you might have otherwise. But that's because the dev chose to change the page content without moving to a new URL, not because that was implemented using React.
It's not possible to flash misinformation with normal front ends before React, without going to extreme extra effort to enable such misbehavior. Whereas with React, the easiest programming path is the user hostile path. And React is adopted only to make it "easier" on programmers.
Nothing about React specifically enables that kind of design.
Redux encourages loading data like that, and the easy way to use Router makes it easy to do that - all URLs get sent to the same backend view to render the app, then the frontend takes the URL args and triggers ajax to get the data. During that interim when the ajax is running is when you get this empty-data state.
For every consequent page transition the performance is actually slightly higher than a full page load since (a) you're probably only fetching JSON instead the entire resulting rendered HTML and (b) you don't have to load the app code any more.
jQuery, Backbone, Angular, etc.. You can / did do this in other frameworks prior to React.
I think, from reading your comments, you think client side routing and single page applications equals React. That's... an interesting take.
If my irrational hatred has a better target than the term "React" I would like to know it. I do despise the usability of nearly every SPA I have used. It is perhaps possible to program an SPA so that the deficiencies are not noticed, which is great, but that does not appear to be the norm nor is it made easy by SPA frameworks.
The flash of inconsistency you see is because the client eagerly modifies state before the server persists it (or some form of this problem).
The routing issue is because the application (SPA) is using business logic to control the browser's navigation state. Sometimes opening a modal will be a new push on to the nav stack so you can hit back, sometimes it isn't, sometimes they forget things, etc..
All of it though is just too much state being managed on the client by the application and that state being managed poorly. This isn't only related to React. It's always been possible to screw up with managing state in any framework.