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 ab

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.