
A summary of jQuery method alternatives in native browser implementation - Liriel
https://github.com/oneuijs/You-Dont-Need-jQuery
======
dr_faustus
Hell yeah, you do. I just recently had to create a tiny script (one of those
notorious cookie warnings) without any dependencies. It's like pulling teeth.
The DOM API is an ugly, verbose mess and its pretty unbareble to use without
JQuery, zepto, etc.. Including the code for parsing cookies (yeah, you still
have to do that, too) the script clocked in at 318 lines of code (without
comments).

With JQuery and the cookies plugin its would probably have been something like
30 lines. Thats 10 times the code you have to write, debug and maintain.

So, of course, you don't NEED JQuery just like you don't NEED any means of
transportation, you can walk everywhere after all. The question is, if you
want to spend you whole life walking/writing verbose ugly JS code.

~~~
lucideer
I'm sorry, I really hate to be condescending. I understand there are a range
of levels of JS expertise out there, and using either jQuery or an appropriate
library represents real value for many.

However, when you're opening a comment with "Hell yeah, you do", I really have
to respond.

Hell no, you don't. If you're writing 318 lines of code just to do a cookie
warning, that's fine. But please don't preach that it's necessary before
actually learning some javascript.

I'm also a bit baffled that it would take an entire 30 lines while using
jQuery AND a cookie plugin. What are you doing to these cookies messages???

::EDIT::

I have no idea if the code below works, and it could do with a lot of
improvement (thinking about secure cookies, cookie paths, or even just using
localStorage instead), but I can't imagine a bit of testing and revision of
the code would balloon it to even twice its size. Least of all _30 times_ its
size.

    
    
      (function() {
        var cookiesMessage = document.getElementById('cookies-message-wrap');
        var cookiesAccept  = document.getElementById('cookies-accept-button');
        var checkCookies   = function () {
          cookiesMessage.setAttribute('class', document.cookie.indexOf('cookiesaccepted=1')===-1?'':'accepted');
        }
        cookiesAccept  .addEventListener('click', function() {
          document.cookie = 'cookiesaccepted=1;expires=Tue, 19 Jan 2038 03:14:07 GMT;path=/';
          checkCookies();
        });
      })();
    

What am I missing?

