Writing in the front

This article is to share the evolution of front-end technology from the perspective of front-end development, without talking about specific technologies, for non-front-end development or other positions of students on the front-end development of a comprehensive understanding. Can be used as a cross-departmental sharing project. Content for my collation, there are descriptions of inaccurate place welcome correction. This share also has made PPT file, if you need the original can contact by private letter.

This article will be shared as PTT pages.

P1 title

The evolution and development of front-end technology

Presenter: XX Department: R&D Center

The P2 interaction

Ask a few interactive questions:

  1. What’s the front end?
  2. What does the front end do?
  3. What skills are required?
  4. What do you know about the front end?

After interaction: we still have a very deep understanding of the front end, today’s sharing content does not talk about a specific front-end technology, I want to share with you the front-end evolution and development process, so that you have a more comprehensive understanding of the front end.

P3 syllabus

  1. “Age
  2. Web2.0 era
  3. Front-end dominated MV* era
  4. Front-end engineering era
  5. Node brings the full stack era
  6. Big front-end era

Remark:

The first Web browser was created in 1990; In 1991, the WWW was born, which marked the beginning of front-end technology. In the 20 years of front-end development, we have gone from the earliest purely static pages to the birth of JavaScript. From PC end to mobile end to small program;

This time, WE will discuss the front-end in depth from these stages. We hope that we can have an understanding of the front-end life and afterlife through this sharing. We can understand the technology stack of front-end development and what the front-end can do

P4 “era

Let’s take a look at the web1.0 era in the following sections

  1. The age of universe
  2. The first browser wars
  3. Dynamic page rise
  4. Back end dominated MVC era
  5. The second browser war

P5 The Primordial Age

Prehistoric Times (1990-1994)

During this period, the World Wide Web (WWW) was born, the browser was born, and JavaScript was born

At the time, there was no professional front end and pages were developed entirely on the back end, which resulted in an obvious drawback: each update required a full page refresh, which, combined with early Internet speeds, was very slow.

Note: The picture above is the first commercial browser Navigator released by Landscape in 1994. That same year, PHP was born. PHP can embed dynamic content in HTML, improving the efficiency and readability of writing pages. PHP delimiter, loop statement and other inventions, a profound impact on the later ASP, JSP, is to the later JavaScript front-end template engine.

In 1994, the W3C group was formed to take charge of the HTML development path, with the goal of facilitating the development of a common protocol. W3C standards are not a single standard, but a collection of standards. Web pages are mainly composed of three parts: structure, presentation and behavior.

P6 The first browser wars

In 1995, netscape engineers designed the JavaScript language in 10 days. The scripting language was originally called Mocha, but was eventually changed to JavaScript for good marketing with the Java language. Netscape built the scripting language into Navigator 2.0 to run in the browser.

In contrast, Microsoft released VBScript and JScript in 1996. JScript is a reverse-engineered implementation of JavaScript built into Internet Explorer 3. But JavaScript and JScript are implemented differently, resulting in web pages that aren’t compatible with both Navigator and Internet Explorer. Internet Explorer began to steal market share from Netscape, which led to the first browser wars.

But because JScript has a lot of bugs, people are not willing to develop websites for IE, so they dug out UA and specifically filtered IE. UA refers to Navigator. UserAgent, which uses a string to record the operating system and browser the user is currently running. The UA of IE3 currently looks like this:

Mozilla / 2.0 (compatible; MSIE 3.02; Windows 95)Copy the code

The program determines the UA information and prompts the user to open it with a Netscape browser if it finds that the current environment is Internet Explorer. So Microsoft had to disguise its UA as much as possible as a Netscape UA and trick the script used to detect UA so that Internet Explorer could run these sites.

The first browser wars ended with Internet Explorer trouncing Netscape, and IE began to dominate the browser market, peaking at 96 percent share in 2002.

One problem with the first browser wars was that despite ecMA-262 (the JavaScript specification document) and W3C (the HTML and CSS specification document), Microsoft didn’t implement JavaScript, HTML, and CSS according to the specification, leading to front-end compatibility problems. So CSS hacks, browser determination, feature detection, all these techniques came into being.

P7 The rise of dynamic pages

