The core jQuery idea - using CSS selectors to find DOM elements and then changing their properties and firing/monitoring events - fits so naturally with the HTML/CSS model that it feels like it should be part of the standard DOM API.<p>I'm not aware of any JS.next-type efforts to do this though :(
jQuery is more or less a wrapper for the DOM API. Considering the amount of man-hours(1 guy over three weeks) that went into designing the DOM, it's safe to assume that jQuery does the interfacing better.<p>I don't understand why people want to make a distinction between vanilla JS and jQuery. It's like saying you want to make a distinction between standard C++ and QT. One is a language, the other is an interface. jQuery doesn't exactly provide a standard library by any stretch of the imagination.
"My only piece of advice is to get a solid background in JavaScript, then move forward, appreciate the blood, sweat and tears Resig put into jQuery"<p>I hear this point made a lot, for example in reference to learning Ruby before Rails or C before Ruby, but I don't think it's right. They used to teach kids Latin before Spanish or French (in the 1700s):<p>"We are told that it is proper to begin first with the Latin, and having acquir'd that, it will be more easy to attain those modern languages which are deriv'd from it" (quote from Ben Franklin's autobiography)<p>But that's silly and no one does this anymore because LATIN SUCKS and it's harder to learn Latin than any other language. jQuery is easier to learn than JavaScript. Why not start with jQuery and then learn JavaScript after?
Can you do X smaller and faster without jQuery?<p>If X is non-trivial and you need to support old/crappy browsers, then probably not (well, not without person-years of pain).<p>Conversely, if you can get away with targeting only IE9+, WebKit and Mozilla, or if X is dead simple, then almost certainly yes. And you should try it, too, because jQuery is a big warty kitchen-sink of a framework. In those cases these days I use CoffeeScript and a few simple homegrown helpers[1].<p>[1] <a href="https://github.com/jawj/affogato" rel="nofollow">https://github.com/jawj/affogato</a>
> <i>The reason being is that it abstracts out a lot of the JavaScript “gotchas” into nice, easy function calls. Most errors are caught by jQuery and never seen by the user, but more dangerously, never seen by the developer.</i><p>I have no idea what he's talking about. jQuery normalizes browser differences, but what on earth kinds of "errors" are "caught" by jQuery, that are "dangerous" to hide from the developer? I mean, I've used jQuery on projects for years, and I can't even imagine.
Using the collective knowledge and testing that has been used to derive the methods in jQuery is hugely attractive, grappling with cross browser issues every time you want to achieve something would be utterly pointless.<p>Despite this, every time I start a new project that requires some DOM manipulation etc I lament at having to include the entire library just to harness a tiny aspect of it's power.<p>A delightful solution to this would be a similar degree of modularity as there is in, for example, jQueyr UI. I know there is a degree of modularity (<a href="https://github.com/jquery/jquery#modules-new-in-18" rel="nofollow">https://github.com/jquery/jquery#modules-new-in-18</a>) but this is reasonably high level and at this level the argument of using google's CDN and so encouraging a cache hit is still very strong.
If you could strip both jQuery core and shizzle (I rarely/never use attribute selectors for example) right down to a hundred lines of so of what you really needed, this would be very very compelling.<p>I had a relatively brief investigation into the codebase a while ago with a view to how hard this would be to implement but didn't really have the time to follow it through. My conclusion was that it wouldn't be easy, anyone have any ideas/thoughts on this?
My evolution as a JavaScript Developer:<p>1. I found out I could use Rails helpers to make really cool stuff. It generated ugly JavaScript code and errors that no one could see. No one got hurt. Win.<p>2. I realized I could use Prototype.js directly. The code was still ugly, but I could do even more. I eventually switched to jQuery because of the large ecosystem.<p>3. I started buying and borrowing JavaScript books. I decided to use vanilla JavaScript. I realized that it was a pointless exercise because of browser incompatabilities: <a href="http://www.quirksmode.org/dom/w3c_core.html" rel="nofollow">http://www.quirksmode.org/dom/w3c_core.html</a>. Now I understand JavaScript, but use jQuery to interact with the DOM.<p>It's probably impractical to suggest people learn vanilla JavaScript first. People who find jQuery are going to use and love it. They are going to write ugly code, but they will actually be able to accomplish something. As time wears on, they will learn the finer points of the language.
Great points and definitely something a lot of developers have started waking up to recently. I could be way off base, but I kind of think that jQuery is to client-size coding what PHP is to backend coding (yes I know there aren't any other client-side languages but just follow me here for a sec). They can be used well in the hands of a competent programmer but they will absolutely let you write god-awful code, never complain, and let you think there's nothing wrong with what you're doing.<p>In the end its just another case of knowing your tools and when to use 'em.
Just to leave here the same comment I left on the blog. I completly agree, jQuery is an awesome tool. But developers need to learn how to write modular javascript before they start hitting on frameworks that provide shortcuts. I recently wrote a post about this issue. Mind if I share it? Feed back is welcome. <a href="http://franciscomsferreira.blogspot.com/2013/01/how-to-write-maintainable-javascript-or.html" rel="nofollow">http://franciscomsferreira.blogspot.com/2013/01/how-to-write...</a>
i definitely think frameworks are a huge help, however, i do believe that understanding the underlying source of the frameworks will help you even more. Use the framework as needed but truely understand why they chose the direction they went with in the framework/toolkit in order to better yourself and grow as a developer
jQuery exists for one simple reason : deal with DOM inconsistencies between browsers, and it works. Some people tested the code for you on all the browers so you can assume your code will work on all the main browsers out there.<p>Those who think they are too smart to use it certainly are not real web-developers in real businesses , having to support legacy browsers because their client base still run on IE6. or they have enough time to work on all the quirks of IE6 IE7 IE8 each time they write a DOM related function , i dont...<p>jQuery is here for quick DOM manipulation, is basically a facade pattern, and the bright idea was to use CSS selectors to query the dom.<p>jQuery selector engine is far more powerfull than document.querySelector<p>Why is it hard to work with the DOM ? because it is STRONGLY and staticaly typed ! it has interfaces and type checking , so using it with a dynamic/weakly typed language is hard. the DOM doesnt use duck typing , that's why can get all these DOM ERROR , invalid DOM LEVEL call ,and you cant create an Element or a Node without a factory etc ... and let's give credit to MS on this, they created DHTML because they understood it made little sense using that api with that language ( each time you are using innerHTML it is DHTML, querySelector to until it was made a standard ).<p>yet I dont see people saying they are too smart to use DHTML because it is not pure DOM. but do they really care about what interface is used ? how the factory method build the given objects ? i dont think so.