S.T. said:
[in response to Matt Kruse]
You are in a small subset of developers that use jQuery by choice, yet
are also highly critical of it. In fact you might be the only person
I've read that shares those characteristics. Not that there's anything
wrong with that, just a somewhat unique view.
You can put me in that category as well.
The category of those who abdicate responsibility for cross-browser
scripting to the jQuery authors (of all people), despite being told
repeatedly of their collective incompetence?
I find that JQuery often
simplifies my development, but I recognize many flaws in it and would
love to see something more solid come along to take it's place.
It only allow creates the illusion of simplifying your development.
Odd that you can't see that after all of the related discussions.
And why do you need something to take its place? It's a 70K QSA
wrapper. As we've been over repeatedly, CSS selector queries are
highly ill-advised and there aren't many "supported" browsers left
that lack QSA anyway. What's left to replace? A ham-fisted API that
is completely inappropriate for browser scripting?
But
those need to be libraries that I would feel comfortable handing off
to a client to continue with, which leaves out, for instance, My
Library.
That makes no sense at all. You'd feel comfortable handing off a
script that you know is full of holes? And unlike jQuery, the code in
My Library is relatively easy to follow. So what's your point? If
the client Googles the name they won't find tons of gushing blog posts
and bad examples?
At the moment, JQuery seems the best of a fairly bad bunch.
And what seems to indicate that? Like the rest, it calls QSA (with
very little in the way of feature testing) and hands off to a proven
mess of unfinished nonsense in the event of an error.
http://www.cinsoft.net/slickspeed.html
But, of course, you've already seen that. IIRC, your position was
that the demonstrably execrable results were somehow my fault for
"trying to break it".
But I
really don't want to skip a library altogether.
Why? Cross-browser scripting is relatively easy these days, making
jQuery and the like antiquated notions. By far, they create more
problems than they solve.
Yes, I trust my own
skills enough to believe I could do everything that's done in those
libraries, but I really don't want to spend the time.
And therein lies the problem. If you would stop and think about it,
you would realize that you don't need most of what is in those
libraries, not to mention the fact that those libraries have failed
miserably (over the course several years) at their shared goal. They
are selling both problems and (very bad) solutions. Using them over
and over leaves you with no solutions of your own, which is your own
fault.
And I don't
think it's *that* bad.
Software either works or it doesn't. Software authors have talent or
they don't. Some apologists like to point to Windows as a product
that is not "that bad", but still pervasive. Of course, the
difference between a completely transparent 70K script and an OS
should be apparent.
What has jQuery done for you, other than leave you short of time and
code and therefore perpetually dependent on it? And what will you do
when new browsers shed more light on its appalling inferences? Go
back and "upgrade" all of your clients to a new jQuery and hope that
it all works out? Seems like a hard way to go, particularly in light
of the ongoing education of the script's authors and their penchant
for breaking compatibility (with browsers as well as their own
scripts). Assuming the applications don't fall apart (something that
will take new rounds of QA testing to determine), do your clients then
need to post disclaimers about the new jQuery breaking anything
released since last year? And will the end-users even know what to
make of such a disclaimer?
In stark contrast, I didn't have to alter a single line to accommodate
IE 8, FF 3, Safari 4, Chrome, Opera 9.5, Opera 10, Opera 10.5, etc.
And I recently tried out the Build Test page in the IE 9 "preview" and
everything worked in both HTML and XHTML DOM's. Furthermore, my users
(as well as participants in this group) have tried it in all sorts of
mobile devices (from brand new to ancient), game consoles, etc.
without issue.
That doesn't mean it is perfect (it isn't), just demonstrably superior
to the "major" libraries, each of which has required frantic efforts
to "keep up" with just the latest versions of a handful of modern
desktop browsers (in their default configurations) and left a trail of
broken browsers behind them (e.g. Opera 9.x, FF2, etc.) To this date,
none of them have come close to "solving" IE 6 and 7, which are
largely the same and by far the most used browsers of the last
decade. Recently, they've taken to calling for a "ban" on those
browsers (despite the obvious futility and IE7's persistence in IE8)
as a substitute "solution".
I have recently fixed bugs for ancient browsers that the other
libraries couldn't support if they wanted to and that gives me
confidence that the script will run in browsers that I haven't heard
of or have never tested (including those that haven't been invented
yet). None of the fixes involved browser-specific code and most were
trivial (e.g. one line to fix an FF1.0 issue, two lines to fix NN4,
another line to fix Opera 6, etc.) I had never bothered to look at
such browsers and clearly didn't write perfect feature detection/
testing for every conceivable environment. But plugging the holes
didn't have the slightest effect on the code's size, performance or
the compatibility with the more recent browsers.
Why should such a contrast exist? Because, relatively speaking, the
authors of jQuery, Prototype, YUI, Dojo, Qooxdoo, SproutCore,
Cappucinno, Closure, etc. haven't got the slightest idea what they are
doing. Over the years, overwhelming evidence has been published (here
and elsewhere) to prove this fact beyond any reasonable doubt. The
only people who fail to grasp this are those who lack a basic
understanding of the subject and those who are completely out to lunch
(e.g. VK). Even the authors of some of these libraries have woken up
of late and decided to scrap their previous efforts and start over
(e.g. Prototype). And to address a previous "point" made earlier in
this interminable thread, stating such is not a "personal smear". I
mean, would you buy an English-language book by an author with a
demonstrably shaky grasp of the English language? By the same token,
you shouldn't abdicate responsibility for browser scripting to
author(s) with a demonstrably shaky grasp of Javascript and its
interaction with browsers.
Unsurprisingly, I have clients who have been using custom builds of My
Library for years without issue. Still more use context-specific
scripts that continue to perform properly, despite the lack of any
sort of GP library. Others simply write (or IM) when they find
themselves stuck (and perhaps leaning towards using a bad script) and
invariably I talk them down by suggesting a solution that avoids the
problem. That's how professional browser scripting is supposed to
work. It requires experience, thinking and yes, actually writing code
rather than piggy-backing on top of popular junk found on the Web. On
the other hand, selling lifetime subscriptions to dubious open source
projects is about as unprofessional as it gets. In many cases it is
downright fraudulent.
