15

We're developing a snippet that is embedded in 3rd party sites, and uses jQuery.

The snippet checks if the site already has jQuery loaded. If so, it uses that library, otherwise it loads our own copy (currently jQuery 1.4.4, we're migrating to the latest soon).

There are breaking changes in jQuery. One such change, for example is the change in semantics of attr(), and introduction of prop().

Are there some guidelines to working with jQuery in a way that will be as backward compatible as possible? Even when we migrate to latest, we still want to use an existing jQuery library if it exists instead of loading a new copy, to save load time and resources.

Community
  • 1
  • 1
ripper234
  • 222,824
  • 274
  • 634
  • 905

3 Answers3

3

There are a few solutions to your problem

1. Use a subset of jQuery

Find the subset of jQuery that works upto a reasonable amount back and only use that subset.

Note that I recommend not using .attr at all, ever. since a) it's a minefield and b) it has different behaviour on different versions. You may find the sensible subset of jQuery is quite small. Good luck finding it.

2. Just use the latest version

Use the latest version of jQuery and tell your library users that they need to upgrade.

Seriously everyone should be using the latest version anyway, force them to upgrade.

3. Don't use jQuery

Don't have a dependency on jQuery.

Seriously, the less dependencies you have the better your code is

I prefer 3. as an optimum solution

Raynos
  • 166,823
  • 56
  • 351
  • 396
  • Wow, 3 is a harsh one. I don't think it's acceptable. And I can't force users to upgrade. This questions is aimed at item 1 on your list - but a good answer would have more details. – ripper234 Jan 25 '12 at 15:21
  • 1
    @ripper234 It's reasonable to force people to use the latest version of jQuery as a dependency on a module. People should be auto updating their versions of jQuery anyway. As for 3, the less dependencies you have the better your module is. – Raynos Jan 25 '12 at 15:27
  • Only if you want to limit your user base. That's a business decision, not a technical one. #3 is difficult for a medium-large app .. this is not a 200 LOC module. – ripper234 Jan 25 '12 at 17:13
  • 1
    @ripper234 I personally have dependencies on DOM polyfills for legacy browsers. And I just write code that works with the DOM, like any piece of code should. – Raynos Jan 25 '12 at 18:25
1

Take a look at these guidelines: http://www.davidtong.me/upgrading-jquery-from-1-4-x-to-1-6-1/

it's not the latest version available of jQuery, but it's enough hot.

Version 1.6.4 is a minor release

From version 1.6.4 to 1.7.x some new features and fixes were introduced but nothing seems is breaking code written for jQuery 1.6 version

Fabrizio Calderan
  • 120,726
  • 26
  • 164
  • 177
  • This is more about upgrading ... I guess we could base on these guidelines and write a new set of guidelines ourselves on how to write code that is version-agnostic. – ripper234 Jan 25 '12 at 15:25
  • It's not always possible to write code future-agnostic. E.g. you can still use .bind() and .unbind() but now jQuery team strongly suggest to use .on() and .off() instead. And maybe they will be replaced in future again. – Fabrizio Calderan Jan 25 '12 at 15:29
  • Well, I'm not looking for absolutes here, but rather for practical guidelines I can implement to improve my overall comparability. – ripper234 Jan 25 '12 at 15:54
0

This is one of my pet peeves with jQuery even though I love what it(jQuery) enables overall.

I wish the jQuery team would have addressed this early in development and created a version initialization method so you could "request" a specific version when building your library. Ideally, you'd have:

(function($, undefined) {
     // your code
}(jQuery.noConflict(false, "1.4.4")));

Where jQuery.noConflict would accept a "key" for which API version you would like to use for this library. Each jQuery loaded would check automatically if a previous jQuery was loaded and create a new reference entry for it in an associative array. (check for jQuery/$, request jQuery.jquery to get version, request jQuery.loadedVersions to obtain the previous associations, and build a master list of all loaded APIs) If no valid library was found, it could default to the latest available version or just kick out an error.

Of course, this doesn't help you (unless you want to modify a subset of jQuery APIs and keep them up to date yourself... /yuck) but short of that, it's a bit of a crap shoot.

noConflict will return the jQuery API if $ is not the current jQuery API (thus, not overwriting the $) but it doesn't really handle API conflicts and you'll only ever get the last jQuery API loaded. It would simply ignore the first loaded API (because it's not === to the current code scope jQuery object) and return itself.

Andir
  • 2,063
  • 1
  • 15
  • 22
  • I don't want to load another jQuery version ... so I don't see how this answer helps ... We're using `noConflict()`, but I'm asking specifically about guidelines for using other jQuery functions. – ripper234 Jan 25 '12 at 18:07
  • I'm not sure I understand then. If you want to create a library that works universally with all Jquery APIs you are up for some very complex and insane code.However, if you were creating a plugin and you target a JQuery version you can always get the jQuery version you wrote the plugin for and reference it's objects with what I suggested. (Edit: If you were able to use that I suggested above, you'd just have to instanciate your snippet with the 1.4.4 version of Jquery and not have to worry about what version is loaded and what features it supports.) – Andir Jan 25 '12 at 18:12
  • If your code has to cooperate with code from another supplier (otherwise you could just *always* load your own jQuery lib), then it probably isn't feasible to load another version on top of what you've got. After all, the last loaded library will stick, so *their* code may end up with a jQuery version that is incompatible with it. OTOH the entry point is the "jQuery" function, so choosing another name for the function might just be enough. – bart Jan 25 '12 at 20:37
  • Right, that's what I was saying. Without proper support from jQuery to do multiple version support you're going to have to do some ugly support checks to find out if the loaded jQuery does what you need it to. – Andir Jan 26 '12 at 15:11