which approach to choose based on business objectives

The approach to developing a front-end in a product has long been not a whim of a developer, but a tool for solving a business problem. The article in simple words about why this is so, how the choice of approach depends on the purpose of the product, as well as examples of the use of approaches.

Greetings! My name is Andrey Stepanov, I am CTO at fuse8. It is interesting for me to get acquainted with the experience of colleagues in the workshop and share my own. I have been in the field for over 20 years. In this article, I will talk about how to choose a front-end approach based on business goals and explain what features each of the approaches has.

Immediately note: this article does not cover options for using website builders like Tilda or Webflow. We will talk about the development of complex IT products: highload projects, personal accounts in B2B and business automation. Designers, as a rule, are not able to cover such requests.

Personal accounts, online services, web applications: client rendering

Let’s talk about applications that the user enters through the login: personal account, internal corporate system, CRM, ERP. This also includes an Internet bank, a web-based mail interface, a personal account on Ozone or State Services, a feed and correspondence in social networks. The user in such applications sees data that is relevant only for him. And indexing by search engines for this data is not needed, so the client rendering method is used.

Client side rendering or SPA (Single Page Application) – a method in which the browser downloads the main structure of the page and the application code once and generates the HTML code of the page in the browser itself on the user’s device.

Further, during user interaction, the browser accesses one or more APIs for additional data and dynamically updates the HTML without the need for a full page reload. As a result, when the user decides to switch to another module, the browser will open it almost instantly.

Front-end client-side rendering takes place in the browser, while the back-end API delivers the data. The organizational plus is that the front-end team with this approach has complete control over the entire logic of the interface and can change it without involving the back-end.

When such applications become large enough, the first download of the application can take several seconds. This is a minus if you open the service many times a day (mail or CRM).

Caching the application code in the browser helps speed up the process. The code is saved and there is no need to download it again every time.

You can download the code in parts. For example, first – the code for displaying the open section of the application with which the user interacts, and the rest of the code is loaded after.

There is one problem with client-side rendering – it is not suitable for projects that require SEO optimization. Search engines do not index pages that are rendered in the browser well, so for SEO it is worth using a different front-end architecture.

PWA: return mobile service to users, even if the application was removed from the stores

Separately, we note Progressive web apps (PWAs): A set of technologies that bring web applications as close as possible to familiar mobile applications. This approach is relevant now, when applications are regularly removed from the App Store and Google Play, and no one can restrict the installation of a PWA application.

PWA allows you to add an application shortcut to your phone desktop, work offline, receive push notifications. The approach is also useful in cases where it is too expensive or difficult to create separate mobile applications for iOS and Android in addition to the web service.

Content portals, media, blogs: static site generation

What projects are users attracted to with the help of SEO? As a rule, these are content resources where new materials are regularly published and then archived, generating traffic. Examples: online media, magazines, blogs, company product catalogs, thematic information portals.

In order for search engines to better index the site, HTML markup for each of its pages should be given from the server. The speed of loading, as well as the quality content of a web page, affects its position in the search engine results. Therefore, it is important that the site loads quickly – both on the server and in the browser.

Static site generation (SSG) – an approach in which the HTML code of the pages is generated once at the time of publication and stored on the server. Changes in this publication do not appear (or appear very rarely), so the generation is “static”. Further, the server will instantly give the HTML code of the finished page to users and search engines, ensuring fast page loading.

A powerful server is not needed to serve a static site, because the main load occurs only at the time of the publication of the article. Additionally, you can lay out a static site on a CDN to further speed up page loading.

Some resource pages with static generation still need to be updated. For example, in online media, the main page, the news page, will be dynamic. For such sections, you can adjust the frequency of updating the static HTML code or update them on certain events. For example, for breaking news.

Headless CMS: Content Builder and API

A portal designed to publish a large amount of indexed content using static generation is good. However, the content needs to be edited and stored. For this, it is convenient to use Headless CMS. For example, Strapi.

The difference between Headless CMS and the previous generation of CMS like Bitrix or WordPress is that they do not generate the HTML code of the pages themselves, but simply provide content through the API in a structured way.

The same content from Headless CMS can thus be reused for different channels. For example, on a website, in a mobile application or in an email newsletter.

Headless CMS allows you to choose any front-end stack or technology for creating a user interface, regardless of the back-end.

Another plus is that projects on Headless CMS can be done entirely by a front-end developer. There is no need to additionally involve, for example, a PHP back-end developer, as when developing on Bitrix or WordPress.

Dynamic online stores and user-generated content: server-side rendering

Content that is frequently published and updated on the portal may also need to be indexed and kept up to date. For example, this happens in online stores where prices, current positions or discounts often change (hello, Ozone!). Another example is sites where user-generated content is based on forums and platforms with ads, such as hh.ru or Avito.

For such services, static generation is not very suitable, because it is important to always display the most up-to-date information. Generating a large amount of content statically is not practical: a complete rebuild can take hours and days, and many terabytes will be required for storage. Therefore, the server rendering method is used.

Server side rendering / SSR – an approach in which the page is generated on the server with each request from the user.

The main feature of server rendering is that you need much more server resources than with static generation, because each request is processed separately. To optimize resource usage, it is wise to apply different caching strategies.

From this follows the need for a more experienced and expensive development team.

Single code for rendering on the server and in the browser

For modern sites with static generation or server rendering, there is an important requirement: after downloading the finished page from the server, users expect that many interactive elements will start working on it without reloading the page, as in client rendering.

For example, a product catalog page with filters. The user gets to it from a search engine and can immediately start filtering products according to different parameters.

In the past (and many still do this), a lot of development time was spent to implement this with their own hands. Now you can use tools that will do everything for you – Next.js, for example.

Previously, when the back-end was implemented in a different language (e.g. PHP or C#) than the front-end, the implementation had to duplicate the rendering logic on the front-end and back-end and keep it in sync with every change.

Now the Next.js framework is used, which allows you to use the same code both on the server and in the browser in JavaScript, and display logic in React. It can automatically “animate” dynamic React components after server rendering and navigate between pages without completely reloading them.

This way you can get the best of both worlds: indexability and speed of the first load of SSR or SSG, and fast navigation and subsequent loading of data as in client rendering. And all this at no additional cost.

Hybrid approaches

Do not think that when creating a complex site, you need to be limited to only one approach to the formation and loading of pages. It is possible and necessary sometimes to make hybrid models.

The most common and simplest case is to load dynamic or personalized data in the browser onto a statically generated page.

On a site, most of the content can be generated statically. In this case, individual blocks are rendered in the browser. These are, for example, user-specific blocks or very dynamic segments.

Another example is to use static generation and client-side rendering for different sections of the site.

Combining approaches helps the web service to be more productive.

What suits my project

To choose the most effective approach, it is worth being as honest as possible at the stage of negotiations with the contractor. Like visiting a doctor. And here the main thing for the client to come with a request is not in the form of a solution (“Develop me a new site”), but in the form of a description of his pain (“My old site does not bring money at all, help”).

A conscientious contractor will not blindly offer his standard architecture or “service package” to the customer, but will try to understand the task. Therefore, the client should describe his “pain” honestly and without concealing details. So the contractor is more likely to be able to understand the problem and offer a solution that will cover the client’s need.