jQuery support

Nao

  • Dadman with a boy
  • Posts: 16,063
jQuery support
« on May 6th, 2011, 05:12 PM »Last edited on February 8th, 2013, 10:33 AM
Feature: jQuery support
Developer: Nao
Target: modders, themers, users, geeks
Status: 100% (believed to be complete.)
Comment:

Many SMF mods tend to add jQuery headers to ease their work in the JavaScript department. They would tend to conflict with each other. Add to this various mods that make use of other librairies, and it's become clear that Wedge really needed to have jQuery by default, so as to provide a standard library for all modders.
Wedge offers to load the jQuery library from three different sources: local (if you want to use your own server to provide it and don't mind the extra load on your bandwidth), jQuery CDN or Google CDN. We recommend the Google CDN, which is the most reliable source for providing jQuery. In addition, it always loads fast, and chances are that the library will already be cached on your computer if you tend to visit other websites that also include jQuery from the Google CDN.
We strive to make Wedge compatible with the latest jQuery, but we're currently staying on the 1.5 branch, until they do something about their oversized library. ;)

:edit: They did -- so we're now following the latest branches.

Re: jQuery support
« Reply #16, on February 1st, 2013, 10:08 AM »
Why did they even introduce .on? What's wrong with .bind? I sincerely don't get it. It sounds stupid. You flick an electrical switch on and off, not a function! Bind/unbind make so much sense to me. I guess you can turn on an event, but you bind the function to the event. As in attach it.

Re: jQuery support
« Reply #17, on February 1st, 2013, 10:29 AM »
Quote from live627 on February 1st, 2013, 10:08 AM
Why did they even introduce .on? What's wrong with .bind? I sincerely don't get it. It sounds stupid.
http://blog.jquery.com/2011/09/28/jquery-1-7-beta-1-released/
They said it was to address an issue where unbinding an element would unbind another one. Which is due to the way they do delegate/live, but... What you gonna do eh?
The only point of these new functions, for me, is that they're shorter, and thus compress better. But because they didn't remove .bind/.unbind, jQuery itself is still larger than needed. To add insult to injury, they removed .live and .delegate, making it impossible to have code that's 100% compatible between 1.5.2 and 2.0... Pfft. I rewrote the .live in editor-func to a simpler .one() (it was begging for it, dunno why I forgot about that method!), but unfortunately I can't do anything about the .ip_button/.remove_button live events: it's got to be in one of the two formats... (Unless, of course, I rewrite the code to selectively spit out a .live or .on depending on the current jQuery version. Which sounds silly, because Wedge only supports one version at a time...)
Quote from live627 on February 1st, 2013, 10:08 AM
You flick an electrical switch on and off, not a function! Bind/unbind make so much sense to me. I guess you can turn on an event, but you bind the function to the event. As in attach it.
Yes, and .on() implies that you can only attach one event to the object.
Of course, they'll say that .on('click') is a reference to .onclick, but then what's .off('click') a reference to..?

Re: jQuery support
« Reply #18, on February 1st, 2013, 03:16 PM »
*scowls at jQuery*

Re: jQuery support
« Reply #19, on February 1st, 2013, 03:41 PM »
Correction, they didn't remove .delegate! Then only removed .live and .die, possibly to force users to update their code. Granted, .live is not as efficient as .delegate, but why not delete ALL at least from v2.0 so they could save more bytes...? I don't see the point.

Anyway.

My biggest problem right now is with .attr() vs .prop()... I was under the impression that jQuery had, from v1.6.1, turned back and decided to let people do as they wish. Apparently, their Migrate plugin indicates that they're back to the "use .prop if it's a property" thing...
Heck, if they could only provide a complete guide with what exactly needs to be converted. I don't see any. I have to GUESS. jQuery is there for SAVING time, not WASTING it... -_-
I even waste a dozen minutes earlier today when I saw they'd removed support for $().error(), and I thought $.post().error() (which we use in topic.js or post.js, something) was in the lot. It wasn't. I posted on their blog to complain that they should update their documentation about that.

My...
Give me another week like that, and I'll definitely write my own 10KB jQuery equivalent.

Re: jQuery support
« Reply #20, on February 1st, 2013, 04:11 PM »
The only thing I liked about .prop() for replacing .attr() was slightly saner handling of the checked attribute, as in you had to .attr('checked', 'checked') and .removeAttr('checked') to change it, but with .prop() it's simpler and could be done inline with a ternary expression.

Other than that it seemed like a change almost for the sake of change.

Re: jQuery support
« Reply #21, on February 1st, 2013, 04:14 PM »
Quote from Arantor on February 1st, 2013, 04:11 PM
The only thing I liked about .prop() for replacing .attr() was slightly saner handling of the checked attribute, as in you had to .attr('checked', 'checked') and .removeAttr('checked') to change it, but with .prop() it's simpler and could be done inline with a ternary expression.
Sure. But just for that one..? Not worth it.
Quote
Other than that it seemed like a change almost for the sake of change.
Which we don't want, either.

I'm starting to wonder whether it isn't too early to switch to jQuery 1.9+2.0... I mean, I'm only thinking of the 'release date', it'll be okay in that fashion, but what was the reason for the switch, already...? Saving 300-400 bytes in v2.0 for non-IE browsers..? Only that? Or something else? lol...

I would have better used my time today had I instead worked on thinking of the mini-skeleton implementation... :^^;:

Re: jQuery support
« Reply #22, on February 1st, 2013, 04:34 PM »
Quote
Sure. But just for that one..? Not worth it.
Of course it wasn't worth it just for that. But I can see the logic of a single unified beast for it.

The thing about it is that there's an awful lot of legacy stuff to keep in mind too.
Quote
I'm starting to wonder whether it isn't too early to switch to jQuery 1.9+2.0... I mean, I'm only thinking of the 'release date', it'll be okay in that fashion, but what was the reason for the switch, already...? Saving 300-400 bytes in v2.0 for non-IE browsers..? Only that? Or something else? lol...
I don't know... I'm fairly happy with what we have... *shrug*

Re: jQuery support
« Reply #23, on February 1st, 2013, 04:43 PM »
Quote from Arantor on February 1st, 2013, 04:34 PM
Of course it wasn't worth it just for that. But I can see the logic of a single unified beast for it.
It's unified to a limit... Doing the big jump is the hardest one, after that it should be fairly easy to upgrade jQuery along with the main one, but then again we have two codebases to keep up with -- one for oldIE, one for HTML5 browsers.
Quote
The thing about it is that there's an awful lot of legacy stuff to keep in mind too.
Like..?
Quote
I don't know... I'm fairly happy with what we have... *shrug*
v1.4: the shortest one... Has all the features we need.
v1.5: a bit bigger, not even sure it fixes anything. Just adds an Ajax rewrite that doesn't really change a thing, except for the callbacks.
v1.6: big pile of crap, followed by a 'mehh..' 1.6.1
v1.7: meh.
v1.8: meh.
v1.9: meh!
v2.0: no IE support, yay!

So, in order to be able to benefit from v2.0 (shorter + likely to have less bugs...???), we have to go through a larger version for oldIE, as well as potentially more bytes in our code because of the .prop() changes. (Oh, you know me -- I'll optimize the code here and there to at least compensate for the loss...)

To me, it makes sense to go back to 1.4, as much as it makes sense to stay at 1.5 or go for 1.9/2.0.
The main consideration should be plugin authors. What do you want? The latest & meanest? Or the old ones that may be more compatible with whatever plugin you want to use?

(It's interesting to note that the jQuery plugin server 'broke' for so long... It's as if they wanted people NOT to download old outdated plugins. It's a conspiracy :P)

Re: jQuery support
« Reply #24, on February 1st, 2013, 04:45 PM »
The main consideration is plugin authors. People are going to want to shove any old jQ plugin they find off the net into it expecting the most recent version. But jQuery itself has to be relatively mindful of its own legacy precisely because there's so much stuff out there built on top of it, so that major changes can't be done in a single version.

You say 1.4 has the features we need, but does it work with jQuery UI as bundled? Does that need rewriting/fetching an older version?

Re: jQuery support
« Reply #25, on February 1st, 2013, 05:23 PM »
I think jQuery 1.4 works with the latest 'legacy' jQuery UI, same as with v1.5...

http://w3techs.com/technologies/details/js-jquery/all/all

This page has interesting statistics for per-version usage.
As I thought, v1.4 is the most widely used 'legacy' version, i.e. that's when jQuery stabilized, having acquired all of its important features and fixed all of its major shortcomings. It went downhill after that, until the jQuery team made the (right) decision to focus on stripping code out of their codebase for v2.

But I was pretty sure v1.5 was more widely used than that. It isn't... However, even v1.4 is not that widely spread. It has a market share of about 20%, meaning that about 10% of all major websites use that version, and you have a relatively good chance of having it in your cache -- but it's not as good a chance as simply going for the most widely available version. As of now, it looks like it's v1.7, but I have good hopes that once we release Wedge to the public, v2.0 will be the most widely used one. (Or maybe v1.9...? That would not be as nice.)

Re: jQuery support
« Reply #26, on February 1st, 2013, 06:01 PM »
I'd say go with 2.0. You'll have to do the switch sooner or later. Because of plugin authors and the thousands of topics that will be open by people complaining Wedge to not have the latest jQuery. We choose not to adopt "Class A/B" browsers because of complaining users, an old jQuery version would be another complain indeed.. :P

Re: jQuery support
« Reply #27, on February 1st, 2013, 07:32 PM »
Alrighty.

I'm just annoyed by the .prop() thing right now... Everything else should be converted (I think), but .prop... It needs some looking into. I guess.
Re: jQuery support
« Reply #28, on February 2nd, 2013, 09:43 PM »
Still annoyed with .prop().
jQuery basically says, "you can keep using .attr, but you'll have to use .prop on a few things."
They never actually explain what the exact difference is.
Another blog says "you should convert EVERYTHING to .prop, it'll always work. Just work .attr if you need the original state of checkboxes and things like that."

I have yet to try the second solution, but it's quite tempting...

From what I could read online, there's an easy way to see the difference between attr and prop: take an anchor link where href="file.html". If you ask for .attr("href"), it'll return "file.html", while .prop("href" returns the entire path (including domain). In fact, .attr() is the equivalent of doing $('something')[0].getAttribute('attr'), while .prop is the equivalent of doing $('something')[0].prop -- now, that makes more sense to me! This is never actually explained in the jQuery documentations...
So, it does mean I should be able to convert .prop('src') and all things like that. But I don't know about, for instance, accessing XML tree attributes... Hopefully .prop() works. If I just need to rename all .attr to .prop, it'll just be easier for me. (And subsequent plugin authors.)

Re: jQuery support
« Reply #29, on February 2nd, 2013, 10:31 PM »
jQuery's documentation has always been a bit sub-par, I thought. Using .prop consistently, if it's an option, would likely be easier.

Re: jQuery support
« Reply #30, on February 3rd, 2013, 10:53 AM »
I'm astounded...

1/ There's an old jQuery blog post that mentions 'in passing' a list of properties that should be used by .prop(), and it's not "everything should use prop more or less", it's just the *boolean* properties that should go through .prop()...

2/ Even worse. I was completely misled both by the migration guide (read that particular paragraph!), and by the jQuery Migrate plugin's source code. While it does indicate that using .attr() for these shouldn't be done, it does NOT mean that the .attr() compatibility code was removed from jQuery 1.9/2.0, EVEN though the plugin proceeds to implement such compatibility... This is where I got screwed. Look for 'rboolean' in both jQuery 1.9 and jQuery Migrate plugin. They're both defined, and tested again. That's madness. I'm disgusted -- wasted a day trying to find proper documentation when all in all, it was still in it.

I sincerely hope that they never frigging enforce the .prop() behavior. If they do, I'll just resort to using it ONLY for boolean properties (the only difference is that a gzipped script.js+sbox.js will take an additional 3 bytes, as only .attr('readOnly', true) is concerned here.)
I will not waste another minute of my time trying to figure out what to do, what to change.

They still have a long list of things that should be checked against re: the upgrade guide... I'm very tempted to call it quits and just go with it.
I know I'll finish it, but I'm still pissed.
Posted: February 3rd, 2013, 10:03 AM
Quote from Nao on February 3rd, 2013, 10:03 AM
I sincerely hope that they never frigging enforce the .prop() behavior. If they do, I'll just resort to using it ONLY for boolean properties (the only difference is that a gzipped script.js+sbox.js will take an additional 3 bytes, as only .attr('readOnly', true) is concerned here.)
There are also two .attr('selected', true) lines in sbox.js, but I don't know if it'd change the byte count.
Not that it matters... As I said, it works right now, and I don't want to even think of separating the two functions.
jQuery's one and ONLY goal is to give developers helper functions to make their life easier. I don't *care* if it makes life hell for the jQuery team. It's not that I don't like them -- it's that they should be happy they're used on half the largest sites of the world. It means what they've been doing is USEFUL. It means they're making JavaScript FUN to use. It means they're making their life hell so that ours isn't. It's a sacrifice for the greater good. So I don't care that I should use .prop() instead of .attr(). So, .attr() is four times slower than .prop() when used on properties? Big deal. If my .attr() calls were time-sensitive, I wouldn't call object.attr(property) or .prop() at all -- I'd call the property directly on the DOM object, that's all.
It's not that I think they should revert their behavior, since that's what they did in 1.6.1... It's that I think they should stop telling people that using .attr() is bad. YES, we KNOW it's bad. Just like using jQuery is BAD on time-sensitive loops, but you'll never see them mention that, will you...? Nothing is bad per se. What is bad is what bothers you. What bothers me is a wasted byte in a gzipped file. That's why I switched Wedge to use jQuery 2.0 -- because it's smaller than v1.5 overall, not for the extra features or bug fixes.

Ahh... Feels good to talk about it.
Posted: February 3rd, 2013, 10:34 AM

I knew there was a Google result that made me jump to my guns and start looking into the migration plugin code! :lol:
https://github.com/bcardarella/client_side_validations/pull/466

So, I guess it was an 'unfortunate series of events' that led me to believe they'd dropped .attr() support for properties...