Why are fewer and fewer people using jQuery?

Most of the early development uses jQuery, which brings a lot of convenience: quick element selection, easy MANIPULATION of DOM element apis, perfect compatibility between browsers, chain manipulation, animation, Ajax, and so on are all the benefits jQuery brings to front-end developers. Why are fewer and fewer people using it now? Let me illustrate my ideas in the following points:

1. Quickly select a DOM node

The ability to quickly pick up DOM nodes is an important factor for most developers using jQuery, but as of now, this advantage has been lost. Why? Told you two API, the two apis have quite a lot of people in use, is the document. The querySelector and document querySelectorAll method. These two methods can match the expected DOM node by passing in a string in the form of a CSS selector.

2. Apis to facilitate manipulation of DOM elements

Apis that make it easy to manipulate DOM elements, such as addClass, removeClass, and toggleClass. Native JS is now supported, too, with an API called classList.

Although IE compatible not too perfect, but the most basic implementation of the implementation are also achieved.

3. The animation

Now CSS3 animation technology has been very mature, has completely replaced jQuery animation, but also can achieve more complex animation than jQuery animate method, good compatibility, low performance consumption, why not? For example, CSS3 works perfectly if you want to implement an excessive background color, but jQuery doesn’t. There are many excellent CSS3 animation libraries, including the Animate. CSS library.

4. Ajax operations

JQuery eliminates browser compatibility issues and provides a concise API to call GET and POST, relieving developers of the hassle of compatibility and using native apis. But that advantage is now very small. Either the Fetch API of native JS or axios. Both give us great Ajax capabilities, and Axios also has the advantage of interceptors. At this point, jQuery’s Ajax really isn’t comparable.

Of course Fetch will not work on IE

But there is already a Polyfill scheme for Fetch: Github/Fetch

This way, you only need to reference this little JS, and you can use ajax conveniently. It’s much smaller than jQuery.

In the original development, engineers didn’t worry too much about performance. But now, in order to improve user representation, the first priority is to solve the performance problems associated with browser drawing. The most classic mo redraw and reflux these two concepts.

Redraw: When the page is redrawn, for example, to change the background color of an element.

Backflow: Typically, when the browser enters a page, it has already backflowed. Backflow refers to the layout of the page.

Since we want to improve performance, we can start with these two concepts, and surely updating pages with minimal cost is the best way to improve performance. Unfortunately, jQuery doesn’t do that. Here’s why:

When we get a set of news data to render to the UL tag, we usually concatenate the news data into a string, then select the UL element with the $character and change the innerHTML value of the UL to a concatenated string (using the HTML API), and complete the first rendering. This time the page was redrawn (of course), not analyzing how well or badly it performed the first time, but using the next illustration will be more powerful.

Let’s say we have a change button. In traditional development, the swap button would still be doing the same thing, fetching the element and modifying the innerHTML of the element, but now the question is, do we have to delete all the elements again and add them again? The answer is definitely no (as you can see below, how expensive it is to create an element).

At this time, we only need to modify the text in each Li and the link in the A label. Obviously, there is no need to add li again as above. Because a DOM element can contain hundreds of attributes, the performance overhead is high.

Now the new concept of Virtual DOM (Virtual DOM) can solve this problem. In fact, the Virtual DOM is a description of the real DOM node, and the real DOM can be changed with minimal change by changing the Virtual DOM (Virtual DOM is not necessarily better than jQuery).

Yubrook: It’s said that the real DOM is slow, but the test results are faster than React. Why?

React, Vue and Angular frameworks that are popular in China are all in the category of MV* frameworks, and their design features are mainly data-centered. I leave it to the framework to manipulate the DOM, so to speak. This is more efficient than traditional jQuery development, high code maintainability, scalability, and good performance.

For example:

I asked jQuery to buy a bottle of soy sauce and gave him 100 yuan. At this point, we need to tell him the way to the shop, how to tell the boss what soy sauce to buy, how much soy sauce to buy, how much change, and how to get back (command).

Then I asked Vue to buy soy sauce. I just gave him the money and told him where the destination was and what soy sauce to buy. There was no need to teach him by hand (functional).

This is the difference between traditional development and modern framework development.

With modern frameworks, you can use Webpack (and jQuery), and you can use off-the-shelf scaffolding provided by others, such as creation-React-app or VUe-CLI. Greatly improve the efficiency of development, and can use the latest ES6, ES7 syntax for development, in the coding experience, on a higher level.

Now that jQuery is out of the picture, it has done what it set out to do.