I’ve been writing a lot of technical articles lately, and I want to write something simple today. When a newcomer asks: How do I start learning the front end? Many Zhihu people will send a brain map like this:

The new guy looks at it and clicks “Close” in the upper right corner.

Personally, I hate to look for learning resources, and experienced people often give “big and comprehensive” answers that are extremely unfriendly to newcomers. I know the person who posts the pictures may really want the best for the newcomers, but such pictures don’t do much except increase anxiety.

But there are so many “nouns” invented at the front end that you can’t understand them without being confused. This article will give you a dish of the front-end development “noun” origin.

The world wide web

Let’s rewind to 1989. Tim Berners-Lee, a Brit

They found that the data in their lab, CERN(European Organization for Nuclear Research), was becoming increasingly difficult to manage. It was easy to “lose” the file name, for example, or the person maintaining the file left. Then the documents might be “lost” in the data forever.

This CERN lab is for physics, not computers! But at that time, laboratories in various places were cooperating with this laboratory, so it was inevitable that they would share information with each other. As the data gets bigger and bigger, it becomes harder to manage. Another point is that CERN’s full name is not English, but French: Conseil Europeen pour la Recherche nucleaire

To this end, Lee proposed the concept of “Linked Information Systems”, called World Wide Web, also known as the “World Wide Web”.

Two years later, in 1990, Lee sent a second proposal. Finally came up with the idea of needing two people to build the World Wide Web in six months. The result was the first website: info.cern.ch/.

As you can see above, a simple client-server architecture has emerged. Put the file on the server and access it on the client.

Building a page skeleton

For academic papers, are generally professional format, if only pure text display, for who can not stand it.

So Lee created HTML(Hyper Text Markup Language) inspired by SGML(Standard Generalized Markup Language). Commonly used labels are h1~ H6, DIV, header, body, main, footer, table, ul, li, button, etc.

<header>head</header>
<main>The body</main>
<footer>foot</footer>
Copy the code

If you simply try to write.html, you’ll find that

has the same effect as

. However, in order to make the code more semantic, that is, to make it easier for others to read, it is common to use

in the header and

in the case of an article as the code block. If you have to carry: I like to use div line, that don’t need to carry, of course!

Beautify the page

Although the label can do some simple style, but still not meet the style requirements of the designer.

To address the Styling problem of web pages, Lee’s colleague Hakon Wium Lie drafted and presented a CSS(Cascading Styling Sheet) in 1994. A simple piece of CSS can make a page rich:

body {
  color: red;
}
Copy the code

Most of you probably know CSS and take it for granted, but have you ever thought that XML can also be used to represent styles, as it does on Android? At the time, DSSSL and FOSI were also candidates for browser styles, but they were too cumbersome to write styles, so CSS was chosen as the browser style writing standard.

CSS is pretty easy to use now, but in the old days the road to CSS standardization was bumpy:

  • When CSS1.0 was released, few browsers supported it. By the time CSS1.0 is supported, CSS2.0 has already been released
  • CSS2.0 adds more style choices. CSS2.0 was introduced in 1997, but underwent a major rollback, overhaul, and renomination when it was upgraded to 3.0. It wasn’t until 2011 that CSS2.1 was released as a standard
  • With CSS3.0, it does not upgrade the entire version like 1.0 and 2.0, but modularizes the style upgrades. Right now, we are still using “CSS3.0”, but some modules are already 4.0

CSS UI library

After writing CSS many times, front-end engineers found that some nice CSS styles can be shared. For example, I wrote a button style:

.btn{... }Copy the code

Then, someone else can just copy the CSS into their project and use the CSS class name in their HTML, and use it directly.

<button class="btn">My button</button>
Copy the code

During this time, CSS styles for UI widgets are flying around, like a button one day and an input field the next. There have also been a lot of similar “XX beautiful UI components” and “XXXX year the most beautiful Y UI components” article.

