You don’t need jQuery, but you do need a DOM library

The purpose of this article is to introduce domq.js, the modular DOM library I wrote, and to give you a sense of how jQuery’s API will continue to exist in a different form, even though jQuery is dying out.

GitHub：github.com/nzbin/domq

Documents: nzbin. Gitbooks. IO/domq – API/us…

JQuery will not die

From GitHub’s abandonment of jQuery to Bootstrap 5’s removal of jQuery, it looks like an era has finally come to an end.

Why did we abandon jQuery? There are several reasons: browser compatibility is no longer needed, native DOM lookups are convenient, there are better alternatives to AJAX requests, and so on.

In my opinion, the biggest drawback of jQuery is that it can’t be introduced in modules. It’s not a good idea to introduce the whole library directly. But jQuery DOM manipulation is still necessary. A lot of people have some questions about this. In fact, when using the MVVM framework, DOM manipulation is really rare. But we can’t always do CRUD functionality. Some DOM manipulation is still required for complex business requirements.

If jQuery could separate out the functional modules associated with DOM manipulation, there would be a lot of room for it.

Native in power

In ordinary projects, more and more people choose to use native JS to operate objects, such as obtaining element attributes, width and height, positioning and so on.

Several years ago, there were many articles on Github about how to replace jQuery with native JS, such as YouDontNeedJQuery, YouMightNotNeedjQuery, etc. As far as I am concerned, pure JS operation is really simple, but it is not very elegant, more complex operation often need to turn MDN.

// jQuery
$('.my #awesome selector');

// JS
document.querySelectorAll('.my #awesome selector');
Copy the code

// jQuery
$(el).hide();

// JS
el.style.display = 'none';
Copy the code

// jQuery
$(el).after(htmlString);

// JS
el.insertAdjacentHTML('afterend', htmlString);
Copy the code

This is a snapshot of how jQuery compares to native JS, and the result is that jQuery’s API is much simpler. In addition, the way the jQuery API is used is very uniform. On the contrary, the native JS API is used in a variety of ways, both assignment, and parameter passing. In addition, the API names of native JS are long and hard to remember. This is why many JS libraries were born.

Most plug-ins have an utils file that basically encapsulates native methods and provides utility methods.

Zepto’s strengths and weaknesses

Zepto is a forward-thinking library. Why do I come to this conclusion? Zepto abstracts the native method further, making it easier to use. As I said above, given the simplicity and familiarity of jQuery’s API, why not combine jQuery with native JS? Surprisingly, Zepto’s authors did just that back in 2010. Most of the jQuery API is implemented with native JS. The replaceable rate is close to 90%. At least in the plug-in I wrote, it can replace almost all of the jQuery API. And Zepto is not always using document.querySelector method, but according to the performance of the merits of the selected use of Document. getElementById and Document. querySelector.

But Zepto also has some obvious flaws, after all, is the product of the last time, the first is not on-demand loaded, now we are writing the project will be more willing to according to their own need to introduce some methods, rather than the introduction of the entire library, although Zepto volume is not big, but as obsessive-compulsive disorder, or have some disgust. Zepto also has some bugs, such as scrollTop and scrollLeft methods. See source code for other differences.

// Zepto
scrollTop: function(value) {
    if (!this.length) return
    var hasScrollTop = 'scrollTop' in this[0]
    if (value === undefined) return hasScrollTop ? this[0].scrollTop : this[0].pageYOffset
    return this.each(hasScrollTop ?
        function() { this.scrollTop = value } :
        function() { this.scrollTo(this.scrollX, value) })
}
Copy the code

The document element can’t get the correct value. I asked about pr but didn’t respond. Zepto has basically stopped maintenance. The correct method is as follows:

// Domq
function scrollTop(value) {
    if (!this.length) return
    var hasScrollTop = 'scrollTop' in this[0]
    if (value === undefined) return hasScrollTop
        ? this[0].scrollTop
        : isWindow(this[0])?this[0].pageYOffset
            : this[0].defaultView.pageYOffset;
    return this.each(hasScrollTop ?
        function () { this.scrollTop = value } :
        function () { this.scrollTo(this.scrollX, value) })
}
Copy the code

The mission of Domq

There are plenty of jquery-like DOM manipulation libraries, such as Bonzo and $DOM, but when I rebuilt the jQuery plugin, I found that there was no way to replace jQuery directly with these libraries. Zepto was perfect, but I didn’t want to introduce extra useless methods.

Finally, I decided to adapt Zepto to make it more in line with current usage. Zepto’s core functions are a bit messy. The namespace includes Zepto, $, and Z. Domq’s core functions have only one namespace, D, which is almost the same as jQuery’s core functions. Think of it as a mini version of jQuery.

Zepto core method
var Zepto = (function() {
    varzepto = {}; . zepto.Z =function(dom, selector) {
        return newZ(dom, selector) } ... $=function(selector, context) {
        returnzepto.init(selector, context) } ... }) ()Copy the code

// Domq core method
var D = function (selector, context) {
    return new D.fn.init(selector, context);
}

D.fn = D.prototype = {
	...
	init: function(){... }... }Copy the code

Of course, the key to Domq is to load on demand, with methods mounted as needed to minimize unnecessary code. It’s easy to use, but you need to create a separate file to remount the required methods into the D namespace, which is useful when writing plug-ins.

import {
  D,
  isArray,
  addClass
} from 'domq.js/src/domq.modular';

// Static method
const methods = {
  isArray
}

// Prototype method
const fnMethods = {
  addClass
}

D.extend(methods);
D.fn.extend(fnMethods);
Copy the code

In addition, there are some tool methods that are often used in projects, and a tool library is probably the best way to expose these methods. Domq also has some common tool approaches, but it needs to be iterated.

D.type()
D.contains()
D.camelCase()
D.isFunction()
D.isWindow()
D.isEmptyObject()
D.isPlainObject()
D.isNumeric()
D.isArray()
D.inArray()
...
Copy the code

There’s not much new about Domq, so there’s not much to say about Domq. It’s already been used in the PhotoViewer plugin as well as in real projects.

conclusion

It’s a good time, it’s a bad time, and jQuery is coming to an end, but there’s no reason to give up on how you use jQuery. As mentioned above, jQuery’s DOM manipulation is still the most useful in my opinion, so you don’t need jQuery, but you do need a DOM library.

GitHub：github.com/nzbin/domq