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.
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.
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.
Surely all of the money invested into that SPA could be redirected into a simpler full-stack app, with sprinkles of progressive JS?
On the one hand you have a shared-nothing architecture that serves HTML and can enjoy varying forms of caching.
On the other you have an application that still depends on a server, but replaces all of that simplicity with a stateful client-server architecture that requires _more_ infra to manage, at a greater expense.
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
I'm not a huge fan of putting client-side rendering on everything, but I still feel it's unfair and shallow to put so much blame on it.
For an app getting more than a couple page views in a session, a SPA solution may provide significant savings on rendering and db queries. Combine that with resource caching and these effects extend to following sessions.
That is, of course, if the app was built with some consideration regarding overall performance. Unfortunately, not too many web developers (both FE and BE) seem to be overly concerned with efficiency.
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.
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.
exactly that. since 2012 i build all my websites as SPAs for this reason. more so, i am not even writing any new backends. i reuse the same backend over and over. most websites (at least the ones i have been building) are just CRUD and don't really need a custom backend.
SPAs bring back the client-server architecture we had before the web. you build desktop clients that consume server-api's.
server-side html generation now feels like cruft and an awkward way of building applications.
> An SPA done right offers amazing interactibily and instant navigation to new views. You already have the templates cached. They probably load from a cdn with good caching policy.
Most of the time I find the initial delay loading/parsing the js to be more problematic than the often tiny speed increase of subsequent loads.
Furthermore, these days it takes minimal to no tweaking to get server-side rendered pages to load fast enough to barely notice the difference (in particular if the client-side is retrieving and parsing JSON in the background through an API request). Perhaps non-webdevs are even less likely to notice this stuff.
> If done well you can totally run offline.
That's definitely an advantage, but most SPAs I encounter don't offer offline functionality, or it's entirely unnecessary to offer it.
> Sure you can build with php, laravel, django. The promise of SPA is a clean separation of UI from the APIs. The same REST APIs that external customers use is the same API you develop on. See travis-ci as an example. It’s the same api that the mobile apps can use.
In some cases that's definitely an advantage. But it's entirely feasible to build an API-based backend and use that API internally for server-side rendering. If you want an app that plays nice with search engines you have to do this anyways.
> This separation allows the api to return very lightweight stateless responses. You can scale much better when there is less state kungfu.
That doesn't make sense to me. One of the biggest issues I have with SPAs is that you now have to deal with the backend state (DB) and a subset of this state on the client, which dramatically increases complexity (state management, sync, etc.). I rather like the old-fashioned approach where all state remains in the backend, except perhaps for the tiny bits you'd put in a cookie (and I suppose the URL could be considered client-site state too).
> The UI can manage the state in very responsive manner. No round trips, instant 60fps render.
How many apps do you use where you really need anything below say, sub-second rendering? Frameworks like Phoenix and/or caching can be much faster than that even (in the order of microseconds).
> And no JavaScript is not slow. It’s just that people don’t know it well and end up loading megs of bloated libs with a 1000 ad tracking libraries.
Clearly if so many SPAs are bloated Mb-size messes, it's not trivial to solve. And it's a problem you can almost entirely avoid if you keep the rendering on the server. After years of agonizing over bundle sizes, I find it incredibly liberating to not have to think about this anymore (much of the time, anyways).
> Don’t throw the baby with the bathwater.
I do agree that there are plenty of use cases for SPAs, but I also agree with many here who say they're very over-used.
I'll add that there are some interesting initiatives to have 'old-fashioned' applications that also get to be dynamic enough for many if most use cases. Phoenix LiveView [1], for example, takes advantage of very fast server-side rendering, websockets, and sending subsets of the templates as HTML snippets to the client, where morphdom simply diffs the HTML string with the element it's supposed to replace. With great performance.
Frankly I think both reasons given for the supposed greater difficulty of building SPAs are wrong- and that SPAs have been successful exactly because they're much easier to develop.
Additional logic tier: exactly the opposite is true. A SPA allows to get rid (almost) completely of the logic on the server, leaving there only a shallow layer of services. While traditional web applications always had the problem of a complex logic layer on the backend, with in addition the need to manage complicated interactions happening only client side (because even traditional web applications couldn't afford an entire page reload for simple things like reordering a table, displaying an error message, etc.). Part of the logic had to be replicated on both sides, with all the problems that it creates.
Data synchronization- again, given the fact that the entire state of the application resides only on the client and is rendered only by the client, data synchronization becomes trivial- it's just a matter of calling some backend service to store or retrieve the full state.
In short, the problem with traditional web apps is that they've always had the need to manage a state on the client as well as on the server; and the client's state was lost at every page reload, or either had to be sent to the server with some hack to be restored after the page reload. A nightmare.
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.
Completely Disagree. SPA's are about making your 'site' like a GUI application. If you had to use Apache to navigate pages in visual .net or QT that'd be crazy.
SPA's also benefit from static caching and serving. You do not always need to have the pages being served from your origin, but can be served from a much cheaper source like Cloudflare or even a different origin.
One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets.
You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performance.)
Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server.
As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)
> And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?
Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.
Every app will have a bunch of serverside data so IMO that's not really a consideration.
The great thing about SPAs is that your server now just returns a simple JSON API. It greatly simplifies the server side. It also tends to make things a lot easier to unit test on the server side. Also, it cleanly segments your staffing requirements. If your app is in some way non-trivial, you can have domain experts working on the backend, and just dumping json into http responses, and have a frontend engineer who doesn't understand any of the magic work on the frontend.
> Returning HTML and doing a simple element replace with the new content is 99.9% indistinguishable from a SPA.
Once you're doing this, your backend engineers are dealing with html in addition to whatever their real job is. If you want to have something other than your website consume your backend, you're rewriting stuff to output json anyway.
If you have no domain-specific computation happening and your service will only ever be consumed as a more or less static website, serverside web frameworks can be faster. For example, if you are building a blogging site, or maybe a CRM.
Half of the article is just ragging on a specific subset of poorly designed SPAs (those that don't use HTML 5 history mode with proper server side routing set up), which the author acknowledges before finally moving onto other points.
The other half I'm not even convinced these are real problems:
> A fantastic example of the problems created by the SPA approach is parallelization of work. If you have a team of multiple people, or God forbid, multiple teams working on the same SPA, you need to come up with a good way to support this. Instead, you can just have each of those teams build their own web application. Each of those applications can be connected to every other one built at the same time by the same organization (as well as to every other web application residing anywhere, if you want to) — in fact relying on the core strength of the web.
This paragraph I guess presents a problem and it's "ROCA" solution, but the solution proposed works for SPAs too. You can just make multiple SPA applications.
> everyone started moving to frontend/backend services and SPAs
Yes, there are valid reasons for SPAs, but many web applications and most classic web sites are still better served with plain old server-generated HTML, IMO.
First, because replicating even basic functionality in JavaScript comes at a cost, namely in bytes sent, bytes to be parsed, bugs introduced, etc. Second, because most projects don’t have unlimited development resources, so developers might just slap a few libraries together without necessary optimization, customization, or testing.
Third, because the well-known experience of browsing static web pages is already pretty darn good, and what developers will find exciting, users might just find irritating. Needlessly breaking conventions is simply bad UX.
Contrary to that, I keep reading that SPAs are the “new way”, as if classic server-rendered HTML enriched with some Ajax suddenly became a deprecated, inferior technology. It really isn’t. Unless you know what you’re doing, and why you need to, the classic way is still a sane default. If in doubt, I would always prefer a solid Django site over a half-baked SPA.
I kind of have to agree here. There are very few times I've ever worked on a SPA and felt like throwing it all away and using the alternative.
The last time I thought about this, which admittedly was many years ago, the alternatives that I knew about were: server-side frameworks like ASP.NET MVC Razor, PHP, RoR templates, Node.js EJS, Jade (now Pug), and static HTML.
Nowadays, you can create extremely elegant and performant SPAs with tools like Next.js and Remix, so I really couldn't agree less to the OP.
I honestly feel the same. I've been working as a web developer for 8 years now, so it's not like I've been locked in a basement for decades and don't like all this new fangled stuff because it's not what I'm used to. I just don't get what SPAs provide over server rendered pages with a sprinkling of JavaScript to make things more interactive.
Ok maybe it makes sense if you are building a game. Or something that needs to run offline. Or Facebook. But most web sites aren't like that.
The other day there was a Ask HN about what stack a CMS should be built in. Most people were recommending their favourite client-side JavaScript framework. I just don't get it...
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.
reply