jQuery + IE8--told you so

[Timo Reitz]

Worst case scenario: Everything you claim about the library is correct
and it's complete rubbish that will blow up in our faces when Browser
X is released. I don't use JavaScript to provide critical
functionality on any website, so the worst thing that would happen is
that the site would be without JS for Browser X until (a) the jQuery
team came up with a fix, which is likely, or (b) we rewrote our
scripts that make use of jQuery, which mostly do some client-side form
validation and a few drop-down menus.

"without JS"? But it's still there, just with a library with an undesired
behaviour. That's not the same! The part of your scripts which changes
something (so it could not be used without JS anymore) may be still
functional, while the part that does the work stops working.

 

[David Mark]

"without JS"? But it's still there, just with a library with an undesired
behaviour. That's not the same! The part of your scripts which changes
something (so it could not be used without JS anymore) may be still
functional, while the part that does the work stops working.

Exactly. Botched attempts at progressive enhancements are very common
and typically render pages unusable. jQuery provides no mechanism to
determine if and when things will work as expected (or not), so it
provides no way to avoid breaking documents. In short, calling apps
blunder right into exceptions with no recourse. It would take a real
fool (or fools) to implement progressive enhancement in this way.

 

[Matt Kruse]

And if you must run a "corrected" version, then you know something is
broken.

Of course. I have several corrections in a local versions. And my own
hacked-up versions of some plugins.

 Why did you not submit a ticket?  

I contribute when the effort to do so is minimal and the potential
benefits to me make it worth it. This is not my job. If I point out
something on the dev mailing list, someone else will submit a ticket.
I find the process annoying.

Why did you not answer any
of the misunderstood questions in the forum(s).

I do answer questions there, randomly. Just like I participate here
randomly.

 Why would you question my assessments about the problem?

I'm not sure I ever did. At least not the technical side of it. The
implications of the problems, well we certainly disagree there.

To you, broken functionality means the whole thing is junk. To me,
broken functionality gets factored into the pro/con list for using the
tool, and gives you something to avoid or patch. No big deal. For me
it's fairly effortless to fix the things in jQuery that I consider
broken enough to need it. If those things get fixed in the core code,
then I just remove that part of my wrapper.

 You are obviously a complete hypocrite.

Nope, I just don't play in the world the way you want me to.

Also, how do you figure that your vague promises about future
overhauls mean anything?  If you had been paying attention way back
when, it wouldn't need an overhaul (hint: overhauls are a major pain
in the ass for everyone involved, not to mention a waste of money.)

They may be a pain in the ass, they may not. Depends on what part of
jQuery you use and what they change. Of course, if things work as-is,
there is no need to upgrade at all.

I've always told people not to rely on jQuery plugins (despite having
written one myself), and _certainly_ not on a stack of plugins with
dependencies. Upgrading to the latest version of jQuery didn't affect
me, AFAIK. If it did, I would either patch my code or my jQuery
wrapper.

I do think that developers using jQuery need some guidance. For
example:

1. Avoid plugins
2. Use POJS and normal DOM methods whenever it makes sense rather than
"the jQuery way"
3. Don't depend on attr()
4. Don't use jQuery on public-facing production sites where you aren't
willing to sacrifice a small percentage of users due to
incompatibility
5. Don't do lots of "progressive enhancement" using $(document).ready
() such as attaching hundreds of event listeners
6. Don't make repeated calls to $() for the same selector - instead,
cache the results into a variable
7. If you require high performance, break out of jQuery and manipulate
the DOM the old fashioned way
8. Use event delegation

In fact, some of these are part of a "jQuery Best Practices" document
I've written and will probably publish at some point.

With that being said, though, I use jQuery because of things like
this:

$('#container').css('position','absolute').animate({left:'+50px'});

How fun is that? It does exactly what I want. Sure, I could write my
own animation methods, but why? This works well, is easy to write, and
even has nice easing effects by default.

And stuff like that is why I use jQuery.

Matt Kruse

 

[David Mark]

Of course. I have several corrections in a local versions. And my own
hacked-up versions of some plugins.

Thank you.

I contribute when the effort to do so is minimal and the potential
benefits to me make it worth it. This is not my job. If I point out
something on the dev mailing list, someone else will submit a ticket.
I find the process annoying.

All that shit about me not submitting tickets, being "unhelpful" was
just a waste of time, wasn't it?

I do answer questions there, randomly. Just like I participate here
randomly.

That's an apt description.

I'm not sure I ever did. At least not the technical side of it. The
implications of the problems, well we certainly disagree there.

To you, broken functionality means the whole thing is junk. To me,
broken functionality gets factored into the pro/con list for using the
tool, and gives you something to avoid or patch. No big deal. For me
it's fairly effortless to fix the things in jQuery that I consider
broken enough to need it. If those things get fixed in the core code,
then I just remove that part of my wrapper.

Shut up.

Nope, I just don't play in the world the way you want me to.


They may be a pain in the ass, they may not. Depends on what part of
jQuery you use and what they change. Of course, if things work as-is,
there is no need to upgrade at all.

Shut up.

