Looking at the 2022 front-end development trend from 2021

This article participated in the SegmentFault "2021 Summary" essay , and you are welcome to join as well.

Preface

At the end of the year, I look back at the entire front-end process in 2021. Generally speaking, the front-end has reached a relatively stable stage of development. Although there are still many libraries and wheels emerging, the most prominent front-end development this year can actually be summarized as a whole. It is the following keywords, namely: engineering infrastructure, low-code, multi-language, cloud + edge + terminal. From the perspective of the division of the entire front-end by different manufacturers, the whole can be divided into two categories. One is focused, such as distinguishing various directions, and each direction is the ultimate; the other is overall planning, which integrates the entire upstream and downstream The link is opened up to extend the front-end boundary. I personally believe that it is difficult to determine which of these two divisions is better. From the macro to the micro, and then from the micro to the macro, it’s just a different way of thinking. Here I will look at the vertical and horizontal directions from a few different perspectives. Talk about my overall front-end development this year and some trends and opportunities that may appear in 2022, in order to provide you with some different perspectives of observation and thinking.

Vertical

If the current front-end is divided into vertical levels, I think it can be roughly divided into the three levels of "base layer, platform layer, and business layer". The following will conduct some thinking and exploration from the different dimensions of these three levels.

Base layer

Undoubtedly, the biggest highlight of this year is undoubtedly the wide exposure of multiple languages into the front-end vision. Below I will state some of my personal views and opinions separately:

Node.js

The application of Node.js in edge areas such as the Internet of Vehicles, Node.js, as the most familiar language for the front-end, is more convenient for upper-level implementation based on the C++ libraries of existing traditional hardware manufacturers in the Internet of Vehicles and other IoT fields;
Node.js is closer to the front-end side and is not handled as a BFF alone. Instead, the transformation of FFB is more in line with the initial role of Node.js. As a pure back-end use, whether it is the limitation of the language itself or the runtime performance of Node.js, both It is difficult to have more room for competition with traditional back-end languages. Node.js is more suitable as a basic layer on the front-end side.

Rust

The core competitiveness of rust lies in memory security. I think it has a big market for wasm on the edge. I think it’s hard to reflect its core value when doing infrastructure on the front-end side, and maybe it’s really possible to work with wasm on the edge. Shake the position of Docker;
Rust as a front-end infrastructure may have a certain market, but it is not enough to serve as the actual stock of its core competition. It is not clear whether it is better or worse than go as a front-end infrastructure tool, but on the edge I think its market is huge. , Can be used as a field of in-depth research as a student who intends to develop on the marginal side.

Deno

Cooperating with the cloud may have a certain breakthrough point, and its network module design is relatively excellent, which may snatch a part of node.js space;
I am not optimistic about the overall development. I personally think that there is no reason or impulse for a core to replace node.js, but it is still an excellent solution, which has certain reference significance for the processing of network modules.

Wasm