It wasn’t long before developers found another problem: conflicts between component styles, such as the style of a button affecting the style of a custom button. The other big problem is that the styling of a single component looks good, but if a web page uses 4 or 5 CSS styles written by other people, it will look very inconsistent and not uniform. Compatibility is also poor.

Mark Otto and Jacob Thornton at Twitter also thought about this, so they developed the Bootstrap UI library:

<div class="input-group mb-3">
  <span class="input-group-text" id="basic-addon1">@</span>
  <input type="text" class="form-control" placeholder="Username" aria-label="Username" aria-describedby="basic-addon1">
</div>
Copy the code

The common buttons, fonts, input box some styles are written, but also provide sample code. After the release of the UI library, almost all developers have used it, after all, CSS can finally be written themselves.

I also used Bootstrap to write class assignments, which was really cool. I never wrote a single line of CSS.

Responsive layout

In 2011, apple released the classic iPhone4S, which marked the beginning of smartphones becoming an indispensable part of people’s lives, and the demand for mobile access also increased considerably.

In those days, when looking at web pages on mobile phones, users had to enter the page first, enlarge it manually, click the corresponding link and then go to the next page. The operation was very complicated and the interface was very ugly.

On the other hand, as mobile phones enter people’s life, apps on mobile phones are springing up like mushrooms after a spring rain. At this point, the programmer thought: just make the webpage look like an App.

So how do you tell if you’re using a phone or a computer? It’s simple: you can tell by the width of the screen, and CSS’s Media Query can be used to solve this problem:

