This week, I will continue my reflections on the front end of change, this time focusing on the front end of change: change and breakthrough

This is the third article in a series of front-end changes. The first two are:

  1. Change of the front end (I) : change and invariance of technology
  2. Front End change (2) : The same front end

Again, before getting into the specifics of what happened to the front end, we need to understand what was the nature of the change

The front end is stuck: stuck in browser support

Going back to my last article about the constant front end, I clearly pointed out in the article that there is a dividing line for the change of the front end. Before this dividing line, the front end has the biggest dilemma, which is:

The front-end technology has always been confined to the browser, unable to break through

Whether it’s HTML, CSS, or JS, their power is always confined to the browser container, and of course the same is true of JQuery, Boostarp and other technical frameworks that were popular a few years ago. If you analyze them carefully, you will find that their power is always within the browser.

We can look at the core technologies of the front end one by one to get a glimpse of this capability limitation.

HTML

HTML is mainly a technique for presenting content. The simplest HTML is as follows:

<! DOCTYPEhtml>
<html>
<head>
<title>HTML sample</title>
</head>
<body>
  <h1>Hello,Html</h1>
</body>
</html>
Copy the code

If we compare HTM to non-front-end technology frameworks, such as back-end FreeMarker scripting technology

< HTML > <head> <title>freemarker example </title> </head> <body> <h1>Welcome ${user}! </h1> <p>Our latest product: <a href="${latestProduct.url}">${latestProduct.name}</a>!
</body>
</html>
Copy the code

Obviously, if we put aside the power of JS, HTML alone, its limitations and limitations are very obvious

  • Without dynamic rendering capability, simple variables, if, and for loops cannot do it at all.
  • It is difficult to break a complex page into smaller pages. A page is an HTML, and you can’t even do something as simple as importing HTML from one HTML into another (without relying on JS)

The fundamental reason is that the browser only provides the ability to render a page based on THE HTML content to show the user. The browser does not provide any dynamic capabilities to HTML, such as basic if,else,for capabilities. HTML could not have developed any similar capabilities in isolation from the browser.

This is why, in previous years, pages were dominated by back-end technologies. HTML alone was too weak to handle complex pages, even with the dynamic capabilities of JS. Big and small, divide and conquer was impossible for the front end at that time.

JavaScript

Of course, browsers solve this problem with another solution, JavaScript, because HTML itself is only capable of presenting content, which is really limited. The solution is to provide a scripting language, and that’s where JavaScript comes from.

JavaScript was originally conceived to be very simple, providing support for browser client behavior to avoid expensive server-side rendering, such as verifying data completeness and accuracy before submitting it. Based on this simplicity, JavaScript is designed to be a simple scripting language without the block-level scope, modules, subtypes, and other features of modern languages.

As a result of this initial design, JavaScript has never behaved like a modern language, and its various design and language features are, to put it nicely, “different.”

We can compare Java to Swift, as well as OC and Kotlin, because they are very similar and belong to the same camp. But compared to JavaScript, there’s no need because you can’t compare.

In fact, JavaScript lacked even one basic capability for a long time:

Introducing one JS into another

Finally, in the era of ES6, JavaScript was designed to introduce modules and support import.

But as I said in my last post, it’s really ES5, not ES6.

The reason: browsers don’t support it

CSS

Again, CSS is styles. The power of CSS is basically the same as that of HTML, simple style definitions

body {
  background-color: lightblue;
}

h1 {
  color: white;
  text-align: center;
}
Copy the code

As with HTML, in the world of CSS

  • There are no dynamic capabilities, and basic syntax like if,for, etc. is not supported
  • There is no way to divide and conquer complex patterns. , of course, you can be a CSS split into many smaller CSS, but first they cannot reference each other, only a unified HTML references, more people are far from each other between any inheritance, interface or abstract concepts, such as the definition of a base color, refer to the basic color in other CSS, this should not do in the CSS, Because CSS has no concept of variables

As a result, it is clear that in the era of the “pre-front-end”, the capabilities of the front-end’s various technologies have always been limited by browser support. Stuck in a browser. Browsers don’t even have the ability to read local operating system files for security reasons.

