- Why are fewer and fewer people using jQuery
- Author: Lemonade
FundebugReprinted with authorization, the copyright belongs to the original author.
Most of the early development uses jQuery, which brings us a lot of convenience: quick selection of elements, API for easy operation of DOM elements, perfect compatibility between different browsers, chain operation, animation, Ajax, and so on are all the benefits jQuery brings to front-end developers. Why are fewer people using it now? I will divide the following points to elaborate my ideas:
I. The impact of JS update
1. Quickly select a DOM node
For most developers using jQuery, the ability to quickly pick up DOM nodes is an important factor, but as of right now, this advantage is clearly gone. 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 be matched to the expected DOM node by passing in a string in the form of a CSS selector. Here’s how the two apis are currently compatible:
As you can see from the figure, the two apis already work well with browsers.
Vue also uses this API for element fetching:
So jQuery’s advantage of quick DOM selection is gone.
2. API for manipulating DOM elements
Apis that make it easy to manipulate DOM elements, such as addClass, removeClass, and toggleClass. Now native JS is also supported, and this API is called classList.
Although IE compatibility is not perfect, but the most basic implementation has been implemented.
3. The animation
CSS3 animation technology is now mature enough to replace jQuery animation, and can achieve more complex animation than jQuery animate method, good compatibility, low performance. For example, CSS3 works perfectly if the background color is excessive, but jQuery doesn’t. There are many good CSS3 animation libraries, such as Animate. CSS library.
4. Ajax operations
JQuery’s Ajax operation eliminates browser compatibility issues and provides a simple API to call GET and post, freeing developers from the hassle of compatibility and using native apis. But now, that advantage is very small. Whether it’s the NATIVE JS Fetch API or axios. Both give us powerful ajax capabilities, and Axios has the advantage of interceptors. At this point, jQuery’s Ajax is really not comparable.
Fetch is not available on IE
But there is already a Polyfill for Fetch: Github/Fetch
That way, you just need to reference this little JS to use convenient Ajax. Compared to jQuery, it’s much smaller.
Second, performance issues
In the old days, the engineers didn’t bother too much with performance. But now, in order to improve user representation, the first priority is to solve the performance problems associated with browser rendering. The most classic of the two concepts of overdraw and reflux.
** redraw: ** is when the page is redrawn, for example, to change the background color of an element.
** Backflow: ** Generally, when the browser enters the page, it has already done a backflow. Backflow refers to the relayout 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 into a ul tag, we usually start by concatenating the news data one by one, then select the ul element using the $sign, and change the ul innerHTML value to the concatenated string (using the HTML API). This completes the first render. This time the page is redrawn (as it must be), and instead of analyzing how good or bad the performance was the first time, the next explanation will be more powerful.
Let’s say we have a change button here. In traditional development mode, the swap button would do the same thing, fetching the element and modifying the innerHTML of the element, but now the question is, do we need to delete all the elements and add them again? The answer is definitely no (see the figure below for how much it costs to create an element).
Because at this time, we only need to modify the text in each LI and the link in a tag, and it is obviously not necessary to add li again as above. Because a DOM element can contain hundreds of attributes, the performance overhead is significant.
Now a new concept, Virtual DOM (Virtual DOM), can solve this problem. In fact, the Virtual DOM is the description of the real DOM node. You can change the Virtual DOM with minimal changes to change the real DOM (Virtual DOM does not necessarily have better performance than jQuery).
Yu Yuxi: It is said on the Internet that real DOM is slow to operate, but the test result is faster than React. Why?
Third, modern frame onjQueryThe influence of
The popular React, Vue and Angular frameworks in China all belong to the category of MV* framework, and their design features are mainly data oriented. I’ll leave it to the framework to manipulate the DOM, so to speak. This is more efficient than traditional jQuery development, code maintainability is high, scalability is strong, good performance.
For example:
I asked jQuery to buy a bottle of soy sauce and gave him 100 RMB. Then we had to tell him the way to the shop, how to tell the boss what to buy, how much to buy, how much change to get, and how to get back ** (imperative) **.
At this time, I asked Vue to buy some soy sauce. At this time, I just need to give him the money, and tell him where the destination is and what kind of soy sauce to buy. There is no need to teach him by hand ** (functional) **.
This is the difference between traditional development and modern framework development.
Using modern frameworks, you can use Webpack (or jQuery), and you can use ready-made scaffolding such as creative-React-app, vue-cli. Greatly improved development efficiency, and can use the latest ES6, ES7 syntax for development, in the coding experience, a higher level.
Now that jQuery is out of the picture, it’s done what it’s supposed to do.
reference
- GitHub: This is how we deprecated jQuery
- What happened to JavaScript in 2018?