/* @media only screen and (max-width: 600px) {body {background-color: red; }} @media only screen and (min-width: 600px) {body {background-color: white; }}Copy the code

The question arises again: should every compatible style be written twice? Is it possible to write only one style that can be compatible with mobile and PC? Programmers started using percentages, EM, REM, optimized layouts, and so on to make the screen smaller and still look good.

This idea of CSS writing is called responsive layout, and it works with mobile and the web.

But responsiveness is not a panacea. For example, some of the flashy styles in taobao pages today are not compatible with the mobile end, so now the practice is to do two sets of web pages, the computer end to do a set, the mobile end to do a set. The difference is that the style of the mobile terminal is similar to that of the App, without too many functions and complicated styles. Moreover, it provides a button to open from THE XX App to divert traffic to its own App. The computer side is cooler and more powerful. After all, no one’s shopping on the mobile web anymore, right?

If you look closely at the address of a web page on a mobile phone, it will always start with m.xxxx, which means the page is only viewed on a mobile phone.

JavaScript animates the content

Note: HTML and CSS are not programming languages. HTML is a markup language and CSS is a style sheet.

Now we have HTML and CSS to make the page look good, but the content of the page is fixed. To make a page “move”, the browser must introduce a programming language. That’s JavaScript.

Back then, someone wanted to use Java as a programming language for browsers, but Sun, the Java company, said, “Not for you.” So Netscape, NetSpace, developed its own programming language. The new language was supposed to be called LiveScript, but the name was too generic to be an instant hit. Java was in its heyday at the time, so, for the sake of headlines and popularity, it changed its name to JavaScript when it was released in December and introduced some Java features that, surprisingly, turned out to be a nightmare for front-end engineers.

JavaScript does some simple business logic, such as determining whether it is male or female:

if (you === 'male') {
  console.log('MSM')}Copy the code

You can manipulate HTML, but isn’t HTML a piece of text? How do you do that? In fact, when the browser gets the.html file, it automatically parses the HTML text, converts it to Document Object Modal (DOM), and converts ordinary text into a tree structure.

JS can modify the layout and structure of HTML simply by manipulating the DOM.

document.getDocumentById('hello').textContent = 'I'm a handsome man' // Change the content to "I am handsome"
Copy the code

JavaScript is an extremely poorly designed language. GetMonth (), for example, returns 0 if it’s January, and getHours() returns the exact current hour. There are few operations on arrays, such as unique and findBy.

In order to clean up the mess for JavaScript design, several tool libraries have been created:

  • JQuery: Provides many apis for manipulating the DOM
  • Moment, dayjs: Provides a number of apis for manipulating Date objects
  • Lodash: More like a tool library

Server side rendering

Although JS can change content dynamically, in the past, sending asynchronous requests was very troublesome.

Java programmers came up with an idea: JSP. Anyway, if you want to access the server, it would be better if I read the data directly from the database and generate an HTML for you. This technology is called JSP.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@ page import="java.io.*,java.util.*" %> <! DOCTYPE HTML < HTML > <head> <meta charset=" utF-8 "> <title> </head> <body> <h2> <table width="100%" border="1" align="center"> <tr bgcolor="#949494"> <th>Header Name</th><th>Header Value(s)</th> </tr>  <% Enumeration headerNames = request.getHeaderNames(); while(headerNames.hasMoreElements()) { String paramName = (String)headerNames.nextElement(); out.print("<tr><td>" + paramName + "</td>\n"); String paramValue = request.getHeader(paramName); out.println("<td> " + paramValue + "</td></tr>\n"); } %> </table> </body> </html>Copy the code

PHP, long touted by programmers as “the best programming language in the world,” follows this line of thinking. This method of dynamically generating HTML from the Server Side is called SSR(Server Side Rendering).

But there are two problems with this:

  1. If there is an error in Java, the page will display the entire error Stack to the user, the experience is very unfriendly, and the whole crash

  1. Highly coupled code is very unmaintainable, for example, and the above code is obvious at first glance
  2. An engineer not only has to deal with the server logic, but also has to consider how to write the style, page logic, and responsibilities are not clear

Although JSP and PHP were popular for a while, programmers chose to have the front-end programmer in charge of page development and the back-end programmer in charge of server development in order to have a clearer division of labor. This development pattern is also known as front – end separation.

An important bridge on the front and back end is asynchronous requests, often referred to today as Ajax requests, but long ago asynchronous requests were a particularly difficult thing to implement. At that point, the page had to be refreshed again, and the user experience was very poor.

JSONP

Here’s the problem: it’s hard for a browser to make an asynchronous request to the server to fetch content without refreshing the page.

Smart programmers start to wonder: What can make asynchronous requests? Then they found that creating an img tag with SRC would send an asynchronous request to the server for xxx.jpg:

<img src="xxx.jpg">
Copy the code

So if you want to send an asynchronous Get request, you can do this:

  1. Sneakily create an invisible IMG tag
  2. Place the URL to be accessed in SRC
function getData(url) {
  var imgEl = document.createElement('img') // Create the img tag

  imgEl.visibility = 'none' // Make the img tag invisible

  imgEl.src = url

  document.appendChild(img) // Add to web page, automatically send Get request
}
Copy the code

But this raises the following question:

  1. Don’t know when to clean up the newly generated IMG
  2. Don’t know how to get data after the request is sent
  3. Write it every timeImgEl. Visibility = 'none' // Make the IMG tag invisibleThis sentence

To this end, programmers again think of many ways.

First, step 3 can be omitted by using the script tag instead of the IMG tag.

Second, define a function globally to get users information:

function getUsers(users) {
  console.log(users)
}
Copy the code

When writing the url added a parameter: https://www.baidu.com/users?callback=getUsers. The server reads getUsers from the argument and returns the javascript script to the browser:

getUsers(['Jack'. 'Mary'])
Copy the code

Since the tag just added is a script tag, getUsers([‘Jack’. ‘Mary’]) will be executed as soon as the server returns, and users will be printed out. This technique is called JSONP, which stands for JSON with Padding.

Another benefit of JSONP is that cross-domain requests can be implemented because script tags can request resources that are not of the same origin policy and retrieve the returned data. But this is very insecure, the server is easy to be attacked by some malicious JS code.

Ajax

From the above, JSONP can be used but is very non-standard, and programmers really want a complete asynchronous request mechanism.

In 2004, When Google developed Gmail and Map, the mechanism for asynchronous requests was perfected and some standards were set.

In 2006, the W3C wrote the first draft of XMLHttpRequest and continued to refine it until the final draft was released in 2016, making it an official standard. What we often call Ajax requests actually use this object to make requests. Here is the code for sending a request with this object:

// Generate the request object
xmlhttp = new XMLHttpRequest();
// Listen for the status and return of the request
xmlhttp.onreadystatechange = function () {
  if (xmlhttp.readyState === 4) {
    if (xmlhttp.status === 200) { // 200 = OK
      console.log('success');
    } else {
      console.log('failure'); }}};// Open the channel
xmlhttp.open('GET', url, true)
// Send the request
xmlhttp.send(null);
Copy the code

Ajax, Asynchronous JavaScript and XML, is not a single technology but a collection of technologies for creating Asynchronous applications on the client side. It’s just that one of the core steps is to make an asynchronous request, and XMLHttpRequest helps us do just that.

Node.js

In 2009, another major hurricane hit the world. Ryan Dahl wrote the first original version of Node.js, which allowed JavaScript to run not only in a browser, but also anywhere that had the Node.js platform, such as on a terminal on your computer.

JavaScript is finally no longer a client-side language and can be used for server-side development. In order to facilitate the development of the server side, TJ Holowaychuk, a foreign super tycoon, borrowed the Rack of Ruby community to develop express.js, a simple JS server framework.

Because express.js is so simple, many developers continue to build various middleware for the framework that users can use to augment their servers, such as Body-Parser, cookie-Parser, passport, and so on.

Later, TJ felt that express. js was not concise enough, and wanted to reconstruct it, but the cost of reconstruction was too high, so we simply rebuilt another wheel, which is also known as KOa.js.

In order to enable JS to better complete the work of server-side development, front-end developers to back-end development of some tools have been built again:

  • Connect to database: mysql, mysql2, mongodb
  • Cache: session, redis
  • ORM: TypeORM, sequelize
  • Scheduled tasks: Node-schedule, cron
  • .

Serverless

When many people started using Node.js, they noticed some problems:

  1. Once you’ve written the code, it runs fine locally, but how do you deploy it to the server?
  2. How to buy a server? Where can I obtain the HTTPS certificate? What is Nginx? Oh, it’s so annoying. I justnpm run start 啊

As a front-end programmer, usually move brick enough tired, but I configure the server, a sword to kill me.

Smart programmers find that whether you write express.js or koa.js, you write response functions.

app.get('/users'.(req, res) = > {
  res.send('I'm a handsome man')})Copy the code

That I server, certificate, domain name these things all give you good, you are responsible for writing corresponding function and give money is not very cool yao? That’s where Serverless comes in. The advantage is that you don’t need to worry about server configuration, expansion and other trivial things, just need to write the response function is good. This “response function” is also called a cloud function, which Amazon calls a Lambda.

At this time, someone found that some of the services I had written, such as sending and receiving emails and accessing databases, could also be provided as a service. Front-end engineers only need to pay and then request THE API interface PROVIDED by me to enjoy my service. This is another source of revenue for many cloud vendors: selling services.

For example, common: language translation services, mobile phone SMS sending services, yellow authenticator, graphic recognition and so on.

modular

As more tools become available, Web applications are getting bigger. A large project can have hundreds or thousands of JavaScript files that depend on each other, and the scary thing is that there is currently no tool that can tell you which file is executed first.

File management becomes a big problem, so applications need to be divided into modules.

Prior to ES6, there were several module loading schemes developed by the community, the most important being CommonJS and AMD. The former is used for servers and the latter for browsers.

const xxx = require('xxx')
Copy the code

ES6 in the language standard level, the realization of module function, and the implementation is quite simple, can completely replace CommonJS and AMD specifications, become a common browser and server module solution. The ES6 module is designed to be as static as possible, so that the module dependencies, as well as the input and output variables, can be determined at compile time.

import xxx from 'xxx'

export default xxx
Copy the code

The idea of modularization has greatly improved the happiness of JS programmers, all JS files are no longer the same level, but can be divided into blocks of management. It plays an indispensable role in front-end engineering.

Package management tool

Some engineers have found that their abstracted modules, such as Axios, which makes asynchronous requests, or LoDash, a library of tools, can be used by others in the community. This requires a central repository to hold these libraries, as well as a package management tool to manage package distribution, installation, upgrade, and so on.

NPM is currently the most used package management tool, and when Node.js is installed on your computer, NPM is installed with it. However, NPM is slow to download in China. Yarn is recommended for faster download speed.

engineering

Module splitting makes writing code fun, but isn’t it too scary to import all these JS files into an HTML file? There are 1000 script tags in an HTML, which is a bit anti-human to have more than content. The same applies to CSS files.

To solve this problem, front-end engineers came up with the concept of bundles — no matter how cluttered or scattered your modules are, they will eventually be converted directly into a.js file through a tool. Such a tool is called a packaging tool.

In 2016, Grunt, a JavaScript Task Runner, was created that allows developers to write their own tasks and then streamline them. This is already an engineering prototype.

But Grunt’s packaging is too slow. The engineers couldn’t take it anymore, so they built another Packaging tool for Glup that did the same thing, but was a word faster!

At the same time, another beast is quietly evolvingWebpack.

Webpack directly grabbed the Glup market with its powerful functions and high flexibility of configuration, and many people have adopted Webpack.

As Webpack’s capabilities continue to grow, so do the demands of developers, and the market is flooded with loaders and plug-ins:

  • Thermal loading
  • Code confusion
  • Code compression
  • Thin code, TreeShaking
  • loader: file-loader, css-loader, vue-loader
  • .

Another problem with Webpack is that different environments require different Webpack configuration, leading to more and more complicated configuration of Webpack. Front-end engineers are also responsible for maintaining webpack.config.js configuration project in addition to writing code.

With The advent of Parcel, like the iPhone, you can pop out of a small web page without much configuration. However, in the face of large projects, there is no way to solve the problem of cumbersome configuration. So, Webpack is still the dominant player in the market.

Another problem with using Webpack is that local development packaging is slow, and Webpack typically packages builds before starting the development server. Evan You came up with another solution: start the development server first and request the files for the module when the code executes until the module loads. Speed up packing and compiling for local development and build Vite. Vite is still a new baby, so keep an eye on it to see what fun things come out of it.

CSS preprocessor

One of the criticisms of CSS is that it’s not simple enough and you can’t reuse a lot of things. Such as:

.container { 
  background: red; /* The background is red */
}

