We analyze the main ways of organizing a web application and how they differ.
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.
Developing such applications is often more difficult, as it may require knowledge of various tools and frameworks.
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:
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.
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)”
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)”
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.
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.
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.