What happened to the development sphere during the last year, what changes were faced by developers and what is just starting being implemented, but will continue to develop further — we tell about all this in today’s review.
1. Serverless architecture
The “serverless” approach implies two types of architecture:
BaaS (backend as a service) — applications that have a large share of the server part stored in the cloud. The standard functionality in such a model is usually provided in the form of SDK or API gateways, and all the necessary actions are performed in the cloud. At the same time, the responsibility for software and infrastructure maintenance lies with the supplier of the BaaS solution.
FaaS (functionality as a service) is a third—party platform for developing, launching and managing functionality that runs parts of its code, focusing on event triggers (the necessary functionality, called on request). The approach is especially good for implementing microservices.
Serverless and microservice architecture — the difference?
Serverless architecture — uses cloud environments: that is, there is still a server, but it does not belong to the owner of the site or application, but is used by someone else, on request. As soon as the trigger event occurs, the serverless functionality is launched — operations are performed in the right sequence (their set depends on the user’s actions), and then the serverless platform works out a pack of ready-made algorithms and rules, makes the necessary calculations and outputs the result. After that, the functionality collapses and waits for a new request. Serverless architecture is especially relevant when you need to optimize the cost of resources and time for development.
Microservice architecture — the application is divided into small components (microservices) that have a clear purpose, are easily replaced and can interact with each other, being loosely connected. Usually, containers like Docker are used to create microservices, with the help of which the necessary data is obtained upon request to a specific API. Microservices are justified, for example, in e-commerce, where it is important to containerize (make independent) huge datasets. And by the way, microservices themselves are also a trend.
Serverless architecture has its advantages:
- rapid deployment of applications, because you don’t need to worry about architecture and infrastructure — just write your own code;
- cost reduction: you no longer need to spend resources on server and database maintenance, product launch is faster and cheaper, and you don’t need to maintain spare capacity — you only pay for what you use;
- simple scaling: if the usual “physical” server is no longer enough, adding another one or moving to a more powerful one is still a task, and there are no such problems with serverless architecture;
- data is relatively “safe” — they are not as afraid of various kinds of attacks as in the case of the traditional server approach to creating websites and applications.
- About security — everything is ambiguous. If a DDoS attack is launched on this “serverless”, which serves 1000 clients, in order to slow down one of them, the remaining 999, unrelated to the purpose of such an attack, will suffer.
Of the minuses, it is difficult, especially in the case of migration of current solutions to a serverless architecture. It can also be potentially expensive, although among the advantages it is said about saving resources. Well, another fly in the ointment: the code execution speed is not high enough and the current solutions are poorly adapted for tasks of processing large amounts of data.
2. Containers
A container is a software package containing all dependencies: code, runtime, configuration, and system libraries. Containers are almost a panacea for web systems: they are light, nimble and can work at a sufficient level of abstraction (that is, independently of other processes). And they also reduce the cost of developing and operating applications.
3. SSG — static site generators
According to the classics, most websites and applications work like this:
- the user clicks on the link;
- the browser sends a request to the server;
- the server executes the code and finds out what content needs to be shown to the user;
- the server uploads the required content from the database to the page template;
- the server renders the resulting HTML code and sends it to the browser;
- the user sees the desired content on the page according to his request.
Static Site Generators (SSGs) work differently. They create static HTML pages based on a template or components, and use a separate source for the content.
Pros:
- simplified technology stack for serving static pages;
- best performance — pages generated in advance;
- security — minimizing dynamic content due to pre-rendering equals greater resistance to attacks.
Of the minuses, at least, there is a very large limitation of such sites, because it is impossible to simply display “own” content to the user. And you can’t change something quickly on such a site. If there is a setting on a regular site that affects the entire site (the phone in the header, for example), you just change something – and it is updated everywhere at once. For SSG — it is necessary to completely regenerate the site with such simple changes.
Static site generators (SSG) are implemented through frameworks — for example, Next. js, Nuxt. js, Gridsome or Gatsby. By the way, Figma is based on Gatsby.
4. Headless CMS
Traditional content management systems (CMS) use a content management framework that combines both an interface (frontend) and a backend (backend). At the same time, the content is associated with a specific technology and architecture within this CMS. But such a monolithic approach in modern web environments turns out to be cumbersome.
Headless CMS solve this problem: they only provide a backend for content management via the API. Due to this, you can use one backend at once to manage the content of several products: several sites at once or a site plus an application. This also makes it possible to automate the distribution of content through all the necessary channels at the same time. The key task of such a CMS is to store and deliver content, and how it will look to the user already depends on the actions of the developer.
Pros:
- optimization of development resources;
- unlimited possibilities for structuring and delivering content to the user;
- centralized content management across multiple channels;
- flexibility — content adapts to each channel.
Cons:
- complexity — you need a sufficient level of professionalism of the developer;
- justified only on large projects where a set of different user interaction interfaces is initially assumed.
There are two types of such CMS:
- Headless CMS with open source — this is more difficult to configure, but the possibilities for configuration and maintenance are wider;
- Headless CMS of the SaaS type (Software as a Service, software as a service) is an easier to configure and safer option, but less interesting in terms of configurations.
Ghost, Strapi and Netlify CMS are among the top popular Headless open source CMS. Tinder, DuoLingo, Mozilla and DuckDuck blogs are made using Ghost. IBM, Walmart, NASA and Societe Generale have chosen Strapi for themselves.
5. Development with JAMstack
The increasing popularity of JAMstack is a logical consequence of the already mentioned trends in serverless architecture, the use of static website generators and Headless CMS. The term JAMstack was introduced by Netlify founders Matt Bijlmann and Chris Bach back in 2015 — the solution, as you can see, is not very new. But it is becoming more and more popular only now.
JAMstack is an abbreviation of three concepts: JavaScript, API and Markup. Actually, it consists of these elements:
Three Whales JAMstack (source)
Western developers sing odes to this approach and believe that the future is behind it. Because with it, you can create web and mobile applications faster, you will have to worry less about the server and hosting (everything was set up for you), and scaling such solutions will be easier and cheaper for the developer.
The essence of the approach is the following:
- the frontend is separated from the backend and databases and deployed via CDN (Content Delivery Network, content Delivery Network) — due to this, sites and applications work faster;
- all the necessary screens are pre—rendered during the build process in the form of optimized static pages with HTML, CSS and JavaScript (in contrast, there are dynamic ones that respond to every user action) – each new page is created only when the code or content changes, and not for every user request;
- Javascript and API are used to link the frontend to the backend, this also allows you to improve and personalize the pages for the user.
How is JAMstack better than the classic approach to development (source)
Have you heard this somewhere before? Looks like server rendering, huh? Yes, but no. When using the JAMstack approach, the code is sent somewhere on GitHub, and all possible elements are turned into pre-rendered static markup, files from which are stored in CDN. When a user makes a request, the browser does not access the server, but the CDN. And with the help of JavaScript and API requests, the dynamic content and personalization necessary for the project is “thrown” onto the static page. And it turns out that all operations to display the final page at the user’s request are no longer carried out on the server, but on the client (in the browser), and even right during the build (build) — you no longer need to generate anything either on the server or on the client.
If it’s even easier to explain how JAMstack works, then the content is created through a Headless CMS, the code is created through a framework, and a static website generator is used to link the first with the second.
It turns out that most of the logic of the web application is delegated to the client side, and all the complex functionality, which usually requires time, resources and knowledge to create it, is implemented through third-party APIs (yes, this is the mentioned microservice architecture!). And if so, you can not worry too much about the logic of the server side. The bonus is a reduction in the response delay from the server and a reduction in the load on it, which is equal to greater performance of SaaS applications and sites (Nike and Mozilla, it seems, are already using this approach).
The JAMstack trend promises to open up great prospects for the development of websites and applications, because this solution combines the best tools and technologies, such as React, Webpack, React-router and GraphQL. This solution attracts developers: you can use the technologies that you like more.
It all sounds fabulously cool. But critics of the approach say that “the JAM stack took the worst from static sites, limiting the possibilities, and from ordinary dynamic pages, taking the complexity of development from there.” I don’t like the connection with GraphQL queries, nor working with the Gatsby framework (there are a lot of dependencies inside it, which over time can lead to problems with the inevitable JS updates).
Whether JAMstack is suitable for online stores is a question. To quickly create a website for a startup — potentially yes. But JAMstack seems to us more like marketing tricks than some kind of revolutionary tool.
JAMstack uses concepts that have been known and used for many years, but calls them new names and mixes everything into a pile.
6. SPA — single-page applications
Classic sites (they are also called MPA — Multi Page Application, multi-page applications) refresh the page every time data changes or new information is loaded, and when switching to another section, they load a new one.
SPA (Single Page Application, single-page application) works differently: upon request, all the necessary code is loaded in the browser at once, but only the fragment the user needs is shown. When he wants to go to another page, the browser takes this data from the already downloaded code and smartly shows them without any page refresh. If necessary, the browser will additionally ask you to upload dynamic content from the server to the page.
SPAS have been used for a long time: for example, Gmail, the social network Facebook, the service for hosting IT projects and their joint development GitHub and the Meduza news site are arranged. But it seems that they began to seriously take a closer look at the SPA only now, in order to make the pages of blogs and catalogs easier, faster and more convenient for the end user (especially on mobile phones).
Pros:
- speed — yes, you will have to wait a bit at the initial loading stage, but then you can quickly switch between the content of the site and stick to it for hours (therefore, this approach is often used by news portals and blogs, real estate search sites and mail services);
- simplified development for different platforms — all data is uploaded in JSON or XML format, which are suitable for both desktop and mobile;
- user-friendly: since the page is actually one, you can play with animations and transitions, and everything will look great, like in a real mobile application (even if it’s a website);
- conditional independence from the Internet — if it was possible to load the page with a connection, then you can work offline.
Cons:
- difficulties with SEO: search robots are looking for individual pages, and here all the content is presented on one — they do not like this, so they will have to conjure with server rendering;
- complexity in development (as for any other technology, for the use of which you have to retrain and use new concepts);
- increased load on the browser (you have to download a large amount of data at once).
PWA and SPA — what’s the difference?
PWA (Progressive Web Apps) is a technology that allows a website to interact with the user as an application (work offline, send push notifications, use GPS navigation and perform other native functions). Google Docs is just a PWA.
The SPA site loads on one page and does not update it anymore, only switches the user between blocks.
Approaches can be combined — for example, to create a SPA and supplement it with advanced functionality using PWA capabilities.
7. WebAssembly
There are usually two types of programming languages used on the Internet:
- server-side (like PHP), which work on the server side and send the already processed information to the user;
- client applications that work on the user’s browser side (JavaScript).
But in 2015, WebAssembly appeared — a low-level virtual machine that compiles (converts) to binary format (byte code, just like in the “Matrix”) code written in a variety of programming languages.
Wasm code (code passed through WebAssembly) takes up much less space than JavaScript – and therefore loads much faster. It can also be broken down into parts/modules that will be loaded as needed. But — an amazing thing — JavaScript can be absolutely divided into modules in the same way.
But to execute JavaScript code, it first has to be parsed and compiled into machine code that is understandable to the browser — it takes time. With Wasm, the browser has no such need. Studies say that Wasm is 30% faster than JavaScript in terms of compilation speed.
Initially, WebAssembly was created to compile code written in C and C++ into browser-friendly code, but today its capabilities are much wider: the list of languages that support it is constantly growing. Kotlin, Go and Rust are already among them.
Why is WebAssembly a trend? Because it can give a head start when developing web applications: with it, developers can potentially write code in any programming language at all – and that will easily be converted into byte code, which is quickly launched in the browser immediately during the download process. Users will definitely like this.
But the scope of WebAssembly is much wider than web applications: there are game environments, virtual machines, databases, PWA, and work with neural networks. The only thing worth remembering is that it is unlikely to be possible to write a website in Wasm without JavaScript at all. Well, there are questions about the security of this solution. So we don’t know if it’s worth bothering at all.
8. Flutter 2.0 and new features
In March 2021, Google released an updated Flutter 2.0, with which you can create beautiful, fast and portable applications for any platform. Even web applications for the web (and not just for mobile phones, as before) using Flutter for Web. This means only one thing — now a single code can kill three birds with one stone: development for iOS, Android and web browsers. But there is also Flutter for Desktop (while it is being rolled out) — it won’t be long before unified development for all platforms at once.
What else can you write web applications on in 2022 to be “on the wave”? Welcome to: React, Angular and Vue.js . Moreover, the latter has the potential to become more popular than the other two.
You’ve probably heard about the trends below somewhere before, but this does not prevent them from continuing to develop further.
Progressive Web Apps (PWA)
PWA is still on trend — especially for e-commerce, because they allow websites to work and look like real mobile applications. This means that you do not need to spend money on creating separate applications for mobile phones (it is convenient and saves resources), but at the same time you can be sure that users will enjoy such an experience. Also, PWA are distinguished by cross-platform, which is also a huge plus (optimizing the cost of creating one is worth it).
AMP pages
AMP (Accelerated Mobile Pages) is an open source technology for accelerated mobile pages. Google announced it in 2015, and now it is actively promoting this topic and continues to encourage owners of sites using AMP with higher positions in search results. It sounds almost like an ultimatum, but what difference does it make to users – the main thing is that the pages load at lightning speed.
Chatbots
Chatbots in tandem with AI can take on all the unpleasant and routine tasks that managers used to get: answer the same questions, send the user to the right page or initially consult. And not only that:
- to pick up products depending on the search queries and interests of the user (based on the data collected about him);
- personalize the site to the user’s preferences (up to the color scheme and the shape of the buttons);
- analyze the user’s mood based on his questions and answers (Big Brother is watching you!).
Voice search
With the development of speech recognition technology, voice search will soon be in every online store, it seems. Just because it’s more convenient and faster. And if you link it with visual search, the accuracy of the results for the user will grow even more — we learned.
Horizontal scrolling
Since users are increasingly watching websites from mobile phones, we have to change the rules of the game — after all, it is quite difficult to organically fit everything that is on the desktop on the mobile version of the site. Salvation is a relatively new user scenario: horizontal scrolling. It allows you to display content compactly and at the same time consistently and is liked by users, since it makes it easier to view websites on mobile device screens.