jQuery support

Nao

  • Dadman with a boy
  • Posts: 16,079
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 #1, on January 5th, 2013, 02:49 PM »
I noticed today that jQuery released a beta version of v1.9 three weeks ago.
It removes a few features that Wedge uses (such as .hover()), nothing that can't be added back manually or just modified anyway, so that's good, and the uglified (packed) version, once zipped, is about 1KB shorter than version 1.7, which is good.
However, it's still 3KB more than jQuery 1.5... I thought their plans was to release a 'final' version for earlier IE compatibility (i.e. v1.9), and a 'semi-final' version for other browsers (i.e. v2.0), without any of the IE compatibility code. I honestly doubt that the IE compat code is more than a couple of kilobytes when gzipped, so it makes it unlikely that there are any filesize advantages in the end over earlier versions of jQuery. Bummer.
I don't see any bugs arising from the use of v1.5.2 these days, so I'd be tempted to call it quits and leave it at v1.5, but I'd like to get opinions on this.
Of course, 29KB versus 32KB isn't much in the end ('only' 10%), and I'd like to delve into the new features, but I don't know what's best for now.

Re: jQuery support
« Reply #2, on January 5th, 2013, 03:15 PM »
Well, the only thing that strikes me as important is jQuery UI compatibility - when finding jQuery UI, I had to find the right version, specifically an older version, that would work on our version of jQuery.

Keeping with older versions of jQuery isn't likely to generate significant bugs, but it might cause trouble for mod authors just using scripts they've found elsewhere on the net, especially if it expects 1.6+ syntax and functionality regarding .prop() I believe it was called.

* Arantor does not particularly like JS.

Re: jQuery support
« Reply #3, on January 5th, 2013, 05:04 PM »
I have a tendency to like JS more than PHP these days, mostly because the 'reward' is immediate and I've always been into real-time rendering. I'm starting to learn Java btw, I'd be willing to bet you hate that one and you're ready to write a 20-page essay on why I shouldn't bother with it :eheh:

Anyway, right now I don't know... What interested me in jQuery 1.9/2.0 is that the team pretty much promised that it would be the last major version (i.e. if we want to add another feature, we'll just write a plugin for it), which is interesting because it has potentially the widest future market share for jQuery versions.

Re: jQuery support
« Reply #4, on January 5th, 2013, 06:11 PM »
<preaching>I have specific issues with specific bits of Java. The two big things are the broken security model and the way everything is turned into classes, and by extension the way you can have multiple copies of a method with the same name but different call signatures. What you end up with is a series of classes with increasingly ridiculously long names. The consequential 'write once run anywhere' myth doesn't work either.</preaching>

Java has a place, and not just because of the amount of code written in it. But you'll never convince me to run it in the browser, and the fact that I've had to deal with users who can't move Java versions because of code that absolutely depends on 1.4 or 1.5 rather than later versions just irritates >_<

Here endeth the lesson.
Quote
which is interesting because it has potentially the widest future market share for jQuery versions.
That's interesting, actually. I'd be inclined to upgrade to that for future compatibility purposes.

Re: jQuery support
« Reply #5, on January 5th, 2013, 06:17 PM »
If you remain with 1.5 now you'll have to upgrade in the future anyway. So maybe upgrading now would save you from this task next, and as said it would help plugin authors (without counting all the questions you would avoid like "why does wedge run an old version of jquery?? Pls update it s00n").

Re: jQuery support
« Reply #6, on January 5th, 2013, 06:25 PM »
No-one's actually noticed except me anyway ;)

Re: jQuery support
« Reply #7, on January 5th, 2013, 06:31 PM »
Newer versions of jquery have some nice speed improvements plus the plugins are being written for them these days anyway, I'd upgrade now. The size vs speed trade kind of balances out.

Re: jQuery support
« Reply #8, on January 17th, 2013, 07:14 PM »
So... It seems that jQuery 1.9 final is out, and 2.0 beta is out too :)

