The article talks a lot about technology choice, but not about given product. I do tend to agree – that SPAs are not necessary, but I would not use this article as an argument.
And if somebody would present this article to me – I would not take it seriously. The fact that author is using very interesting language when refering to React and Angular does not help. I'd love to hear customer-centric or product-centric reasoning.
* Don't use SPA because customers hate it when you change entire app on them.
* Don't use SPA, because customers of our particular product require faster turn-around.
* Don't use SPA, because they are harder to test in our organisation.
I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.
To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking.
A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions immediately. Articles like this talk to SPAs as if they are unnecessary or overused. I disagree, I think SPAs are mostly appropriate for most SaaS, social media, or business tooling. Sure, the poorly implemented version of an SPA is harder to debug than a poorly implemented template generated site, but that's like comparing the complexity of a car built in 2021 to a car built in 1980. And cars from 2021 sell better than cars from 1980.
A lot of these articles strike me as opinion pieces decrying the direction of modern web development, and seem to point to the past as a more 'gilded age' of internet browsing. But this was back when users sat at a desk, and scrolled pages using a analog mouse, viewing it on a CRT monitor. Users today want to browse on their phones, want to share and upload, to take live videos, to see when their message was sent, delivered and read. We need SPAs and libraries like React just like we need cars that can do lane assist. It's because it's a feature users want, and on the whole, it is much easier to build using React and SPAs.
Your conclusion is hard to disagree with. I don't think anyone's saying all apps should be SPA's or no apps should be SPA's
I think what a lot of us are saying here is that SPA's in general are overused in our industry when simpler solutions are more appropriate. And that's having a negative effect on productivity and developer happiness.
> SPAs have allowed engineers to create some great web applications, but they come with a cost:
> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.
Yes, better quality software usually packages a bit more complexity.
SPAs are popular, just like native apps, because people don't like jarring reloads. Webviews in native apps are panned for a reason; turning your whole app into a series of webviews would be stupid, right?
> Tooling is an ever-shifting landscape in terms of building and packaging code.
I've used these 4 libraries to build apps since 2015:
* React
* MobX
* D3
* Webpack
The only one I have had pain with is react-router-dom, which has had 2 or 3 "fuck our last approach" refactors in this time. And I added TypeScript in 2018.
PEBCAK
> Managing state on both the client and server
It's a lie that a thin client isn't managing state; it's just doing a static, dumb job of it.
Imagine some cool feature like... collaborative editing.
How would you pull that off in HTMX?
> Frameworks, on top of libraries, on top of other libraries, on top of polyfills. React even recommend using a framework on top of their tech:
Yes, React is famously not a batteries-included library, while Angular is. But, as addressed, you need about 3 other libraries.
Besides, did you know: HTMX is also a framework. Did you know: HTMX also has a learning curve. Did you know: HTMX forces you to be able to manipulate and assemble HTMLstrings in a language that might not have any typing or tooling for that?
Anyways, I've said enough. I should've just said what I really think: someone who can't even get their nested HTML lists to actually indent the nesting shouldn't give advice on building UIs.
I'm not anti-SPA (and in fact, I think of the tools out there react is a pretty good one if you're going to do SPA), but I do think it's the wrong tool for a lot of jobs. If your site is mainly content-based, like a blog or a forum, why make it an SPA?
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.
That’s not an argument against SPAs, that’s an argument for investing more time on product discovery stage to understand that this is actually a requirement. When implemented with relatively small effort, it does have better UX.
I feel that this argument is pretty outdated at this point.
Most new SPAs people build use frameworks like NextJS that solve all of the big complaints.
Sure, there's plenty of old, crufty SPAs from the pre-react-router days still out there. I also dislike those apps.
I guess my point is... there was a time when you could blanketly hate SPAs and be mostly right about the category. And you could be mad at a company for even daring to try because they were very likely to screw it up. But I think we are now past that period. SPAs are now pretty awesome and fast and good!
Edit: ah, this article is from 2016. Which actually was a very valid time to hate SPAs! Maybe this is a good moment to applaud the hard work of folks at Vercel for fixing the problem :-)
> If you follow the "modern best practices" to make a SPA, you are talking about pulling in at least: npm, webpack, react, react-router, lodash, redux, bootstrap, and perhaps much more.
I wouldn't call that best practice, more like the hype train. All you really need, at a minimum is a text editor and jQuery. Once you're comfortable with that, you can move on to the more fancy stuff.
I don't think it's holding SPAs to a higher standard. It's holding SPAs to a reasonable expectation for SPAs. An SPA is significantly more complicated on the client side in exchange for some purported benefits, especially to the user (such as only downloading what you need). If everything is discarded on each "page" transition and re-downloaded again upon a return, and has the page-popping-into-place effect, that eliminates one of the foremost benefits of an SPA and diminishes the UX.
I encourage anyone developing an SPA to go talk to actual end users about this. Most will report that they don't like the experience, often citing a variety of issues, but one of the biggest ones is related to the immediate page transitions followed by blank boxes or loading spinners for a perceptible amount of time. You'll hear comments like "it feels too fast" or "it feels like nothing is happening". These are not good things, and developers shouldn't be clutching their React/Angular/Vue/whatever framework just because it's what they know how to develop in, at the cost of producing products that users don't like as much as normal server side rendered applications.
You are conflating the root comment of this and the OP's point. It's not about SPA. It's about network effect / marketing / cult / lack-principle insanity of frondend or web market that's heavily into React specially.
I think the author is mistaken. You can build a PWA, SPA in Next.js and it's even easier than not using it.
I feel like the author is just confused that they're not specifically focusing on SPA because whether anyone wants to admit or not, enterprise companies aren't asking for SPA, or mobile apps, they're asking for headless, static websites. It makes sense that React would respond to those market demands.
> Currently 99% of websites are not SPAs, but I think a lot of sites will switch to SPAs in the future, since they offer a better UX(no full reloads, more interactivity etc) in most cases. I'm sure customers will demand these sort of sites once they start using more SPAs.
I can see highly interactive sites switching, but most sites are not highly interactive and would have no reason to switch to an SPA. For any content (as opposed to interaction) heavy site, like a blog, I can't see any advantage of an SPA. Server rendered pages can be cached and served lightning fast. For an SPA, in addition to the time to transfer the page content and assets (which is required for both server and SPA apps), they have to load a JS framework and then render the page browser side. This will cause slower load times, so I don't see many sites choosing this trade off unless they are highly interactive.
> A lot things can be easier if you do things the "wrong way".
> It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable...
I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA.
When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion.
The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway.
When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage.
Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.
> Doesn't really sound like an application, but a website.
That's probably the key thing - most companies building SPA's don't really need an application but a website. There are many interesting products that need to be applications because of the functionality they need, but for every one such product there's at least a dozen that does not.
People are emotionally attached to SPA's because they are:
1) Annoyed by page refreshes
2) SPA's is a special skill now, frontend developers take pride in knowing everything about React, Vue, Angular and spending hours and hours updating their NPM dependencies. How can they justify all the time spent if it's not almost like a science?
3) Separates the frontend guys from the backend guys. Technologies like HTMX allows the backend developer to pretty much do the whole job, which concerns a few people.
I've been working with SPAs for the last 4 years and I must say I can't decide which approach is better. I believe SPAs provide better user experience, but the cost of that is significant. Also, not every component-based page must be an SPA. You can have multiple pages, each of them having some components.
Regarding the article, it feels like author is angry that someone prefers server-side approach instead of his favourite way of developing apps. I disagree with a bunch of arguments in the article:
> (about server-side templates) For any large application (by large I mean more than 50 individually developed screens) this slowly becomes harder to maintain.
50 server-side templates vs 50 stateful components, I really don't see why the former is harder to maintain
> (about server-side templates) How to name things — when everything is dynamic, naming becomes hard.
Again, no idea why naming would be easier with SPAs
> Use runtime templating after AJAX call is done. We cannot use server side rendering any more — or can we? Let’s write endpoints that return HTML and not JSON.
Or course we can do that, why not? Even more - when lazily loading templates in component framework like Angular, I need to not only download the template that's in HTML, but also Angular needs to compile that template.
> Let’s be honest — the only way one can say developing SPA application is costly is if they either don’t know any SPA technology or if they don’t want to learn it.
I don't have any hard data, but neither does the author, so I guess we'll focus on personal experience. From my experience keeping state only in the backend is easier to maintain and therefore cheaper than keeping the state both in the backend and in the frontend.
> Knowing server side templating language. Also not being able to use the same language for AJAX templating.
But to write client components I also need to learn some Angular templating syntax or JSX or some other stuff. And it's not simpler to learn than let's say PHP templating.
If I use PHP for my backend, then I don't need to learn template language, because I just use HTML + embedded PHP.
> If you have proper mobile app, an API has to be developed for that. Having two layers accessing the same data in two different ways is not practical.
That's a fair point, however it doesn't make a big difference.
Using SPA I need to develop JSON API + mobile views + SPA components
Using multi page app, I need to develop JSON API + mobile views + server side templates
> State on the client — because that is where the state belongs to.
But why? The state does not need to belong to the client. The client might be a representation of the state that comes from the server.
Sure! I think it's just a question of scale and knowing your problem. If it's "the entire customer-facing area needs a large amount of interactivity" then going with a SPA makes sense. If it's "this particular UI element on the customer app needs a large amount of interactivity", that's easy to build as an isolated component regardless of the technology of the rest of the app.
One thing that I'll always view as a smell though is "we don't need X now, but we might need X in the future, so we should adopt this more complex technology just in case". We've learned that lesson MANY times as developers, it's not any less true for front-end technologies.
And if somebody would present this article to me – I would not take it seriously. The fact that author is using very interesting language when refering to React and Angular does not help. I'd love to hear customer-centric or product-centric reasoning. * Don't use SPA because customers hate it when you change entire app on them. * Don't use SPA, because customers of our particular product require faster turn-around. * Don't use SPA, because they are harder to test in our organisation.
reply