This week I’ll continue with some thoughts on the front end.

Before we get into how the technology on the front end has changed, let’s talk about what the front end “doesn’t change.” Only by understanding what has not changed can we better understand what has changed.

This is the second in a series of front-end changes.

  1. Change of the front end (I) : change and invariance of technology

Unchanging core

The front end technology may change, but the three core technologies that support the front end are ALWAYS HTML,JavaScript and CSS, right

  • HTML is responsible for the content of the page
  • CSS is responsible for content styling
  • JavaScript is responsible for some dynamic capabilities. Such as dynamic loading data

No matter how advanced some of the current front-end technology concepts are, the whole front-end is still tied to these three cores.

However, each of these three cores has its own development and evolution:

  • Act&vue These are variations that replace HTML, but ultimately they’re still generating HTML.

  • Less,Sass, and so on are variations of CSS styles, but ultimately they still generate CSS.

  • TypeScript is a variation on JavaScript, but TypeScript only exists at the programming stage, and ultimately it still generates JavaScript.

So, we found something very interesting:

On the premise that the front end is unchanged, there is a tendency of disconnection between the code and the product. The technology in the coding phase is evolving faster and more advanced, but the end product is always evolving slowly.

Dividing line

I think there is a clear dividing line between what happens at the front end and what happens after that line is not comparable.

I call these two phases the “front” front and the “back” front

As shown above:

The similarities and differences between the two stages are as follows:

The same

  • The end product doesn’t change at all, it’s all HTML,JavaScript, CSS stuff
  • The division of responsibilities hasn’t changed: HTML for content, CSS for styling, and JavaScript for dynamic capabilities
  • Both depend on the browser and are limited to the browser

The difference between

  • In the “pre-” front-end phase, the code is essentially the same type of thing as the product, as JQuery is a type of JavaScript. In the “post-” front-end phase, the coding and production begin to disconnect.
  • The “pre-” front-end phase is not only browser-constrained in terms of production, but also browser-constrained in terms of coding. But in the “post-” front-end phase, while the artifacts are still browser-bound, the coding phase has moved away from the browser, with sophisticated tools and capabilities such as NPM package dependency management
  • The “post-” front-end, freed from the constraints of the browser, advances in coding power by leaps and bounds. CSS with programming capabilities like LESS and SASS would have been unthinkable in the “pre-” front-end stage.

So, from the above analysis, if we look at it from the product point of view, the front end hasn’t changed much.

The front end is stuck

Let’s go back a few years, and at that time, the front end was a headache, with a lot of problems:

JavaScript is a terrible language

Even though JavaScript is getting more powerful. What started as a browser script has evolved into something that can handle the front end, React Native on the mobile side, NodeJS on the back end, and seems to be getting stronger and stronger.

But if we really look at it for what it is, JavaScript is still a very bad language. Prototype-based design is not really advanced or good, weak typing causes problems to be difficult to find, and all sorts of annoying things. So-called ES6 or ES7, etc., have been stuck in the support of various browsers and have been slow to spread. Good language design can’t be applied. So in the book “javascript Language Essentials”, the author said that to learn javascript, just read his book is enough, the other need not read. Because those features are terrible.

We can’t blame JavaScript, of course. It was originally conceived as a script, and the people responsible for designing it didn’t expect it to come this far. And unlike other languages, JavaScript doesn’t even have a direct responsible party; it’s more of a specification that ultimately still needs to be implemented by browsers.

Front-end style compatibility

While the situation is much better now, thanks to the popularity and compliance of Chrome, people on the front end are still feeling the pain of different browsers supporting different CSS and JS when they talk about compatibility.

Even now, the front end faces a choice: Do you want to support IE?

Although Microsoft itself has given up, but when the real decision, who can easily say not support?

Difficulty with complex software

In the three paradigms of procedure, object and function, object orientation is easier to deal with complex software because it is easy to divide and conquer

The fundamental solution to complex software is to divide and conquer

Obviously, JavaScript, a prototype-based, script-oriented, process-oriented language, can’t handle complex software. This is why TypeScript quickly replaced JavaScript as the mainstream. TypeScript will eventually be translated into JavaScript, though.

Real change.

The good news, of course, is that we’ve moved past the “before” front-end and into the “after” front-end.

But if we really think about what’s happening in the front end over the years, it’s actually happening very slowly.

HTML changes

  • In 1997, THE HTML4 standard was released

  • In 2000, HTML4 strict edition was released

  • In 2014, the HTML5 standard was released

JavaScript changes

At the heart of JavaScript is ECMAScript

  • In 2009, ES5 standard

  • In 2015, the ES6 standard

  • In 2016, the ES7 standard

    .

Skip the rest, because if you were in the “front” phase, you wouldn’t be using ES6 standards right now. The mainstream is ES5.

In the “post-” front end, you can code with the latest ES standard, but the product will still be ES5.

Why is that?

Due to browser incompatibility, ES5 is still the prevailing choice for compatibility with most browsers

* * * * CSS change

  • In 2011, the CSS3 standard was finalized
  • In 2011, CSS4 was developed and then… No more (until now only a few features are supported by some web browsers)

The “front” front-end phase is the most valuable change

The most valuable change in the “front” front-end phase is JQuery.

For the first time, it treats the entire HTML as a DOM tree on the basis of JavaScript, providing quick JS ability to find, modify, and add DOM elements, combined with Ajax capabilities (JavaScript also has the ability to manipulate elements, but the functionality is too primitive, far less than JQuery).

To:

Let the front-end initial with their own dynamic rendering data ability

You can use Ajax to query data from the back end, and JQuery to dynamically manipulate elements to render the page.

This is why JQuery was the most popular JS framework in recent years.

Change and Breakthrough

If nothing transformative happens, we’re probably still in the “pre” front end, which is a very bad one.

In the “pre-” front-end phase, depending on this JAVASCRIPT +HTML scripting language, you want to deal with complex software or logic, which is very difficult and unmanageable.

Fortunately, the technology never stopped changing, and finally something transformative came along that completely reversed the direction of development on the front end, pushing it into a completely different phase.

The next article continues: Change at the front end (III) : Change and Breakthrough

—

Please visit our official website taoofcode.cc or follow our public account: – Spread the code with our small power