Does your WebApp really need jQuery?

First of all, we need to acknowledge the strong charm of jQuery. It is a lightweight and user-friendly way to accompany us through every day of desktop browser development. This is one of the mainstream frameworks commonly used in desktop browser projects. But in mobile browser projects, such as WebApp, are you willing to reference such a huge and swollen front-end framework? Do you really need it? In fact, you don't need it because the APIs in high-end mobile devices are enough.

Next, let's talk about the reason you should give up jQuery on a mobile device.

Why do front-end engineers need to care about the front-end framework on mobile devices?

As we all know, the most obvious difference between mobile devices and fixed devices is the bandwidth problem. Loading external resources on mobile devices is certainly much slower than loading external resources on fixed devices. We direct the problem to the front-end framework. The min version of jQuery's latest version is 77KB, which requires a compromise between front-end engineers.

A major proportion of jQuery is the Sizzle selector, which is an open-source javascript selector framework compatible with multiple platforms. However, we do not need this Sizzle selector on mobile devices, the other part is the jQuery animation library, which is also compatible with multi-platform animation libraries. But in webapps, we also don't need it. We need the translate and animation of CSS 3 to meet our needs, the last one is jQuery's OOP, which is completely unnecessary. developers can encapsulate a set of OOP methods based on their own professional skills.

First, let's look at javascript selector.

We usually perform DOM operations on DHTML websites. jQuery is a lightweight and powerful JavaScript framework with flexible DOM operations. When you use jQuery to operate the DOM, just like playing Magic, this is exactly the original design of jQuery.

However, when your user base is Iphone, Android, Ipad, Blackberry, and other high-end users, you should not introduce such a huge JavaScript framework to use selector. You should do this:

 
 

  
  
document.querySelector(DOM);  
 
 

QuerySelectorIt is an easier, faster, and more reliable local selector engine. You can also use three lines of code to encapsulate a function like jQuery to use the selector.

 
 

  
  
function $(query) {    
  
  
     return document.querySelectorAll(query);    
  
  
}  
 
 

Here you like $, just three lines of code! You may be asked to use getElementById to get the DOM faster, which is good. The getElementById method is faster to get the DOM, but this method can be used to get the pleasure of DOM only when there are many elements on the page, however, it is impossible for a WebApp to have many elements on the same page. It will not be the same as a Web product. So here I do not recommend that front-end engineers abandon querySelectorAll/querySelector and use getElementById to re-encapsulate it for this reason. In actual project development, you can save the obtained DOM in the variable, which also reduces DOM access.

DOMReady Function

Of course, sometimes we may need to wait for the DOM to load before executing our function. JQuery has the ready method. We can also have our own ready method.

 
 

  
  
function ready (fn) {    
  
  
    document.addEventListener('DOMContentLoaded', fn, false);    
  
  
}  
 
 

Therefore, all functions will be executed immediately after the DOM element is loaded. image | audio | video is not included here.

 
 

  
  
ready(function (){    
  
  
    alert($('#demo')[0].innerHTML);    
  
  
});  
 
 

You may have discovered that this ready method is not very flexible. First, you Cannot uninstall the DOMContentLoaded event. Every time you call the ready method, the DOMContentLoaded event is registered for the document. Second, after the DOM is loaded, only one function call is executed. This is not what we want. We need to improve it.

 
 

  
  
var readyFuns = [];    
  
  
function DOMReady(){    
  
  
    for(var i=0,l=readyFuns.length;i<l;i++){    
  
  
      readyFun[i]();    
  
  
    }    
  
  
    readyFuns = null;    
  
  
    document.removeEventListener('DOMContentLoaded',DOMReady,false);    
  
  
}    
  
  
function readyFun(fn){    
  
  
    if(readyFuns.length == 0){    
  
  
       document.addEventListener('DOMContentLoaded',DOMReady,false);    
  
  
    }    
  
  
    readyFuns.push(fn);    
  
  
}  
 
 

This seems to have solved the above two problems. The current DOMReady method can ensure that multiple functions are executed at a time after the DOM is loaded, and the DOMContentLoaded event can be uninstalled. Encapsulate a domready method in a WebApp. You do not need to consider IE or other statistical tools. You only need to consider the WebKit kernel browser. Therefore, you can use a pair of removeEventListener and addEventListener. These two methods are also W3C standard methods, so we have covered jQuery's DOMReady50 % code.