"We knew we wanted to build a single page application (SPA) in order to have more control over the user experience of our website, making it as smooth as possible. On top of this, it also helps speed our website up since there’s no longer a need for full page reloads. We only need to load the data that we don’t have yet, and then re-render the page."
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
I wish I would hear this expressed more often. Many, many web apps lend themselves well to a very simple page-based UI. The development community can just never seem to recognize or acknowledge how many of their decisions are based on whatever the latest fad happens to be.
"Also there is no inherent speed boost from an SPA"
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
In theory yes, and if you only aim your site at flagship smart phone owners.
In my experience in Latin America with 50-150$ Android phones, very few developers/managers in the "western world" actually care about their SPAs performance and in about 9/10 cases the simple backend rendered sites provide a better experience for me.
edit: Of course there also plenty of devs that add a ton of inperformant js to their backend rendered sites, destroying the experience.
Don't know why this was downvoted, it is relevant. That's the main reason why hacks like PJAX/turbolinks were invented in the first place, not having to reparse the same JS and CSS for every page change has a noticeable impact in perceived performance.
A wonderful solution for this is the Turbolinks approach which is a part of the standard Rails stack.
The new page request takes place over Ajax, the server sends the whole page, and only the body gets replaced thus avoiding the need for loading common assets and initializing js.
Svelte allows isomorphic rendering (client & server side). Svelte also has a feature called rehydrate, which will bind the component to html rendered on the server side; sortof like serializing/unserializing.
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
That speed improvement is assuming that people are actually browsing around your app/site. Which might or might not be true depending on what your are building.
This is one of the reason why I really dislike most news sites or blogs using SPAs. I usually get to a page via direct link and leave immediately after reading. But every time i have to stare at a spinner or coloured progress bar until the styled plain text finally is revealed to me.
SPA applications support the ability to update parts of a web page e.g. an article content might be 5K out of a 20K file. A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
Browser caching, not server-side caching. The browser doesn't have to "bring down" the 20k page "again and again", it gets the assets out of its cache (html, js, css, images, etc), and then the JavaScript loads the 5k article when the DOM is ready. Hope you're not trolling. Non-SPA websites can be basically just as fast as SPA's, and in practice they are often faster since they are usually built without frameworks and have less JavaScripts.
We aren't talking about CSS, JS, Images but purely about the HTML page. If you have a 20K page and 15K of that belongs to header, footer, sidebar then in a server side rendered site that 15K has to be downloaded for every page on the site. On a SPA site it only has to be downloaded once as you can dynamically switch out the other parts.
If there was a mechanism in the HTML spec to tag parts of a page for partial caching then we wouldn't need SPA in most cases. But browsers only cache the entire HTML.
You can totally reimplement a model that the browser supports natively, but you close off basically every affordance that a page-based approach provides unless you commit to reimplementing things like (among others) accessibility support for screen readers or reader views, usability with nonstandard clients, and interoperability with the client's environment (I guarantee that your custom progress bar doesn't have the same semantics as the loading spinner on my browser tab). Most of these things come effectively for free with regular pages, so I don't see what benefit doing extra work to reduce your product's flexibility has if a page-based model already suits your content in the first place.
You are talking in abstracts. What does nonstandard clients or interoperability with the client's environment specifically mean ?
And all modern day screen readers support SPA applications. They wouldn't be much use if they couldn't and is the reason you have SPA sites amongst major enterprise companies (who always comply with accessibility policies).
Comments
"We knew we wanted to build a single page application (SPA) in order to have more control over the user experience of our website, making it as smooth as possible. On top of this, it also helps speed our website up since there’s no longer a need for full page reloads. We only need to load the data that we don’t have yet, and then re-render the page."
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
I wish I would hear this expressed more often. Many, many web apps lend themselves well to a very simple page-based UI. The development community can just never seem to recognize or acknowledge how many of their decisions are based on whatever the latest fad happens to be.
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
In theory yes, and if you only aim your site at flagship smart phone owners.
In my experience in Latin America with 50-150$ Android phones, very few developers/managers in the "western world" actually care about their SPAs performance and in about 9/10 cases the simple backend rendered sites provide a better experience for me.
edit: Of course there also plenty of devs that add a ton of inperformant js to their backend rendered sites, destroying the experience.
Don't know why this was downvoted, it is relevant. That's the main reason why hacks like PJAX/turbolinks were invented in the first place, not having to reparse the same JS and CSS for every page change has a noticeable impact in perceived performance.
A wonderful solution for this is the Turbolinks approach which is a part of the standard Rails stack.
The new page request takes place over Ajax, the server sends the whole page, and only the body gets replaced thus avoiding the need for loading common assets and initializing js.
I'm simplifying but hopefully you get the point.
Svelte allows isomorphic rendering (client & server side). Svelte also has a feature called rehydrate, which will bind the component to html rendered on the server side; sortof like serializing/unserializing.
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
https://svelte.technology/
Here's a quick post about my setup for static sites.
http://www.briantakita.com/posts/monorepo-static-sites-using...
Here's a post on converting from riotjs to svelte on a client project.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
You realize it's just html and css with some js to swap out elements right
Case in point: plain HTML gmail is more far responsive than both Inbox and regular AJAXy gmail.
None of what you said makes any sense to me.
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
That speed improvement is assuming that people are actually browsing around your app/site. Which might or might not be true depending on what your are building.
This is one of the reason why I really dislike most news sites or blogs using SPAs. I usually get to a page via direct link and leave immediately after reading. But every time i have to stare at a spinner or coloured progress bar until the styled plain text finally is revealed to me.
Not true. If you do proper caching and configure your nginx properly back-end rendering can be just as fast.
What you are saying technically makes no sense.
SPA applications support the ability to update parts of a web page e.g. an article content might be 5K out of a 20K file. A server side website has to bring down the 20K page again and again as the user navigates through your site. Caching or web server configuration makes no difference here.
Browser caching, not server-side caching. The browser doesn't have to "bring down" the 20k page "again and again", it gets the assets out of its cache (html, js, css, images, etc), and then the JavaScript loads the 5k article when the DOM is ready. Hope you're not trolling. Non-SPA websites can be basically just as fast as SPA's, and in practice they are often faster since they are usually built without frameworks and have less JavaScripts.
How is this hard to understand ?
We aren't talking about CSS, JS, Images but purely about the HTML page. If you have a 20K page and 15K of that belongs to header, footer, sidebar then in a server side rendered site that 15K has to be downloaded for every page on the site. On a SPA site it only has to be downloaded once as you can dynamically switch out the other parts.
If there was a mechanism in the HTML spec to tag parts of a page for partial caching then we wouldn't need SPA in most cases. But browsers only cache the entire HTML.
Your header and footer must be pretty horrible if they take 75% of HTML.
You can totally reimplement a model that the browser supports natively, but you close off basically every affordance that a page-based approach provides unless you commit to reimplementing things like (among others) accessibility support for screen readers or reader views, usability with nonstandard clients, and interoperability with the client's environment (I guarantee that your custom progress bar doesn't have the same semantics as the loading spinner on my browser tab). Most of these things come effectively for free with regular pages, so I don't see what benefit doing extra work to reduce your product's flexibility has if a page-based model already suits your content in the first place.
You are talking in abstracts. What does nonstandard clients or interoperability with the client's environment specifically mean ?
And all modern day screen readers support SPA applications. They wouldn't be much use if they couldn't and is the reason you have SPA sites amongst major enterprise companies (who always comply with accessibility policies).