
“You Don't Need JQuery”  Part 5: Events - rnicholus
http://blog.garstasio.com/you-dont-need-jquery/events/
======
joshstrange
I applaud the author for figuring out how and blogging about how to get away
without using jQuery but I'll say the same thing I said last time I saw one of
these posts:

> If we've heard this argument once we've heard it a million times. Of course
> you don't need jQuery but unless you are writing an internal-only app and
> plan on writing everything from the ground up (all your auto-completes,
> multi-selects, etc) then you do need jQuery.

> I am not a fan of a lot of the code that I've seen written with jQuery but
> jQuery itself is not evil anymore than PHP is evil because people do stupid
> stuff with it. If you use jQuery correctly it is an invaluable tool that
> makes your like 100x easier.

> Event handling alone, I want to puke when I see the default way to do this,
> way too much typing, way too verbose. If I had to write that multiple times
> a day then I would probably create a helper function to abstract it away and
> I'd be on my way to building my own jQuery. No thank you, I'll take the one
> that's battle-tested and maintained.

> I'm getting sick of seeing this argument, if you work in a bubble then sure,
> be my guest (I'll be laughing at all the extra typing you will be doing) but
> if you plan on deploying your code to the real world? Just use jQuery and
> save yourself a headache.

~~~
izietto
I would add another point, which is the strongest IMHO: using jQuery you won't
incur any of the tons browser bugs fixed by jQuery, like for instance [this
workaround to bugged Safari 7.1/8.0
querySelector]([http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-re...](http://blog.jquery.com/2014/12/18/jquery-1-11-2-and-2-1-3-released-
safari-fail-safe-edition)), which was just solved.

------
oneeyedpigeon
I think everyone's being a bit too harsh on the author here. For one, there's
evidently a great bit of teaching material here, perfect for programmers who
have started with jQuery and want to understand a bit more about javascript
and how both work. Second, as hackers, many of us find value in simply
understanding how things work, practising various techniques, etc. without
there necessarily being an end production deliverable. Finally, there are
clearly _some_ cases (some kinds of embedded programming, maybe?) where the
overheads of a general-purpose library may be too great, and bypassing it is
preferable, particularly if a specific user agent can be targeted (or
ignored!). So, yeah, no-one should just chuck jQuery away and start coding
everything from scratch, but neither should we altogether dismiss a series of
articles that has clearly been put together with some care and effort.

------
Raphmedia
This series of article should be renamed "You should know how to do the things
that jQuery do for you by yourself." On a live environnement, there are so
many upside to using jQuery that even if you don't need it, you want it.

Good article.

------
ascotan
Just my opinion here, but this is terrible advice. I agree with the author
that JQuery's existence was predicated on the fact that it wrapped terrible
browser APIs, and that in the (more) modern world we no longer need these
wrappers. However, non-framework code is more verbose and is more likely to be
prone to error. It's also likely harder to code review with peers. From a
maintenance perspective you want less content/more safety.

------
voidr
> But if, for some reason, you must target ancient browsers, such as IE8 (or
> older), you can use the following code to register for an event in any
> browser:

And then the author proceeded to write a function that handles event
listening.

And then there is the "Libraries to Consider".

It's ironic the the author demonstrates it clearly that the "modern Web API"
is still not ready and we will still be using libraries like jQuery for the
next couple of years.

> I fell into a trap, and this is a trap that many new, occassional, and
> hobbyist web developers fall into. Had I taken the time to understand
> JavaScript and the API provided by the browser first, I would have saved
> myself a lot of trouble.

This is the only justification we get from the author for not using jQuery.
You can actually learn about the DOM and JavaScript while using jQuery, in
fact you have to if you write anything that's more complicated then form
validation.

I would say that the actual trap is not using jQuery, just because some people
don't think it's "cool" anymore.

Also using jQuery doesn't mean that you cannot the DOM API directly if it
makes sense.

------
carrier_lost
If websites call jQuery from a common CDN (like Google's, or Microsoft's, or
jQuery's own) then it's already cached in the browser, and processing time
really is negligible on a modern browser with a decent Internet connection.

If I may toss out a couple of cliches -- why reinvent the wheel when you can
stand on the shoulders of giants?

~~~
joshuacc
> If websites call jQuery from a common CDN (like Google's, or Microsoft's, or
> jQuery's own) then it's already cached in the browser

That's only if you point to the exact same version everyone else is using.

------
fat0wl
it's kindof funny the way frameworks/libs work

My thought process using Spring in Java:

1\. I should try to just use pure EE to leverage the power of the web
container so I don't include a heavy framework for no reason.

2\. Now I have a need that pure EE doesn't solve so well.... Googling for
solutions... oh look Spring framework can accomplish this.

3\. I might as well go with Spring because it is well-maintained, convenient,
& will probably solve some other utility needs that come up anyway. Better to
have 1 solution than patchwork of several...

4\. Well, now that Spring framework is installed I might as well just refactor
some of this code to Spring, it will be slimmer...

Same with jQuery.... if there is effort in learning compensatory methods for a
various needs, there usually aren't many valid reasons for not just embracing
a major lib/framework. (At this point I pretty much jump straight to step 4 as
quickly as possible at the start of projects to avoid the refactor...)

------
onion2k
"You don't need jQuery" is completely true, but only in the same way that you
don't need Rails, or Express, or Laravel, or stdio.h.. It just makes life _a
lot_ easier if you use it, and there's nothing wrong with that.

~~~
fat0wl
While I agree with your sentiment I think your analogy is a bit off... there
is a big difference between adding a utility library like jQuery to your
project vs. committing to the project layout of a framework like Rails.

jQuery is actually _less_ intrusive and therefore more of a no-brainer for me!
(I know i use Spring as an analogy in my own comment on this thread, but
despite being a framework you can use a lot of its libs without committing to
any of its other aspects)

sorry for being nitpicky i am just into analogies :)

------
timwaagh
event models in javascript accross browsers are very different. you will lose
a lot of time debugging and testing. I tried it when i was doing it the first
time. it wasnt much fun. jquery is a savior. maybe one should try to do it
without and try to support IE8 to appreciate its real value.

------
talmand
Funny to me that the section "Sending Custom Events" near the beginning
actually supports the idea of using jQuery, or something like it, to get
around browser inconsistencies and to prevent eventually building your own
jQuery-like library.

