It’s a bit of a clicker, jQ is not something I can comment on. Of course, the so-called where to go is just a prediction and imagination, purely subjective expression.

Note: in that ie6, IE7 rampant era, in the web front-end industry just sprout era, JQ was irreplaceable and even standard with sharp tools. Today, JQ is still favored by a large number of developers. However, nowadays, with the popularity of MV *, jQ seems to have lost its way.

One, from entry to give up

I naively thought THAT JQ could take care of everything and be fearless. I wonder which framework/library the world never stops for.

In the era of a MV *, JQ has slowly faded out of people’s attention. Angular, React, Vue, Ember, Knockout, and many others have risen to mainstream status. React is shown as follows:

1) The separation of style, structure, and behavior advocated by the JQ era has been gradually replaced by the more advanced thought of Component:

/* Separate style, structure, and behavior from CSS and JS */
       

        
    hello, world!
  
       



Copy the code
/* A JSX is a complete and independent component, which directly introduces related styles, and is written in a mixture of HTML and JS. */ // index.jsx import React from 'React' require('index.scss') const Box = React. CreateClass ({render () { return (
       

        
        hello, world!
      
       

    )
  }
})

export default BoxCopy the code

2) Instead of being heavily dependent on selectors, we can write event bindings and styles directly between lines. The advantages of this are obvious. One is that we no longer need to write long and nested selectors for fetching. One is to make goals clearer and operations easier:


  


  
       

        
    hello, world!
  
       
// index.css .box { background-color: 'green'; color: 'red'; } // index.js $(document).ready(function() { var $box = $('#box') $box.click(function() { $(this) .html('hello, jq! ') .css({ 'color': '#fff' }) }) })Copy the code
// index.jsx
import React from 'react'
const Box = React.createClass({
  getInitialState () {
    return {
      target: 'world',
      styles: {
        backgroundColor: 'green',
        color: 'red'
      }
    }
  },
  render () {
    var _t = this

    return (
      
       

        
        hello, {_t.state.name}!
      
       

    )
  },
  changeTarget () {
    var styles = this.state.styles
    styles.color = '#fff'
    this.setState({
      target: 'jq',
      styles: styles
    })
  }
})

export default BoxCopy the code

3) MV * puts front-end programming into advanced mode. The advent of JQ has given us a new, better programming paradigm that people may not have noticed, for example:

Var box = document.getelementById ('box') var items = box. GetElementByTagName ('li') for (var I = 0; i < items.length; I ++) {items[I].style.color = 'red' items[I].onclick = function () {alert(this.innerhtml)}} $('#box li') .css({color: 'red'}) .click(function () { alert($(this).html()) }).css()Copy the code

Instead of talking about how much code JQ saves and how simple it is, let’s just talk about the benefits of this pattern:

  • The traditional approach exposes/hoists box, items, and I variables globally, while JQ has none at all. All are anonymous, greatly reducing global pollution.
  • Automatic traversal;
  • Chain calls, we can go on and on forever if we need to. This makes operations more coherent and understandable, with each operation tightly linked and ready to be split;
  • Jq also eliminates browser differences, which are commonly referred to as compatibility issues. In the hands of developers, there is only a unified API, and no different browsers. This is one of the biggest advantages of JQ, which allows developers to focus on their business and not worry about browser compatibility issues.

Finally, a slightly less accurate note is that the PERFORMANCE of the JQ API may be higher than what you write, depending on your level.

However, JQ does not solve the problem from the level of the whole Web application, it only complements and embellishes JS in detail. As Web front-end engineering becomes more complex, we need more advanced patterns to solve problems.

With the advent of NodeJS, the front-end has entered the engineering era. Subsequent AMD/CMD frameworks such as RequireJS, SeaJS, etc., all attempt to solve the problem of building complex applications. Since these can coexist with JQ without conflict, we won’t go into details.

Then there are the mv* frameworks like Angular and React, which suggest a more advanced way to organize code. Meanwhile, thanks to ES6, react’s JSX combines es6 features like a duck to water.

(Use react as a reference.)

At this point, JQ starts to look a little embarrassed.

  • Componentization makes JQ’s selector useless, and you can no longer use it$(document).readyGet the element safely, because you don’t know thiselementWhat time(un)mount;
  • You can install a lightweight, pure Ajax package instead of JQ’s Ajax;
  • Instead of manipulating the DOM directly, we change state;
  • If the JQ plugin is not enjoyable to use, the purpose of JQ is greatly diminished;

… The way of JQ is fading away.

Second, the future of plug-ins

Jq’s rich world of plugins is a huge asset, and if JQ goes away, then plugins that rely on JQ, or that don’t rely on JQ but don’t have CMD/AMD-enabled plugins, will surely go down as well.

But there’s always someone to do that, right?

In fact, most plug-ins can be easily converted to CMD/AMD (code from the network) by:

; (function(){ function MyModule() { // ... } var moduleName = MyModule; if (typeof module ! == 'undefined' && typeof exports === 'object' && define.cmd) { module.exports = moduleName; } else if (typeof define === 'function' && define.amd) { define(function() { return moduleName; }); } else { this.moduleName = moduleName; } }).call(function() { return this || (typeof window ! == 'undefined' ? window : global); });Copy the code

Of course JQ itself supports AMD/CMD.

But it’s clear that JQ is no longer necessary, and developers are slowly turning to new communities to inject new power into frameworks like React and Vue.

Instead of plug-ins, say components. The AMD/CMD transformation is only the first step, and the results are barely functional, but it is still quite a hassle to go from a traditional plug-in to a reactive one.

In React, the final form of a component is a simple extended tag that takes arguments (states/props/methods) from the parent component as input and outputs the view:

// index.jsx
import React from 'react'
import Box from './component/Box'
const Index = React.createClass({
  getInitialState () {
    return {
      target: 'world',
      styles: {
        backgroundColor: 'green',
        color: 'red'
      }
    }
  },
  render () {
    var _t = this

    return (
      
       

        
        hello, {_t.state.target}!
        
      
       
) }, changeTarget () { var styles = this.state.styles styles.color = '#fff' this.setState({ target: 'jq', styles: styles }) } }) export default Index // box.jsx import React from 'react' const Box = React.createClass({ render () { var  _t = this return (
       

        
        hello, {_t.props.target}!
      
       

    )
  }
})

export default BoxCopy the code
Three, the dust settled

However, jq has not remained unchanged over the years, and it is a good thing that Internet explorer 6/7/8 will no longer be supported in jQuery2.0 and later versions, which at least shows that jq has kept up with The Times.

June 3 of this year (2016), jQuery3.0 release; On July 7, jQuery3.1 was released, which was the most recent version at the time of publication.

Currently, jQ is still used in the following situations:

  • Need to be compatible with old IE projects;
  • Old projects that are still being maintained;
  • A beginner in the industry;
  • Developers who insist on the separation of style, structure, and behavior;

What changes can JQ make in an era where everyone has a MV *? The answer is no, jQ’s advantage is gone, mv* framework blocks DOM manipulation, becomes transparent, we only need to care about the data, modify the data. People who have used it have experienced that leaving JQ can still be fun.

It’s also unlikely that JQ will build a wheel and turn itself into an MV *. If they do that, then JQ will not do what they are good at and will choose not to do it. Library is not a framework after all. Adding a module loader to JQ won’t change anything.

Bottom line: Once we get used to programming data-bound views, we don’t want to manually manipulate the DOM ourselves.

(If there are any fallacies in the article, please leave comments.)