2 ms·

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 sa

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.

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.