I agree with the overall message- you should be thoughtful with all your dependencies. You should only add complexity when it makes sense.

However, the author goes beyond just selector vs. getElementById().

Does the way the author uses XMLHttpRequest work in other browsers the way it works in IE? I honestly dont even remember anymore.

How about the code for fade? I never even knew the details of this feature. And I'm not sure I want to.

IE has been basically standards-compliant for XHR since IE9, and possibly before:

http://www.w3.org/TR/XMLHttpRequest/#interface-xmlhttpreques...

http://msdn.microsoft.com/en-us/library/ie/ms535874(v=vs.85)...

For IE9, don't you need IE-specific code for cross domain requests?

Yeah, you need XDomainRequest for CORS requests in IE8 and 9. IE10 is fully standards-compliant.

http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdoma...

It is very castrated, better to use hidden iframe + window.postMessage for cors in ie8 and ie9.

I don't think "castrated" is the word you meant :-) Perhaps "constrained" or "restricted"

...why not?

"to render impotent or deprive of vitality"

Funny, because IE invented XHR.

For fading, I recommend just adding or removing a class and let css transitions do the job. If you dont mind it not working in IE8 of course

and IE9: http://caniuse.com/css-transitions.

Pedantry aside, your point stands, CSS transitions can use the GPU and degrade gracefully.

Considering XMLHttpRequest is what other browsers used before IE caught up, I assume it does work the way you'd expect across modern browsers. I'd have to check the standard and IE8+'s conformance to the standard to be sure. That's what this post is really about for me, reminding that modern browsers follow a standard that allows for getting rid of most of jQuery. Reading it also made me recall a post from 2005 by PHP's creator: http://rajshekhar.net/blog/archives/85-Rasmus-30-second-AJAX... (Note IE uses ActiveXObject.)

XMLHttpRequest was first introduced in IE5. I think in retrospect MS regrets its introduction, but that is another discussion entirely.

As I recall, they specifically implemented it in order to facilitate Outlook’s web interface – their collective regret may be tempered by the satisfaction they got from all those high-margin site license sales to which that feature contributed.

I wouldn't mind hearing a snippet of that discussion. Why would MS regret XMLHttpRequest?

Microsoft twiddled its thumbs while the web grew up and around Windows using the technology the company introduced.

That makes complete sense. Never thought of it that way.

For me jquery is all about events. Making sure I get the event tree bubbling in the correct way across the entire universe of browsers and all its data being normalized is such a time saver. Even their support isn't perfect, but I'm sure its way better than any other event library out there in terms of breadth and depth of testing. The selectors bit is a nice to have, but that is getting easier since its inclusion in dom itself.

Since I code mostly in clojurescript in my home hours any functional idioms from jQuery I no longer use. A long time ago jresig joked about making an oo form of jQuery. It's not that funny now, as it might be slightly easier to wrap an object based lib for all the various compile down to js languages (typescript, coffeescript, clojurescript, scalajs, etc)

About one year ago, I developed a shared widget. Some fraction of my clients refused to load jQuery, as they still preferred older, less popular DOM libraries.

Starting with jQuery's battle-tested event handling code, I trimmed features unnecessary for my widget: event.data, IE7 support, consistent focus events. I replaced jQuery's indispensable descendant selector feature, formerly jQuery.delegate, with a simple conditional in my event handlers. (e.g. Walk parentNode references from event.target, looking for a class name.)

I was left with about 75 lines of code in my DOM abstraction library. I preserved jQuery's tricks for Microsoft's attachEvent and Safari's text nodes. About 15 lines were dedicated to normalizing attributes. My polyfills for preventDefault and stopPropagation were about 10 lines each.

It's amazing how far native DOM has come in recent years.

If you are looking for a standalone event (delegation) library check out one I wrote http://craig.is/riding/gators. The syntax is very similar to jQuery.

Two things:

1) The minified jquery script is ~100kb, for a script that is loaded once per website that's pretty tiny. Especially when you consider the fact that the latency involved with opening the network connection to fetch the file will likely exceed the time required to pull the file down. Once you've initiated the download the difference between pulling down 20kb and 100kb isn't all that much.

2) You can use the google jquery file reference. That means a big % of your site visitors will already have the cached script in memory, and for those that don't the download will be pretty speedy given that it can be fetched from the google domain in the background (while the rest of your site assets are being fetched by the browser).

It might be the most cached file on the internet. Pulling jQuery is hardly expensive. Especially if you're pulling it from the google cdn.

Caching or CDN does not help in squeezing out JS performance (actual JS execution and not n/w performance)

You think that a page that loads jQuery but doesn't use most of it incurs a performance penalty? I'll grant there are a few initializations and dom checks that jQuery does, but it probably blocks for all of 20ms.

...which is significant.

20ms is significant?

Think of it as a fifth of your time budget spent doing nothing.

Most modern browsers are able to paint while loading script files, especially if you put your script files at the bottom of the page, where they belong. So, no, 20ms of parsing, compiling, and a small amount of execution is not a lot of time. Period.

caching won't help for libraries that want to have a particular version of jquery baked in ...

> I believe the point is that many libraries use about 1% of jQuery. That hardly justifies pulling in the entire thing.

Sure, but if you use a few libraries that all use a couple features of jQuery you still only need to load jQuery one time and everything just works. You may not care if it only works on the most modern browsers, but someone who uses your library probably will.

Or you need jQuery two times because one of the plugins you need is not well maintained and depends on an older version. This actually happens.

$('#something') and document.getElementById('something') are not quite the same thing because of what you'll do after you create that reference.

document.querySelectorAll() uses the same kind of syntax for selectors as jQuery.

And requires IE 9+ which rules it out for a lot of people...

Actually, no. IE8 supports it.

http://caniuse.com/queryselector

IE8 is limited to the old CSS selectors so basically it sucks and doesn't really support it.

In practice, especially for javascript usage, the old CSS selectors cover all the bases.

The new-stuff, while great for styling, isn't all that relevant for scripting. nth-child, say, is often (though not always) simply an indexing operation on the return value of querySelectorAll; and in general you don't even want that since usually you have a specific element in mind and have labelled that element with a class to find it.

I don't support IE8 anymore, and use CSS3 liberally in the actual css, yet I can't think of more than a handful of cases I used the selectors from javascript, certainly none of them critical. Do you actually use this?

But so is all of the actual CSS in your app.

and support only a limited subset of the selectors jQuery supports.

> $("#something") instead of document.getElementById("something")

or even just document.querySelectorAll("#something")

You lose some browser compatibility with qSA, whereas gEBId works everywhere. You need IE8+ for qSA, and you need to ensure the page isn't in quirks mode. If you're OK with that then you can also do: var $ = document.querySelectorAll.

Probably best to do this within a closure so that you're not hijacking any jQuery instances that may be on the page.

Would just like to point out that, if you are using a commonly used CDN, jQuery/Zepto will most likely be cached already in the browser.

So why not break up a large library into smaller useful pieces. Why can't we import only what we need.

You can create a custom build of jQuery and exclude specific modules: https://github.com/jquery/jquery#modules.