.container .title { 
  color: red; /* The title font is red */
}
Copy the code

Why not write it like this:

.container {
  backtround: red; /* The background is red */
  .title {
    color: red; /* The title font is red */}}Copy the code

Unfortunately, browsers only know CSS, not this. The programmer starts to think: I don’t need a browser to know the second script, I just need to convert the second script to CSS when I package it. With the bonus to packing tools, I think it’s possible! Therefore, the second advanced writing method is called CSS preprocessor, which means that the writing method is processed into CSS and then used as normal CSS.

So, in 2007, Sass was born. It borrowed the Syntax of Sass from the Ruby community, but the front-end programmers were very proud of it. They called it Scss because Scss can’t read.

Then, in 2009, Less was created, with syntax Scss, not much different.

In 2010, another preprocessor, the Stylus, was born.

Currently, Scss and Less are widely used, while Stylus has a relatively low reputation. Novice don’t worry, the syntax of these three things is almost the same, will be equivalent to three metropolis.

To advance the JavaScript

JavaScript is a poorly designed programming language, but JS is not a fish. It strives to be the best programming language in the world!

JavaScript can’t stay the same, can it? But it can’t change all of a sudden, can it? Therefore, there needs to be a drafting plan, review the plan, agree with the plan, into the standard process, which requires a lot of manpower and experts, that is better to do a “JS enthusiasts association”? The European Computer Manufacturers Association (ECMA) is a similar organization, but its structure is much larger than that of “JS Enthusiasts Association”. Its main task is to standardize Computer systems.