The good news is that v2.0 is around the same size as v1.5.2. When gzipped, it's even actually a bit shorter (by around half a KB). It doesn't support old IEs though, so we'll have to include both versions in our repo, and load v1.9 for IE < 9, which is fine by me. Heck, it's not my bandwidth anyway :P

I'll have to work on finishing the conversion to v2.0, though... I suspect I'll have a lot to do. Especially since v1.6 and v1.7 already changed a lot of things themselves.

Re: jQuery support
« Reply #9, on January 17th, 2013, 07:56 PM »
Fair enough, as long as 1.9 is available for those who don't want/can't use a CDN copy.

Re: jQuery support
« Reply #10, on January 17th, 2013, 09:37 PM »
Both versions will be available in CDN anyway...
1.9 = for IE 6,7,8.
2.0 = for everything else.
They promise that 2.0 final will be even smaller :)

I'm interested in seeing how they're gonna handle the torture of wanting to add a new feature and being forced to do it via a plugin because they're not planning to do further major releases after that one... :^^;:

Re: jQuery support
« Reply #11, on January 17th, 2013, 10:13 PM »
Yes... but not everyone will be *using* CDN, that's my point.

I won't use CDN at all, ever, but that's just me being picky. Intranets for example won't necessarily have CDN facilities to make it work.

Re: jQuery support
« Reply #12, on January 18th, 2013, 05:17 AM »
The largest SMF install is an intranet install which doesn't access the Internet

Re: jQuery support
« Reply #13, on January 18th, 2013, 05:20 AM »
Yup. That's always going to be the case in terms of its size because it has to be self contained, as a result jQuery etc. must be local - and must provide all relevant versions of things.

I haven't compared the install size of SMF and Wedge lately but I suspect it would not be entirely favourable, even if I were to even the playing field by neatening up the languages folder, though that's really a side note in the grand scheme of things - and there are things we can cut if we really need to, though I'd rather have functionality than keeping it small. Just as long as we don't get into the territory that MediaWiki is in; the base installation package is now 68MB of uncompressed files.

Re: jQuery support
« Reply #14, on January 18th, 2013, 05:33 PM »
SMF 2.0 = 6.5 MB
SMF 2.1 = 7.2 MB (latest)
Wedge = 11.4 MB (latest)

Also...

I was wondering... Should we use //urls instead of http://urls? This is supported by all browsers, the only situation where it doesn't work is if you're browsing via file://. Other than that, it saves bytes and all. But ultimately, the best way to save bytes is to also do the same on all other URLs... And that's where I'm starting to wonder and wander...

So, yeah, I updated the jQuery URLs to use the https protocol if the current website is running on https.
At least THAT is done. :P
Re: jQuery support
« Reply #15, on February 1st, 2013, 09:18 AM »
Quote from Nao on January 17th, 2013, 09:37 PM
I'm interested in seeing how they're gonna handle the torture of wanting to add a new feature and being forced to do it via a plugin because they're not planning to do further major releases after that one... :^^;:
Some people say they'll just release a version 1.10 for IE and 2.1 for non-IE, and so on...

Okay, I've started working on the upgrade to jQuery 1.9/2.0.

One thing I have to say.
.on()/.off() is utter bollocks.

Because .unbind('click') shares a 'bind('click')' with .bind('click'), it compresses very well. While .on and .off don't share the same 'suffix'.
That means the actual compression rate is not as good as I thought it would be. Maybe it would help if I turned all .click() calls to .on('click'), but I did try that in the 1.5 days and it was disappointed and I reverted it.

Considering that .bind and .unbind are not deprecated (probably because they're used so much... So what's the point eh?), I could keep using them. But, fact is, I *do* save a couple of bytes per gzipped file when using .on(). The real only drawback is that we lose compatibility with 1.6 and below.

So, do you think we should keep .bind or drop it..?