How can I deal with outdated versions of jQuery on a client site?

Try and make the clients aware that the "resources" needed are typically pretty light. Converting to a new version is usually a very quick process, unless they had a lot of erroneous code that was allowed before, but incorrect.

Have them take a look at the release notes for 1.4, and for that matter 1.4.1 and 1.4.2, the benefits of the upgrade far outweigh the time it takes to upgrade in every case I've come across. The only caveat to this is in the 1.4 upgrade specifically, the added JSON strictness. From the 1.4 release notes:

jQuery 1.3 and earlier used JavaScript’s eval to evaluate incoming JSON. jQuery 1.4 uses the native JSON parser if available. It also validates incoming JSON for validity, so malformed JSON (for instance {foo: "bar"}) will be rejected by jQuery in jQuery.getJSON and when specifying “json” as the dataType of an Ajax request.

This means JSON operations are much faster, but old/invalid JSON won't cut it. If they have to go fixing web-services because the JSON has to be absolutely valid in 1.4+, this could be a show-stopper on an upgrade for a large project...and I'm not sure what to tell you on that one.

As for plugins...every major/popular plugin supports new releases very quickly, if not they're pretty quick to fix yourself...and many just don't need any editing at all, because they weren't broken by the upgrade (still, check for new versions of a plugin, they may get performance boosts from a new version of core).

I can modify the template: So, I guess it might be possible to put something on each page ... which could "notify" the *template* that it needs 1.4 (and tell it to **not** include 1.3) ... not sure about the performance repercussion of that however?

Justin Jenkins 2010-07-19 10:51:21

@Justin any server-side languages available? PHP? ASP?

Pekka 2010-07-19 10:52:42

@Justin can you write something into the `head` section of each file *before* jQuery is included, or can that be done only centrally in the template?

Pekka 2010-07-19 10:53:35

@Justin are *your* pages in their own directory?

Pekka 2010-07-19 10:54:42

@Pekka I could write something with jQuery 1.3 to the head AFTER 1.3 is included ... would that work? :) The client really doesn't want to use anything server side (more their issue then mine.) ASP.net (with PHP available) but they are weary of any server side stuff (I know wack.)

Justin Jenkins 2010-07-19 11:01:21

@Justin nope, once the `<script src....>` has been issued it is too late.... It would be very elegantly solvable in a server-side language by checking the current URL (`REQUEST_URI` in Apache). If it is in "your" app's directory, output the 1.4 `<script>` directive, otherwise the 1.3 one. If the directory is not an option to distinguish your project, then you'd have to come up with some naming convention for your pages `contactform.1-4.html` or whatever, you get my drift.

Pekka 2010-07-19 11:05:45

Hum since I can edit the template ... what if I wrapped the <script src....> of 1.3 in some JS script (clearly not in jQuery) that I could have MY page tell which version to load? And if the page didn't say which version to load, "else" to 1.3 ... am I crazy?

Justin Jenkins 2010-07-19 11:10:03

@Justin I thought about that as well, it should be possible. You could parse `location.href` or check your custom variable you specified before (`jquery_version = "1.4";`). It's only that `document.write()` doesn't work in the `head` AFAIK, so you'd have to create the script object using `createElement`. Probably possible - maybe worth a separate question.

Pekka 2010-07-19 11:13:10

Justin Jenkins 2010-07-19 11:16:29

In other words ... The client has many, many pages on their site that would break if upgraded to 1.4 (mostly due to bad code ...) so the entire template can't be upgraded as it would break said pages. However those pages have nothing to do with the newer project.

Justin Jenkins 2010-07-19 10:46:08

If it has nothing to do with the new project you are working on.. why worry about the pages using 1.3? work on your project with 1.4 as you are comfortable with it and follow Nick's advice on making the clients aware

Abdel Olakara 2010-07-19 10:55:05

1.3 does have to do with my project in that 1.3 is included in the site wide template (which my pages need) ... and I need 1.4 on my page, and NOT 1.3

Justin Jenkins 2010-07-19 11:04:09

Thank you resource, and for the vote of confidence in 1.4 ... I too believe it would be worth the upgrade and that helps a lot.

Justin Jenkins 2010-07-19 10:47:47

+1 this is really the way to go.

Pekka 2010-07-19 10:49:48

FWIW, you could monkey-patch the jQuery.parseJSON(json) function to use the old eval() way if you really need support for broken JSON.

AKX 2010-07-19 10:52:52

Justin Jenkins 2010-07-19 10:57:17

@Justin - It is...but the time doesn't matter, it's how many changes in the release, and there weren't that many breaking changes from 1.3 to 1.4, can you give a few examples of breaks it creates? I might be able to answer a bit narrower if I had some examples :)

Nick Craver 2010-07-19 11:00:28

@Nick Crave it seems to be mostly their (uhm not so great) custom code and some plugins that don't work ... and that's not really my problem it's theirs. Thanks for the offer tho.

Justin Jenkins 2010-07-19 11:03:05

ansaurus

tags:

views:

answers:

How can I deal with outdated versions of jQuery on a client site?

related questions