This is cute and all, but JQuery is slightly more than just a framework for accessing the DOM.<p>My JS is a bit rusty, but I remember that in JQuery I could do:<p>$("some selector").do_things()<p>And "do_things" would be done on all matching elements. For example:<p>$("li").addClass("foo")<p>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.<p>With the "plain js" solution, you have to "querySelectorAll" and then iterate over each element.<p>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.<p>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.<p>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).<p>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.