Due to the limited capabilities provided by browsers, it has been difficult for the front end to develop language designs and frameworks that can be compared to other modern languages, such as

  • Object-oriented capabilities features, inheritance, encapsulation, polymorphism in the front-end technology do not know how to achieve
  • Much like applying design principles to the front end, such as singletons, factories, observers, etc
  • Not the core solution for dealing with complex software: “Divide and conquer.”

Of course, all of this has become a thing of the past, thanks to a fundamental breakthrough, which is

Suddenly one day, the front end finds itself in a technology that is no longer limited by the browser

Break through and say goodbye to the browser

Finally, after crossing a clear dividing line, there was a breakthrough in the development of front-end technology:

At the end product stage, the browser is still a constraint, but at the coding stage, technology development and capabilities are no longer relevant to the browser

No longer constrained by the browser, front-end technology began to advance by leaps and bounds, including but not limited to:

  • Because JavaScript is bad, alternatives like TypeScript, which closely resembles the modern Java language, have emerged to replace JavaScript
  • In the HTML direction, React,Vue, and other component frameworks emerged
  • In response to the need for complex styles, styles with programmability have evolved, such as LESS, SASS, etc

Let’s go through the top three core technologies one by one

HTML

React and Vue and similar frameworks completely replaced HTML at the coding stage. A simple React page might look something like this:

const numbers = [1, 2, 3, 4, 5];
const listItems = numbers.map((number) =>
  <li>{number}</li>
); 
ReactDOM.render(
  <ul>{listItems}</ul>,
  document.getElementById('root')
);
Copy the code

Even the simple code above shows that React and other technologies can do the job compared to HTML

  • Support basic programming capabilities, if,for and so on can be used
  • Support componentization capability to split a large page into different components and pages.

In PCX, for example, there are many types of chat, such as text, images, and voice. In React, you can divide and conquer complex pages by making them large and small

As shown above: for each message class, a separate subclass is used.

This is fully capable of modern language. In the old DAYS of HTML+JS, there was no way to do that.

JavaScript

In the “post-” front-end phase, JavaScript is not being replaced by TypeScript, but TypeScript is becoming more popular and more popular. But JavaScript still exists in abundance and is still irreplaceable.

TypeScript is still ultimately translated into JavaScript, and it doesn’t replace JavaScript, but TypeScript is still a milestone for the front end, in a way:

TypeScript enables the front-end to have an object-oriented language for the first time

export class SessionRepository extends ISessionRepository {


    protected getRepository():IRepository{
        return BaseRepository.getInstance().getRepository();
    }
  
     /** * Delete a session *@param sessionId 
     */
    public async deleteSession(sessionId:string) :Promise<boolean> {const deleteSQL = "delete from session_ where identifier = $sessionId";
        return this.getRepository().executeUpdate(deleteSQL,{
            $sessionId:sessionId }); }}Copy the code

The TS code above comes from a snippet of code I worked on in PCX for 20 years.

We can completely see that TypeScript is more like Java than JavaScript. If you have a back-end Java person and a front-end JavaScript person learning at the same time, Java people will learn faster because TypeScript is an object-oriented language similar to Java.

Of course, there are five basic principles of object orientation:

  • Single responsibility principle
  • Richter’s substitution principle
  • The open closed principle
  • Rely on the inversion principle
  • Interface Isolation Principle

And more than two dozen familiar design patterns, such as factory, Observer, and command, can be used in TypeScript without barriers.

But in JavaScript, at least I don’t know how to do that.

CSS

In the “post-” front-end era, there are naturally better ALTERNATIVES to CSS as they break through the limitations of browsers.

Such as less

In fact, less is basically the same as CSS in general, it does not provide any new CSS styles, its difference is only in the simple static CSS style on the basis of adding some dynamic capabilities, such as variables, functions and so on

@width: 10px;
@height: @width + 10px;

#header {
  width: @width;
  height: @height;
}

.class {
  // Calculate by function
  width: percentage(@width); // returns `50%`
  color: saturate(@base.5%);
  background-color: spin(lighten(@base.25%), 8);
}
Copy the code

More and more

Even with the breakthrough of the browser, the natural overall technology development will not be limited to HTML,JS and CSS, because without the limitation of the browser, in the coding stage, there are more breakthrough technologies in the front end, the most typical representative is: NPM dependency management

