I am incredibly thankful that jQuery exists. The other day I had to code some basic javascript in a environment where embedding jQuery wasn't an option (too much overhead) - boy what a PITA. Basic stuff like writing selectors took forever and I had to resolve to "low level" coding. What would have taken a couple of seconds in jQuery took several hours of research, and trial and error. I planned on adding a basic fading/sliding effect - forget about it. Takes to much time in ordinary javascript.
So thanks John Resig and the rest of the jQuery dev team for making us web dev guys more productive and actually making JavaScript fun.
Question is for how long. I've written several thousand lines of native, cross-browser javascript some years ago and from time to time again. But i don't remember a lot of the workarounds, from the top of my head.
Fiddling with cross-browser support is something that my brain don't like to keep today, be it js or css. Things like jQuery for js and compass for css come in handy to brush over that. :)
Pretty much any environment where you care about performance of your code, actually. A lot of the simple-looking jquery stuff is implemented with tons of indirection, branching, etc.
Just compare the work a browser has to do for something like:
Now the good thing is that most consumers of jquery don't care about performance of their code (in that they're doing small enough amounts of stuff it doesn't matter much).
> Now the good thing is that most consumers of jquery don't
> care about performance of their code
Many do, but more do care about cross-browser compatibility and when you need to support IE6,7 home-rolled code is not likely to cut all the research and effort that's embedded in jQuery.
In most cases, though, using jquery to do something like adding a class, or setting a value, is still plenty fast enough. We're talking about code that runs in the browser, where things move on human timescales. Don't optimize prematurely.
The problems start when you add a class to 10,000 elements on the page. And yes, I've seen pages doing this with jquery where the jquery overhead was what made the difference between a 20ms operation (not user-perceptible) and a 1s operation (very much user-perceptible).
I really do realize computer systems and software are primarily designed
for normal people rather than the disabled. I also understand the vastly
competitive world of web development and the advantages of having a cool
looking, feature rich site.
None the less, I take offense to the part of jquery-ui that is hijacking
the web browser UI. It is remapping keys and pointer usage (text
selection). This should have never been allowed in the W3C and
EMACscript (javascript) standards. Hijacking the browser UI of a
disabled person is like kicking the crutches out from under someone just
to see them fall and because you think it will make you look cool to
others.
Web developers never know how a user-agent is configured and never
know the needs of the person using the web browser. Changing how the UI
normally works really does hurt, confuse and infuriate many people, and
probably more than just the disabled folks.
Sure, disabled people are a very small part of the population, and they
typically are not the rich consumers buying the latest and greatest.
They may not be your target market, your real customer concern, but
excluding them with browser hijacking is unnecessary, and in some ways
unfair.
I'm not really sure what you're responding to, specifically. You do realize that jQuery UI (and jQuery Mobile) are both ARIA compliant, right? This means that it's actually far easier to use these UIs then you might expect.
John, it might be a day or four for me to type them up, but I mail you the test cases, configs, code and details where jquery-ui breaks when it hijacks the UI of the browser. I've tracked the problem to a faulty assumption, namely assuming the user-agent doesn't already have any existing user specified key bindings defined for special needs access. The conflict breaks all key bindings, including the defaults.
Not sure that jQuery deserves to be blamed for shoddy interface coding. Any competent web developer knows that you always start out by designing your interfaces so that they work with scripts and plugins disabled [1]. If some - ok, most - devs choose to ignore this design principle then jQuery is hardly to blame.
[1] Obviously there are situations when it simply isn't possible to create fully accessible solutions. Sometimes our hands are tied by management, tech stack requirements, etc.
You're right on many points, of course, but hyperboles of cruelty like "kicking the crutches out...just to see them fall and...you think it will make you look cool" don't seem to be grounded in reality.
Your criticism is fair, and I should have written something better. I won't edit the original and I'll stand by my mistake since it would make your comment seem off.
The thing to realize is I was REALLY trying to contain my temper when the hyperbole slipped out. It's tough be positive while share a perspective of frustration few developers ever see.
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.
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).
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?
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).
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.
So thanks John Resig and the rest of the jQuery dev team for making us web dev guys more productive and actually making JavaScript fun.