Hacker News Reader

Comment by jherdman | Hacker News Reader

Really? Why ever not? What do they prefer?

Something lighter than 238kb. I remember when jquery first came out, and ExtJS was around that size (actually a bit larger) and one of the big popularity factors of jQuery was a much smaller library size.

Also some places like Apple have their own internal js frameworks and want folks who know and can code bare-metal js.

There's Zepto.js.

For desktop browsers, use the Google CDN and your users probably won't download a thing. And for free, you get sane DOM interaction, and an enormous body of work papering over the differences between browsers.

For desktop browsers, use the Google CDN and your users probably won't download a thing.

And Google is one step closer to tracking everything everyone does on every website.

As if now forcing people to deploy Google Analytics on their websites if they want keyword data from Google wasn't enough, do we really want to help and encourage Google to get in a position where they effectively control the entire internet?

One company controls over 90% of internet search and referral and they actually have the power to kill any company they don't like. Right now they may be behaving, but what if some competitor comes along which is showing some edge? Can we trust Google to do the right thing?

Google also hosts files needed by a majority of websites. They also withhold information from you about you and your site and force you to register an account with them and deploy their software on your sites to get access to a subset of that information. And you are encouraging people to help that company get a stronger grip. For what benefit? At what cost? Sorry for not being a fanboy, but try looking at the bigger picture here.

Would you be OK with one company controlling the entire Internet if that company was Apple? If it was Microsoft?

Hosting your own 23kb jQuery file does not cost that much. Actually practically nothing. Not in terms of bandwidth and neither in terms of perceived performance. Unless you are hosting your website on a 36.6kbps modem, host your own. Do the web some good.

> And Google is one step closer to tracking everything everyone does on every website.

As long as you link the right files (make sure you specify the specific version and not use the one to give the lastest), there are very long expires headers and Google will have no idea the vast majority of your users ever visited. A user just needs to visit one site using the same version of Google hosted jQuery and they won't have to download it again when visiting another site.

> Hosting your own 23kb jQuery file does not cost that much. Actually practically nothing. Not in terms of bandwidth and neither in terms of perceived performance. Unless you are hosting your website on a 36.6kbps modem, host your own. Do the web some good.

People aren't using Google CDN for the cost, but for the performance. A high percentage of user will have the file cached already, so the performance gain is quite significant. Doubly so in a mobile environment.

I don't really get this viewpoint, you can load JQuery once then it's cached. Is a barely noticeable load time difference really worth the extra power and time saving you get from JQuery?

jQuery is not 238KB in any form that you would ship to a user. It is a 29KB minified and gzipped - which is a world of difference and perfectly acceptable for mobile use (likely smaller than most images you'll be using on your site, for example).

Of course if you have IE6, gzip can be a problem.

If you have IE6, then gzip is the least of your problems.

Ah yes, blame the user. That's always the best policy.

But he's blaming the browser.

I downloaded the minified version yesterday: 88kb. 1/3 the size of what you're claiming. You shouldn't be using the development version for production uses (no reason).

And 88kb isn't even gziped. When it's actually downloaded from your (or a CDN's) server it's less than 30kb.

If you use a CDN isn't it cached across multiple sites?

MooTools. I hate jQuery's api, but Id rather use it than vanilla JS for the majority of the things that I do with JS.

Just curious: what in particular do you hate about it?

I find it to be very confusing and difficult to do very complicated things with. You have methods like position, or height, or width that all deal with the element. But size deals with the size of the collection and not the element. There are multiple ways to add events/delegate events and some are frowned upon in favor of others. The plugin system doesn't allow you to make reference to the instance of the plugin (without what seems to be a hack), I really dislike the fact that you have to constantly wrap element in the jQuery object, even if they exist in a collection inside of a jQuery object, and I just dislike how it uses argument overloading for most of its methods (sometimes its an obj literal, sometimes it can be a string, if its a string then the args found in the obj liters go in this order after the string, etc)

But like I said, I would rather use it than have to come up with a bunch of cross browser supported js on my own. The guys behind the lib are clearly JavaScript rockstars :) while I am fan. I just find the lib's api and general approach to problem solving to be a bit wonky and dont really understand "the ease of use" that everyone touts it having.

what's the problem with using the jquery selector? i mean you can always just assign objects to a variable like:

var elemt = $('#elementID')

and then you can call something like elemt.hide() or whatever.

Reply on news.ycombinator.com