ECMA International regulates JavaScript in ECMA-262. It can be considered that ECMAScript is standard JavaScript, and all browsers must support standard JavaScript. The 262 standard specification was first published in 1997.

As can be seen from the above, the next few years will be the NTH generation of ES standard JavaScript is ECMAScript 201(N-1), for example, the most familiar ES6 is actually ECMAScript 2015. ES6 is a big change for JavaScript, and ES7 and ES8 add very little, so now ES6 is actually a generic term for ES6+.

But have you ever wondered: even though I’m developing with the latest syntax, users might still be using older browsers?

Thanks again to the advent of automated packaging tools, we can use the latest syntax for development and just switch the new syntax to the old syntax when packaging production code. This syntax may sound like a lot of trouble, but clever front-end engineers have already done it for you: Babel.

Babel has evolved to support JSX syntax conversions in addition to old and new syntax conversions.

TypeScript

While ES6’s new syntax and apis have greatly improved the happiness of front-end programmers, JavaScript is still a weakly typed language:

Type is not standard, two lines of tears colleagues. When a type is used incorrectly:

Can you force JavaScript to be typed? Microsoft said: Yes! Microsoft has taken the lead in developing the TypeScript programming language, which is a superset of JavaScript with a lot more polish, and the TypeScript compiler. The latter is responsible for compiling TypeScript into JavaScript.

