When to use single-page applications
These days, many of our clients are asking for modern frontends – in particular for websites that use single-page application (SPA) frameworks. SPA websites have been around for awhile, but they’re experiencing a resurgence in popularity as the gold standard of website creation (think of Spotify or Netflix). The most popular libraries are React, Angular, and Vue, and they all support the development of single-page applications, making SPAs all the more relevant today. SPAs seem to be a widespread solution for today’s frontend needs – but what needs do they solve for exactly and how do they compare to other approaches?
But of course, SPAs are not magical, one-size-fits-all solutions. There are several factors that can affect speed, and determine whether SPAs are right for a use case. Let’s unpack some of these considerations.
User experience is critical in the consideration of any tech build. We should always start with the user journey – their motivations and the paths they’re taking through the ecosystem – to decide what sort of architecture and tools makes the most sense.
The browser’s page history is another aspect in the UX that should be considered. The built-in history allows you to navigate back and forth between visited pages. SPAs effectively re-engineer this feature, as state management happens within the application hidden from the browser. You’ve probably encountered this in web apps that break when you try to use the regular back button. This is a critical UX issue that requires some additional consideration to be implemented correctly.
The need for speed
We also need to differentiate between initial page loads and subsequent page changes. After a SPA has been fully loaded into the client browser, loading a second state may be faster than a regular page change. In the end, SPAs just load whatever they need to and refresh the UI; so the payload is smaller, but HTML rendering comes on top. We should always consider what the user journey actually calls for. If your site is usually accessed via deep links and the user doesn’t usually visit multiple pages, it doesn’t make sense to slow down the first-page load to make subsequent loads faster. It’s best to make data-driven decisions and test along the way to find the right solution for your use cases.
There are many options to integrate a SPA with AEM. The question comes down to how we combine the application and presentation logic from the SPA with the content from AEM. AEM is highly flexible and can support most use cases. Whether it makes more sense to keep the application logic in the browser within a SPA or server-side in AEM, you should consider specific use cases and set up a well-rounded architecture.
These are some of the most common setups, according to the combinations of requirements:
- SPAs with AEM serving content completely headless as JSON (aka Content Fragments)
- SPAs with AEM serving content as snippets of HTML (aka Experience Fragments)
- SPA that only cover parts of the page, embedded into server-side rendered HTML coming from AEM
- Using the AEM SPA Editor to seamlessly edit content through the AEM Authoring Editor
- Using Commerce React Core Components to setup shopping scenarios on page
These setups aren’t mutually exclusive, either. They can be hand-picked and even combined for individual use cases. Everything depends on what you require. Ask yourself: what’s our plan for maintaining the code and content? What role does the content play? For example, do we need a what-you-see-is-what-you-get editor? How much influence over layout do authors need on a regular basis? The answers to these questions will determine what kind of architecture will serve your scenario best.
Think about your case
As with making any kind of architectural decision, whether or not SPAs are right for you will depend on your particular goals and context. While we’re fans of adopting new technology and frameworks, we will always be stronger advocates for keeping it simple, rather than jumping into needlessly complex architectural setups.
Here are some good questions to ask to guide your team to a sound decision:
- How is your application used? By whom?
- How modern is your IT landscape? Is it service-oriented?
- How do you ensure the quality of development, maintenance, and support?
- How user-specific is your content?
- How much do users interact with the content or transition between blocks of content?
- How important is SEO to your business?
- What are your key performance metrics? (i.e. initial bootstrap time, follow-up content reload speed)
Talk to one of our experts today – we’ll be happy to help you hone in on the solution that best supports your users and business goals.