I've always told people not to rely on jQuery plugins (despite having
written one myself), and _certainly_ not on a stack of plugins with
dependencies. Upgrading to the latest version of jQuery didn't affect
me, AFAIK. If it did, I would either patch my code or my jQuery
wrapper.

Dear God.

I do think that developers using jQuery need some guidance. For
example:

1. Avoid plugins
2. Use POJS and normal DOM methods whenever it makes sense rather than
"the jQuery way"

So, if I may jump in to sum up. Avoid jQuery plug-ins and avoid
jQuery whenever possible. Do you hear yourself?

3. Don't depend on attr()

Too bad the entire culture revolves around that method.

4. Don't use jQuery on public-facing production sites where you aren't
willing to sacrifice a small percentage of users due to
incompatibility

LOL. A small percentage?

5. Don't do lots of "progressive enhancement" using $(document).ready

But, but, but... That's the "jQuery way!" Oh, see #2.

() such as attaching hundreds of event listeners
6. Don't make repeated calls to $() for the same selector - instead,
cache the results into a variable

Too bad the entire culture revolves around that technique. They've
never heard of "caching" references to host objects.

7. If you require high performance, break out of jQuery and manipulate
the DOM the old fashioned way

If I could reach through the monitor and strangle you at this point,
you can believe I would. Why have you wasted all of this time, just
to make all of my points for me?

8. Use event delegation

Thanks for that tip, professor. What does this have to do with
jQuery.

In fact, some of these are part of a "jQuery Best Practices" document
I've written and will probably publish at some point.

You've got a best-seller there for sure!

With that being said, though, I use jQuery because of things like
this:

  $('#container').css('position','absolute').animate({left:'+50px'});

(Test your code before posting.)

In other words, you are a complete prat. That ridiculous chaining,
which saved you nothing but some whitespace (which will likely be
minified out of the equation anyway) makes debugging a nightmare (even
before minification.)

var el = document.getElementById('container');
el.style.position = 'absolute';

Never mind the animation. The default browsers for Mac and Windows
come with that built-in. The others will follow. Whatever your next
call, it is just another line:

animate(el, {left:'+50px'});

Which is simpler? One long, ugly mess or three concise lines? We
know which is simpler to debug.

How fun is that? It does exactly what I want. Sure, I could write my

Not fun at all. It does not do exactly what you want. You have no
idea what it does (in many cases.) You only have your own empirical
evidence, which doesn't add up to an argument.

own animation methods, but why? This works well, is easy to write, and
even has nice easing effects by default.

Little need to write animation methods at this point (or at all in the
near future.) Many good examples out there. And easing functions are
one-liners, genius. Copy all you want, they'll make more. Certainly
no need to tangle up animation and easing with a CSS selector query
engine (or the rest of Resig's interdependent follies.)

You can't even update a one-line function (or add new ones) without
breaking compatibility. And you have to upgrade every time as they
never get things right, so you can't break compatibility. Your
arguments go around in cirles.

And stuff like that is why I use jQuery.

And why you should be considered a less than reliable source of
information on Javascript, browser scripting or programming in general.

 

[Thomas Allen]

"without JS"? But it's still there, just with a library with an undesired
behaviour. That's not the same! The part of your scripts which changes
something (so it could not be used without JS anymore) may be still
functional, while the part that does the work stops working.

By "without JS," I meant "without features provided by jQuery," as I
was referring to sites with mainly jQuery-derived functionality in the
first place. As I typically use

$(document).ready(function() { ...

to add onload events, these sites that lean on jQuery probably would
in fact lose all JS functionality (which, like I said, consists of non-
essentials, because I make sure that all of my sites work well with JS
absent).

But so far, so good. I honestly wasn't too worried about the upgrade
process for a browser that is gradually becoming more standards-
compliant.

Thomas

 

[Eric Bednarz]

True, true.

To be fair, I probably hate jQuery much more then David does, with
probably much better reasons, I just don’t enjoy these long pointless
threads.

 

[David Mark]

To be fair, I probably hate jQuery much more then David does, with
probably much better reasons, I just don’t enjoy these long pointless
threads.

Well, are they better reasons or not? Would you be willing to file a
ticket on them?

 

[Eric Bednarz]

To be fair, I probably hate jQuery much more then David does, with
probably much better reasons, […]

Well, are they better reasons or not?

That depends on your point of view (all of the following would be true
for me even if your technical criticism were not valid).

I don’t mind so much if people wanna use jQuery on their own website or
one man company work, but I do mind it on the work floor a lot. While I
can sort of see its appeal for front-end developers who quickly want to
prototype behaviour in a website mockup, it creates the delusion (also
at the management level) that something is ‘about 95% finished’ after
that; all what is usually needed then is somebody to tear down the brick
wall that has the remaining “5%†on its other side (guess who is *not*
going to do *that*, especially when it turns out that those 5% require
500% of the previous development time ;-).

And it seems to encourage trial & error spaghetti code that has to be
totally rewritten. That’s the curse of quickly and easily ‘prototyping’
applications, instead of design you get a lot of ad hoc features
patched together.