Note: TypeScript -> JavaScript cannot be implemented with Babel because this step is compilation, not substitution of old and new syntax. TypeScript is not a new syntax; it is a serious programming language that can be compiled into JavaScript.

With TypeScript, developers finally enjoy the benefits of strong typing constraints:

const x: string = '123'
Copy the code

Once again, thanks to Webpack, an automated packaging tool, TypeScript can be compiled into JavaScript when output production code and, if Babel is added, ECMAScript of a generation.

A single page application

While packaging tools continue to compete, single-page application frameworks are also evolving.

In the past, most people have been using jQuery to directly manipulate the DOM to update pages.

Every time you manipulate the DOM, you have to write some noodle code. But this is very troublesome, can not manipulate the DOM step encapsulation, data update automatically manipulate DOM to update the page?

In 2010, Angular.js, developed by Google, was the first to implement the idea of MVVM, in which developers could render a moral-view of the page directly without manipulating the DOM, and changes to the page, such as changes in input values, could in turn change the content of the data. Later, Angular2 was developed, but both Angular.js and Angular itself were too complex and borrowed a lot of backend design, making it too difficult for front-end engineers to get started, and it didn’t become a big trend.

Notice that angular. js and Angular are two different things!

In 2013, a new front-end framework was born — Facebook’s React. Js. React is a very clean JS framework that doesn’t have the hassle of Angular and allows developers to simply focus on one-way data flow. Eventually react.js caught on in the front-end community.

However, React. Js also has its own problems. Because React. As a result, the React community is constantly fighting, with gangs and various chains of contempt.

For example, you can import style files directly when writing styles:

import 'xxx.css'

const xxx = <button className="xxx">xxx</button>
Copy the code

You can also use CSS Modules

import styles from 'xxx.css'

const xxx = <button className={styles.xxx}>xxx</button>
Copy the code

Styled -component can also be used

const Button = styled.a`
  color: white;
`

const xxx = <Button>xxx</Button>
Copy the code

Styled components, for the style network, are styled and styled components. Styled components, for the style network, are styled and styled components, for the style network.

Another trouble spot is that one-way data flows are not everyone’s favorite, and people are starting to miss Angular’s two-way data binding.

Then in 2014, the man came, and he came with vue.js!

