Web DevelopmentAPI Development

Single Page Web Apps: Why building a web app means less… and more than it used to


The number of modern web technologies available to software engineers is mind boggling. Developers building applications for the web - especially of the JavaScript-heavy variety - have been talking about “framework fatigue” and “analysis paralysis” for years.

At WillowTree, our engineering team knows that focusing on high-level architecture decisions first can help alleviate some of this paralysis. This saves you money and critical development time, and most importantly, results in a better product for your users.

The quickest path to understanding your options is to understand how web development has bloomed over the last ten years.

How we got here

Call this a spicy take if you want, but the current state of the web app ecosystem can be traced in large part back to the introduction of the iPhone and the resultant explosion of native app development and app stores.

This isn’t because web apps now had to compete with a whole new breed of native siblings - apps that had access to device-level functionality and clear distribution channels. Or at least that’s not the whole story. Much more important was the fact that companies of all stripes, in all industries, were now building data-rich APIs, exposing crucial user data in a format that was suitable for consumption by native apps.

How do we know? WillowTree’s DNA formed in the early days of Apple’s App Store. Our web practice grew primarily out of a belief that users deserved better than the static, “obviously web” UX of the past. An explosion of software tools and browser capabilities has helped us reach that goal.

When “Single Page Apps” were all the rage

Because of our deep experience building native apps for Fortune 500 companies, our web team was well prepared for the mindset shift that happened in the early 2010s. Backbone.js, Angular, and Ember.js all encouraged web developers to consider pushing web application architectures to the extreme. Namely: “What if we put all the business logic in client side JavaScript? What if the only HTML from the server was a shell to hold dynamic content?”

“Single Page App” became the best available shorthand for this architecture. Apps were, quite literally in many cases, a single page of HTML. Not every app had to adhere that strictly to the rules (sometimes you might have a single page per feature set, for example), but the concept is still the same.

But there were downsides, too. All that JavaScript meant that Google had a harder time indexing content (when it could at all), and interfaces built with a bunch of asynchronous requests to the server often left users watching multiple loading spinners, at least on the initial page load.

React, Node.js, and Universal JavaScript

React exploded onto the web development scene in 2013, and WillowTree started building production apps using it as soon as it was released to the public shortly thereafter. React was a game changer in the world of single page apps, and we’ve shipped dozens of high performance apps that use it. We’ve found React apps take less effort to make performant and are easier for developers to reason about - and thus build and maintain.

But arguably React’s biggest contributions to the web app ecosystem have been:

  • Tremendous staying power. React won large market and mind share for a huge percentage of the web developer community and has held it for a long time. This means developers have been able to build up a host of best practices around its use and haven’t had to constantly switch from framework to framework.
  • Versatility. In particular, it works well in a server-rendered environment.

I can hear you now: “But wait - server-side rendering? Isn’t that the model of apps built years ago? How does that even work?”

Server-side rendering refers to the practice of assembling a “complete” HTML page by way of display logic that executes on the server. The user gets the whole page all at once - without loading spinners, but with the drawback of a potentially longer wait before the user sees any rendered content.

Node.js, first released in 2009, allows developers to write server-side logic in JavaScript. Universal JavaScript refers to the architectural pattern of sharing view code between the server - which runs Node.js - and the client. I wrote about this in depth on this blog when Netflix first started using this pattern for their biggest web properties.

In short, the magic here is that you can use view logic to render on the server at first page load and on the client (e.g. in the browser) for subsequent user interactions. As I said in that previous post: “It’s important to consider that Universal JavaScript is a new technology. As a result, there’s a good deal of churn around the “right way” to approach technical design.”

Enter Next.js

No single tool (since React) has captured the attention of the web team at WillowTree as completely as Next.js. Why? It is, quite simply, the most user-friendly attempt yet to provide a toolkit for building out Universal JS applications.

But what’s providing even more sticking power is the feature set Next.js continues to build. Baked-in tools for building out data-rich APIs gives the team another way to provide network APIs to power apps of all varieties. The team at Next.js also keeps up with advances in the tooling space - providing automatic code splitting and hot code reloading, for example - to help developers stay more focused on the job of building apps and less concerned with maintaining development environment tools.

But one of the most interesting and … well, fun arguments for Next.js’s importance in the evolution of the web ecosystem is that it also includes a sane way to do static site generation. In other words, to build static HTML versions of your site that can be hosted as flat files on a server or CDN.

It’s possible, even likely, that this functionality, itself a throwback to the very earliest days of the web when static site generation using scripting languages like Perl was used often, is the least used feature of Next.js. But it nods to a fact that seasoned developers have long understood to be true: there’s nothing faster in the web world than static, flat files.

A mature ecosystem means more - and better choices

Tools are important, but they’re not nearly as important as choosing the right architecture for the job. What a mature ecosystem, like the one that has developed in the front-end web space over the last 10 or so years, gives you is a tool that addresses a wide array of different architectural patterns. Moreover, a mature ecosystem has some semblance of tool stability in each of those architectural arenas.

Future pieces on this blog will talk about some of the architectural patterns discussed here, and the circumstances in which you may want to pick a particular one. These include:

  • Static Site Generation
  • Single Page Apps
  • Server Side Rendering (with Universal JS)

At the end of the day, end user experience is more important than any tool or even architecture. The current ecosystem provides developers with enough high quality tools, servicing enough well-conceived architectural models, to deliver rock solid software on time and then iterate often. That’s good news for both developers and end users of modern web software.

Join our team to work with Fortune 500 companies in solving real-world product strategy, design, and technical problems.

Find Your Role

Improving Web App Performance with Web Workers

Introduction Web applications are, for the most part, single-threaded. All of...

Read the article