Vuejs, Angular, React, and the history of the front-end

Today, front-end history and framework

We all know that popular frameworks — vue.js, AngularJs, ReactJs — are increasingly being used in projects and applications as part of the MVVM data-driven framework family.

Before getting to know MVVM, let’s look back at the historical stages of front-end development to get a better idea.

This historical review, because there are many sources available online, is very long and difficult to understand.

So I quoted liao Xuefeng teacher website summary of a paragraph, simple meaning scary, convenient for everyone to understand reading seconds

---

In 1989, Tim Berners-Lee, a physicist at CERN, invented The HyperText Markup Language, or HTML, which became a draft of the Internet in 1993. Since then, the Internet began to commercialize rapidly, giving birth to a large number of commercial websites.

The earliest HTML pages were completely static Web pages, which were PRE-written HTML files stored on a Web server.

When the browser requests a URL, the Web server throws the corresponding HTML file to the browser and displays the contents of the HTML file.

If you want to display different pages for different users, it is obviously impossible to prepare thousands of different HTML files for thousands of users, so the server needs to dynamically generate different HTML files for different users. One of the most straightforward ideas is to use programming languages like C and C++ to output concatenated strings directly to the browser. This technology is called CGI: Common Gateway Interface.

Obviously, complex HTML like sina’s home page cannot be created by spelling strings. As a result, it was discovered that most of the strings were HTML fragments that didn’t change, and only a few bits of user-relevant data changed. So new ways of creating dynamic HTML emerged: ASP, JSP, AND PHP — developed by Microsoft, SUN, and the open source community, respectively.

Back in the day: in ASP, an ASP file was an HTML file, but the variables that needed to be replaced were marked with special <%=var%> tags, combined with loops and conditional judgment, making it much easier to create dynamic HTML than CGI.

However, once the browser displays an HTML page, the only way to update the page content is to fetch a new HTML content from the server. What if the browser wants to modify the content of the HTML page itself? That would have to wait until the end of 1995, when JavaScript was introduced into the browser.

Once you have JavaScript, the browser can run JavaScript and then make some modifications to the page. JavaScript can also modify THE DOM structure of HTML and CSS to achieve some animation effects, which cannot be done through the server, but must be implemented in the browser.

The above page development history, excerpts from liao Xuefeng summary, interested can go to search

Let’s follow my rhythm and uncover the principles of MVVM.

---

As for how JS is executed in the browser, this is another senior topic (the front end is really just a big mess), here we do not do research, interested can go to the information. All we need to know is that the browser is the JS execution container, and when it’s done, it displays the results on the page, just like Java needs a compiler.

Using JavaScript to manipulate HTML in a browser has also gone through several stages of development: we use the case of “Xiaobeizuoshuai” to demonstrate this

HTML:

<div id="name" style="color:#fff"</div><div id="age">3</div>
Copy the code

JavaScript:

// JavaScriptvar
dom1 = document.getElementById('name');var dom2 = document.getElementById('age');
dom1.innerHTML = 'the north'; 
dom2.innerHTML = '666';
dom1.style.color = '# 000000';  // CSS styles can also be manipulated
Copy the code

The result is:

<div id="name" style="color:#fff"Small north > < / div ><div id="age">'666,</div>
Copy the code

I use a word Is lazy, is that we said in the previous era of jQuery, due to the native API arcane, syntax for long bad to use, the most important thing is to consider all sorts of browser compatibility, because their analytical standard is different, caused the, write a result code to write a lot of compatible syntax, frustrating, so the emergence of jQuery, Quickly took over the world.

The above example looks like this with jQuery

HTML:

<div id="name" style="color:#fff"</div><div id="age">3</div>
Copy the code

JavaScript:

// jQuery will do

$('#name').text('Xiao Bei is so handsome.').css('color'.'# 000000');

$('#age').text('666').css('color'.'#fff');
Copy the code

The result is:

<div id="name" style="color:#fff"< div style = "box-sizing: border-box! Important; word-wrap: break-word! Important;<div id="age">666</div>
Copy the code

MVC mode, need server-side cooperation, JavaScript can modify the data rendered by the server in the front end.

In a word, all communication is one-way: that is, in the early stage we most commonly used state, submission once feedback once, communication once mutual restriction.

For example: submit the form to fill in the content → click submit → business logic processing → store in the database → refresh the page → server to get the database data → render to the client page → show the content you submitted last time

View: User interface.

Controller: service logic

Model: Data is saved

The communication between the parts is as follows.

The View sends instructions to the Controller

After the Controller completes the business logic, it asks the Model to change state

The Model sends the new data to the View, and the user gets feedback