When JavaScript was born, it could be used to change the style of the front-end DOM and implement small functions like clocks. JavaScript at the time was limited to that, and most of the front interfaces were simple, displaying purely static text and images. This kind of static page cannot read the data in the background database. In order to make the Web more vibrant, dynamic page technology represented by PHP, JSP and ASP.NET was born one after another.

This model works well for small entrepreneurial projects, where there is no front or back end, and often 3-5 people do all the development. Page by JSP, PHP and other engineers in the server generated, browser is responsible for display. Basically what the Server presents to the browser, the control of the presentation is in the Web Server layer.

The advantage of this mode is that it is simple and quick, you can develop Tomcat or Apache locally, and debugging is ok, as long as the business is not too complicated.

But businesses always get complicated, and that’s a good thing, because otherwise it’s probably a failure. The complexity of the business will lead to more and more services, and the number of people involved in development will likely grow from a few to dozens. In this case, some typical problems are encountered:

1. With the increasing number of services, the call relationship becomes complicated, and it is no longer a simple matter for the front-end to set up the local environment. When you think about teamwork, you often think about setting up a centralized development server to solve it. This solution may be fine for compiled back-end development, but it’s not friendly for front-end development. Oh, my God, I just wanted to tweak the button style, but it took several steps to develop it locally, upload the code, validate it, etc. It may be ok to get used to it, but development servers are not always stable, and you often have to rely on back-end development to fix things when they go wrong. It may seem like just front-end development is hard to localize, but the impact on r&d efficiency is actually quite large.

2. The maintainability of JSP code is getting worse and worse. JSPS are very powerful and can embed Java code. This power makes the responsibilities of the front and back ends unclear, and JSPS become a gray area. Often in order to catch up on projects, for a variety of urgent needs, will be mixed in JSP a large number of business code. At a certain stage of accumulation, there are often significant maintenance costs.

P8 backend dominated MVC era

In order to reduce complexity, there are architecture upgrades of the Web Server layer, such as Structs, Spring MVC, etc. This is the era of back-end MVC.

Code maintainability has improved significantly, and MVC is a great collaboration model to let developers know what code to write and where on an architectural level. To keep the View layer simple and crisp, there are also templates like Velocity and Freemaker. Typical questions at this stage are:

1. Front-end development is heavily dependent on the development environment. In this architecture, there are two modes of front-end and back-end collaboration: one is for the front-end to write the demo, and after the demo is written, the back-end to set the template. Taobao early including now still have a large number of business lines is this model. The benefit is obvious. Demo can be developed locally and is very efficient. The disadvantage is that the back-end template also needs to be set, which may be wrong. After the set, the front-end needs to be determined, and the cost of communication and adjustment is relatively large. Another collaboration mode is that the front end is responsible for all the development of the browser side and the template development of the View layer on the server side. Alipay is this mode. The advantage is that the UI-related code is written in the front end, and the back end does not need to pay too much attention. The disadvantage is that the front end development is heavily bound to the back end environment, and the environment becomes an important factor affecting the efficiency of the front end development.

The responsibilities of the front and back end are still entangled. Velocity templates are pretty powerful, with variables, logic, macros, and other features. You can still use context variables to implement business logic. As a result, as long as the front end is weak, it is often required by the back end to write a lot of business code in the template layer. Another big grey area is controllers, where functions like page routing should be the front end’s primary focus, but are implemented by the back end. The Controller itself is often entangled with the Model, and the annoying code often appears in the Controller layer. These problems cannot all be attributed to programmer literacy, otherwise JSPS would be enough.

P9 The second browser war

IE won the first browser war against Netscape and dominated the browser market. As a dictator, IE did not follow the W3C standards, IE became the de facto standard.

Internet Explorer’s dominance was first challenged when Firefox was first released in November 2004 and downloaded more than 60 million copies within nine months, sparking the second Browser War. At the end of 2008, Firefox’s market share had reached more than 25%, while IE’s had fallen below 65%.

In the second browser war, as the W3C group led by Firefox and Opera intensified their fight against Internet Explorer, the fragmentation of browsers became more and more serious. Different browsers implemented different standards, which was a nightmare for developers.

