Single Page Applications: A Powerful Design Pattern for Modern Web Apps
Single page applications (SPAs) are a hot item in the technology sector. As the demand for complex apps and rich user interfaces increase, developers are repeatedly turning to the SPA design pattern. SPAs are known for their fast and seamless responses to user interaction, relative ease of building and debugging, and a straightforward transition into mobile development, since the back-end and front-end of the app are decoupled. Many users interact with this type of application everyday — Gmail, Google Docs, Facebook, Twitter, and GitHub are all SPAs.
The two major design patterns for web application development are single page applications and multi-page applications (MPAs). As with any design pattern, SPAs have their benefits and drawbacks, and developers should clearly understand how SPAs work in order to make the right choice when considering the infrastructure of their application. Here, we will review the basics of SPAs and how they are different from traditional MPAs, along with their pros and cons.
What Is A Single Page Application?
A SPA is a web application that literally has one page — a single HTML page is loaded in the browser and is not reloaded during use. When users interact with the page, the application dynamically rewrites/updates the current page rather than loading a new page from the server. Since the HTML is rendered and manipulated client-side, the size of the payload is decreased because the server returns only JSON, not HTML. Many popular JavaScript frameworks, including Vue.js, AngularJS, Ember.js, Meteor.js, and React, have adopted SPA principles.
What Is A Multi-Page Application?
MPAs are a traditional kind of web app — every time the application needs to display data or submit data back to server, it must request a new page, which is then rendered in the web browser. This approach is fine for simple applications, but if the app becomes more complex with lots of data or an intricate interface, it may run into performance issues. Generating pages on a server, transferring them to the client, and rendering them into the browser takes time, and can degrade the user experience.
How SPAs Work
SPAs can work in two ways:
- All the necessary code (HTML, CSS, and JavaScript) is received in a single page load, or,
- The appropriate code is dynamically loaded as needed in response to user actions.
SPAs request the markup (HTML) and data (JSON) independently and renders pages directly in the browser. While a SPA is running, only data is sent over the wire, which takes a lot less time and bandwidth than constantly sending HTML. To reflect changes from user interaction, the application relies on dynamic communication with a web server, via AJAX or web sockets, behind the scenes. This handy graphic visualizes the lifecycle processes of a multi-page (traditional) app vs an SPA:
SPAs offer a superior UX by mimicking the experience of a desktop app — no wait time and no page reloads, making content and performance the priority.
Pros of SPAs:
- Fast and fluid response time — as discussed above, the user doesn’t have to wait for a new page to be loaded from the server, therefore avoiding interruptions in the experience and making the web app behave more like a desktop application.
- Simple to build and debug — the developer does not have to write code to render pages on the server, resulting in a streamlined development process. After the skeleton page loads, the server acts purely as a service layer. Theoretically, the entire backend can be replaced and as long as you don’t change the API, the client won’t break. The reverse is also true — you can redo the entire client app without changing the service layer. Debugging SPAs in Chrome is also straightforward — it’s easy to investigate page elements and HTTP requests.
- Easy to deploy in production — SPAs load just one index.html file, with a CSS bundle and a JavaScript bundle. These static files can then be uploaded to any content server, like Amazon S3 or Apache.
- Smooth transition to mobile development — since front-end and back-end development are decoupled, it is simpler to develop a mobile interface from a SPA. The backend can remain the same, as the client only needs to know what HTTP requests to send.
Cons of SPAs:
- SEO implications — the biggest drawback of SPAs, until recently, is that most search engines didn’t support client-side rendering when crawling websites, and had trouble correctly indexing a SPA. As of this writing, Google is generally able to crawl websites that use AJAX calls, but some reports say it isn’t completely able to do so yet. Therefore, additional thought may need to be put into the content so that it can be discoverable by search engines and have a link preview in social media sites.
Some of these SEO concerns can be mitigated with isomorphic /server-side rendering, where the initial rendering is done on the server and can be cached. This is a way of handling SEO optimizations for now until enhancements are in place.
- Long initial wait time — the initial load of the page can be slow, as all the HTML has to be loaded into the browser. Potentially heavy front-end frameworks are required to build SPAs, as the browser is the workhouse in this design pattern. Note that some of this can also be mitigated with frameworks/libraries such as Vue.js and React — which are lightweight and flexible.
- Still need to wait for data — users still have to wait for data to come back via AJAX/XHR in JSON after the skeleton page has loaded.
SPAs have become a popular technology in recent years and for good reason — users expect rich, detailed interfaces that are both visually appealing and performant. While there are still some drawbacks to using the SPA design pattern, many of these concerns are becoming less relevant with various technologies and infrastructures adapting to the SPA design and increased use of AJAX.
This post was first published on my company’s blog. Check us out here: http://www.eikospartners.com/!