Evan You has previously worked at Google and Meteor. Vue. Js takes the middle ground between Angular and React, landing in the front-end community in an elegant, lightweight way. It retains Angular’s bidirectional data binding, but does away with much of Angular’s complex design and apis. It’s not as clean as React. Vue-loader is also developed based on Webpack to parse.vue template files. This.vue template file is very similar to.html, making it easy for newcomers to get started.

At the same time, thanks to Vue’s concise and good-looking Chinese official documents, Vue. Js has quickly captured the market of small companies in China.

But because vue.js is so easy to learn, it’s often felt by some in the React. Js community that people who write vue.js are newbies. The Vue. Js people think the React. Js people are wasting their lives with “best practices”, and JSX syntax is ugly, not as simple as my template syntax. To this day, the Vue and React communities occasionally erupt in small fights.

Another problem arises: the original UI library only provided simple CSS and native JS, which were a bit redundant in a single page application, and some reported errors because most of them were DOM manipulations. Therefore, the UI library must be upgraded with the corresponding SPA framework. While other UI libraries were being upgraded, Ele. me developed Element UI for vue. js, while Ant Financial developed Antd for React. Later, more UI libraries emerged, such as iView, Ant Design for Vue, Ant Design for Angular, etc.

In summary, Angular, react. js, and Vue. Js all develop their own single-page Application framework, which ends with SPA(Single Page Application). That is, all the logic is wrapped up in JavaScript files. Externally, you only see an.html, a.css, and a.js file.

Wait a minute? An.html file? So how to jump to different pages? That’s where front-end routing comes in.

The front-end routing

Think about how routing used to be done: the user page is user.html, the home page is index.html, and a URL corresponds to a file, which means that every time we type a URL, we’re actually accessing some.html.

The browser has a function to monitor browser address changes, single-page application developers think: I just listen to address URL changes, and then render the corresponding page components with JS, can not realize the front-end control routing? This is the basic idea of front-end routing.

Each of the three single-page application frameworks has its own front-end routing framework: @angular/ Router, React-Router, and Vue-Router.

Data management

Another problem with single-page application frameworks is data management. Data accessed by child components can only be passed from parent to parent. If a deep child component wants data from the outermost component, it has to pass data all the way from beginning to end.

To deal with the difficulty of sharing data, programmers thought, “Why don’t I just store all my data in a common place?” Help yourself when you need it.

What are the public places? Save global variables? No, it will be overwritten by others, and the view cannot be changed after the data is changed. So, engineers have developed some global data management libraries: Mobx, vuex, Redux.

Isomorphism rendering

With the addition of a single page framework, programmers found that the single page ended up generating HTML like this:

<body>
  <div id="root"></div>
  <script src="bundle.js"></script>
</body>
Copy the code

To know that Search engines will use web crawlers every day to crawl thousands of web pages, analyze the CONTENT of HTML, in order to improve the accuracy of the Search, this practice is called SEO(Search engine optimization). But if you look at the structure above, search engines have no idea what your page is for. Another problem is that if the user’s network environment is poor, the web will always be white as long as JS is not loaded, which will affect the user experience. How do you solve this?

We began to miss when JSP, PHP server rendering HTML, because the server rendering HTML can immediately return to the HTML structure, the page will first show some content, not white screen, and with the approximate HTML structure, search engines easier to do SEO. Server-side Rendering is also called SSR(Server Side Rendering).

The front-end engineer realized that some static content, such as product category or navigation bar content, could be added at the time the HTML was generated, without needing to fetch it through the API. Such technologies are called Static Site Generation (SSG). What about dynamic content, like moments? The data initially displayed can be rendered by the server before the user interacts with the page, such as clicking a button before sending a request to obtain the data. This is isomorphic rendering.

Unlike traditional server rendering, the server side of isomorphic rendering is also written in JavaScript, so both the front and back ends use JavaScript.

