Web Application Types (Part 1)

No two web apps are the same. There are many factors that go into choosing an architecture for your web app: page speeds, SEO, interactivity, maintainability, security, complexity—the list goes on and on.

In my experience, the architectures of web apps follow one of a few common patterns that optimize on a few of these factors at the expense of the others.

Static Website

This web app style has been around since the beginning of the Internet. All assets (HTML, CSS, etc.) are prepared in advance, then sent from the server and rendered in the browser. There is little to no client-side logic (e.g., JavaScript) running in the browser.

Such sites have very minimal server requirements and are very search engine– and cache- friendly. They usually have very fast page-load times. However, static sites offer little to no interactivity and do not support displaying user-specific content. These websites aren’t really web apps in any meaningful sense.

Traditional Server-Side Rendering

Also referred to as “multi-page apps”, server-side apps dynamically generate some or all of the assets while processing the browser’s request. These web apps contain varying levels of client-side logic, which is primarily used to coordinate user activity and dynamically show/hide content provided by the server. It is not used to generate large sections of HTML.

The server HTTP endpoints rarely return data, but instead return new full or partial HTML pages to be rendered in the browser.

Server types come in endless variations. A few server types we commonly work with at Expero include:

• Node.js Express
• ASP.NET MVC
• Java Spring MVC
• Ruby on Rails
• Laravel
• Django

These web apps can customize the content for each request, allowing for user-specific content. The sections of the web app that aren’t locked behind authentication tend to be search engine–friendly and, if engineered correctly, can have very fast page-load times. However, because user interactions require a round-trip server request to generate updated HTML, they do not support low-latency user interactions.

Client-Side Single-Page App

In these apps, the majority of the HTML generation is performed in the client browser. The server’s role is to provide the assets needed to launch the client-side app (e.g., scripts, CSS, etc.) as well as data to be rendered by the client app. The client JavaScript is responsible for retrieving data from the server, generating displays for the user, collecting user input and making requests to the server on behalf of the user.

The server tends to have a rich REST API and most of its endpoints return raw data. Very few HTTP endpoints will return actual HTML.

The client JavaScript often uses a framework to help with the HTML generation. Some of the common frameworks we encounter at Expero:

• jQuery
• Angular
• React
• Ember
• Durandal

Client-side single-page apps can customize the content for each request, allowing for user-specific content. Because the client generates all of the HTML, these web apps support low-latency user interactions indistinguishable from a traditional desktop client application. The website relies upon JavaScript to generate HTML, so these apps are not search engine–friendly and also tend to have slower page-load times.

Isomorphic Single-Page Apps

These web apps combine server-side rendering with client-side rendering. In this scenario, the server generates a complete initial view of the HTML. Once the initial view is shown to the user, the client takes over all HTML-generation responsibilities.

The server tends to have both a rich REST API as well as HTTP endpoints that serve HTML. The client JavaScript often uses a framework to help with the HTML generation.

By combining server-side rendering and client-side rendering, these web apps enjoy the benefits of both techniques without their downsides. They support low-latency user interactions, and are also search engine–friendly and have slow page-load times.

However, they suffer from increased complexity and often lead to duplication of code. For this reason, the server is most commonly implemented in Node.js so that the same JavaScript HTML-generation code can be shared between the client and server.

Common frameworks we’ve encountered at Expero include:

• React
• Meteor

Conclusion

There’s no one “best” web app architecture. Every option out there will come with some tradeoffs that you’ll need to map against your particular needs.

One aspect of web apps that still needs to be explored is how different architectures offer different deployment opportunities. In my next post, I’ll go into more detail on the Client-Side Single-Page App and discuss how this type of web app is really two different applications that have completely different deployment options.