P10 Web2.0 era

Let’s take a look at the web2.0 era in the following sections

  1. Ajax was born
  2. JQuery rules the world
  3. Post-jquery – Modular front end

P11 Ajax was born

In 1999, Microsoft released Internet Explorer 5, which for the first time introduced a new feature that allowed JavaScript scripts to make HTTP requests to the server. This feature didn’t get much attention until 2004 and 2005, when Google’s two Web products, Gmail and Google Map, made extensive use of Ajax technology, allowing the front end to communicate with the server over the Web without requiring a page refresh. This may seem obvious today, but a decade ago AJAX was a revolutionary technology that changed the user experience, and the CDN began to be used for static resource storage in large part, leading to the return of JavaScript in the Web 2.0 era.

In this mode, the division of labor on the front and back ends is very clear, and the key collaborative point on the front and back ends is the Ajax interface. It looks so wonderful.

P12 jQuery rules the world

Back in 2006, when jQuery was released, the front end was dealing with browser compatibility issues. JQuery was very clever at dealing with DOM compatibility and discovered a number of DOM/BOM compatibility solutions

// js native var tabTotal = document.getelementById (' TAB '); var tabNav = tabTotal.querySelectorAll('.tab-nav a'); var tabContent = tabTotal.querySelectorAll('.tab-content .content'); for(var i = 0; i < tabNav.length; Return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () {return function () 0; j < tabNav.length; j++){ tabNav[j].classList.remove('current'); } // Add style tabNav[I].classlist.add ('current'); // Clear all Tab options for(j = 0; j < tabContent.length; j++){ tabContent[j].classList.remove('current'); } tabContent[i].classList.add('current'); } })(i); } // jQuery $(".tab-nav a"). Each (function (index) {$(this).click(function () {$(this).click(function () { $(this).css({'background':'black','color':'white'}).siblings().css({'background':'white','color':'black'}); $(".content").eq(index).css("display","block").siblings().css("display","none"); })})Copy the code

The popularity of jQuery has indirectly led to the following developments:

  1. Promote the learning of CSS1~CSS3 selectors
  2. The most important thing is to lower the threshold of the front end, let more people enter the industry, the front end engineer team is growing.
  3. Developers are starting to focus on front – and back-end separation.

JQuery also breaks the front end developer’s programming mentality, which is based on the back end development mentality: to do a business, first encapsulate a class, once you have this class, then find a way to pass in a DOM, and then manipulate the DOM through class methods. JQuery is DOM-centric, so developers can select one or more DOM objects, turn them into jQuery objects, and chain them. A lot of good engineers have created a lot of jQuery plug-ins and UI libraries.

P13 Post-jquery era – Front-end modular

As it goes,jQuery has some problems:

  1. JQuery’s chained operations are all the rage, but they also cause a lot of problems, and when Ajax dependencies occur, callback hell is inevitable.
// Demonstrates nesting, CPS, 'callback hell'
 $.get('api1/data', function(resp1) {
     // Next that depended on the first response.
     $.get('api2/data', function(resp2) {
         // Next request that depended on the second response.
         $.get('api3/data', function(resp3) {
             // Next request that depended on the third response.
             $.get(); // ... you get the idea.
         });
     });
 });
Copy the code
  1. JQuery has so many selectors that are difficult to maintain. With the development of the Web Page, the interaction of the Page becomes more and more complex, resulting in the evolution of the Web Page to the Web App. The new trend brings new development methods.
  2. Front-end engineers often write a page that introduces a dozen or even dozens of jQuery plug-ins and fills the page with Script tags. As we all know, browsers are single-threaded, and Script loading will affect page parsing and rendering, leading to the famous white screen problem
  3. Another problem with jQuery is global contamination, caused by plugin quality issues, or development quality issues.

So some of the best front-end engineers decided to take a page from the back end and introduce a modular mechanism. So someone decided to unify this approach to module definition and set up CommonJS. CommonJS came into play a long time later when node.js came into play in the back end.

The CommonJS specification is relatively old. NodeJS uses CommonJS. The module is loaded like this:

Module.exports ={satrt:function(){}} var clock = require('clock'); clock.start();Copy the code