Isomorphic rendering is simply a piece of code. The server first generates HTML and initialization data through server-side rendering. After the client gets the code and initialization data, Client side activation of THE DOM is revealed through patch and event binding of the HTML DOM.

This whole process is called isomorphic rendering. It can not only absorb the advantages of the server side, such as accelerating the first screen rendering, but also retain the characteristics of SPA application, such as front-end control of route jump, so that there is no need to render new HTML when jumping.

Single-SPA

As more and more projects are using the SPA framework, it will be very troublesome for companies to combine multiple projects into one project. Different projects may use different frameworks, such as vue. js for user details and React.

Single-spa and The Chinese company Ali are trying to solve this problem. It essentially creates a larger “one-page app,” and within that “one-page app” there will be multiple one-page apps.

This technique of combining multiple SpAs into one large Project is called the microfront end.

Automated testing

As the front end becomes more and more engineered, automated testing is a must. Once you’ve built some wheels, you need to plug in automated testing, or you need to do manual testing on every modification.

The simplest is unit testing. Currently, libraries commonly used for single testing include * Ava, Jest, Moch, Sinon, Chai, etc. The front end is a very environment dependent job, often using different environments, such as JSX environment, browser environment, Vue environment. There are many libraries that provide Mock environments, such as the enzyme used to provide the React environment.

Also, to simulate certain scenarios, the front end mocks things like localStorage, indexedDB, cookies, etc. There are different libraries and tools to implement these, such as mock-axios, mock-redux, mock-cookie, and so on.

The above just belongs to the white box test practice, the front end can directly simulate the manual do dot dot operation? Yes, this is called end-to-end testing, or E2E testing, or integration testing. The popular tools right now are Cypress and Nightwatch.

However, automated testing is not a good thing for projects where the business changes frequently, which leads to fickle test cases. Writing too much test code can sometimes be counterproductive.

Mobile phone H5

With the development of smart phones faster and faster, some applications such as wechat have to embed some front-end H5 pages, such as wechat public number articles, in fact, is a small web page.

In another application scenario, engineers found it possible to embed H5 in apps for simple presentation and interaction, which would require less development on mobile. This type of embedded H5 page application development is also known as hybrid development, and the resulting App is the Hybird App.

At present, alipay, wechat and QQ on our mobile phones have adopted the mode of mixed development, which can not only use the native code to ensure fluency, but also embed H5 to improve the development speed (note that speed is not equal to efficiency).

Low code

After writing many H5 on mobile phones, front-end engineers found that many H5 are the same, many are a set of templates, and then change the color is OK.

So, smart programmers thought, can you just drag and drop and generate a web page? In fact, drag and drop to generate web pages is not new, and it is not difficult to implement, back in the era of wordpress has been the emergence of drag and drop to generate personal blog tools. Only now it’s on your phone.

But the problem with drag and drop is that it’s inflexible and sometimes very rigid. Some operations people know a little bit about code. So the drag and drop tool has evolved again to give people a portal to do simple custom things. This type of template + simple code development is called “low code” development and can automatically generate pages with simple configuration.

Requirement generation code

Are there more advanced tools for generating code besides drag and drop? There are! For example, using words to describe scenarios to generate front-end Code, which Is what Ali is doing, they are working on P2C (PRD to Code). Personally I think this is a good thing, for simple requirements can be generated directly faster than anything else.

Some people worry: Will this replace the front end engineer? The answer is impossible and unscientific. No amount of artificial intelligence is capable of delivering complex, flexible, whimsical, wildly iterative products. They eventually replace low-level engineers who can only write simple HTML and CSS.

The last

Imperceptibly wrote a lot of things, visible front-end things really a lot of very miscellaneous. In fact, I could have written more details, but the article is too long, and that’s the end.

This article in addition to take you to understand the common front end “noun”, but also hope that you do not learn the front end when I want to master XXX. You see how bumpy the development of the front end, are through solving a problem to have today’s front end, learning is the same, first to achieve a Low version, and then slowly upgrade themselves.