3 ms·

We must just make different types of apps. I work on a couple of startups at the moment, one of which that has an admin interface in a SPA, one doesn't. I can

We must just make different types of apps. I work on a couple of startups at the moment, one of which that has an admin interface in a SPA, one doesn't. I can throw in new reports, functionality, etc. in the non-SPA one with less than 1/2 day's worth of work, sometimes even in minutes. The SPA one takes days to do similar functionality. It's just all so bloody complicated getting it working together. Make a new end point, create a new DTO, make sure you're not leaking anything from the end-point, duplicate validation logic, wire up view models, have it not work completely for an hour or two of debugging because you forget to add one line to some gulp file or something equally ridiculous. And then you throw in something like React and they want you to do it X way with Y thinking and Z plugin doesn't like you're returning the wrong content type or data structure or something but doesn't throw an error about it, logs it as some sort of warning, or if there is an error it's deep in the guts of 10 nested 1 line self-referential call in the library. It just adds so many moving parts, functionality ends up sprawled over 10 different files, it's hard to grok or reason about, hard to know if you've done everything you need to. I find it simply unpleasant to work in that way. I just want to write the UI and the logic and be gone, not dealing with frameworks barfing out bizarre warnings or mysteriously broken builds. Actually, nothing fills me with more dread in a SPA than when I click a button or something and nothing happens. The worst problem programming in SPAs is when things simply just don't work and there's no error at all because you didn't quite invoke the magic framework in quite the correct way. Yay SPAs.

lobster_johnson 10y ago
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

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.