export function extend(src) {
      var obj, args = arguments
      
      for (let i = 1; i < args.length; ++i) {
        if (obj = args[i]) {
          for (let key in obj) {
            // check if this property of the source object could be overridden
            if (isWritable(src, key))
              src[key] = obj[key]
          }
        }
      }
     }

    DragSelect.prototype.removeClass = function( element, classname ) {    
      var cn = element.className;
      var rxp = new RegExp( classname + \'\\b\', \'g\' );
      cn = cn.replace( rxp, \'\' );
      element.className = cn;
      return element;    
    };
    
    DragSelect.prototype.hasClass = function( element, classname ) {    
      var cn = element.className;
      if( cn.indexOf( classname ) > -1 ) { return true; }
      else { return false; }    
    };

    if (typeof element === 'string') {
        owner.element = document.querySelector(element);
    } else {
        owner.element = ((typeof element.length !== 'undefined') && element.length > 0) ? element[0] : element;
    }

[1] https://github.com/oncode/handorgel/blob/master/src/helpers....

[2] https://github.com/ThibaultJanBeyer/DragSelect/blob/master/s...

    Object.assign(target, object1, objectN);

    element.classList.add(className);
    element.classList.contains(className);

I don't think anybody was against jQuery back when the alternative was helper functions, I certainly wasn't. But that's five years ago at this point. Modern JavaScript looks nothing like the code you posted, it's actually been built up into a pretty good language.

At this point in front-end development something like Babel is a must. If you aren't using Babel/Flow/Typescript in your workflow, you are putting yourself at disadvantage for no good reason.

For better or worse, transpiling is a fact of life.

If your Uber-for-toothpaste startup doesn't care then fine. But crusty old browsers are still a crucial factor in many markets.

This situation is actually improving too. Chrome's "evergreen" development cycle has made a world of difference to feature adoption rate, and it's spread to every other major browser vendor. Once IE11 dies out, we'll have no non-evergreen browsers over 1% market share, and it makes me so happy to say that.

I find this debate so aggravating. I'm glad you can do some of the stuff jQuery does using modern vanilla js. Perhaps jQuery is overkill for doing one hide/show (or toggle) action on the page. But what about the more complex stuff. What is primary motivation behind this nagging issue, of the load time of jQuery?

I suspect it is that many developers have some obsession over shaving a few milliseconds on their load time. For jQuery? One library? Is it that bad that you need to write vanilla js? So you can save a few milliseconds?

Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read? What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass").

I like jQuery because the syntax makes sense, its clear and concise, you can do complex things with less code. Maybe some of the new stuff can be clean and concise and easy to read, but all of it? I have my doubts.

Can you give us some examples of things that you're worried can't be written clearly using plain JS? Obviously everything you can do with jquery you can do without jquery. Its just a library.

> Can you have a sophisticated selector for Event Delegation without using jQuery but make the code concise and easy to read?

What do you mean by event delegation in this context?

> What about child selectors ("ul.thisClass > li.thatClass" > span.otherClass")

document.querySelector / querySelectorAll supports this. Its available in all browsers on all platforms if thats how you chose to make web apps: http://caniuse.com/#feat=queryselector

The not() selector for jquery is one. The closest() is another that I have used multiple times.

> What do you mean by event delegation in this context?

This is what event delegation looks like in jQuery; $("ul#listid").( "click", "li.classThatMatters", function() { //do something });

How would event delegation look when selecting a child element with a specific class? Event delegation from scratch in vanilla js is longer than this.

I don't know much about query selectors. I'm going to read up on them. I suspect it handles most if not all the basic stuff jQuery does. However I suspect that are use cases that it might now.

fetch(url)

.then(res => res.status === 200 ? res.json() : Promise.reject(res))

.then(data => { ... })

For some things, like those mentioned by twhb, where support is >90%, sure, ditch the library and use the supported stuff. But I don't think all of jQuery is that well supported, yet, and/or has as decent an interface.

[1]: https://caniuse.com/#search=fetch

https://github.com/github/fetch or https://www.npmjs.com/package/fetch-ie8

I believe that jQuery is not "modular" enough for today's web development environment. The "light" version is a step in the right direction but it's not enough. If one could configure the "modules" needed and download/load a single file/library, it would be tremendous.

Native selectors are nearly as powerful. Your example works as-is, "not" is there, full reference at https://www.w3.org/TR/css3-selectors/#selectors.

Event delegation isn't native, but is now possible in five simple lines. That's the pattern: even when there's no native equivalent, new language features facilitate shorter, simpler implementations.

jQuery's performance impact is orders of magnitude worse than "a few milliseconds". On semi-old laptops and on mobile I've seen 200ms in just the time it takes to execute jQuery after loading it. There's also runtime overhead. It's not unbearable, but it's a real hit on a page with high user experience goals.

Native alternatives are often better–thought-out and better-integrated. For example, native Promises have better exception handling (thrown errors can be caught to continue down the "then" chain), more reliable execution order ("then" always defers callbacks, jQuery sometimes executes them inline), and integrate with `await`, like `const data = (await fetch("data.json")).json();`. (Though you should still transpile that, some browsers that don't support it are still in use.)

Besides that, unnecessary abstraction resists novelty and efficiency in the use of underlying resources.

For example, I don't support browsers without classList, so I don't need your regexp stuff. Maybe you do, but my code shouldn't be larger because of that.

Having said that, it's all about tradeoffs. Whether your project needs something as big as <insert JS framework or lib here> or if you can live with just needing a few utility functions, you make those choices, doesn't mean one is better than the other as it all depends on context and situation.

jQuery has become the defacto must-use library for javascript now which IMO is unfortunate, as a lot of sites and apps include it when they barely use most of what jQuery offers. I'm guessing most use jQuery for only a few things - Ajax, DOM querying, and events. I hope that sometime in the future jQuery would be more modular.

I haven’t done serious web work in ages but if I did I’m quite sure I’d find all of today’s “required” build tools quite frustrating.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

Builtin functions for adding, removing, toggling and querying classes on elements.

See:

- https://github.com/webpack/webpack/issues/2867

- https://github.com/webpack/webpack/issues/4784

(Note: webpack doesn't do any dead code elimination, it relies on UglifyJS to do so)

Are you aware of any alternative that can do tree shaking? Reading those issues' comments there is a link to babel-webpack-tree-shaking [1] which seems to do it?

[1] https://github.com/Aladdin-ADD/babel-webpack-tree-shaking

But both come with their own tradeoffs: Rollup is ES6 only and doesn't support certain features from TC39's Stage 3. Babili is very very new :)

[1] https://rollupjs.org

[2] https://github.com/babel/minify

Imagine your app uses, modals, dropdowns, multiselects, search autocompletes, sliders, rich text areas etc. Instead of having one cached utility library upfront you have many hidden utility libraries scattered around each component, which makes it difficult to say clearly that jQuery is always larger.

The other issue is maintainability. When you're working with third party components, hot-fixing an OS library can be fairly daunting if you need to also learn their own internal class structure, selector helpers, dom manip functions. Doing this in jQuery, it's fairly easy to fork the codebase and plop in a .clone() or .append() to fix a stale issue.

Ultimately mutating the DOM directly is just an awful job - it's solving problems that are ancillary to the problem that you are trying to solve (making great UIs). React and Vue feel like sensible abstractions, although there's still a far better but undiscovered solution to this problem.

I grant that the things linked from this site are useful and novel, but I don't want to build a project sourcing things from 16 different developers when I could just bring in one library that does all of them, and might weigh a little more over the net.

There are some projects that don't require all that jQuery provides, and sometimes you want to min-max performance and size of JS that gets downloaded.

Keep in mind that jQuery is maintained and contributed to by more than 16 developers so you are technically sourcing things from multiple developers, just so happens they are in a single library.

Again, it really depends on what you're doing with your project and what you need for your project. Most developers include jQuery by default because it's just the most common and most used library, and PlainJS offers an alternative which I think is great.

Anyone maintaining a public-facing codebase should note that "All functions work properly in IE 9 and above - most of them are compatible with IE 8." jQuery has compatibility going back much, much further. Users in third world countries with older computers are better served by jQuery.

jQuery has an enormous test suite, tons of documentation with examples, and unparalleled third-party support.

My JS is a bit rusty, but I remember that in JQuery I could do:

$("some selector").do_things()

And "do_things" would be done on all matching elements. For example:

$("li").addClass("foo")

Would add the class "foo" to all "li". I could further refine the selector above to select only the "li"s I wanted of course.

With the "plain js" solution, you have to "querySelectorAll" and then iterate over each element.

Another example is "ajax" requests. In JQuery you have the general purpose "ajax" method, with simple "success" and "failure" callbacks, and configuration done via a standard JS object filled with all the necessary parameters (and this object could be reused for the most part, since most of the parameters don't change). You can also chain ajax requests together with deferred objects. Simple, straightforward and useful.

With their proposed solution here, you have to faff around with the XMLHttpRequest object every single time you want to make a POST or a GET. Ugh. And if you need to chain a bunch of those together? Uuuuugh.

Yeah, you can put all of these things inside helper functions to hide the ugliness, but if you are going through all that trouble, you are essentially rewriting JQuery (or similar libraries), badly. If it is a one off thing, I guess you don't need JQuery, but if you are rewriting most of these methods, you are crazy. Use a library, and trim it down to remove the stuff you don't need (JQuery allows this, IIRC).

A final aside. One oft overlooked advantage of JQuery is that the "$()" method can be applied to anything, not just the DOM. You can create a JQuery object that encapsulates, say, an array. Then you can iterate with "each", you can "filter", etc. Also, you can easily trigger events on your objects with "trigger" that other interested parties can listen to them by setting up event listener with "on". Useful to give your classes some Qt style signal/slot semantics.

https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1...

...only with a ton of wrapper code around it in order to support IE9 and below. If you don't have to support ancient browsers, there's no reason you can't write QSA code.

var nodes = document.querySelectorAll("li"); for(var i=0; i<nodes.length; i++) { nodes[i].classList.add("foo"); }

Yes it's slightly more code. It's also going to run a hell of a lot faster on, eg, a mobile device.

    for (let node of document.querySelectorAll("li"))
        node.classList.add('foo');

    Array.from(document.querySelectorAll("li")).forEach(node => node.classList.add('foo'))

    let qsa => s => Array.from(document.querySelectorAll(s));

---

jQuery selectors were matched in native JS by `document.querySelector()` and `document.querySelectorAll()`

Pretty sure `querySelectorAll()` operates quite the same as jQuery's selector which returns an array of element objects that you can perform actions upon. The primary difference being that you'll have to run the actions in a loop over the array if you want to perform them over the entire selection. Eg:

   let elements = document.querySelectorAll('li');
   for(let i = 0; i < elements.length; i++) {
     elements[i].addEventListener('click', e => {
       console.log(`This element is ${elements[i]}`);
     });
   }

  const elements = document.querySelectorAll('li');
  [...elements].forEach((element) => element.addEventListener('click', this.onClickHandler));

https://developer.mozilla.org/en-US/docs/Web/API/NodeList

Is there a website that stays up-to-date with a brief summary of all this nonsense? I haven't programmed in JavaScript in 4 years but am needing to relearn it again for a project, and searching Google for "iterating over elements" in JavaScript returns 57 different techniques, all considered "the best way" at some different point in time over the last few years, and all with varying levels of browser support.

Looping/filtering over things should just not be this convoluted of a process...

    var elements = document.querySelectorAll('li');
    
    var arr_elements = [].slice.call(elements);

Funny how the first words of your statement are completely negated by the last half of your statement.

jQuery:

   $(<any selector>).anyfunction

The so called matching `document.querySelector()` and `document.querySelectorAll()` cannot come even close to the ease of use of jQuery's selectors.

`document.querySelector` returns one element only. It will be the first element matched, even if you have more.

`document.querySelectorAll` returns a pseudo-array of elements (in reality a NodeList) that lacks most of functionality of arrays, and you cannot apply any DOM functions to it without iterating through the entire list.

jQuery came out in 2006. It took w3c several years after that to come up with something resembling jQuery's selection function. 11 years later there's still not a single method in the entire DOM API that comes even close to jQuery's simplicity and expressiveness.

Anyway it's pretty simple to emulate the jQuery selectors' syntax elegance.

eg. from a link I posted below. This would produce similar results to jQuery selectors (minus backwards compatibility for older versions of IE).

-- Note if you try to use vanilla JS methods on a jQuery-selected element you will have to target which of the selected elements you want to act upon. It will return undefined for the selected element and throw an error if you try to, for instance `$('p').innerHTML = 'something';`:

  class DOM {
    constructor ( selector ) {
      let elements = document.querySelectorAll(selector);

      this.length = elements.length;
      Object.assign(this, elements);
    }

    each ( callback ) {
      for (let el of Array.from(this) ) {
        callback.call(el);
      }

      return this;
    }

    on( eventType, callback ) {
      this.each(function() {
        this.addEventListener( eventType, callback, false );
      });
    }

  }


  let $ = s => new DOM(s);

  $('#something').on('click', e => console.log(`Hello, event: ${e}`) );

I was replying to this statement:

"jQuery selectors were matched in native JS by `document.querySelector()` and `document.querySelectorAll()`"

> it's likely because of them that selectors were approached from said angle at all.

This is true :)

> This would produce similar results to jQuery selectors (minus backwards compatibility for older versions of IE).

It doesn't though. There are many more useful methods in jQuery, and you will eventually need to re-implement many of them. (Even such simple once as `.class()` or `.toggleClass()`, or `.attr()`, or `append()`, and many others).

It's easier to just go with jQuery :)

edit: I extended the above example to include some of the methods you mentioned, just for kicks. The append() function was the most difficult, but only because I had to figure out how to grab the child function's selector argument. I just had to bind the initial argument to the object in the constructor. It was a fun little challenge. I'm likely missing some functionality of it, but I was going for quick and dirty implementation as simply as I could make it.

https://gist.github.com/Robert-Fairley/5e1ae9f84bf6072b70892...

Question is: but why? :) What you do is basically re-implemeting jQuery with an untested code which is largely an unknown quantity. Whereas jQuery has countless little snippets like "We can't cloneNode fragments that contain checked, in WebKit"[1] any "simple, quick, dirty implementation" will not have that.

It's better to use a "select number of methods from jQuery" directly from jQuery than spend any time re-implementing them anew and missing multiple details that jQuery has accumulated over the years. Even is size is an issue. If it really really is an issue, the best approach is to actually extract relevant code from jQuery and not re-implement it.

My original point was: nothing in DOM APIs matches jQuery functionality. All attempts to prove anything otherwise only reinforce my point.

[1] https://github.com/jquery/jquery/blob/master/src/manipulatio...

each and filter are native functions on Array.

You don't have "on", "off" and "trigger", for example.

I only understand what VanillaJS is supposed to do by implication, by looking at the PlainJS sight and then extrapolating that this must be competition.

On the other hand, I like jQuery more for the support community :)

At the end of the day when you need to just get things done jQuery still shines. Does it produce spaghetti code? No, you are doing it. Does it become an enabler in spaghetti code? Yes. But not all the use cases are the same.

Recently I've missed the way you create DOM elements like you do with React.DOM so I created a simple proxy function like this:

let bai = {};

bai.DOM = function(){

    return new Proxy({}, {

        get: function(target, name){

            return function(args, body) {

                let newEle = document.createElement(name);

                if(args){
                    let keys = Object.keys(args);
                    for (let i = 0; i < keys.length; i++) {
                        newEle.setAttribute(keys[i], args[keys[i]]);
                    }
                }

                if(body){
                    if(typeof body === 'string'){
                        newEle.textContent = body;
                    } else {
                        newEle.appendChild(body);
                    }
                }
                return newEle;
            }
        }
    })

With this you can create new DOM elements as following,

document.body.appendChild(

    bai.DOM.div(

        {"id": "message"}, 

        bai.DOM.p(null, "hello world")

    )

Without using any framework you'll find yourself iterating over NodeLists all over the place.

ie, it's much cleaner to write

$('p').css('color', 'blue');

Than

document.querySelectorAll('p').forEach(el => el.style.color = 'blue');

Also, Microsoft kinda screwed us by keeping IE 11 around until 2025.

    let $ = s => document.querySelectorAll(s);

    for (let p of $('p'))
       p.style.color = 'blue';

    $('p')
         .css('color', 'blue')
         .addClass('bla')
         .filter(function() { $(this).parent().is('article'); })
              .removeClass('qwe');

    for (let p of $('p')) {
       p.style.color = 'blue';
       p.classList.add('ble');
       if (p.parentNode.matches('article'))
           p.classList.remove('qwe');
    }

Putting more effort into my code to remove unnecessary libraries allows the end user to load pages faster, and that's what I think matters most, because I hate having to wait, sometimes even twenty seconds for some simple pages to pass a loading screen

Given millions of people used jQuery for years without issue it's difficult to believe those who benefited are going to run it down publicly because they found something better.

The only people who would do this are those marketing something else. This is by far the worst part of tech forums, this kind of insidious marketing that seeks to 'force obsolence' on software and entire groups of people happily using it because some are promoting their own thing.

I have been a web developer for 18 years, and kicking the jQuery habit has been one of the toughest.

Frameworks also still rely on them. I'm a full time ember developer and last I checked they're trying pretty hard to drop the jQuery limitation (REALLY sorry to Ember devs if my info is outdated on this), but the ecosystem of ember/non-ember addons surrounding it will prolong things even longer I'm sure.

It's true that the DOM interface has stabilised and is now mostly consistent cross browser, however the API is massively unwieldy in places, from excessively long method names to irritating asymmetric potholes.

TLDR; Jquery is not needed for cross browser now, it's needed to make using the DOM API not so ridiculously verbose and long winded. You need to use jQuery today because: you want your DOM code to be 1/5th the size, more legible, more debug-able.

I still use native methods where possible where there is little difference, especially when performance is a concern.

Angular did that.

I think Zepto was that for a while.

Isn't jQuery's lite version already there, which drops Android support etc.

Why not serve that to correct browsers?

* http://projects.jga.me/jquery-builder/

* https://www.ericponto.com/blog/2014/10/05/es6-dom-library/

jQuery has been a good friend for many years. It saved us from the drudgery of cross-browser support and gave us an enjoyable API for browser development.

Technology moves on, today's browser APIs and tooling are light years ahead of what we had 11 years. You might not need jQuery, and that's ok!

https://trends.builtwith.com/javascript/jQuery

Perhaps new projects shouldn't be using jQuery, but it's possible that some devs who just churn out code without watching the industry aren't aware of this. Increasing that awareness appears to be the point of this plainJS landing page.

Or maybe those devs are watching the industry but don't care for the direction it's urging them to take, e.g. locking themselves into complex frameworks like React for simple crud pages that have the basically the same DOM each and every time they're loaded.

https://w3techs.com/technologies/overview/javascript_library...

So essentially we are talking about server side apps that still leverages jQuery to achieve some level of dynamicity on the front-end.

Personal anecdotal evidence: helping a friend create a very simple dashboard of running jobs returned by a REST service + stats returned by the same service etc. I've yet to find a reason to use jQuery, much less a bigger framework.

So do you primarily write server side web apps? Anything slightly more sophisticated on the front-end beyond imperative jQuery calls, requires a framework, to organize your logic, and to scale up to a team level where multiple devs can contribute to the same front-end codebase.

> Anything slightly more sophisticated on the front-end beyond imperative jQuery calls, requires a framework, to organize your logic, and to scale up to a team level where multiple devs can contribute to the same front-end codebase.

Yes. Often though, not a framework, but a library.

One thing I'll say about jQuery vs doing POJS (Plain-ol' JavaScript, pronounced Poise, heh) is that jQuery comes from a world where browsers sucked and build processes for JS were virtually non-existent. The market share of sucky browsers is much smaller now, and we have sophisticated build systems for JS. All of the benefits of jQuery (normalization, removing boilerplate, etc) can be had with vanilla plugins that you can put in your project and forget about.

The lingering damage of jQuery is that we have a bunch of jQuery devs in the world now who simply cannot write JavaScript. We've got to move past that.

No, we've got to move past lazy generalizations.

You've boiled down multiple issues to 'people only know jQuery'. Meanwhile the rest of this thread is dealing with more interesting and accurate specifics.