Are there any javascript libraries that don't require updating when new browser versions come out?

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 func开发者_如何学运维tionality 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.

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).

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.

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

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.