4 ms·

Having done both classical Rails apps and React, I still disagree that the classical way is somehow superior. You still have to do the same amount of work — wir

Having done both classical Rails apps and React, I still disagree that the classical way is somehow superior. You still have to do the same amount of work — wire up models, routes and such. There are annoyances — occasionally we have to wrestle with NPM (though now that we use Yarn, the problems are generally gone), low-quality third-party libs, browser compatibility issues, etc. But it's just exchanging one set of problems for another. The React world isn't any worse than the Rails world there. I get that some people get JavaScript fatigue and don't understand/are able to keep up with the new technologies. For those of us who are comfortable with the React way of doing things, it's fantastic. I have no difficulties reasoning about the code, nor with correctly organizing code into separate files (you don't always need "10 different files"; you have a choice!). React + WebPack + NPM modules beats the old way by a mile; I couldn't be happier. I have things to complain about, to be sure, but they're less about frameworks and more about the challenges that arise in a browser-based environment. Again, a different set of problems. > Actually, nothing fills me with more dread in a SPA than when I click a button or something and nothing happens. Something is definitely wrong here. This is not a problem I've ever had.

always_good 10y ago
> Something is definitely wrong here. > This is not a problem I've ever had. Guess you always have good internet. If you truly can't identify with the parent comment or SPAs acting up, you might want to explore your own applications on slower internet. I'd say most SPAs are clearly built with the latency of localhost in mind during development. Even Slack. Even Google Translate is terrible on a suboptimal connection. It just seems to hang and rarely recovers when the internet comes back. At least with server-rendered apps, when you click submit, you either timeout or hit a DNS resolution error, and the back button will restore your <textarea> from page cache. It's never ambiguous. But SPAs usually require some more thought, like more deliberate "waiting..." UI between the time the user does something and the response comes back from the server. I know I have to.
- lobster_johnson 10y ago
  I thought the parent poster was referring to his own apps, not others'? It's trivial to provide progress and retry capabilities, especially if you're using Redux where you can build retrying into the reducer pipeline itself instead of reimplementing it for every use case. With React/Redux I recommend integrating it into a reusable component such as this: <ProgressStatus task={this.props.save}> <Button label="Save" onClick={this.props.dispatch(save())}/> </ProgressStatus> Here, ProgressStatus is a high-level component that renders a progress spinner or similar if it's "task" is busy, otherwise displays its children. So the moment anyone clicks the save button, the save button will be replaced with a spinner. You can also build this directly into the button component and make it disabled while it's busy. Of course a lot of SPAs are less great at dealing with slow/bad connections. I find Google's apps to be particularly bad at this.
  - mattmanser 10y ago
    It is "trivial", "easy", "simple". I've become increasingly distrustful of your view point as you've simply just kept replying to a load of different replies saying otherwise that everything's so easy, when it's not. It's all adding extra complexity. It's absolutely laughable for you tell people that a great solution is adding an API. Boom, extra layers of complexity. Connection problems? Add progress spinners! Progress spinners are yet another complication you have to constantly think around and with deal in SPAs, not something to be celebrated. And what do they actually do? Apparently you don't split your code up? I deal with 1500 line files in a project because of what came before, not splitting it up would be an even greater disaster. It's beginning to sound like either you work on trivial month or two projects, or you don't work with other people.
    - lobster_johnson 10y ago
      There's no need to get nasty and personal. Of course I work with other people. I've been working on multiple (I'm counting at least 6) complex React apps for about 4 years now. Our largest React UI app is about 40kloc lines. Before that most of the apps I worked on were large Rails or Sinatra apps. 1500-line files are not desirable. My point was that you have to choice whether to split up files or not, exactly the same way that you would do in a non-SPA app. The reason for using words like "trivial" isn't to belittle problems, but because these are solved problems. You describe them as though they're painful hurdles, and I simply disgaree. Describing a component as "adding an API" is disingenuous, considering that it solves a problem and is — yes — trivial and completely reusable. You would have to do the same thing in a non-SPA application if you're submitting data to an API via XHR, of course; you also have to handle connection errors there. If you're doing a "web 1.0" form that submits to a new page, it turns out modern browsers aren't particularly good as display progress or recovering from errors, either. I'd say the XHR/SPA approach gives a better UX here: In my SPA I can store a "draft" object to localstorage, display a nice progress spinner, show an error message and a "retry" button on connection errors, and recover the draft again in case the user accidentally lost the page.

always_good 10y ago

> Something is definitely wrong here. > This is not a problem I've ever had. Guess you always have good internet. If you truly can't identify with the parent comment or SPAs acting up, you might want to explore your own applications on slower internet. I'd say most SPAs are clearly built with the latency of localhost in mind during development. Even Slack. Even Google Translate is terrible on a suboptimal connection. It just seems to hang and rarely recovers when the internet comes back. At least with server-rendered apps, when you click submit, you either timeout or hit a DNS resolution error, and the back button will restore your <textarea> from page cache. It's never ambiguous. But SPAs usually require some more thought, like more deliberate "waiting..." UI between the time the user does something and the response comes back from the server. I know I have to.

lobster_johnson 10y ago
I thought the parent poster was referring to his own apps, not others'? It's trivial to provide progress and retry capabilities, especially if you're using Redux where you can build retrying into the reducer pipeline itself instead of reimplementing it for every use case. With React/Redux I recommend integrating it into a reusable component such as this: <ProgressStatus task={this.props.save}> <Button label="Save" onClick={this.props.dispatch(save())}/> </ProgressStatus> Here, ProgressStatus is a high-level component that renders a progress spinner or similar if it's "task" is busy, otherwise displays its children. So the moment anyone clicks the save button, the save button will be replaced with a spinner. You can also build this directly into the button component and make it disabled while it's busy. Of course a lot of SPAs are less great at dealing with slow/bad connections. I find Google's apps to be particularly bad at this.
- mattmanser 10y ago
  It is "trivial", "easy", "simple". I've become increasingly distrustful of your view point as you've simply just kept replying to a load of different replies saying otherwise that everything's so easy, when it's not. It's all adding extra complexity. It's absolutely laughable for you tell people that a great solution is adding an API. Boom, extra layers of complexity. Connection problems? Add progress spinners! Progress spinners are yet another complication you have to constantly think around and with deal in SPAs, not something to be celebrated. And what do they actually do? Apparently you don't split your code up? I deal with 1500 line files in a project because of what came before, not splitting it up would be an even greater disaster. It's beginning to sound like either you work on trivial month or two projects, or you don't work with other people.
  - lobster_johnson 10y ago
    There's no need to get nasty and personal. Of course I work with other people. I've been working on multiple (I'm counting at least 6) complex React apps for about 4 years now. Our largest React UI app is about 40kloc lines. Before that most of the apps I worked on were large Rails or Sinatra apps. 1500-line files are not desirable. My point was that you have to choice whether to split up files or not, exactly the same way that you would do in a non-SPA app. The reason for using words like "trivial" isn't to belittle problems, but because these are solved problems. You describe them as though they're painful hurdles, and I simply disgaree. Describing a component as "adding an API" is disingenuous, considering that it solves a problem and is — yes — trivial and completely reusable. You would have to do the same thing in a non-SPA application if you're submitting data to an API via XHR, of course; you also have to handle connection errors there. If you're doing a "web 1.0" form that submits to a new page, it turns out modern browsers aren't particularly good as display progress or recovering from errors, either. I'd say the XHR/SPA approach gives a better UX here: In my SPA I can store a "draft" object to localstorage, display a nice progress spinner, show an error message and a "retry" button on connection errors, and recover the draft again in case the user accidentally lost the page.