by Santiago L. Valdarrama and originally posted on his blog svpino.com

I’ve been developing Single-Page Applications for a while. I started using plain JavaScript, then jQuery, then a bunch of other crazy libraries, to then finally settle with AngularJS. I’ve been a fan since day one, and I believe users can benefit a lot from them.

By now I think I’ve learned what happens when a SPA is used instead of what should have been a regular web site. Nothing surprising here; there’s no silver bullet in any aspect of software development, specially when we are talking about the whole architecture of a web site or application.

My intention is not to make this post a rant about all the drawbacks of Single-Page Applications. Instead, I want to share their current status from my personal perspective and point out those situations where they can hurt more than help.

What’s a Single-Page Application?

If you don’t know what I’m talking about, here is Wikipedia’s definition of Single-Page Applications:

A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.

That’s clear; is a way to bring a more fluid, desktop-alike experience to the web, but the best interesting part about SPAs comes right next:

In a SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions. The page does not reload at any point in the process, nor does control transfer to another page, (…).

If you don’t learn anything else from this post, at least keep in mind how a SPA works and why is useful. Thanks to this architecture, we can develop a better user experience through a more fluid interface by hiding all the complexity inherent to the web (requests, responses, etc.)

How do Single-Page Applications work?

The simplest definition of a web site is basically a set of pages with links between each other. Every time a user clicks on a link, the browser sends a request to the server to retrieve the new page and show it to the user.

In a regular web site, there are usually sections that are repeated across multiple pages: the header, the footer, maybe a side bar with links. The content area is usually the only one changing from page to page. One type of Single-Page Application leverages this fact, and instead of keeping separate physical pages around, embeds the content of multiple pages into one single page, keeping only the right content visible at a time. Whenever a user clicks a link, instead of having to request a full new page from the server, the SPA hides the current content and displays the new content in place.

Another type of Single-Page Application is all AJAX-based. In this case, only a bare minimum of HTML is served to the browser, and whenever the user engages, all the new content is retrieved using AJAX calls. Note that only the content that changes will be requested, keeping the user all the time in the same page with no reloads.

As you can imagine, the experience when using a SPA is faster and more fluid. If the content to display wasn’t downloaded from the beginning, and instead is being requested using AJAX, the experience still feels snappier to the user since only the portion that changes is retrieved behind the scenes. A Single-Page Application does most of the heavy work up-front by downloading everything that’s needed, swapping the content later on in place, or requesting just small portions of it.

Linking becomes an issue

Linking is the main problem with this approach: since a Single-Page Application is not actually keeping multiple physical pages but instead swapping and retrieving content from inside a unique page, there aren’t “real links” going out to “real pages”, but instead the linking schema is used in the browser to decide which particular section needs to be displayed or retrieved from the server.

Have you seen a hash symbol (#) used as part of a URL? It’s called a fragment identifier. This is what Single-Page Applications use to identify what content section to display or retrieve when a link is clicked. An example link in a SPA might look like this: http://www.example.com/#contact-us. Everything after the fragment identifier (contact-us in this case) refers to a subordinate resource to the default page (index.html). Using JavaScript, a SPA uses this information to select the proper section to display.

Note that fragments identifiers are never sent to the server. A request tohttp://www.example.com/page.html#section2 will be sent ashttp://www.example.com/page.html only, leaving the fragment identifier off the request. The fragment identifier needs to be processed then by JavaScript in the client side.

SEO implications

You’d agree with me if I say that Search Engine Optimization is one of the most important topics when building a web site. It doesn’t matter how good is your site if you aren’t discovered by your potential users. Unfortunately, creating a Single-Page Application has huge implications for SEO.

Since your pages are built in the browser, the search engine crawler will see a different version of the page than your users; when the crawler requests a page from your server, you’d either be serving the whole package containing all the content, or just a shell with AJAX hooks to execute and retrieve the proper content after the page is displayed. This, of course, causes the crawler to see either the wrong information, or not information at all, which will not help you to score well in their ranking algorithms.

Also, when the crawler sees a link, it will only request the base URL from the server leaving the fragment identifier off the request. This means that bothhttp://www.example.com/#contact-us andhttp://www.example.com/#about will end up returning the sameindex.html page from the server. If all the different sections are included as part of the the response, both URLs will look exactly the same to the crawler. If the content is accessed using AJAX instead, the crawler won’t see anything useful to index.

This is a big hurdle for web site developers. There’s a solution to this problem commonly referred as the hashbang approach, but it means adding server side code to return a static HTML snapshot of the page to the crawler and the regular code to the browser. Setting this up correctly makes the whole SPA approach very complicated and inconvenient.

Performance implications

Once the user starts interacting with a Single-Page Application, the whole experience will feel better than a regular web site, but depending on what approach is used to deliver the content to the browser, we might create a performance problem.

When using AJAX calls to retrieve different sections of the site, performance is less of an issue than when the whole content is embedded into one single HTML file and delivered all at once during the first request. Instead of downloading only what the user needs, we are forcing them to wait for the whole site before even knowing if they are going to visit past our home page.

Depending on what type of web site you are building, using this approach may be prohibitive for your users; they just don’t have the patience to sit tight while you display a blank page waiting for all the content to come through. This problem is amplified for mobile devices which usually suffer from very slow connections.

JavaScript support

I know. I shouldn’t be talking about this in 2014, but the fact is that JavaScript support is still an issue all across the globe. It’s not only a matter of what browser are our users using, but whether or not they have JavaScript enabled on the first place.

I can name (but won’t) a couple of high-profile companies with entire departments using IE8 with no JavaScript. If you want to count those users as yours, you need to stay away from web sites that heavily rely on JavaScript to present the content. It’s okay if they get a stripped-down version of your page with limited functionality, but it’s unacceptable if they can’t access it at all.

Conclusions

Does this mean Single-Page Applications are not useful? Not at all! I love them and they solve a real problem, but we need to make sure we use them only when they make sense.

I’ve found out that the sweet spot for a SPA are web applications instead of regular web sites. Web apps are not usually searchable (most of them are hidden after some sort of authentication wall anyway), so SEO is not an issue. Your users are already committed to the app. They want to use it, so they are willing to navigate any hurdles to get the benefits you are offering them by using a SPA.

A regular discoverable and public web site on the other hand is a different story. You need to weight all the pros and cons before making the decision of going with a SPA. It’s never a clear cut, so make sure you explore the implications before committing for the long term.