I recommend reading my comment again, it's not about what each approach can and cannot accomplish technically, it's about maintainability.
I can give examples of a lot of things that SPA's can't do, that's not the point.
I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad.
SPA's do not help split responsibilities, I can easily give the SPA a low level Data API and start implementing data processing functionalities in the frontend.
SPA's don't help build services, good frameworks do.
SPA is a religion, cause it states 'Single Page'. What if I want to have an application with 2 or 3 pages just because it doesn't make any sense whatsoever to cram everything into 1 page? What if I can render a lot of stuff on the backend and be 100x more efficient and provide far superior UX?
I had a colleague once who wanted to do everything on the client side, he said that the SPA is the way to go. He got 6 months to prove his approach is good. He failed. His application was both slow as hell and nobody on the team could maintain it. So after he left it took me roughly 2 months to implement what he had in 1/5th of the code.
On the other hand, it saves a lot of time in backend development if all you have there is an API.
HTML rendering, form handling, etc take up a lot of time in the backend too. And with the interactivity that is expected now for many pages (forms just as an example), you end up having to duplicate a lot of things on backend end frontend.
And you end up using a framework on the backend too, because you really don't want to hand roll all the routing, templating and form handling. You don't. Trust me.
As long as you are comfortable with a JS stack (or have specialized devs for that) and have a good way of server side rendering figured out, I don't think an SPA incurs a big overall tax.
As an additional plus, there can be a lot more decoupling between frontend and backend work. You can stub out the API and work on the frontend independently in a much cleaner fashion.
While the author explains that the front and backend are coupled, I think they overstate the coupling of client/API but don’t account for the numerous and disparate factors that motivated the popularity of SPAs to begin with. It’s perhaps out of scope of a comment to go into those details, but anyone who’s built and had to evolve large business applications on the web in the early 2000s is familiar with the headaches of the traditional server side techniques [sweats in server-side includes, ASP.NET form state, unnecessary db calls loading whole pages when only part has changed, etc.]. Not even getting into other benefits (API reuse and the flexibility to support multiple clients and use cases simultaneously).
In my opinion, the two major problems are tooling (which I think is more of an issue with browsers and the deficiencies of JS) and people using SPAs as an all purpose solution (does your blog or marketing homepage really need to be a SPA, really?). The former has seen steady improvements, but at any rate I’ll eat the cost of because it’s worth it for some of the larger systems I have to build and maintain. The former, well I dunno what to tell you, the cargo cult has been a fixture in this industry for a long time. I don’t think wearing a “you’re a bad person if you develop SPAs” helps (not accusing OP of this, but remarking on a general attitude) but in fact furthers the problem by pressing devs into binary thinking rather than evaluating and making decisions on their own.
So I’m with you: I won’t be shamed for having written SPAs and I’ll continue to do so as needed
Your arguments seem to be assuming a particularly bad implementation of a traditional backend.
Whenever someone says "this particular architecture is bad!" they're talking a bad implementation of it.
The point is whether or not you're more likely to succeed at making a good app with an SPA or a multi-page site. For pretty much all brochure-styles websites and many SaaS webapps you're more likely to achieve success (for every common understanding of success) by using a multi-page architecture because they're usually simpler to implement, they work the way browsers expect things to work, and you don't need to implement some hard things yourself. You can make a brilliant SPA website for any purpose, but often people try and fail. Saying "you shouldn't have used an SPA" is shorthand for "You didn't understand or implement an SPA well enough, and now your web thing is failing to serve users as well as it should, and using a multi-page architecture would have avoided the problems your website has now."
I completely disagree with the assessment of this article. I've been building and managing the build of simple to enterprise web applications since the web was born. I'm familiar with the entire spectrum of development platforms from old CGI/Perl, ASP, JSP, Cold Fusion, ASP.NET, MVC-platforms (pick one), and now SPA's using front-end platforms like AngularJS and ReactJS.
The amount of time saved in developing services and front-ends over a server-based system is so significant as to offset any of the complexities mentioned here.
The speed of development, the ability to rapidly change requirements, to adapt to stakeholders wants and needs...all are supported by the service+SPA model.
And tooling is coming in many forms to support this pattern, so it's not going anywhere.
> 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.
This was one of the points that stood out for me in the article too, also because I strongly disagreed with it. There is nothing inherently wonderful about doing everything client-side.
You get a much more limited range of languages and libraries to work with. You get to use overcomplicated build and deployment processes with ever-changing tools. You get to reinvent the wheel if you do want to use things like URI-based routing and browser history in a sensible way. In many cases you are going to need most of the same back-end infrastructure to supply the underlying data anyway.
Also, it's tough to argue the SPA approach is significantly more efficient if it's being compared with a traditional web app built using a server-side framework where switching contexts requests exactly one uncached HTML file, no uncached CSS or JS in many cases, and any specific resources for the new page that you would have had to download anyway.
Of course some web apps are sufficiently interactive that you do need to move more of the code client-side, and beyond a certain point you might find it's then easier to do everything there instead of splitting responsibilities. I'm not saying everything should be done server-side; I'm saying different choices work for different projects and it is unwise to assume that SPA will be a good choice for all new projects.
Great advice. Thanks. Somehow I think it proves my point, though - that SPA frameworks lead to endless complexity making the whole front-end industry the province of senior developers.
I agree and disagree. I think API first and some form of a SPA is insanely powerful and probably the way to go for most larger scale projects. For everything else there is a lot of things that can be solved from a simple templating system. Sure its not as sexy but for a lot of the business cases you really don't need a sexy interface.
My favorite example is the bloatware that is Asana. I would be 10x happier if it was a using simple components written in JS but not the whole app hiding inside of a bloated SPA.
YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff.
Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things.
Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me.
Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.
The major argument is that if you build an SPA, you'll do a bad job. So... don't do a bad job?
This completely misses the major benefit of SPA: reusable web components made with the latest version of JS with a framework that updates the DOM from a view model. I guess you could accomplish that without SPA, but I'm pretty sure we're all here for the frameworks/es6/typescript/compnents, and SPA is just the deployment model. A deployment model which allows all that to happen with a fairly short initial load if you're doing things right.
If you're loading multiple megabytes in your first chunk in 2018, then you're doing it wrong.
All that said, are you making an 'application', or are you making an informational website?
If you're making a simple website, SPA is just silly. If you're making an application, and it just happens to be deployed via a browser, SPA, and more importantly, the things I mentioned going with it, are a huge productivity and organizational boost.
The SPA movement has always seemed like a cargo cult to me. Yes, AJAX is handy and it was exciting when it came out. We used it to update search results when you changed a filter.
For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.
This misses the part where with an SPA I have to figure out what data and access patterns my frontend code is going to want, define an API+schema for the frontend-backend interactions, and (often) write data validation on both the frontend and the backend - all this in addition to the data definition I would have to do on the backend in any case.
If I'm able to render things from the backend, I just have to query the data and slot it into the page. No need to design an API that's flexible enough for application use but still inflexible enough to prevent security holes.
Also, if I decide later to update how the data is represented (a common activity in early-stage projects), I only have to edit only one thing instead of two things.
not sure why you're being downvoted. SPA's have their place but I agree with you that they are being heavily overused.
I've seen plenty of applications that could have easily been a collection of server driven pages broken into an api and spa. I think it comes down to a few things where SPAs are great.
1. Programmers padding their resume. react looks more marketable that any server side templating technology
2. fomo, what if later we want to add something that needs it
3. seperate api/frontend teams, spas make seperating responsibility easier. two seperate codebases.
of course it has its downsides
1. you're maintaining a communication bridege between two different applications. This entails a context switch if you're a developer hopping back and forth.
2. more failure modes to handle. Only so many things can go wrong loading a page. If an SPA breaks, it can render the entire page unusable. You also need to have error. handling code for inputs on both your frontend and backend.
3. large file sizes to download. This one has been beaten to death but it still holds true.
Ive personally found a nice middleground with phoenix liveview. Its slightly more work than a tradtional page driven app while giving me teh ability to create all the features I was being asked for that before would have warrented an SPA. I hear livewire and stimulus reflex are great too.
> Developing SPAs is easier than server-render applications.
Not sure about "easier". I'm a backend person so take this with a grain of salt but, to me, nothing on the web is easier than doing everything server side. All of your code can be in one language (plus a template) and the same build.
Consider what it takes to make a change in each model. In an SPA with one of the frameworks mentioned, it requires several changes, across directories and languages in both the front and back-end, and usually two different build chains.
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.
Could not disagree more with the article. In my experience, well designed SPAs are almost always better and lighter than multi page apps. The fact that a lot of SPAs are implemented quite poorly is a different story. In actual fact, whether a web app is single or multi page is merely an implementation detail; in both cases we're just passing information back and forth between client and server. With multi page apps, you transmit and parse full markup each time. With SPAs, you do it once and then mutate as needed. In that sense it's more efficient and I can't see why that's a bad thing.
I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application.
The browser <-> multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working.
UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can be without all the cruft you have to add to make a SPA work because it's actually a sort-of-massive-workaround.
But that probably lies more in the framework used rather then in the "SPA concept". Disclaimer: I'm not a front-end developer so I may be totally wrong.
Your point is orthogonal, even if true. My point is that SPA frameworks are necessarily buggy and inefficient - after all, their whole point is to reimplement in a bespoke fashion the stuff that the browser already implemented.
Buggy and inefficient stuff sometimes makes sense to a business, this is true.
I can give examples of a lot of things that SPA's can't do, that's not the point.
I also don't think, you should either build everything on the backend or everything on the frontend, I consider both approaches to be equally bad.
SPA's do not help split responsibilities, I can easily give the SPA a low level Data API and start implementing data processing functionalities in the frontend.
SPA's don't help build services, good frameworks do.
SPA is a religion, cause it states 'Single Page'. What if I want to have an application with 2 or 3 pages just because it doesn't make any sense whatsoever to cram everything into 1 page? What if I can render a lot of stuff on the backend and be 100x more efficient and provide far superior UX?
I had a colleague once who wanted to do everything on the client side, he said that the SPA is the way to go. He got 6 months to prove his approach is good. He failed. His application was both slow as hell and nobody on the team could maintain it. So after he left it took me roughly 2 months to implement what he had in 1/5th of the code.
reply