The core is to cooperate with Rust to build edge-side infrastructure, open up the edge-side market, and be optimistic in the long-term;
As the "glue" of various other languages, with js, etc. in the browser and other runtimes, such as: Node.js, etc. (ps: still need to consider Deno's feelings), there is also a certain degree of development imagination, but personally more Optimistic about its development on the marginal side.

Go

The core lies in goroutine. I personally think that as a front-end infrastructure side, it is difficult to distinguish from rust, but go is relatively easier to learn;
Cloud-side go is the best choice, and it must be go. Its ecology is very perfect. Students who want to dig deeper in the cloud field suggest that they must learn go.

C++

The old acquaintance of the front-end, as the initial development language of v8 and chromium, cpp has always been the basic big brother of the major high-level languages. It has stable development and privately thinks that rust is difficult to shake its status, but the coexistence of the two is actually not impossible;
Traditional veteran hardware manufacturers expose cpp to the front-end side, such as: v8 or other engines, which can greatly expand the development market. After all, js is still easier than cpp.

In summary, it is summarized as follows: On the end side, Nodejs is the main one, Deno is properly considered, and cpp is optimized; on the edge side, rust+wasm has a bright future; on the cloud side, go is the best choice. Multilingual development as an extension of front-end development should indeed be the keynote of future development, especially in the field of engineering, and its market still has very broad prospects.

Platform layer

At the platform layer, relying on some basic bearers of the basic layer, the front-end generally presents the following platform-based perspectives, namely: serverless, construction, scenarios, and frameworks. Below, I will elaborate on some personal understandings:

Serverless

Serverless currently does not have a clear definition, but in terms of practical cases, the whole can be defined as "Baas + Faas", computing and storage are separated at the Baas layer, and the "cloud + terminal" Web Function is provided at the Faas layer;
Sandboxed lightweight vm based on Rust+Wasm, microvm is applied to serverless sandbox isolation;
Multi-form coordination, service-based orchestration instead of resource-based expansion, full stack observable, service manageable, and traffic manageable.

Construct

There are multiple build tools, webpack is still the mainstream of application packaging, rollup is mostly used for libraries, and gulp is more suitable for node-side construction;
Multi-language invades the front-end construction field, such as: esbuild, vite, swc, etc. On the construction side, language-level rolling is irreversible and will become the mainstream construction solution at the platform layer. After all, packaging tools do not need to be handwritten from scratch for every business development, so a high-performance packaging solution must have huge front-end development In the market, what is left is that the language talents and the writers cooperate with each other to create infinite possibilities.

Scenes

Choose different rendering schemes for different business scenarios, SSG, ISR, CSR, SSR, ESR, SPR, etc.;
The choice of all scenes is essentially the choice of render. There is no silver bullet in software engineering. It is the best way to choose a rendering scheme suitable for the business scene.

frame

Meta Framework, the framework of the framework, different ends have different frameworks, the front end has a front end framework, and the server end has a server end framework;
Framework evolution: pure front-end + pure back-end, namely: front-end Vue, React, Angular, etc., back-end Express, Koa, etc.; business front-end + business back-end, namely: business front-end Umi, Ice, etc., business back-end Midway, Egg, Nest, etc.; front-end back-end or back-end front-end, such as: Next, Nuxt, Remix, etc.

In summary, the summary is as follows: Serverless releases large front-end capabilities, multi-language construction, multi-scene selection, and framework-based framework. From this point of view, it basically changes from service-oriented development to capability-oriented development, and the end engineer is transformed into an application engineer.

Business Layer

At the business level, last year, I roughly explained the basic front-end technology deepening direction. This year, I will focus on some highlights and feelings in the intersection of several directions:

Visualization + Engineering

Position 1 shown in the picture above

Low code, especially logical arrangement, etc. In LCDP, the visual presentation of data logical arrangement or decision arrangement;
State visualization, logical visualization, etc., the visualization in all engineering fields, and all links from the machine-oriented to the human-oriented can visually display the engineering.

Visualization + Intelligence

Position 2 as shown in the picture above

Layout display of massive data, combined with ai reasoning to build a visual view;
Link diagnosis path and graph pattern matching;
The D2C field is deepened, and the model is optimized based on the developer's thinking habits.

Engineering + middle and back office

Position 3 shown in the picture above

Engineering link closed loop, development => testing => construction => deployment => monitoring;
Focus on each stage, output quantifiable products that can be engineered, and provide engineering template solutions such as middle and backstage. For example, the development stage includes: scaffolding, public libraries, package managers, editors, build tools, debugging kits, etc.; testing stages include: Unit testing framework, static scanning tools, automated testing tools, performance testing tools, etc.; construction phase includes: packaging scripts, building services, etc.; deployment phase includes: release platform, iteration management platform, etc.; monitoring phase includes: embedded point platform, monitoring platform Wait.

Mid-to-backend + cross-end

Position 4 shown in the picture above

Multi-end framework presentation, mostly presented in a Flutter-like structure, including a unified small program underlying engine, etc.;
The application of multiple operating systems, such as the adaptation of Hongmeng operating system.

In summary, it is summarized as follows: engineering is the mainstay, visualization provides humanized display, intelligentization provides modeling capabilities, and the middle and back office + cross-end provides development solutions for different users. Each subdivision is deep and intertwined with each other, bursting out a variety of possible developments, long-term integration must be combined, long-term integration must be divided.

Horizontal

From a horizontal perspective, I would like to talk about the expansion of some business or product forms that may be involved as a front-end engineer from the perspective of technology from the two dimensions of user-oriented and development-oriented. It is more business-oriented; the more it leans toward the DX side, the more it leans toward the development side, and the more it leans toward technology.

Below I will use the front-end technology as an anchor to expand to the product side, and talk about my views and thoughts on some areas:

Product

Upper left corner of matrix

Documentation

Collaborative editing, B-side or simple document editing will be available;
Mass data processing, such as financial table calculations, etc.

Design Tools

Design drawing to code;
Design tool plug-ins, such as sketch, photoshop plug-ins, etc.;
Collaborative modification, cutting diagrams, etc.

Component library

General-purpose component library, theme, Design Token, etc.;
Business component library, business domain boundaries are determined;
Design language + interactive language, material market.

Star

Upper right corner of the matrix

Low code

General capability engine: UI visualization development, logic visualization development, code language, production operation, quality assurance;
Facing the audience, favoring development, favoring users;

Tech

The bottom right corner of the matrix

IDE

Integrated cloud construction, cloud ide and end ide;
Release, build function establishment, ide peripheral and system construction.

devops

ci link, including requirement association, trigger mechanism, notification, script, storyboard, etc.;
cd link, including scheduling, monitoring, product library, release mechanism, etc.

Tool chain

When the framework is running, write framework plug-ins, etc.;
Scaffolding construction, including selection of construction tools, etc.;
Compile debugging tools, including custom debugging toolkits, etc.;

Material

Bottom left corner of matrix

Monitoring system

Log monitoring, including log analysis, filtering, etc.;
Tracking the link, including link analysis, etc.;
Measurement monitoring, including quality analysis, health status, etc.

Summarize

Don't stop at the browser, don't stop at js, where there is a web runtime belongs to the front-end field

Looking back to 2021 and looking forward to 2022, the summary is as follows:

three eras have never been reached, the meta universe still needs to wait and see;

cloud edge terminal has come in the future, and the terminal engineering application will be completed;

The front-end expansion is boundless, and it is

browser cannot be restrained, and multi-language is the prevailing trend.

Well, 2022 is here. I wish you all to be strong in this cold winter, "The road is long and long, and the line is coming; if you continue to work, the future can be expected", and encourage!