Is Single Page Application Worth the Hype?

Decrease costs

05 Jun Is Single Page Application Worth the Hype?

Single page applications (SPAs) are all the rage today. But, are they really worth the hype? Absolutely. SPAs are a significant enhancement over traditional website development applications, which haven’t changed much in the last 20 years. With SPAs, you can:
• Save time
• Streamline support and maintenance
• Reduce costs
• Enhance the site experience

Before we discuss the benefits, we’ll briefly discuss traditional application delivery methods such as JSP, PHP, ASP, and Ruby (Ruby on Rails). These tech stacks have one thing in common: server side rendering, which has been the standard for web application development and delivery for more than 20 years.

With traditional website applications, each event rendering or action that is driven by a page interaction results in a lengthy and complicated process. With each call, a network call must be initiated, data fetched and then rendered on an HTML view, then transmitted back to the client application, and rendered as a document object model (DOM) in the browser. This cumbersome process is the primary reason why SPAs have recently gained traction. SPAs don’t eliminate the round-trip request or the response paradigm of the client/server interaction, but they do improve the experience surrounding it.

The primary difference between traditional website applications and SPAs is that now you only have to wait once for a SPA to download and initialize, then it seamlessly navigates through the application interface, creating a client side experience that’s completely local. Although any service calls to the various data subscriptions must still make the round trip to the server and back, because a SPA only fetches data and returns the response as JSON or XML, packages aren’t burdened with full HTML/CSS rendering.

Save Time
A SPA can manage its own routing within the SPA, not through the browser. Because the SPA templates, CSS, and DOM are already loaded to memory, rendering the view does not require as much time or client memory. When accessing a new route, the SPA pulls what the route does and loads it from the local memory, eliminating any wait for new pages – and saving a lot of time. With SPAs, developers can also save time because they can push updates continuously rather waiting for a scheduled build, significantly reducing development timelines.

Streamline Support and Maintenance
A SPA can use the service-oriented architecture (SOA) landscape to fetch data it needs via a pub/sub relationship with data services. It’s not bound to one data set or set of APIs. In contrast, traditional website applications bind data fetching and data rendering to a specific view or template, which makes the site more difficult to maintain, especially if the data and data model change regularly. The service-agnostic approach allows for easier support and maintenance.

Reduce Costs
Because SPA reduces development efforts and saves time, overall costs for site development and maintenance are reduced. SPA also reduces the need for highly experienced JSP developers because HTML, JavaScript, and CSS developers have the necessary skills to develop within the SPA environment.

Enhance User Experience for Developers and Site Visitors
The SPA routing and SOA access helps provide a much better developer experience. The SPA architecture ensures that developers can spend more time on usability competencies such as information architecture, interaction design, visual design, and technical writing. But most importantly, SPA also improves the application’s performance and scalability for developers.

While less time, streamlined processes, and reduced costs are all benefits internally, the greatest benefit comes from a much-improved user experience because the overall site performance improves. With the site rendering locally (on the device) your site visitors will experience a better overall site experience – which help drive up conversions and revenue.

The Tradeoff
Who cares if your information architecture and site experience are the best, if each page load takes longer than the 3-second threshold? SPAs try to bridge this load time problem by minimizing wait time between the SPA pages. There is a tradeoff, however, as users must endure a longer initial load and initialization process for the benefit. Users are willing to make this tradeoff to a degree, which explains the popularity of SPA. However, users continue to demand faster, more responsive web applications that can be viewed anywhere. In our next two articles, we discuss how combining SPAs with server side rendering and ahead of time (AOT) compiling can deliver an even bigger impact on site performance and the overall site experience.

No Comments

Sorry, the comment form is closed at this time.