Types of web applications

We analyze the main ways of organizing a web application and how they differ.

All web applications are made using the same technologies: HTML, CSS and JavaScript. However, there are many ways to organize the work of the application. The choice of method depends on the purpose of the application and the user experience we want to achieve. Although there are only two main approaches: multi-page applications and Single Page Applications, each of them is divided into subspecies.

Static multipage applications consist of a set of static pages. They are easy to develop, but if there are a lot of pages (hundreds and thousands), or the data on the page changes, then you will have to generate them on the fly. To do this, you need to connect the server and write additional code. For each transition, you need to generate and load a new page, and this takes time.

Single-page applications (SPA) make it possible to develop client applications with complex logic using JavaScript. In this approach, JavaScript controls the rendering of content on the page. Transitions between screens will be instantaneous, and the user will immediately see the result of their actions. However, this approach creates new problems. How do I not upload too much code to the browser? How to ensure good performance? Where to render the application: only on the client or on the server?

Developing such applications is often more difficult, as it may require knowledge of various tools and frameworks.

Multi-page applications

Multi–page applications are a set of static web pages that are linked together using links. When you click on the links, there is a transition between the pages, which leads to a complete refresh of the page in the browser. This is one of the most significant differences from SPA, we will talk about it separately.

To begin with , we will distinguish two main types of multi-page applications:

A set of ready-made pages that lie on the server and with them are other static files (CSS, JavaScript and images). The server sends these files via pre-configured paths.

Dynamic HTML generation on the server. Most often, such a solution can be found in the programming languages PHP, Python and Ruby. With each request, the server runs an HTML page generation script. The script can take data from the database, perform calculations and assemble the ready HTML code of the page.

Ready-made web pages

They are suitable if you need to collect several linked pages, which, for the most part, will contain static information with which the user can interact little. For example, a landing page is a website that provides information about a company, products or a product.

Development with this approach is usually the simplest. Several html files are stacked side by side, which contain all the necessary layout and additional CSS/JavaScript files connected to the page. In an advanced version, you can reuse parts of the code using template engines (for example, Pug) and assemble the site piece by piece using assemblers (Gulp, Rollup, Webpack, etc.). As a result, a set of static files will get to the server, which will be distributed using a web server (Nginx, Apache).

The advantage of this approach is excellent performance. Static pages and files can be easily cached using a browser, CDN or Service Worker.

Dynamic HTML generation

Dynamic HTML page generation was often used before the invention of the Single Page approach. This is how most forums, online stores, as well as large applications like Facebook or VKontakte still work.

The peculiarity of this approach is the use of server-side programming languages (for example, PHP or Ruby) to generate the final HTML of the page, collecting it from different parts and enriching it with data.

For example, a user went to a page with a list of friends:

  • The server receives the request.
  • Goes to the database, selects a list of friends and auxiliary data.
  • Collects HTML by template.
  • Sends HTML as a response to the request.

The user immediately receives a generated page with a list of friends. If you add new friends and go to the page again, the result will be different, because the list of friends has changed.

Using the server to generate content allows you not to load the client code with complex logic, which means the final page size will be smaller. At the same time, static parts of the application and whole chunks of pages can be cached just as easily.

a schema for the dynamic web pages approach

With all the advantages of multi-page applications, they all suffer from one main drawback: when switching between pages, the browser completely updates the content, which is why it is impossible to create a full-fledged interaction experience “as in the application”: uncached pages need time to load, which means there will be no instant transition; the scrollbar position will be lost, etc.

In an effort to solve these problems and create a full-fledged application experience, web developers have invented single-page applications.

Single page applications (SPA)

Section of the article “Single page applications (SPA)”

Single-page applications (abbreviated SPA) consist of a single page, and JavaScript performs all the rest of the work (creating content, switching between screens and receiving data). This approach allows you to create a full-fledged application experience: transitions between screens occur instantly, you can give the user a visual response while the data is loaded asynchronously using the API.

The development of single-page applications has a rich ecosystem: frameworks and libraries for creating interfaces, development approaches, architectural patterns. Single-page applications are divided according to the place of initial page rendering: in the browser (client side rendering) or on the server (server side rendering).

Client Side Rendering (CSR)

Section of the article “Client Side Rendering (CSR)”

In such an application, all rendering of the page content, including the first one, takes place in the browser. The user must first load all the JavaScript, and only after that something will be able to be rendered. Until then, the page will either be empty, or it will contain a static stub loader.

This is the easiest way to display the SPA. It is suitable for small applications, as it loads and runs quickly. If there is a lot of code and the application turns out to be large, users with weak devices or slow Internet may not wait for the download and leave.

SPA does not work without JavaScript. If for some reason the user has disabled it in his browser, then the one-page application will not start at all.

This requirement is especially important in the context of how search services index SPA. Previously, search engines did not know how to execute JavaScript, and therefore single-page applications did not get into the search results. Now the situation has changed, search services are able to execute JavaScript, but static sites are still indexed better.

Client Side Rendering scheme

Server side rendering (SSR)

Section of the article “Server side rendering (SSR)”

To prevent the user from looking at an empty page while waiting for the application to load, you can give him the HTML generated by the server. Thus, the user will immediately receive the expected page and start viewing it while the main application is loaded and launched.

This approach is called server rendering. It helps to improve both the user experience and the site’s position in search engines. Google and Yandex search can execute JavaScript, but sites with static content are preferred.

The main difference between this approach and rendering on the client is the server that does the rendering. Most often it is a ready-made solution based on Node.js . Many SPA frameworks have proven solutions for a quick start of an application with server rendering. For example, Next.js for React or Nuxt for Vue.

Your solution for SSR is not an easy task. There are many factors to consider: how and where to go for data, how to draw the application correctly, and many other details.

An additional server part may require additional infrastructure, which makes it more difficult to develop an application with server side rendering.

Leave a Reply

Your email address will not be published. Required fields are marked *