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