4 ms·
> 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 Re
by michaelmior 3y ago
> 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.
- spencerchubb 3y agoif you use regular html, the developer does not need to implement those things
- Klonoar 3y agoTheir point is that it’s the dev choosing to do this stuff. Even if using regular HTML/CSS many devs opt to do that stuff.
- michaelmior 3y agoI don't think it's always that the dev is choosing to implement these quirks. They're choosing to add extra functionality, but not always implementing it well. 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.
- epistasis 3y agoWhat you say would actually indicate that yes, it is React'a fault, would it not? 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.
- efdee 3y agoI have no idea what would make you say such things other than a deep, unrational hatred for a framework. Nothing about React specifically enables that kind of design.
- ipaddr 3y agoReact router encourages this design. Hard to blame react when angularjs started the trend many years ago.
- efdee 3y agoWhat makes you feel that react-router encourages this?
- deleted 3y ago[deleted]
- Izkata 3y agoAsynchronous data loading is the core of the problem. React without any other addons like redux, where state is dumped into the page and just passed down through props would avoid the issue (though it can have a different one where the page is blank for a moment before the javascript renders the page). Same with HTML and no frontend framework, it's all loaded synchronously with page load so there's no "empty data" state. 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.
- efdee 3y agoThe overhead is only the latency of the ajax call on the first load (since you are going to the server to fetch the app code, then going to the server again to fetch the data, instead of going to the server and fetching the app code + the data). 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.