“You Don't Need JQuery” Part 5: Events(blog.garstasio.com)
blog.garstasio.com
“You Don't Need JQuery” Part 5: Events
http://blog.garstasio.com/you-dont-need-jquery/events/
10 comments
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...), which was just solved.
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.
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.
Good article.
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.
> 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.
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.
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?
If I may toss out a couple of cliches -- why reinvent the wheel when you can stand on the shoulders of giants?
> 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.
That's only if you point to the exact same version everyone else is using.
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...)
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...)
"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.
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 :)
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 :)
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.
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.
> 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.