preface
The only constant in the world is change.
The only constant in the world is change. “– Spencer Johnson, Who Moved My Cheese
The IT industry is changing so fast, especially Frontend Development. If you could go back 10 years and meet a Web development software engineer, they would tell you that mastering the front end meant mastering jQuery and getting Internet Explorer compatibility right. However, as the front end continues to evolve, jQuery has suffered from “official fandom” (element selection and manipulation are unified by the standard DOM API). And the Internet Explorer browser compatibility problem is criticized, because the Internet Explorer market is gradually shrinking and some compatibility tools (Polyfill) appear, let it from the previous core optimization problem to the itching problem now, no longer become the standard configuration of front-end engineers.
Today’s front-end development, with all its jargon and technical complexity, can make a new engineer nervous: there’s just so much to learn. If front-end engineers don’t know Webpack, Babel, Node.js, NPM/Yarn, ES6/7, React/Vue, Sass/Less, TypeScript, ESLint, Canvas/SVG and other modern front-end knowledge, It’s hard to convince people of their professional background. The front end of the 2021 engineers may be real engineers (Engineer), they often need to use a lot of professional knowledge to solve engineering problems, including how to manage the modularized program, how to design the interaction between components, how to improve the reusability, how to improve packaging efficiency, optimize the browser rendering performance, and so on. They don’t just need HTML/CSS/JS to develop static pages like they used to.
This article will focus on the topic of modern front-end development, to introduce in detail each important technology of front-end engineering, to help readers understand how the complexity and diversity of modern front-end pages are constructed. This article is about front-end engineering, even if you don’t know much about front-end technology, you can benefit from this article.
Packaged deployment
If there’s one big difference between modern front-end development and 10 years ago, I’d say Bundling & Deployment. Developers who lived in the “Stone Age” of the front-end (when jQuery was mainstream) would have a hard time imagining that front-end projects need to be compiled today. In the past, most of the Web UI was provided to the user through MVC, and the front-end page was mostly rendered by the back-end template to generate static resources (HTML/CSS/JS) without any processing to the browser. That is, the static resources on the front end were part of the back-end Presentation Layer, where complex interactions were usually done. As a result, front-end static resources are usually very simple and do not require complex compilation packages, at best Minify into smaller files.
Now, however, the situation is very different. Users want more interactivity and don’t want to spend too much time waiting for a page to respond. The traditional MVC pattern is limited by network traffic, and it usually takes a few hundred milliseconds or more to complete a page navigation, which is very disruptive to the user experience. As a result, the front-end projects are increasingly separated and run as a single application in the browser, with interaction occurring on the browser side and very fast. However, complex interactions are concentrated in the front end, making front-end projects more complex, bloated, and difficult to manage. Therefore, the source code for large projects needs to be compressed into small static files that use as little network resources as possible to transfer to the browser. A slightly larger front-end project now has more than 500MB of dependency files. You’re not stupid enough to dump so many files on users, are you?
Therefore, you need a very powerful packaging and compilation tool. Webpack is now a relatively mainstream packaging tool, which can cooperate with compilation tools (such as Babel) to package various types of project source code files (such as.vue,.ts,.tsx,.sass) into native.js,.css,.html and other static files, which can be directly provided to the browser to run. The diagram below is the flow diagram of Webpack’s official website. Webpack examines various dependencies of source code files and generates corresponding static resource files after analysis and compilation. This is the same with compiling Java and C# code.
The Webpack configuration is defined by a JavaScript file, usually named webpack.config.js. Here is a basic Webpack configuration.
const path = require('path');
module.exports = {
entry: {
main: './src/main.js' // Import file
}
output: {
path: path.resolve(__dirname, 'dist'), // The packaged output path
filename: 'bundle.js' // The packaged output file name
},
module: {
rules: [{test: /\.css$/, use: 'css-loader' }, //.css file conversion module
{ test: /\.ts$/, use: 'ts-loader' } //.ts file conversion module]}};Copy the code
This configuration code defines the packaged entries, outputs, and loading Rules for compilation, all of which can be done through a configuration file. The configuration file, webpack.config.js, is defined and loaded by default by executing the webpack command in the project root directory. The source code is then read and packaged as a compiled static file. You may have noticed that there is a configuration item in the array structure module.rules, which can define Loaders for various file types, or be considered a compiler. In this case, csS-loader is the loader that processes.css files, converting keywords such as @import, URL (), import, require into native CSS/JS compatible code. For csS-loader to take effect, you need to install the loader by running NPM install CSS-loader –save in the project root directory. In the same way, ts-loader that processes.ts files needs to be installed by NPM for ts-loader –save to take effect. In fact, in order for Webpack to handle various file types (e.g..vue,.tsx,.sass), it is often necessary to install the corresponding loader, which actually gives Webpack great extensibility. Unifying different types of files into native front-end code by installing loaders also allows us to manage complex and large front-end projects very efficiently.
Since this article is not intended as a reference guide, the detailed configuration of Webpack is not covered in this article. If you need to learn more about Webpack, you can go to the official Webpack documentation (webpack.js.org/concepts) to dig deeper… Webpack is one, along with other popular tools such as rollup. js, gulp.js, Parcel. Interested readers can delve deeper.
Webpack and other packaging tools are driven by Node.js, which means they run as a dependency on Node.js. In fact, any modern front-end project is inseparable from Node.js and its package management system, NPM. We’ll cover modularity of front-end projects, including NPM, in the next section.
modular
Modupenalty is an important concept in any technical engineering project. A complex stable operation of a large system is usually composed of a number of sub-modules, they communicate with each other, work together to complete some very complex logic or tasks. Complexity is often non-linear, meaning that the cost per unit of size increases exponentially as the system grows to a certain size. A project of this size would be almost unmaintainable if we didn’t do something to limit maintenance costs. In order to enable developers to manage large projects effectively, our approach is often to reduce complexity and understandability, and to minimize the rate at which system complexity increases. An effective way to reduce complexity is to divide and conquer, which in the case of software projects is modularity. Modularity allows subsystems that are responsible for the same or similar functions to operate independently (high cohesion) and appropriately open up some interfaces to other sub-modules (low coupling). In this way, the entire system is described by multiple sub-modules. These sub-modules have their own features and functions, enabling maintenance personnel to accurately locate the modules corresponding to each function, greatly reducing maintenance costs. “High cohesion, low coupling” is the core concept of modularity, and its ultimate purpose is to reduce system complexity and improve maintainability. Modularity is very, very important for increasingly complex front-end projects with hundreds of megabytes of code.
NPM
For front-end projects, NPM (Node Package Manager) is an indispensable front-end project construction tool. NPM is a package management tool for node.js, similar to PIP for Python, Maven for Java, Nuget for C#, and so on. For some modules or features that already exist, we Don’t need to write them from scratch because of the DRY principle (Don’t Repeat Yourself) advocated by software engineering, otherwise we would spend a lot of time reinventing the wheel. NPM is a dependency management tool for front end projects. It helps you install the packages and libraries needed to build your front end projects, and then compile the source code into native front end static files using Wepback and other packaging tools.
Json, similar to setup.py in Python or Pom.xml in Java, defines dependencies, runtime entry, environment requirements, and so on. Package. json can be generated manually or created as NPM init. Here is a sample package.json file.
{
"name": "crawlab-frontend"."version": "0.1.0 from"."private": true."scripts": {
"serve": "vue-cli-service serve"."build": "vue-cli-service build"."lint": "vue-cli-service lint"."test": "jest"
},
"dependencies": {
"@fortawesome/fontawesome-svg-core": "^ 1.2.32"."@fortawesome/free-brands-svg-icons": "^ 5.15.1"."@fortawesome/free-regular-svg-icons": "^ 5.15.1"."@fortawesome/free-solid-svg-icons": "^ 5.15.1"."@fortawesome/vue-fontawesome": "^ 3.0.0-2"."@popperjs/core": ^ "server"."@types/codemirror": "^ 0.0.103"."@types/md5": "^ 2.2.1." "."atom-material-icons": "^ 3.0.0"."codemirror": "^ 5.59.1"."core-js": "^ 3.6.5." "."element-plus": "^ - beta 1.0.1. 7"."font-awesome": "^ 4.7.0"."md5": "^ 2.3.0." "."node-sass": "^ 5.0.0"."normalize.css": "^ 8.0.1." "."vue": "^ 3.0.0"."vue-i18n": 11 "^ 9.0.0 - beta."."vue-router": "^ 4.0.0-0"."vuex": "^ 4.0.0-0"
},
"devDependencies": {
"@babel/preset-typescript": "^ 7.12.7"."@types/jest": "^ 26.0.19"."@typescript-eslint/eslint-plugin": "^ 2.33.0"."@typescript-eslint/parser": "^ 2.33.0"."@vue/cli-plugin-babel": "~ 4.5.0." "."@vue/cli-plugin-eslint": "~ 4.5.0." "."@vue/cli-plugin-router": "~ 4.5.0." "."@vue/cli-plugin-typescript": "~ 4.5.0." "."@vue/cli-plugin-vuex": "~ 4.5.0." "."@vue/cli-service": "~ 4.5.0." "."@vue/compiler-sfc": "^ 3.0.0"."@vue/eslint-config-typescript": "^ 5.0.2"."eslint": "^ 6.7.2." "."eslint-plugin-vue": "^ 7.0.0-0"."sass-loader": "^ 10.1.0"."scss-loader": "^ 0.0.1." "."typescript": "~ 3.9.3." "}}Copy the code
Of particular importance are the configuration items Dependencies and devDependencies, which define the packages on which the project depends. They are in the form of key-value, where Key is the name of the dependent package and Value is the version number or version number matching expression of the corresponding dependent package. When the project is created, NPM install will automatically pull the dependencies from the package hosting site npmjs.com. All installed modules appear in the node_modules directory, which is named after each package. When we package and compile the source code, the project build tool automatically analyzes the source code dependencies and finds the corresponding modules from node_modules to compile and build.
Scripts configuration items are command line aliases for project development, debugging, build, test, and deployment to help you quickly start your project. It is also in the form of key-value, where Key is an alias and Value is a specific command to execute. For example, if NPM run build is executed, vue-cli-service build is executed. Vue-cli-service is the official command line tool for packaging and compiling front-end projects (vue-cli-service is a Webpack build tool for vue projects).
In addition to the points mentioned earlier, NPM has many other configuration capabilities. For more information, see the official documentation (docs.npmjs.com). If you want to learn more about front-end package management, I recommend Yarn, which is Facebook’s open source package management tool. It is very similar to NPM, but has some utility features, such as dependency caching.
The project structure
If the above mentioned NPM and package management systems are macro-level modularity between projects, the project structure described in this section is micro-level modularity within projects. In order to ensure the maintainability of front-end project code, front-end development engineers usually need to master clear and reasonable code organization, including how to classify and manage different types of files or components, and how to organize the hierarchy and structure of the project directory. The following is a typical Vue3 front-end project code structure.
.├ ── LICENSE ├─ readme.md ├── ├─ jest.config.ts ├─ package.json // ├─ │ ├─ favicon. Ico │ ├─ ├─ SRC │ ├─ assets │ ├─ ├─ public // ├─ favicon. │ ├─ ├─ i18N │ ├─ interfaces // Type definition │ ├── layouts // │ ├─ main.ts │ ├─ Heavy Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal Metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal metal Test │ ├ ─ ─ utils / / public methods │ └ ─ ─ page views / / ├ ─ ─ tsconfig. Json / / TS configuration └ ─ ─ yarn. The lock / / yarn depend on the lockCopy the code
As you can see, some of the base configuration files are in the root directory. The SRC directory is the main directory for the source code. In the SRC directory, there are subdirectories that are the core modules of the front-end project, including Views, Router, Components, Layouts, and Stores. Of course, not every project is organized the same way, and may be more or less different, but pages, components, and routing are often important modules that need to stand alone. Components are typically reusable and part of a page; Routing is the function of front navigation matching page. Pages are the actual content of various web pages. In fact, this code is organized like a traditional back-end project, in that highly cohesive modules responsible for different functions are separated into the same type of structure.
The advantage of this is that developers can categorize the problems to be solved so that they can pinpoint the relevant modules and quickly complete development tasks or solve difficult problems. Just like organizing clutter or filing papers around the house, organizing can make your living and working environment more organized if you do it regularly.
Of course, it’s not that traditional front-end projects don’t have the concept of modularity, but in the era of jQuery, there’s no standard on how to do it, or even if you need it at all. If you worked on front-end projects 10 years ago, you know all about the “shit mountain” of code that stinks. Nowadays, with the continuous development of the front-end technology, front-end industry has spawned a lot of helps front-end engineer in engineering tools and methodologies, in addition to this section of the modular, and describes the front end of the next frame, which is now known as the React, Vue, presents three framework and other niche framework.
The front frame
JQuery (Stone Age)
Many times, the birth and popularity of a new thing is by no means accidental. Like jQuery, which burst onto the scene in 2006, it solves the pain point of manipulating the DOM in a native way. JQuery was the standard in the front-end world with its clean API and high performance. The success of jQuery was built on the shortcomings of native JavaScript at the time: verbose and bloated syntax, complex and difficult to understand design patterns, and inconsistent browser standards. This caused great pain for Web developers at the time. As a lightweight tool library of JavaScript, jQuery makes up for the shortcomings of JS to a large extent, so it is welcomed by a large number of developers. With the development of the Internet industry, jQuery has become the front-end overlord for many years. Many other well-known third-party libraries, such as Bootstrap, are also built on top of jQuery.
As more and more developers embrace jQuery, many complain about its shortcomings. As user experience becomes more and more important, some developers begin to migrate some interaction logic from the back end to the front end, in pursuit of faster response speed and smoother user experience. In order to achieve this goal, many developers have started to make extensive use of jQuery to render front-end pages in real time through Ajax asynchronous requests, that is, to manipulate the DOM with JS code. This change has led to a number of complaints from jQuery users: they find it a pain to implement a UI with complex interaction logic in jQuery. First, jQuery relies heavily on CSS or XPath selectors for DOM elements, which makes modularity a big problem for projects: All elements are almost global to a front-end application, which means that attributes like class and ID become extremely sensitive to project stability, because you can accidentally change elements that shouldn’t be changed, contaminating the entire application. Secondly, jQuery implements front-end interaction by manipulating the DOM directly, which is fine for simple applications, but if the front-end interface has a lot of data or content that needs to be rendered, or requires frequent changes in the style of the interface, this will cause significant performance problems, resulting in browser lag and a severe impact on the user experience. Third, jQuery doesn’t have a uniform model for writing front-end projects, and programmers can do whatever they like, which is one of the reasons for the bugs in front-end applications. In general, the heavy use of jQuery for front-end interaction makes front-end projects very Fragile.
AngularJS (Iron Age)
In 2009, a Google engineer opened source his side project AngularJS, a new framework that revolutionized the front-end industry, which was then dominated by jQuery. The engineer implemented an internal project of 17,000 lines of AngularJS code that had taken three people six months to develop in two weeks with just 1,500 lines. This shows how powerful this framework is. The main feature of AngularJS is the two-way Binding between the HTML View and the Data Model, which means that the front-end interface automatically changes in response to the Data. This feature is both new and expected by front-end engineers who are used to writing jQuery, because this writing mode no longer requires active DOM updates, thus saving a lot of code and logic for active DOM manipulation, which AngularJS does automatically for you. The following is a schematic of AnguarJS bidirectional binding.
AngularJS (version 1.0, later renamed Angular) does some Componentization, but it’s not fully supported. Using Directive to componentize some common modules is too much. This led to the inspiration and opportunity for React (developed by Facebook) and Vue (developed by former Google engineer Yu Stream).
React, Vue & Angular
In 2013, Facebook publicly unveiled React as a new front-end framework in JS ConfUS. React is unique, creating the concept of the Virtual DOM, which cleverly solves front-end rendering performance problems. React also supports componentization very well. React’s one-way data-view Binding, on the other hand, addresses consistency issues and supports TypeScript very well, bringing stability and robustness to large front-end projects. But it also creates a large threshold. React beginners usually need to understand a number of basic concepts, such as JSX, to write React applications.
A year later, the upstart Vue was unveiled by former Google engineer Yu Yuxi. It takes a different approach, incorporating the best of React and AngularJS while also making some great innovations. Vue combines views (HTML), data models (JS), and styles (CSS) into a.vue file and uses AngularJS two-way binding, which lowers the barriers to front-end development. If you’ve written AngularJS, it’s pretty easy to get started with Vue. Vue also does a great job of componentizing support. The recently released Vue3 also adds TypeScript support, making it fully capable of supporting large front-end projects. Readers who want to learn more about Vue3 can check out the “Code Way” account (ID: CoDAO) for the history article “TS Enhanced Vue3: How to Easily Build Enterprise Front-end Applications”, which provides a very detailed description of Vue3’s new features and how to use it to build large projects.
Since version 2.0, AngularJS has changed its name to Angular, optimizing some of its shortcomings and embracing TypeScript in its entirety. Angular and AngularJS are almost syntactically two completely different frameworks. Angular’s mandate for TS development makes it ideal for building large front-end projects. However, it also requires beginners to learn TS and the very complex concepts in Angular, making the learning curve very steep.
Here is a summary of the current three front-end frameworks.
attribute | React | Vue | Angular |
---|---|---|---|
founder | Yuxi You (former Google engineer) | Misko Hevery (Google) | |
First Release Date | 2013 (8 years ago) | 2014 (7 years ago) | 2009 (12 years ago) |
Domestic usage | high | high | low |
Foreign usage | high | low | In the |
To fit the difficulty | high | low | Very high |
Applicable project size | Large and medium-sized | Big small and medium-sized | large |
Ecological richness | high | In the | low |
Data binding | A one-way | two-way | two-way |
TypeScript | support | support | mandatory |
The file size | 43KB | 23KB | 143KB |
Github Stars | 145k | 158k | 58k |
advantages | Fast, stable and ecological | Simple, flexible, easy to learn, detailed documentation | Strong reuse, mandatory TS, suitable for enterprise projects |
disadvantages | High learning cost and slow document update | Slightly less stability, not much community | Complex, very high learning curve, not detailed documentation |
future
React, Vue, and Angular have become front-end frameworks that front-end engineers must understand, master, and even master. However, with the rise of mobile and the emergence of new technologies, we can expect this three-pronged trend to change dramatically in the coming years. The emergence of WebAssembly brings challenges to the front-end traditional HTML/CSS/JS technology. Technologies such as Hybrid Development, mini-program, and PWA enable front-end engineers to dabble in mobile Development; Emerging front-end frameworks such as Svelte, Elm.js, ReasonML, etc., are likely to influence existing technologies as their popularity increases. In short, as stated at The beginning of this article, “The only constant in The world is change”.
componentization
For modern front-end engineering, componentization is a core concept. Componentization is actually the modularization of the front-end UI interface. For complex front-end applications, many components, such as buttons, navigation, input fields, etc., are reusable UI modules that can be used in a variety of pages. In addition, you can apply child components within a component and child components within a component, making the organization of the front end interface very flexible. If you design well, you’ll be able to take your time when your boss or product manager asks you to change your layout, change your style, or expand your functionality. Componentization is so important that every front-end engineer needs to understand the principles of design, no matter what front-end framework you use.
If the goal is to achieve a large and scalable front-end project, front-end engineers need to organize the code structure (layout, components, routing) in advance, and also consider designing some basic components to simplify the subsequent development and maintenance. The most basic Components are Layout Components. You may need to design the top (Header), Sidebar (Sidebar), Main Container (Footer), etc. Of course, some commonly used functional components also need to be considered, such as Input, Form, pop-up, and so on. Don’t reinvent the wheel. You can choose your own UI framework, such as React Ant Design or Vue ElementUI. Only special components need to be implemented by yourself.
In addition, front-end engineers need to be very familiar with how to design communication between components. General communication between parent and child components can be achieved through Property Propagation and Event Emission. For communication between layers, consider using Context or Event Bus for handling. Communication between sibling components is usually implemented using state management (Store) **.
Of course, componentized design patterns are not uniform, and front-end engineers generally accumulate experience from practice and reference to form their own knowledge system. For starters, take a look at a previously published open source framework, such as Ant Design or ElementUI, where the source code and implementation process are open to the public. Studying the source code can help you master Design concepts that have been tested by your project.
Type constraints
JavaScript plays a very important role in front-end development and is the core of interactive logic. However, JavaScript is a weakly typed dynamic language, which means that various basic types can be converted to each other, so the stability and robustness of programs written in JS is relatively worrying. This is a fatal drawback for building large front-end applications. Fortunately, Microsoft released TypeScript in 2012, which uses static code detection to bind JavaScript to strong typing. TypeScript is a superset of JavaScript, that is, TS contains all the syntax and features of JS, OOP concepts such as classes, interfaces, Decorators, and namespaces were added to this foundation.
For those unfamiliar with TypeScript, see our previous post “Why TypeScript is a Necessary Language for Developing Large Front-end Projects” on the Codeway public account (ID: CoDAO) for historical articles.
As defined on the TypeScript website, TypeScript is “Typed JavaScript at Any Scale”. TypeScript’s main feature is the type system, which extends JavaScript by adding types. If you understand the difference between Static Typing and Dynamic Typing, you should be aware of the advantages of Static Typing: predictability, robustness, and stability. TS code can be converted to native JS code by compilation, so there is no problem with TS code in browser compatibility.
The following two sections of code can clearly understand the difference between writing front-end applications with pure JS and TS respectively. First look at the sample code for pure JS (without TS).
// JS Example
// There is no type definition
// Data type constraints depend on documentation or memory
// Valid user instance
const validUser = {
name: 'Zhang San'.sex: 'male'.age: 40};// Invalid user instance, no error at compile time
const invalidUser: User = {
sex: 'unknown'.age: '10'};console.log(invalidUser.name); // undefined
console.log(invalidUser.name.substr(0.10)); // Uncaught TypeError: Cannot read property 'substr' of undefined
Copy the code
As you can see, the entire code does not report Syntax errors, so it runs smoothly in the JS engine. Log (invalidUser.name) will print undefined. This, however, has implications for the code that follows. Uncaught TypeError: console.log(invalidUser.name.substr(0, 10)) Uncaught TypeError: console.log(invalidUser.name.substr(0, 10)) Cannot read property ‘substr’ of undefined a very common error in JavaScript. For large projects, when developers encounter such errors, there is usually no way to start because you don’t know how the undefined error came from a background API, or from a previous code logic error, or a data problem.
Let’s look at the next piece of TS code.
// TS Example
/ / gender
type Sex = 'female' | 'male';
/ / user classes
interface User {
name: string;
sex: Sex;
age: number;
}
// Valid user instance
const validUser: User = {
name: 'Zhang San'.sex: 'male'.age: 40};// Invalid user instance. A compiler error
const invalidUser: User = {
sex: 'unknown'.age: '10'};console.log(invalidUser.name); // Compile error
console.log(invalidUser.name.substr(0.10)); // Compile error
Copy the code
Because types are defined with type and interface, the TS compiler can scan the code at precompile time to detect errors, such as missing fields or invalid fields, and so on. When you compile this code, you will find that errors are thrown ahead of time at compile time. So developers can warn of possible bugs before they run the code and take action.
TypeScript is almost a standard part of large front-end projects and an essential skill for almost every front-end engineer.
other
There is a lot of knowledge related to front-end engineering, but the previous article only introduced some core knowledge. Other front-end engineering knowledge includes, but is not limited to, the following:
- Code style constraints. Helps unify code styles, such as ESLint.
- Unit testing. Effective Bug avoidance tools include Jest, Mocha, etc.
- Multi-project management. Breaking up large projects into different subprojects or modules to help manage multi-module projects, represented by Lerna.
- Project deployment. CI/CD, Nginx, etc.
conclusion
This paper starts from the development of the front-end industry, introduces the historical background of the development of front-end technology, explains the importance and necessity of front-end engineering, and explains the packaging and deployment process and implementation tools of modern front-end engineering starting from packaging and deployment. Next, this paper introduces another important concept of front-end engineering, modularization, and explains the need for modularization as front-end applications become more complex, and how to achieve modularization. It also introduces the development of front-end frameworks, including jQuery and AngularJS, React, Vue and Angular, and the future development prospects of front-end frameworks. This article also covers componentization and type constraints, and explains why you should use TypeScript in large projects.
In a word, front-end industry is a high-speed development of the industry, especially in recent years, the rapid development of the Internet spawned the development of front-end engineering, so that front-end engineers become a veritable engineer position. Front-end engineers are called engineers not just because they can write front-end code, but because they can use architectural and engineering thinking to build and manage large and complex front-end applications, so that users can experience a variety of Web or mobile applications with complex back-end functions but simple front-end use. Front-end technology and front-end engineering continue to evolve, and as new technologies emerge and mature, we will learn more interesting and useful front-end knowledge. Did you learn today when you were in the pit?
community
If you are interested in the author’s article, you can add the author’s wechat tikazyQ1 and mark “code of Tao”, and the author will pull you into the “code of Tao” communication group.