~~~
throwanem
I'd default the notice invisible and show it when it hasn't been accepted,
rather than vice versa as you do here. That way, in the more common case,
nothing needs doing. (Maybe there's a regulatory reason that won't fly? I
don't know or care much beyond the obvious about the EU cookie rule.) I'd also
break out some of the inlining, just to make it read more easily, if this were
destined for production.

But the functionality looks good! I mean, document.cookie can be a huge pain
to deal with if you actually have to _deal_ with it, and jQuery has a plugin
for that - but this doesn't take any kind of parsing, just a cheap substring
check, and the class list manipulation is equally trivial. Even animation
could be handled in CSS.

Perhaps OP's use case is much more complex than it sounds, in a way that's far
from obvious?

~~~
lucideer
I'm not sure what the regulation would say, but if I'm choosing to comply, I'm
going to default to visible as absence of JS doesn't equal absence of cookies.
It maybe annoying that the accept button won't work, but at least the user is
informed, which I guess was the intent of the (tbh misguided) regulation.

------
dageshi
I really don't get this vendetta some small number of people seem to have
against jQuery. It seems like it gets looked down upon in the same way that
PHP gets looked down upon. But while PHP has legitimate problems most
arguments against jQuery seem to boil down to "You can save a 100k download!".

Big deal.

~~~
forestjc
what kind of problems has PHP?

~~~
tudorw
too old, like me :) Seriously, [https://symfony.com/](https://symfony.com/) is
awesome.

------
jorgeleo
I am sorry, this just does not make sense.

It claims that because there is direct access to all the DOM API, you really
don't need jQuery, but then it gives examples on how simple jQuery calls maps
to different, multimethod calls to the DOM API. Those examples show how jQuery
provide a nice abstraction on top of the DOM.

This article is like saying, we don't need high-level languages because we can
all learn assembler.

~~~
dullgiulio
Exactly. As a person who doesn not usually write Javascript, this project
looks like an involutary advertisement for jQuery.

Half of the native solutions have bugs or no IE support. All are three or more
times more tendious than jQuery.

The adage in the other comments seem "but jQuery is a big dependency."

Did we already forget the left_pad npm debacle? jQuery didn't break then.

~~~
throwanem
If you're doing a bunch of these things, jQuery makes sense.

If you're doing one of them, just write it out and move on. Don't pull in a
multi-kilobyte dependency for one thing that takes two minutes to write.

What relevance has left-pad here?

------
grabcocque
Why use JQuery when you can do it in a way that's more ugly, more verbose,
less portable, more likely to break?

~~~
fiiv
JQuery is massive and has a lot of functionality. Sometimes this is nice, but
sometimes all you need from it is a small part of that whole. I think the
point of that link is that if you are looking to build in some simple
functionality like hide and show an element when someone clicks a button, then
you do not really need to include the whole JQuery library just to do that
because then the massive library is not being used and you would be better
served to write your own vanilla function.

I don't see anything wrong with that. No one is saying that JQuery sucks or
that it should die, I think the point is more "use the best tool for the job".

You can buy a massive wrench with all kinds of adjustable settings and addons
and stuff but if all you ever need is an Alan key, then maybe the little one
that comes with your IKEA furniture is actually better and easier to use than
that massive wrench.

~~~
Jazcash
30KB after being minified and gzipped is massive to you?

~~~
lucideer
Yes. This comment is why Wirth's law is a thing.

------
matthewmacleod
Obviously you don't _need_ jQuery, and twiddling in the DOM for an Angular app
means you are doing something wrong.

However, jQuery is still quite useful and I include it in most projects. It
makes various tasks, like event handling, AJAX requests and minor DOM tweaks,
quite a bit nicer. Zepto is a good alternative with an almost-compatible API
([http://zeptojs.com](http://zeptojs.com)). I would rather generally that
developers used these off-the-shelf tools instead of implementing possibly
buggy versions of functions like `height()`!

~~~
masklinn
Though I've been using it less and less with the rise and convenience of
vdoms, I always found that the most useful and delightful bit of jQuery is its
treatment of nodesets as proper _ordered sets_ , and that many of its
manipulatory methods properly work on sets.

~~~
throwanem
[].slice.call on the result of querySelectorAll turns that NodeMap (NodeList?
I forget) into a proper array, on which _all_ of the language's sequence
manipulatory methods work as they should. I don't know why that method doesn't
just return an array to begin with, but this is how you get one from it.

~~~
masklinn
> on which all of the language's sequence manipulatory methods work as they
> should.

Which is significantly less convenient and readable than using set-operatic
traversal and manipulation functions:

    
    
        $('div').prev()
    

will give me the preceding sibling of every div in the page, in native, best
case scenario using ES2015 arrow functions and Array.from it's something like
this:

    
    
        Array.from(document.querySelectorAll('div'))
            .map(e => e.previousElementSibling)
            .filter(e => e)
    

and if you need pre-2015 compat you get this ball of itchy yarn:

    
    
        Array.prototype.slice.call(document.querySelectorAll('div'))
            .map(function (e) { return e.previousElementSibling; })
            .filter(Boolean)
    

jQuery works on and manipulates node _sets_ , and I find that to be a
beautiful _and convenient_ abstraction. I expect that is not unlike the
satisfaction users of APL or its descendants feel (although I can't for the
life of me get beyond their sigil soup).

~~~
throwanem
I don't really have a positive counter-argument for this claim.

The closest I can come is that, while the latter two examples are indeed more
verbose, they're not really unattractive in their own right, and they do have
the virtue of explicitude which jQuery's set operations, while conceptually
clean and syntactically concise, lack. If you're not closely familiar with
jQuery - which I no longer am, having touched it barely at all for better than
half a decade now - what comes back from

    
    
        $('div').prev()
    

isn't obvious. It probably requires experimentation in the console or a
documentation review to be clear on the return value - and jQuery's
documentation is, to be charitable, not of the most lucid.

Meanwhile, in either of the native ES examples, it is immediately clear what's
going on, albeit at the cost of additional verbosity: you're getting a set of
elements, mapping each to its prior sibling, and filtering out those whose
lack of a prior sibling resulted in a meaningless value in the map. (To this
point, in ES5, I would instead write .filter(function(e) { return e !== null;
}); the Boolean constructor is a useful shorthand, but shares the jQuery
property of lacking lucidity.)

In a team with deep enough experience of jQuery that the meaning of your first
example would be clear to anyone working on the code, I wouldn't object to
writing it that way. In any other context, and especially on a team with
widely varying levels of skill and experience not just with jQuery but with
relevant concepts in general, I would strongly favor the more verbose
examples, both because they're easier to follow from scratch in their own
right, and because they serve as complete examples of a pattern with
applications far beyond the realm of DOM manipulation and thus have value
beyond there mere convenience to type.

Horses for courses, I suppose.

~~~
throwanem
_Their_ mere convenience to type.

How horrifying.

------
iSnow
I don't quite understand why browser vendors haven't developed a terse, fluid
API similar to jQuery/zepto with a touch of underscore/lodash and standardized
on it. Not only would this be easier to code to, but the JS runtime should
have some opportunities optimizing chained function calls to the DOM.

10y after release, jQuery is an established pseudo-standard that is not going
away any time soon. Even with
querySelector/querySelectorAll/getElementsByTagName/getElementsByClassName, I
am still using jQ as the vanillaJs API feels so clunky and verbose.

~~~
vatotemking
not invented here syndrome, probably

------
kibibu

        // jQuery
        $el.siblings();
    
        // Native
        Array.prototype.filter.call(el.parentNode.children, (child) =>
          child !== el
        );
    

Yes, much clearer

~~~
petepete
While I'm firmly of the opinion that full jQuery is a fine choice for most
projects, _if_ you don't need `$.animate` or favour fetch over `$.ajax` you
might be better-served choosing the slim build or smaller libraries that
provide only a subset of jQuery's functionality (Domtastic, Zepto, etc)

------
fuhrysteve
While I don't agree that eliminating JQuery is necessarily something to strive
for, I do like to see these sorts of projects because they help me learn how
to reduce my dependency on jQuery _when it makes sense to_

For example, there are new native language features in ES6 that make little
utility functions like $.inArray obsolete.

------
jwarren
I used [http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)
a lot when I was trying to wean myself off mental jQuery dependencies. It's
nice to know that there are some alternatives too.

If you miss the $ function for DOM element selection, it's pretty trivial to
wrap querySelectorAll in your own one-line helper function.

------
andrewclunn
The only future proof form of web development is being able to write things
natively. Everyone gets pissy when you show that maybe their preferred
framework or library isn't needed because that means their way of doing things
might be replaced. But native code doesn't give a damn.

------
izolate
Next phase: You Don't Need Native APIs, use React.

Source: lamenting the fact that I haven't used querySelector in almost a year.

~~~
pluma
Note: you can use `querySelector` on elements other than the root element.
This can be helpful if you need to use React's `ref` escape hatch to do
something "low-level".

------
err4nt
I love these sorts of comparisons. For years I was working with and around
jQuery code and coders, and no matter how much I tired, I could just never
learn jQuery. It felt too high level, like a world built out of train tracks,
so instead of going directly from point A to point B you took the 'easy' route
that quickly takes you from A to C with no traffic, how fast was that? To D,
then D in such a simp,e and easy way. Then finally maybe end up at our
destination.

It wasn't until I resolved to try to learn JavaScript without jQuery at all
that that mental barrier preventing me from understanding was removed. I blame
the abstraction level and omnipresence of jQuery for preventing me from being
able to learn JavaScript.

Now Ive been writing vanilla JS for a couple of years, a, learning s lot, and
I gain a lot of knowledge from posts like this, Ditching jQuery, and
YouMightNotNeedJquery, not because I knew the jQuery way—just because they lay
out the simple JS way to do common things.

Long story short, after starting to learn JS I still cant figure out what a
block of jQuery code is doing unless i re-implement it as vanilla to check and
see if my guess is correct. I cant wait for the day when people are content
with browser APIs for these things, many are simple but much more flexible.

------
drawkbox
One can drive automatic (jquery - no worry of browser issues) or stick shift
(native - test in all browsers of all types for everything). In most cases you
prefer automatic but sometimes you need stick shift when you go off-roading.
If others have to drive, automatic is still probably better.

When on a team it is good to use a common library that is tested across all
browsers and does native calls encapsulated within it. When working on an app
the last thing you usually want to get caught up on is browser inconsistencies
that are easily avoidable, wasting time on that when not necessarily needed
for that project. Other times you might need to go off-roading. If you always
offroad though because you just hate automatic, well you won't be drinking
coffee or using your phone much, you'll be worrying about shifting.

------
ge96
I wouldn't mind a smaller version of jQuery, I've heard of some, I've also
tried min/slim versions.

Still including a 200+kb file for jQuery... to just use well these are the
most common ones I use:

var targ = $("#targ");
targ.show,.hide,.val(),.text(),.css,.post(),.done,.promise(),.each(),.remove(),.on('blur"
or .on({ blur: mouseup, .height(), .width(), .scrollTop(), etc...

Probably much more, yeah certainly shorter code, gotten used to using it.

edit: At this time I always build with jQuery, always include it in the <head>
section. Could wait if it's a potential thing to slow down loading of site but
I usually just have a copy on my server.

~~~
iSnow
Hm, over here, the 3.2-version of jQuery comes in as something like 85Kb,
323Kb when zipped. The slim build under 70Kb and compressed it's something
like 20Kb. And there's zepto which comes in at around 10Kb.

~~~
ge96
Haven't heard of Zepto. Will check that out. I realize too that ~70KB is not
bad really. But I was working on a site for a client where their internet
speed is 0.3Mbps and a ~300KB file was taking ~300ms+ to load. No maybe more
than that actually(can't recall right now). 1KB files were taking a second to
load. I don't know, had to figure out a closer data center and change the site
a lot with how it loaded stuff.

------
squeral
My view on this is that if you are going to take advantage of the extended
list of jQuery plugins out there then you should definitely use it. But if you
are just using it to make your own changes to DOM then just use native JS.

------
exodust
jQuery plugins have come to my rescue many times in tight production
deadlines. The options out there, and generosity of developers to give away
and keep updated in response to demands, is first class.

jQuery by itself is something which is just nice to know is there, for quick
DOM manipulation in the standard way you know how, and other devs know how.
Hassle-free and accessible.

As a jQuery fan I'm glad there's more tools and methods out there, however.
I'm keen on VueJS myself but not yet confident. I'll be avoiding React and
Angular because to me they feel like using an industrial lathe when all you
need is a Dremel.

Performance crumbling is still more likely to be caused not by choice of JS
library, but shoving too much content down the throat of users because you as
developer couldn't say no, or when you advised against it were ignored.

------
franciscop
A made a small experiment about this:

    
    
        https://superdom.site/
    

It's probably not for anyone to use it, but it was really fun exploring other
possible APIs as alternatives to jQuery and with modern ES6+

------
nautical
I actually tried using plain JS in recent projects of mine , here`s my take .

If it is a simple 3-4 page website I write it in plain JS , if it is a complex
website with lots of views and components I write in Vue + plain JS (if req).

------
BuuQu9hu
This is hilarious. I mean, relying on external libraries aside, just look at
the readability and intuitiveness of the native syntax by comparison. It's not
even _close_.

------
draw_down
Be careful- NodeList/HTMLCollection/etc are not Arrays!

But, it's nice to make something dependency-free if you can.