Disadvantage 1: It must wait for instructions from the server side, and in asynchronous mode, all HTML nodes, data, and page structures are requested from the back end.

The browser only serves as a display container for parsing, the Model function is almost useless, the Model layer does very little and the front end is almost out of control, your front end is almost cutting graphics and doing the work/crying of rotation graphics

Disadvantage 2: because of the structure of the page rendered in your front end, it’s almost like the back end server wraps up a bunch of data and sends it all together, and you only need to use a concatenation string or a string concatenation engine for the front end

With Mustache, Jade, artTemplate, TMPL, kissyTemplate, EJS, etc., pure drudge and repetitive work is pretty much the rule, which leads to a lot of people who don’t think the front end is important and just do the art and the action experience.

Disadvantage three: one and move the whole body. Data, display is not separated! Why do I say that? Because if the business logic is going to change, for example, for a very simple requirement, if you have an Ajax data page that you put together with JSP or PHP, I don’t need the age field, separate the gender field, separate the male field, separate the female field, which used to be in the same table together

So, the back end of the SQL query to separate male and female data, and then render the string to remove the age field, and then split male and female into two tables, and then push to the front-end reception.

The front end receives it, and then renders it again, processes the page and even shows the action effect… Really helpless and painful ah (front and back end shout together: overtime makes me happy, woo woo woo)

---

Finally [stage 4], why do I talk so much nonsense in MVC mode, because you can understand MVC better

“What is the MVVM Pattern?”

MVVM was first proposed by Microsoft. It draws on the MVC idea of desktop applications. In the front page, Model is expressed as a pure JavaScript object and View is in charge of display, thus achieving maximum separation between the two. This is what we call the separation of the front and the back, and it’s really happening here

It adopts data-binding: Changes to the View are automatically reflected in the ViewModel, and vice versa, changes to model data are automatically displayed on the page

The thing that connects a Model to a View is the ViewModel. The ViewModel is responsible for synchronizing data from the Model to the View and for synchronizing changes from the View back to the Model.

Maybe the theoretical knowledge is boring, so we are still practical, look at the code is not good? Or just [small north the most handsome] case

MVVM data binding (MVVM data binding)

Since the essence of the data-driven model is the separation of [data] and [view], we don’t care about DOM structure in the first place, but rather the presentation of data.

What’s the easiest way to store data? Obviously not mysql, not a database, but JavaScript objects

HTML:

I don't care about you this time, Hem
Copy the code

JavaScript:

// JS base object // raw data \
var xiaobei = {   
   name: 'Keep your nose clean'.age: 3Tag:'dry'
>};
Copy the code

The result is:

Name: Don't make trouble in the front endage: 3
tag: dryCopy the code

Suppose: we treat the variable Xiaobei as Model data and some HTML DOM nodes as views, and imagine that they are already associated by some means.

Change the name from [front end don’t make a lot of mistake] to [small north], change the display age from [3] to [666], change the tag to [most handsome! We used to manipulate DOM nodes, but now we just need to modify JavaScript objects:

JavaScript:

// JS base object // changed data \

var xiaobei = {    
   name: 'the north'.age: Awesome!Tag:'the most handsome'
};
Copy the code

The result is:

Name: small northage: Awesome!
tag: the most handsomeCopy the code

By experiment and theory

When we change the content of the JavaScript object, the DOM structure changes accordingly. This changes our focus from how to manipulate the DOM to how to change the state of JavaScript objects, which is a planet’s distance easier than getting and manipulating the DOM!

This is also the core idea of MVVM: pay attention to Model changes and let the MVVM framework use its own mechanism to automatically update the DOM, thus freeing developers from the chore of manipulating the DOM!

The so-called data-view separation, data-driven view, view does not affect the data, no longer need to deal with the tedious DOM structure manipulation, the world suddenly clean, perfect!

Common MVVM frameworks: vue.js, AngularJs, reactJs, etc., will be discussed in the next article

Very tired, finally through simple examples and very plain language, led to the TOPIC of MVVM framework, Daniel please ignore, do not laugh at me, I just use the most simple language and expression, so that more people understand the principle, it is good for practical application, in fact, there is no technical difficulties.

As I am committed to writing a front-end series serial out, from the original page three musketeers era to the JS world now, so first make up the front link

[Web front-end pit series] : Click the title to enter

What is a Web front End? Promising?

Chapter 2: How to learn the Web front end? Dry goods information!

Chapter 3: A “Road of No Return” — the Learning route

Article 4: the web front end into the pit article 4: the web front end | you still use jQuery?

conclusion

I am beima, an Internet man who is afraid that you will suffer losses. I have established a peach blossom island in the complicated Internet and real world, hoping to cultivate evolution and improve together with my friends. Welcome to the island. — > the boiling point