S.T. said:
On 2/18/2010 4:26 PM, David Mark wrote:
[...]
If a script can't survive from one version of IE (or any major browser)
to the next, what possible shot does it have with older, unknown or
otherwise "unsupported" browsers. As Richard has said, such
multi-browser scripts can only be _expected_ to work in environments
where they have been _demonstrated_ to work (paraphrasing and emphasis
is mine). Taken to the extreme, due to the seemingly constant browser
revisions and automated delivery mechanisms such as Windows Update, you
really can't feel confident in anything you haven't tested _today_. And
seeing as IE - for example - has more configuration permutations than
can be tested in one lifetime, understanding and logic has to win out
over confused hacking by empirical observation.
I know what you're saying, but....
In my couple year's of jQuery experience, which is admittedly a small
sample being one developer, I've had virtually no issues with upgrading
-- both browsers and newer jQuery versions.
There's no question it can happen for some people in some contexts (and
it is a little hard to tell unless you talk to every visitor). But what
if I offered you a new type of calculator that makes calculations a
little easier and the only caveat is that occasionally, for some
operations, it may give an incorrect answer? And what if you had to
constantly upgrade it, else the invalid results will become more
prevalent, eventually degrading to all wrong answers? It may be hard to
spot the issues at first and if you constantly upgrade it you may never
spot them, but they are definitely there.
Specifically zero problems
when IE8 was introduced, zero problems swapping jQuery 1.2 for 1.3, and
the single problem I had upgrading to jQuery 1.4 was a plugin called
BlockUI failed.
The plug-ins are absolutely poison. Even the staunchest jQuery defender
will tell you that. And now that jQuery is releasing a new incompatible
version every month or so, it will just get worse as there is no way to
keep the third parties in sync. It just can't work, except
superficially (and not even that the way they are going).
And, let me tell you, there isn't a single version of jQuery that is
consistent from one IE version (or mode) to the next. You are just
straddling the very well-documented land mines. Take a step in any
direction and you could well blow up. That's not a good foundation in
any type of software development, particularly browser scripting.
I removed it's functionality in the interface in about
45 seconds and all was resolved (generally speaking, I avoid jQuery
plugins for this reason).
Good idea. But plug-ins are its main "selling point". Without those,
what have you got? It's a poorly designed API with almost zero
flexibility, a single $ factory function for every task and a very buggy
and inconsistent CSS selector query engine. All in about 70K, minified.
Perhaps I should explain what I do, as maybe a narrow niche makes me a
better candidate for jQuery than others.
It would have to be _very_ narrow.
My work (aside from occasional
freelance project) entails, basically, six projects - 2 public-facing
websites and 4 projects best described as intranet apps, two of which
are quite extensive.
You can't use that thing on the Web. There's no telling what
browsers/modes/configuration/plug-ins are in play. It's not a
cross-browser script, but a multi-browser stream of inferences based on
the observations of relative neophytes. Just don't. Your users will
thank you with more visits.
As a footnote, every single page on my sites is
DOCTYPE'd HTML4.01 Strict (aside from those outputting JSON, etc).
Okay. Good to avoid quirks mode and phony XHTML.
Perhaps that is among the reason I run into virtually no issues.
No. Avoiding quirks mode only sidesteps a few recent revelations (for
their developers). Everything else I've documented over the last few
years applies to either mode.
On the public websites, the javascript functionality is fairly trivial
stuff intended simply to enhance the experience for visitors, and to a
lesser degree for SEO.
You aren't doing your visitors any favors by making them download 70K of
jQuery to do trivial stuff. And what about SEO? For one, jQuery does
not do progressive enhancement at all. It isn't capable. You call a
method and it either works or blows up. It's like trying to defuse a
bomb by shaking it violently.
We're talking basic AJAX stuff, toggling some div
visibility for makeshift filtering of results, form validation, *very*
light animation to, etc.
Toggling styles is clearly trivial and the same for form validation,
which should work in any UA, not just the handful that the jQuery team
"supports" (they love to pretend that anything released last year has
ceased to exist, but the end-users are oblivious to their delusions).
And jQuery is terrible for animations, which are also trivial. It's got
a little bit of everything in it, but does virtually nothing well. It
has been well documented (here and elsewhere).
I can barely get Joe Surfer to consistently
realize he should click the giant orange button that says "Proceed" in
the event he wishes to proceed -- much less create complex interfaces
for public use.
Proceed to what? If your users are confused, it is your problem to
solve. jQuery can't help you there either.
Of my past month's visitors (roughly 20K), 98.8% of visitors are on
Safari3+, IE6+, FF2+ or Chrome -- or what jQuery claims to support
(granted, Android and iPhones will be lumped in there too.
"Claims" is the operative word.
And forget mobile with jQuery.
It's too large and lumbering (like a dinosaur), as well as inorganic due
to incessant interdependencies. The ugly truth is that jQuery is just a
brand. They are working on some "new jQuery" that will work "better" on
mobile devices. But why would you need two scripts? Wouldn't you then
need two sites? That's going in the wrong direction.
Also, you can't trust browser statistics at all, for reasons that have
been discussed here ad nauseam (search the archive).
More on that
below). If I add in Opera9+, not officially supported but seems to work
anyhow, its 0.2% share brings the total is 99%.
I assure you that jQuery isn't close to compatible with Opera 9 and it
goes downhill from there (e.g. Opera 8). And those things are in game
consoles (Wii), tons of fairly capable phones and other devices.
http://www.cinsoft.net/slickspeed.html
3.2% of last month's traffic was mobile (iPhone, iPod, Android and
Blackberry). Our site is a poor candidate for mobile browsers.
There you go. It is self-imposed.
We are in
the travel sector with an average transaction of ~$3600. Folks are not
using their mobile phones to plan $3600 travel packages, nor will they
in the near future.
Why not? It sounds like exactly the sort of site that _needs_ to work
on mobile devices (at least on the iPhone).
I can see the search terms mobile browsers use to
reach the site and they're ALL reference searches, not commercial
searches.
I don't follow.
I'm happy to help these guys out but, to put it bluntly,
reference seekers don't matter to my primary objective (sales/revenue).
Still. How do you pigeonhole potential customers?
Most are just seeking a phone number or property address - even if my
jQuery code is failing on those browsers (don't know, don't care)
they're unlikely to spot the error.
I really don't follow that. What they will likely spot is their browser
bogging down or crashing before they get a chance to read your pitch.
So on the public side I'm perfectly content with jQuery's limitations as
they don't have any negative impact except, possibly, the <1% of my
sites' non-mobile visitors using obscure browsers.
I think you are mistaken.
I don't know for
certain but can live with it regardless. Perhaps this is because I'm not
doing anything 'cutting edge', just some convenience for AJAX and DOM
selection and basic manipulation.
But you are using a sledgehammer to swat a fly and it is excluding
potential customers.
jQuery's advantages here aren't
dramatic either, but it's just faster, much much faster, for me to code
using it's wrappers. Since most visitors have it cached from Google
already, or worst-case an efficient CDN delivers it to them, I prefer to
use it.
No good. I just read a post from one of their UI guys explaining to a
user that their site was broken because the latest CDN jQuery was three
days behind the latest UI stuff and to please wait it out. And there
are lots of other reasons not to rely on a third-party host like that
(search the archive). Also, iPhones won't cache jQuery. It's too large.
Now on the intranet side my coding is a bit more 'adventurous'. More
dramatic appending and re-arranging the DOM, overlays to set crop marks
on photos, drag and drop, etc. More wide-ranging stuff that's a little
more suspect on the cross-browser front. But, being an intranet, I get
to tell the users to use the latest version of FF or Chrome -- or else
don't bother me if there's a problem. I don't bother to support IE
in-house largely because it's slow and due to it's rendering bugs.
You could do all of that without jQuery. Why don't you try mine as it
does actually work in IE.
Some still use IE on occasion (third-party airline res systems used
in-house require IE and they'll forget to switch browsers) and, while I
never bother to test any of my intranet stuff on IE, the only 'errors'
I've been called to fix were the result of non-jQuery stuff - awful
overflow: rendering or float: issues. In fact, since IE8 came out, all
my intranet stuff appears to work just fine except a) parts of my UI's
rely on CSS -*-border-radius: to look correct and b) re-arranging a
couple hundred DIVs on a sorting function still takes 5x longer vs. FF
or Chrome.
Yes, jQuery and its various plug-ins and widgets are notoriously slow.
From what I've seen they are now claiming that the latest rendition
(sixth so far in twelve months I think) has caught up to Dojo. They are
all lagging way behind context-specific solutions, as well as My
Library.
http://www.cinsoft.net/taskspeed.html
The development I'm doing on intranet sites is RIDICULOUSLY faster using
jQuery. For me, at least. Its AJAX and DOM selection,
You shouldn't be using that query engine. It's notoriously slipshod.
As for Ajax, download my Ajax module and be done with it.
As mentioned, they aren't very good at those.
bubbling for virtually all event types (since 1.4),
The whole "live" event thing is a sham (trying to bottle event
delegation because the original jQuery way of attaching a gazillion
listeners was pointed out to be outrageously inefficient). You don't
want to attach _every_ listener to the documentElement. Trust me as I
actually have some practical experience with event delegation.
And their endless attempts to "normalize" things like event bubbling are
just complicating something that is already way to complicated. These
are marketers, not scientists.
it's handy
Serialize() function couple with PHP's parse_str() -- all of it has sped
up development...
Form serialization? That was the first topic covered by CWR (search the
archive) and is alive and well in My Library. I'm sure mine will work
with PHP as well.
I'm guessing here... five-fold.
Guessing what?
Most importantly, it
allows me to code in a manner that feels much more comfortable to me.
I think you need to snap out of that. Kicking in a door may feel
rewarding (it does to me anyway), but a key works much better and is
unlikely to break the hinges.
Many compact, independent functions - easy to code, easy to debug.
jQuery has the worst sort of API. In fact, it really has no API (just a
single object with a lot of oddly named and "overloaded" methods). How
is it readable (or efficient) when you have to count the number of
arguments passed to a method to determine whether it is a get or a set?
Others might use a different coding mindset with jQuery but I like to
keep it simple, even if slightly inefficient.
Show me the code. I have to believe it (like most jQueried JS) is more
than a _little_ inefficient. And keeping it simple is a good thing, but
jQuery is outrageously complex (and error-prone, of course) under the hood.
I don't doubt you that attr() has issues, but not for what I'm using it
for.
How do you know? Which version of jQuery? It has changed just enough
over the years to cause obscure compatibility breakages, but has never
moved an inch towards something that makes sense. What is it you think
that function does? I can tell you that the documentation doesn't have
the answer and neither do the authors.
I'm not trying to change tabindex on the fly or convert an <input>
from 'text' to 'file' or use change a predefined input's 'value' that
may then conflict with a user-input value.
You have mistaken minor issues for the majors that are found in jQuery's
attr method. Search the archive (or just take my word for it at this
point).
Or whatever odd uses might
cause errors.
What do you consider odd? And do you know which odd uses cause problems
(which are not always manifested as errors, but silent inconsistencies).
This stuff can be hard enough to debug without adding a buggy
abstraction layer on top of the DOM.
I'd prefer it to be flawless, but it doesn't really matter
to me. I use it to switch an src,
Oops. The file URI properties/attributes are a big problem that they
don't handle properly. If you foul those up, depending on the user
cache settings, your slide shows may have hiccups.
or perhaps grab/switch an alt or title
as a hacky means of outputting SQL data into parts of the DOM. Works
fine for those purposes.
I don't follow that last bit. And how do you know it works fine? How
many modes, versions and configurations of the major browsers (even the
latest ones) have you tested thoroughly? ISTM that you are relying on
the alleged expertise of John Resig, who has been demonstrated to be
something less of an expert in this field (to put it very mildly).
Maybe jQuery over-advertises by calling itself "cross-browser".
It's a flat-out lie. It's multi-browser at best and shifts constantly
to "keep up" with the very latest browsers in their default
configurations, with default plug-ins enabled, etc., etc. That's not
how cross-browser scripting works. Cross-browser scripts don't fall
apart in new (or old) browsers for a start.
Maybe
"cross-current-major-desktop-browser" is more apt.
More apt, but still not accurate. Every jQuery script uses that attr
method to death. That method is not even cross-IE8-compatible (not by a
longshot). Wouldn't it be a good idea to consider my opinion on this?
http://www.cinsoft.net/attributes.html
For many of us, that's all we need.
But you aren't getting what you think you are getting. Not even close.
Maybe you're right and it's not a great choice for
"build it and forget about it" development -- most everything I do will
never live more than one IE cycle before being
revisited/enhanced/tweaked/completely rewritten anyhow regardless of
jQuery.
And why should that be?
Mostly jQuery gives me time, and a lot of it.
Ultimately it is a major time _thief_ due to the need for constant
upgrades and revisited regression testing (for those that bother with
minor details like that).
Faster development time
and the ability to code pretty advanced stuff without an extensive
knowledge of each browser's nuances, or need to learn it.
But in the time you spent learning jQuery...
That time, and
what I'm able to accomplish with it, is far more valuable to our bottom
line than a minute percentage of our traffic who may be struggling with
certain functionality on our sites because jQuery isn't perfect.
It's trivial to script a handful of modern browsers without jQuery. Why
not try it the other way before you try to compare the two methodologies?
My goal is not to cater our sites to 100% of the possible audience. My
goal is to maximize revenue and minimize expenses.
You absolutely, positively cannot do that with jQuery. Not on this planet.
In our company's case
I can assure you, in no uncertain terms, jQuery assists dramatically.
I hardly feel assured by such a general statement. What makes you think
it is doing anything positive for you? You need to try something else
before you can make a comparison.
Perhaps your library will become an even better choice for those in my
situation (for me, as a non-JS expert, once documented a bit better and
more sample code found to review can be found) and jQuery should have
followed the path you've taken to begin with -- but that still wouldn't
discount the value jQuery has provided.
Thanks for the vote of confidence! I hope I can help you in the future.
And more documentation is coming (a lot of it).