But there were factions within CommonJS, and no one would talk to the other. Finally, one person couldn’t resist developing RequireJS on his own, and the module specification is AMD. AMD’s biggest advantage is that it supports plug-ins, is straightforward, and provides a SHIM mechanism for loading JavaScript code written in non-AMD specifications.

AMD (Asynchronous Module Definition), which is the Asynchronous loading of modules, is applied by requireJs. Define all dependencies and then execute them in the loaded callback function:

// define(function (){return {attr1: 'attr1', attr2:456, start:function(){}}}); // require(['clock'],function(clock){clock. Start (); });Copy the code

AMD implements asynchronous loading, but does not require all dependencies to be written out at the beginning of the logical order, like commonJS when used, and also supports asynchronous loading after execution?

In China, another normative style is popular, backed by Ali’s banner, someone launched SeaJS, claiming its specification as CMD. In fact, both at home and abroad, have produced many module loaders, but finally was eliminated, the specification is enough, not too much.

CMD (Common Module Definition) is the standard recommended by SEAJS, while CMD relies on nearby and requires when used. It reads like this:

define(function(require, exports, module) {
   var clock = require('clock');
   clock.start();
});
Copy the code

Until the advent of ES6, the ES6 standard was modular

ES6’s statically loaded design allows you to determine module dependencies and input and output variables at compile time. ES6 has realized modularization in language level, replacing CommonJS, AMD, CMD to become a common module solution on server and browser side. (CommonJS, AMD, CMD runtimes determine dependencies)

Note: The CommonJS specification is defined through module.exports, which is not supported in the front-end browser and is used through the Node.js backend. Nodejs side is the use of CommonJS specification, front-end browsers generally use AMD, CMD, ES6 definition of modular development

P14 front-end dominated MV* era

Title page

P15 backend MVC issues

The BACK-END oriented MVC mode is adopted. The business form leads to the weak mode of the front-end Model, so we choose to use Service instead of Model to do API aggregation

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 responsible for display. The ViewModel is responsible for synchronizing data from the Model to the View, and for synchronizing changes from the View back to the Model. The synchronization between the View and the Model is completely automatic, without human intervention.

P16 React & Angular

With the development of front-end technology, React, Vue, Angular three MV* frameworks have gradually emerged to divide the world. React is a frontend framework from Facebook, Angular is backed by Google, and Vue is a framework created by Evan You, one of Google’s core developers

Angular was one of the earliest MVVM frameworks to emerge, but due to the steep learning curve, rapid disruptive upgrades, and the rise of React and Vue, domestic Angular usage has also declined. React is lighter and more flexible than Angular. In addition, The React ecosystem, React-Native, is an excellent mobile development framework that can be adapted to Android and IOS development systems and can be hot updated. It is favored by many major manufacturers.

P17 Vue

As a homegrown framework, Vue borrows the good stuff from React and Angular, a hybrid of functional and object-oriented programming. There are more perfect Chinese documents, the lowest learning cost, syntax concise, elegant and concise, readable code, mature modular components are very popular in China.

Vue has two characteristics: responsive programming and componentization.

Vue’s advantages: lightweight framework, easy to learn, two-way data binding, componentization, separation of data and structure, virtual DOM, fast runtime.

Vue is a single-page application that refreshes the page locally, eliminating the need to request all data and DOM every time you jump to a page, which greatly speeds up access and improves the user experience.

P18 Comparison between Vue and JQuery

For a more intuitive comparison of the advantages of MVVM, if you want to achieve a data binding effect on the input box, using Vue and JQuery respectively to achieve this logic code comparison:

After comparison, Vue can implement the complex logic of jQuery with just a few lines of code. And there are improvements in efficiency and performance. JQuery is fading from the scene.

To be continued

Because of the length of the space, today we share the first half of the evolution of front-end technology.

The second half of the front-end engineering, the full stack development era, the big front end era will be shared in the next part

Here is a screenshot of PPT, if you need PPT file can leave a message or private chat oh

If you are interested in this article, please give it a thumbs up and forward

The last

Welcome to visit our small program small program small program front end test treasure book (point me point me point me), which has collected 600+ common front end test questions and answers, I hope to help students on the way to interview.