I feel like React/Angular/Vue/etc apps are becoming "the way the web is done" when so many things would be simpler and more efficient as plain old web sites with server-rendered HTML. It's like everyone decided that because convertibles are cool, they should be used for everything, and are now spending a ton of effort hitching trailers to their convertibles when it would have been much simpler and more effective to just drive a boring minivan in the first place.
But what drives me crazy is sites like Medium [0][1]. It's a shared blog site. To read a one sentence essay on Medium requires downloading over a megabyte of data. And their comment system is still inscrutably terrible.
Content-focused sites should absolutely not be done as SPAs. Server rendered HTML and client-side enhancement will deliver a better experience to the customer and IMO a better developer experience as well.
[0]: http://idlewords.com/talks/website_obesity.htm [1]: https://medium.com/@mceglowski/chickenshit-minimalism-846fc1...
Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster.
I understand where you are coming from, but you picked a bad example.
That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?
In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.
That's not usually the reality but it's definitely possible.
>Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load.
In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.
Because if it's just to display comments or something, I stand by my original statement.
* 10 XHR requests on page load
* 3 downloaded fonts
* Continuous XHR requests as you scroll through the article
* ~400ms time spent executing javascript (according to timeline benchmark)
I'm not really sure why all those things need to happen to load some text in a blog article.
Of course MVC (React, Angular, ...) has its place for web apps and is great when it fits, but I think it's crazy and counter-productive to use complex and costly MVC frameworks for mere content-driven sites (like what most public websites are about).
[1]: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend...
Don't kid yourself, Facebook is much much more than just a forum. It might have been little more than a forum initially, and the amount of javascript it originally had kind of upholds the OP's original statement. It was a pretty slim webapp originally.
Even when your application is not an SPA, some areas could still be SPA: editors, etc.
Why? Because after the problem of initial load, I think that further web requests are among the most expensive things you can do in terms of user wait time or latency, and that if you only start moving at the very time of user request, then it's too late to prevent a moment user waiting.
A forum is actually a pretty solid choice for an SPA, specifically the isomorphic react kind next.js sponsors. If you disagree or don't need the benefits, most existing forum software is already not an SPA, so no big deal. But a forum as an SPA can enable some more high tech forum solutions that may blur the distinction between forum community and slack community. Once the groundwork is laid out, who knows what kind of alternative architectures or plugins we'll see for it.
Also, when JS is disabled, the server will take you to the intended page and render it for you. Literally the best of both worlds.
Parent comment's point was that you could create different experiences that bring it closer to Slack.
I tried to learn it and struggled understanding the new concepts react was bringing in all while people were saying "It's easy! Everything's a components. HTML,CSS,JS all in one place!" whilst I was struggling to get a simple hello world example to run.
Just recently at my University we were forced to learn React as a part of our course and damn after I finally understood it I fell in love! It's a huge improvement over the normal web-app design work flow.
So, I would urge anyone whose anti-react to honestly give it a good go and force yourself a little to get over the initial learning curve and trust me you'll love it!
Being "anti-react" doesn't mean anti-component approach. You can do same with angular 1.5+, vue, aurelia or others.
I like React (especially with all the new setup and debugging tooling) but whenever I use it, I feel that it is a small step down from Polymer.
I think that unfortunately Polymer 0.5 was launched too early and its reputation has been tainted even though Polymer 2.0 is amazing.
I do know that there are also developers in the Vue.js camp who would never use React out of principle. I spoke with HR people from Facebook in the past and they've told me that there are developers who simply refuse to use React but I think it's more a matter of stubbornness because, all things considered, it is roughly comparable to Polymer and Vue.js.
I'd love browser makers to focus on the basics like rendering, js and asm.js and leave the rest to libs.
It just happens that out of all libraries that help you create web components, polymer is probably most widely used - well, angular 2.x can technically output web components too, but I don't want to compare a framework with library. But you can mix those components with other solutions (like x-tags, skatejs, bosonic, "pure components" etc.), they are interoperable, I even have them cooperate with legacy jquery application.
In my personal opinion, these reasons are superficial: the reason to use React is that programming UIs declaratively is easier to reason about than imperative UIs. That point can be subtle. It helps to have worked on (and struggled with) an imperatively-programmed UI before you can see how much of a pain it is. And it didn't help that out of the gate, React was pitched with "components" and "virtual DOM," and it took a while for even Facebook to be able to communicate what was so compelling about it.
Any concise answer on how react's declarative UI differs from a 2 way binding approach in angular (or if they have changed it that)?
React's virtual DOM is a hands off implementation detail that forces understanding of MVC. People can't asks= "How do I put the thing in the place", b/c that's automated by the virtual DOM. Instead, they are forced to understand that they need to describe the end state. Which is something that even an older framework like Backbone tried to do, with the end state being you only having to care about your models with the rendering automated.
Progression of (frontend) MVC started with Backbone, with manually wiring up models and view render functions so that the model changes could drive the UI. It's a specific implementation of pub/sub with the published events being a certain set of model changes. (add/change/delete/...)
(Redux is pub/sub with a security guard logging your actions and only giving you specific vetted actions to combine. Also, functional goodness.)
Angular 1 went with a polling approach that negated much of the boilerplate in backbone but was not performant (and bad docs, new things to learn, etc..) but also showed many people a cleaner paradigm of writing UI code. The trap with angular was putting everything in the controller just like the trap with backbone was putting everything in the render function.
React uses a virtual DOM so the thing to render doesn't need developer input. It's automatically inferred from the DOM diffs so the developer can focus purely on describing the UI. This is the forcing function that forces people to put down jquery and actually learn MVC.
Once this is understood, you can get into managing more complex models that actually mutually affect each other that may necessitate something like Redux. (Also, somewhere along the way, OOP become unpopular and functional stuff became hip)
JSX btw, is just an extension of javascript to create DOM elements in a less ugly way. Angular and Vue went from the other direction and extended HTML to support javascript functions. It's "<div v-for="a in apples">{{a}}</div>" vs apples.map(() => <div>red apple</div>)" It's personal preference in many ways. (You'd actually need to know a fair bit of functional js though to write concise non-ugly JSX that doesn't bury the meaning of your UI description)
The main issue I have with react is that it seems much more like a lifestyle than a tool that gets out of the way. When people list out their reasons for liking react I'm mostly just hearing "because facebook, facebook, cool, cool, facebook" just like angular was driven by google before the angular 2 marketing fiasco.
And there IS truth in it. The background philosophy driving React is actually a philosophy of functional programming which has real merit. In the real world though, with many people knowing only how to use jquery, React may help you explain to them how to understand MVC, but you're going to have a much more difficult time shoving the functional lifestyle that comes with it down their throat. But hey, if you're in the facebook sphere of influence or want to be a part of it, go for React. (Also, if you're a new grad who doesn't have the baggage of jquery)
Paradigm shifts often take a much longer time horizon than expected and often require an "earthquake" for newcomers to upset the established ideas. React and Typescript were in background mode for quite a while. The non-backwards compatibility of angular2 drove people to React, and I think Java programmers getting into web development and Satya Nadella being cooler than Balmer gave typescript a good boost.
In the end though, I don't really want to be comparing hundreds of different hammers to build my house. I just want to build a house. And hey, hopefully I have more skills than being a builder so that when entire houses are 3D printed I can still find a way to justify my existence.
The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on.
We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works.
No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc.
Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying.
Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable.
So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.
This couldn't be further from the truth. And besides, create-react-app solves that.
> No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades
I have been using react since early 2014, back when it was still very early pre-release. I have had to change exactly one thing w.r.t to the react API. When we decided to add in webpack, again, I had to change exactly one thing there as well -- I switched to a .babelrc file and they included the react transpiler by default.
Until something breaks, and you have to go through all the configs and try to fix it.
I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.
> Until something breaks, and you have to go through all the configs and try to fix it.
This is solved by understanding the language and the tools you are using. I see so many people screw up a react app because they don't know javascript. They take the same smorgasbord approach to languages and tools they have used in the past (like jQuery) and apply it to react. React is really a frontend framework for javascript developers, not a frontend framework for creative types (like Misko originally slated angular to be) If people would just take the time to learn the actual language they are using, it would make these other tools easier to grok. This is software development. It is suppose to be hard. Take the time to learn your tools.
> I’ve seen https://kukuruku.co/post/hello-real-world-in-php-in-2017/ far too often.
I always wonder why people elect to use a heavy set of opinionated tools to solve simple problems. I understand the point the blog post is trying to make, but again, it's like taking a highly set of specialized tools and complaining when it is difficult to do the simple things, when all you needed was a hammer. React is a UI library first and foremost. You can take it, inject it into your page, and use it. You shouldn't add the bells and whistles until your complexity grows to the point where it makes sense to use it. I tell people to ask themselves this question all the time, "Are you sure you need flux?" Stop and ask that question. Can this be solved by just maintaining state on a top level component and passing down props? Do you need codesplitting and chunking and the advanced features of webpack? Or do you still operate in a traditional way where designers hand of their templates to coders to create the html and css and you are just tasked with writing the javascript? Then don't use webpack loaders. Use your coder's classnames on your components.
This is people making things harder than they have to be. But again, all of this is really not that difficult if you take the time to fundamentally understand javascript.
See, in the Java world, lambdas were introduced, and I can write code with them using RetroLambda, and it will run on old JVMs, too.
But Java 8 has them natively.
And I can write a modern Java8 project with nano and javac. No transpilers, nothing.
While in the JS world, even now that browsers are starting to support ES6, everyone just adds more and more steps to the build process, instead of trying to simplify them.
Ideally, if I write code, I want it to be simple, without any such tools.
I want to be able to write one file containing dependencies, my code in a few files, execute one command, maybe two, and have a fully working product. And have it work for years, even while dependencies update.
One config, one command, and my code. Not any single LOC or invocation more.
That’s doable with JS – you just need a dependency format where dependencies can define macros over the language, and they’re handled by a transpiler or compiler, and you can import them normally. And just like that, a lot of this stuff would go away. TypeScript would just use its own frontend to the transpiler, and in your config you’d just define a different plugin.
In the gradle and java world, all that exists, with language-plugins, and annotation processors.
Yet in the JS world, it’s not like that, you have dozens of abstractions on top of another.
> This is solved by understanding the language and the tools you are using.
The problem is that the JS world is simply more complex than the Java world.
A helloworld JavaFX app is about 30LOC of config, and 20LOC of code and imports. And compared to a production JavaFX app, no more config will be added. It’s just that. That’s all you need. And easy to understand.
For React, it’s an entirely different beast (see the mentioned link)
To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated. The solution to that problem is to stick to the stable syntax until the new becomes fully supported. Admittedly, this is a problem with browsers where instead of 1 environment, there are 8 with some 1 offs, but again, there is IBM JDK, OpenJDK, Oracle JDK, Android Java (whatever that's called, Dalvik or something?)
> The problem is that the JS world is simply more complex than the Java world.
I strongly disagree. Have you seen "enterprise fizzbuzz"?* I don't mean disrespect but you are kidding yourself if you think Java isn't as complex (if not more) than the current JavaScript ecosystem. I spent 6 years programming in Java and never felt I scratched 10% of the surface.
* https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But that’s the point. That’s all just code. Just normal code. Not additional command line utilities. Even Enterprise FizzBuzz can be compiled simply with gradle or maven. No processors. No transpilers.
> To build on your Java comparison -- this is would be akin to using a new feature that is still in the JSR approval process, and then downloading an edgey JVM platform (maybe OpenJDK nightly, or something like that) and then complaining when your app gets more complicated.
But I can do that. And I just have to import one single plugin – https://github.com/evant/gradle-retrolambda, and never configure it! Nothing to configure, nothing else. One import, and I’m done.
Look at that fizzbuzz enterprise build.gradle, it’s 29LOC!
The problem of "good defaults" was never even considered in the JS world, it seems.
> But that’s the point. That’s all just code. Just normal code. Not additional command line utilities.
First, Maven does not come standard with java. Second, in a previous reply, I mentioned that if you are not comfortable with the latest and greatest, then stick to the current standard. There is nothing wrong with that, and you can be productive. If transpilers and babel seems too scary to you, which given you mention maven and gradle I assume not, then don't use them, use polyfil, which is just like that retrolambda you linked. Most all of ES6's features are sugar anyways.
Your intimate knowledge of tools and frameworks for the Java ecosystem will not equal another. What's a plugin? Ohhh you mean OSGI? No? Oh well I am lost.
What is gradle? Oh it's a new build tool? Well sorry I only know ant, and my coworker uses sbt. He's hipster like that.
> The problem of "good defaults" was never even considered in the JS world, it seems.
touché for java.
You're right in that JS tools do need to get stronger, and over even the last 2-3 years they have. I haven't had mine "constantly breaking", generally once you build a new application and set it up with your standard dependencies. Like an ORM, what ever server middleware, test frameworks, utility libraries, etc. It tends to be pretty stable, unless you try to upgrade something years down the road.
No, that shouldn’t even be a thing. All runtimes, worst case, should be maybe 6 months behind the standard, otherwise I’d want to use a single transpiler.
Going TypeScript -> ES7 -> ES6 -> ES5 is insanity.
> Hand bundling/splitting of code would be faster than browserify, webpack?
Why should that even be necessary? Upload your code file by file, and actually use the browser’s required, or have one single script implementing this as polyfill. Why should I even have to do this?
> Hand finding, curating, tracking of dependencies would be faster than NPM? mmk.
No, but NPM’s tracking is useless when dependencies constantly change their API with every release.
I’ve got so many dependencies via NPM that even change their name and API constantly that many of my projects have been broken after just a year, but all after max 2 years.
I’ve got Java projects that are 5 years old and every dependency is still update, with a stable API.
Their Hackernews clone based on their own SPA framework is much slower than the plain old HTML site.
Cannot blame them, althought the situation is better nowadays, it's still not uncommon to find a spa site where the said things are broken.
I feel like there was a huge reduction in bug-prone madness when React + the Flux pattern started gaining steam. We are still collectively working toward an end (reliable software in the browser) but it's impossible for me not to feel the difference in the past few years, as a dev and a user.
SPAs are sort of a hack. The web was designed for documents that link to each other. Maybe they'll never be perfect until we reach some sort of impossible isomorphic framework utopia, but there is real progress being made
What I'm suggesting is you ask your mother, father, grandparents,other developers, the person working the counter at the cafe, etc. Listen closely. I'm not so sure there's massive support to believe UXs are improving noticably.
The canonical example: a CRUD page with a dropdown of choices based on entitlement.
Server rendered: in your template somewhere, {for choice in limited_choices} and so on.
SPA: you need to coordinate a REST endpoint that has options for entitlement of just this dropdown, etc. You now need a route for REST, a route for the SPA page, and view code for both.
Don't get me wrong, with unlimited time, build everything as REST services with a client that consumes it. But sometimes server-side rendering is just simpler.
It's a lot faster to load template once and re-render on client with different data.
And we are pretty closely work with JS stuff. But Next.js is inspired by the simplicity of PHP.
### Anti SPA
The whole idea of Next.js is to build a SPA easily. But it's also server rendered by default.
Are you implying that react-way is the only way of doing SPA-s?
> Do you think the web Peaked with Perl-based CGI-scripts
I think your comment is just rude. There are plenty of other options in the JS world - react is just one of them.
Pretty sure he's generalizing; i.e. "anti-banana? (anti-fruit?)"
Personally, I dislike that React is 100+KB file size, when Preact or Inferno can do 95% of what I want at with 3KB.
(Yes, I know gzipping exists but it's still huge by comparison, and JS parse time is a real issue on underpowered mobile devices)
There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.
Next.js and React Server are making steps towards solving this by bringing concepts like incremental loading and data hydration by default.
I've talked about some of the approaches Facebook used to improve startup performance in the past: https://www.youtube.com/watch?v=b875VAC6r-w
In some very important ways, yes. Specifically, it was still within the contraints of what HTTP and HTML were designed for: the transfer and rendering of marked up documents. Obviously all technology is x steps forward, y steps back, and you aim for some workable linear combination of x and y, but there have definitely been several regressions since the days of Perl-based CGI scripts, and I personally haven't found them worth the advances.
I don't trust their License Agreement when it states they can revoke your License for any reason. Basically, if I get on the wrong side of Facebook, they can pull my License for React without a warning.
Unless they have amended their license since the last time I read it. In which case, I would like to see the updated version. Until then, I will continue to use InfernoJS.
React is another in a long line of Backbone, Angular, Durandal, etc. that ultimately just make stuff a lot more complicated for fairly trivial benefits. It dictates fairly complicated ways of doing simple things with long complicated tool chains that regularly break for obscure reasons that you can debug but ultimately it feels like you're simply wasting your life dealing with it. It's easy for juniors to make ridiculously complicated messes in them. They remind me of the good old days of RAD dev tools. "Oh so easy" they claimed.
And if you're any good, you can enhance traditional web forms and add the same sort of functionality without all the overhead, or complexity. Perhaps I simply have the benefit of over a decade of front-end dev.
As for SPAs, they still live firmly in the uncanny valley. They're poor versions of desktop apps, even desktop apps from the 1990s. Anyone claiming otherwise is simply delusional. Because of javascript and the DOM, they also tend to complexity, so that anything past a glorified to-do app becomes an absolute nightmare to code in.
I use Trello, Asana, Toggl, SendWithUs, etc., etc. They're all, well, a bit shit. All of them have really annoying niggles, fields you click and then might auto-save but might not. Poor desktop interfaces because "mobile first". Tabbing that doesn't work properly. Data that gets out of sync. Or they're sllllooooowwwwwwwwwww.
As for the reason React became so popular? This happened before with terrible frameworks. I may be a cynic, but it feels front end devs have got into some sort of mega-echo chamber where a new framework comes along and everyone jumps on to it because they don't want to seem out-of-date. The front-end world feels like it's in a strange kind of culture at the moment, a type of Emperor's New Clothes, where if you're not using The Latest Framework, you're obviously not worth employing.
Not because it makes you get a product to market quicker. It's a new form of bike shedding.
You sound like you don't really know or understand React. Which is fine, but it doesn't put you in a good position to criticize it intelligently. React isn't popular because of any kind of echo chamber phenomenon. It's popular because of its design; it managed hit a particular very sweet spot combining the various principles of composition, modularity, functional purity and internally consistent state management.
I do agree that web apps aren't as good as desktop apps. But that's not the fault of SPAs.
I know you can use react on top of rails (with postgres, mysql, etc), but then I start feeling too many weird abstractions going on and have a hard time following the bouncing ball. React claims to be just the V part of MVC which is fine, but when I'm trying to quickly build up a full stack application rails just felt the simplest way to do so.
Bringing this up not because I think there is anything wrong with React and I know they are solving a pure front end problem, but this is more of a question to what's the most elegant full stack solution that would be comparable to RoR solution with any of these new hot js frameworks? If there is I think I'd be more than happy to startup some projects that way.
You can write your backend in Rails (or Sinatra, which we've used a lot) and use the same workflows to wire up models and so forth.
I wouldn't want to write database stuff in JavaScript. The frameworks are all terrible. Nobody has managed to replicate the ActiveRecord story for Node.js.
Except for legacy stuff (which use Ruby + Sinatra), we write our backends in Go. But that might not be your cup of tea.
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.
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.
> Something is definitely wrong here.
> This is not a problem I've ever had.
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.
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>
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.
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.
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.