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.
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:
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.
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:
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.