In fact, one of the easiest ways to tell whether you are in the “front” or “back” front-end phase is:

Do you use NPM dependency management

Because:

In the “front” phase, this is impossible. NPM dependency management requires extensive reading and analysis of local files

{
  "name": "taoofcode"."version": "1.0.0"."private": true."description": "Microvoice code"."author": "lingen.liu"."keywords": [
    "gatsby"]."license": "0BSD"."dependencies": {
    "@fika/gatsby-source-cockpit": "^ 1.1.2." "."@material-ui/core": "^ 4.11.2"."@material-ui/icons": "^ 4.11.2"."@material-ui/lab": 57 "" ^ 4.0.0 - alpha.."@mdx-js/mdx": "^ 1.6.22"."@mdx-js/react": "^ 1.6.22"."@types/react-helmet": "^ 6.1.0"."gatsby": "^ 2.26.1"."gatsby-image": "^ 2.8.0"."gatsby-plugin-css-modules-typings": "^" 1.0.1."gatsby-plugin-google-analytics": "^ 2.9.0"."gatsby-plugin-less": "^ 4.4.0"."gatsby-plugin-manifest": "^ 2.9.1." "."gatsby-plugin-material-ui": "^ 2.1.10"."gatsby-plugin-mdx": "^ 1.7.1." "."gatsby-plugin-react-helmet": "^ 3.7.0"."gatsby-plugin-sharp": "^ 2.11.2"."gatsby-plugin-sitemap": "^ 2.9.0"."gatsby-remark-prismjs": "^ 3.10.0"."gatsby-source-filesystem": "^ 2.8.1"."gatsby-transformer-remark": "Tokens ^ 2.13.1"."gatsby-transformer-sharp": "^ 2.9.0"."prismjs": "^ 1.22.0"."react": "^ 16.13.1"."react-dom": "^ 16.13.1"."react-helmet": "^ 6.1.0"}}Copy the code

Now you declare and manage your dependencies through NPM.

What does that make you think? It has its own dependency management in other directions

  • The back end uses Maven or Gradle for dependency management
  • The most popular iOS app is Cocoapods
  • Android is Gradle to manage dependencies

See, the front end is finally on par with the rest of the technology.

Conversion technology

As I said in the previous article, the front end hasn’t really changed; it’s still mostly HTML,JS, and CSS.

In the “post-” front-end phase, the code has changed dramatically, but the end product is still these three, unchanged.

So how does it do it?

That is dependency – transformation technology

Anything is possible by breaking the limits of the browser, and of course the ability to translate can be added. Therefore, there are some front-end translation conversion technology, their role is to the front of a variety of fancy new technology toys into HTML,CSS,JS three things.

That is, in fact, no matter how many new technologies and concepts are on the front end, it still depends on transformation technology, and it still needs to be converted to HTML,JS, and CSS.

That is:

  • React,Vue this code only exists in the coding phase, and ultimately it’s HTML+JS
  • TypeScript only exists in the coding phase; ultimately it is JavaScript
  • Less,Sass also exists only in the coding phase, and ultimately CSS

Isn’t that interesting?

Mainstream conversion technologies include:

  1. Babel – This is the syntax for converting some new features from ES6 and above to ES5
  2. Webpack – much more complex than Babel, which does one thing, Webpack does a bunch of things. It uses TS-Loader to convert typescript, less-Loader to convert less, and Balbel to convert es6 syntax and beyond. It has a lot of plug-ins.

Of course webpack also has some of the same level of technology, but in terms of popularity, or WebPack.

Therefore, it is almost impossible for front-end development to get rid of Webpack. Some integrated frameworks or technologies, such as Gatsby, do not see the existence of Webpack in the code, but it does not mean that it does not exist, but is hidden behind by Gatsby. It builds its own set of rules on top of Webpack so that developers don’t have to worry about Webpack configuration.

In addition, create-React-app works the same way.

Front end, the return of the king

We have to ask the question, right?

How did it all happen?

From the “front” front-end phase to the “back” front-end phase, who made this happen?

Next, the Change of the front end (4) : The Return of the King

Visit the official website taoofcode.cc – Spreading the taoof coding with our little power