2

In my work I use dojo, and the experience I've had is that when a major browser upgrade occurs, some parts of the old version of dojo will break. In order to keep the web app working in the latest browser versions, you really have to keep updating to the latest version of dojo.

I'd like to know if this is the case for all javascript libraries, because I'm now working on a masters project which is a web app that my prof has already put into use. I'd like to use some of the nice functionality of a library, but I don't expect that I'll keep maintaining this project forever. I wouldn't want the app to stop working when browser upgrades come out.

Anyway if anyone has info or advice on this topic I would really appreciate it.

Gino Mempin
  • 25,369
  • 29
  • 96
  • 135
Maltiriel
  • 793
  • 2
  • 11
  • 28
  • 1
    Wouldn't it be great if we could develop code today that would not require maintenance, ever? I don't think you will be able to do what you want. The best bet is to go with an established library that will probably be still around as browsers improve. This way the update might be as simple as updating the library. But even then there is no guarantee that you won't have to update your code when new browsers are released. Sorry! – jdias Sep 20 '11 at 18:54
  • Since you have chosen an answer already Ill put it here: [mLibrary](http://www.cinsoft.net/mylib.html). – Knu Apr 27 '12 at 21:08

4 Answers4

2

Of course this is the case for all javascript libraries.

Browsers come out with new features or break features that worked with older versions. The only thing a library can do is release an updated version that deals with breakages.

If the code is live and needs to keep working, this is all you can do.

The only way to mitigate against it is to stick to standards and only use common functionality that is not a browser hack within the library of choice (which limits you greatly and is not guaranteed to help).

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • This may be a stupid question, but how do you tell what functionality is or isn't a browser hack, short of looking at the base code for everything you want to use? – Maltiriel Sep 20 '11 at 20:46
  • @Maltiriel - Not a stupid question at all. But yes, that would be just about the only way. – Oded Sep 20 '11 at 20:48
1

This is much broader than JavaScript. When new versions of OSes come out, native apps need some tweaking. When new versions of software come out, plugins need some tweaking. Anything that relies on something outside of itself is likely going to need some maintenance when that "something" changes. It does tend to be worse for JavaScript, though....

That doesn't mean it's completely hopeless. You can minimize the issues by following some guidelines:

  • Read the documentation of things you rely on, and stick to documented behavior. Things you just beat on until they "seem to work" are much more likely to break later because they're more likely to rely on undocumented functionality. The more you code things correctly (i.e. how the framework providers expect you to), the more likely that it will stay stable.

  • Keep the number of things you rely on as small as possible. If you rely on six things, one of them is going to break. If you rely on two things, it may be a lot longer before there's a problem.

  • Look for frameworks with a long track-record, and look at how they've behaved during upgrades. Unless the development team has a strong statement that they've changed their approach, you should expect the future to look like the past.

  • Keep the things you rely on simple. The bigger and more all-encompassing the framework, the more likely that some parts of it will have trouble when there's an underlying change. The corollary to this is: keep what you're doing simple. The more complicated your make your program, the more likely it will have problems.

  • If complexity is required, then it is usually better to be in the framework than in your code. It is more likely that a broadly-used framework will be carefully written to try to avoid future breaks than something random you write of similar complexity.

In the end, complex requirements lead to complex features lead to complex dependencies lead to fragile upgrades. Keep your requirements simple, and your upgrades will be more seamless. There is a trade-off between flashy/fancy and long-term robust. If long-term maintenance is a high cost for you, then keep it simple.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • In light of your answer, what libraries would you recommend? How can I judge which one is simpler than another? – Maltiriel Sep 20 '11 at 20:38
  • Personally I'd go with jQuery Core as offering a reasonable set of trade-offs. I don't know if I'd say the same of jQuery UI, though, given your concern of maintenance. I'd be tempted to keep the UI as simple as possible, with minimal effects. I haven't taken jQuery through a browser upgrade on a production system, so someone with more experience with that may have some thoughts. – Rob Napier Sep 20 '11 at 21:55
0

Javascript libraries are not browser-dependent, it would be impossible to manage libraries if it was like that.

  • I'll admit I haven't looked at the dojo code specifically, but I don't see how else to explain functionality breaking when IE 7 and 8 came out. My understanding has always been that javascript libraries use browser specific code to accomplish neat tricks; they hide it so you don't have to mess with it. – Maltiriel Sep 20 '11 at 20:45
  • @Maltiriel It is IE’s fault, They normally break their Javascript support in every new release, as well as CSS, and many other things which web developers have to always deal with. If you are worried about people using IE, when visiting your site... try using http://marious-alex.co.cc/ie-alert/ to make them upgrade. –  Sep 20 '11 at 21:29
  • It's NOT just IE. Our apps had issues when Firefox 4 came out, too. Personally I think using any sort of trick to try and force people not to use their browser of choice is far more likely to result in users never using your app rather than actually convincing them to switch. That's why I would never use that kind of thing. It's better to deal with the occasional update of the js library. – Maltiriel Sep 20 '11 at 21:45
  • Just as you say, breaks are very occasional in other browsers than IE. IE is the king when it is about breaking a lot when there are minor updates. –  Sep 20 '11 at 22:18
-1

Your best bet is to go with JQuery... you might need to update it, not for compatibility, but for new, improved features at least. But it will be updated frequently enough to keep compatibility current. Remember that updating a library doesn't necessarily mean updating the code, thanks to backwards compatibility.

AJC
  • 1,853
  • 1
  • 17
  • 28