Did anyone else consider the "currency localization" bit silly? I mean, Apple can pull it off to sell songs for 0.99USD, 0.99UKP or 0.99EUR, respectively, but if my locale determines the currency, I'd rather read Japanese dates and pay 1000 Yen for something than read English dates and pay 1000 Pounds for the same thing. (roughly: 1000 Yen ~ 10$, 1000 Pounds ~ 1500$)
tl;dr: IMO, currency is an example where localization has to be server-side (exchange rates, sale taxes, yadda yadda ...)
The thing I found most interesting was that Microsoft chose to release the source via GitHub rather than CodePlex. Perhaps I'm reading too much into it, but the hopeful part of me looks at that as going _with_ the community, rather than trying to shepherd the community to where MS wants them to go. Then again, I guess that was true of their (long overdue) decision to abandon MS AJAX in favor of jQuery, as well.
I've been wanting to move over to jquery for my newer sites for a while, but it's always been just a bit too big to force users to download. Worse, every time I hear about them, it's because they've added more extraneous crap to it.
Is there a subset of jquery that I can pull in that just does the basic DOM stuff that makes it so useful, yet fits into 5k?
The smallest I've seen it pack down to is about 70k, which is bigger than most of the pages I server. Hell, that's bigger than the entire javascript component of Twiddla!
Which bits do you consider "extraneous crap"? The only part that I feel could fit that description is the Events part. Is there anything else you feel doesn't belong in the core jquery?
The current version is about 24kB gzipped. Also given the ubiquity of jquery and the popularity of the Google hosted version, chances are your users already has jquery in their browser cache. Just slap http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min... at the top your pages and don't worry too much about it.
I'd consider a library to handle i18n in javascript to be extraneous, thus the comment.
The current version is 71k before gzipping, which is how you compare it apples-to-apples to everything else that you serve, since everything gets gzipped before it goes out the door and it's easier to compare file sizes on the server than it is to sniff traffic as it goes past. It's a bit dishonest for them to promote it that way on their site. They might as well say it's 0k, since your browser will have it cached.
I guess my point is that it's just not useful enough to make up for the bandwidth it takes up. I mean sure, 10 years ago when browsers were genuinely dissimilar, it made sense to abstract out DOM calls. But now, document.getElementById("id").style.width will work exactly the same on every single browser, so all jQuery does is save you a bit of typing.
I guess today, all you really need is
window.$ = document.getElementById
and maybe a home-rolled map function and 50 lines of xmlhttprequest code.
> I'd consider a library to handle i18n in javascript to be extraneous, thus the comment.
It may be extraneous, but it has nothing to do with the size of jQuery core: it's a plugin, not part of the actual library. jQuery has a plugin system that lets people add features to extend its functionality.
Actually, most of the posts that mention jQuery are really plugins, not features of jQuery itself.
The list of things actually included in the latest release is in the API docs. It's actually not a very long list of functions; I expect most of the code bloat is for dealing with browser quirks.
