Related
Some of the projects we're working on have strong roots in jQuery 1.4.2 or earlier, and somewhere between lacking the performance edge (or syntactic sugar) of the latest releases, the humiliation of using now-deprecated methods, and the discomfort of deploying a 3+ year old version of an actively maintained library, an upgrade is now imminent.
What are some practices popular in the community that we could adopt/re-visit to ensure a smooth rollout (i.e. focus on obscure compatibility issues, picking up global regressions, re-factoring some of the older code...)? How would they be best integrated into SDLC for future upgrades? What is a reasonable upgrade schedule for a library such as jQuery (I don't anticipate significant gains or justifyable costs to do so with every point release, but once every 6-12 months may very well be reasonable)?
To actually answer your three questions, here are some things I've done or at least recommend:
Best practices for a smooth upgrade rollout
Have tests. These can be unit tests for your JS and/or browser tests. These should cover at least the most typical and the most complex functionality used within your projects. If you don't have tests, write them. If you don't want to write tests, reconsider. If you reeeeally don't want to write tests, at least have a list of use cases that someone will be able to execute manually.
Make sure all your tests pass before the upgrade.
Read the release notes for every (major) version between the version you use now and the most current release. See also the Removed and Deprecated categories in the API docs. If any of your code uses jQuery UI, also look at those release notes and upgrade guides for the interstitial versions. As you do this, make note of the things you would likely have to change in your codebase (possibly making heavy use of grep).
If your project's current jQuery version is >= 1.6.4, also consider using the jQuery Migrate plugin to further assess the work required.
Decide on which version you want to be your upgrade target, based on the work required to get there, whether your project is using any third-party libraries that require a certain version of jQuery, other factors only you can consider, etc.
Meet with your team to go over the list of changes to be done to your codebase, and divide/assign the work accordingly. Maybe write some scripts or other tools to help out. If you have one, your team's coding style guide / best practices document may also need to be updated. Decide on one-shot (recommended) or rolling update releases, if that's possible+desirable. Come up with a suitable release strategy. (I recommend against releasing the upgrade as part of another unrelated large change to your codebase, so it's easy to roll back if you need to.)
Throughout the upgrade process, continually run your tests. When testing manually, always monitor the browser console for new errors. Write new tests that cover unexpected errors.
When all tests pass, decide on how you want to roll out--if it's a site, all users at once or a percentage at a time, etc. For a library or other project, maybe you'd release a beta/bleeding edge version that you can let your more ambitious users test out for you in the wild.
Document everything you just did so it will be easier for the next time.
[Profit.]
How to integrate upgrades into normal workflow
Again, tests. Make sure you have them. Make sure they're good, maintained, and cover a large portion of your codebase and use cases. A continuous integration setup to automate the running of these tests is highly recommended.
Consider getting your team to create and agree to follow a coding style guide or standard. This will make it easier in the future to search for deprecated function calls or constructs, since everyone would be following similar coding patterns. Tools such as scripts, commit hooks, static analysis utils, etc. to enforce good or sniff out bad coding style might be useful (depending on the team).
Investigate and maybe decide to use a package manager like NPM or bower to manage jQuery versions and other third party libraries you might use that depend on it. (You'll still need to maintain your own JS code and go through pretty much the same process as above.)
Again, once you're past version 1.6.4, make sure the Migrate plugin is part of your upgrade workflow.
Assess what worked from the initial big upgrade process, what didn't work, and extract a general process from this that works best with your current workflow. Whether or not you plan to upgrade every time there's a new version, there will be ongoing maintenance tasks and habits that you'd probably want to keep as general development best practices.
Reasonable upgrade schedule
That's essentially a CBA/risk management question. You'll have to weigh some things:
There should be no breaking API changes within the same major version, so you should generally be able to upgrade to the most recent minor version with minimal effort, no refactoring required. This assumes you have and maintain good tests, which you can run on your projects before you decide that all is well enough for a rollout.
Major version upgrades require more research, more refactoring, and more testing. After the research step, you should do a cost-benefit analysis of upgrading.
This might not matter much, but if any of your projects is a website that has many users, what would be the cost of making all of your users have to download essentially all of the changed JS files on your site the next time they visit it (instead of sticking with the older versions that are probably still cached in their browsers)?
The decision to upgrade should always be a subjective one. Minor or major, you'll still have to justify each time whether any upgrade would be worth it. Always read the release notes. Does it fix a security vulnerability or a bug related to issues that you or your users are currently experiencing? Would it significantly improve the performance of your project (be sure to have benchmarks to verify it later)? Does it greatly simplify a coding pattern you've been using, allowing your code to be written more cleanly and easily? Is there a third-party library you want to use that is dependent on this newer version? Are there third-party libraries you already use which are dependent upon the older version? (If so, are these libraries likely to be upgraded anytime soon to work with the newer version?) Are you that confident in your tests and QA process that an upgrade will take a reasonable amount of development resources and cause no major regressions? Were you thinking of eventually switching out jQuery with something else anyway? Etc.
Of course this is just my advice. There are a few recurring themes in it, and I hope they are clear. In any case, I hope someone finds this helpful!
You will always be outdated. Once you are done updating to the latest version, a newer one will come out a few months later.
Unless you are willing to put hours/days/weeks of development, testing and bugfixing, with the possibility of breaking user-facing functionality, you shouldn't be updating just to use the newest way of declaring event handlers. It won't hurt you. And normally this is a risky thing to do. This translates into dev team costs. You already know this. Refactoring, especially when there is no evident risk for the project, is in general hard to justify to managers. And you should double check your thoughts to be sure if having the new jQuery in code that is already working will make any difference.
Now, if you are working on creating new pages in an existing site, you could be including a new version in those areas. But, this will have a consequence: lets assume that you and your team, apart from developing the new part of the site, also have to maintain the part that is using the old one. Everybody will need to be aware of the specific version of jQuery they are writing their code against.
So, to close, I would say something like this. Unless there is real justifiable risk for the project to be delayed or to be technically blocked because of an older jQuery version, you are going to be getting into trouble for breaking something that is already working and will need to put extra hours just to make everything work as well as it was working before.
Anyway, this approach doesn't mean that you could start separating the 'new sections' from the old ones, and using the newest libraries in the new areas.
This is worth looking into: https://github.com/jquery/jquery-migrate/#readme
This plugin can be used to detect and restore APIs or features that
have been deprecated in jQuery and removed as of version 1.9. See the
warnings page for more information regarding messages the plugin
generates. For more information about the changes made in jQuery 1.9,
see the upgrade guide and blog post.
The Twitter guys have solved this problem quite nicely.
http://github.com/twitter/bower
It does what it says on the tin - it is a package manager for the web (and that includes keeping JS files like JQuery up to date)
In order to keep up to date in your development tree, I recommend using src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.js" (the full un-minified version which allows for easier debugging)
Then when you go to publish, just replace it with the specific minified version that is in the header comment (currently http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js) This has the bonus of allowing better client side caching and using someone else's bandwidth.
If caching is less of a concern than ensuring that it will automatically get bugfixes for that minor version release, you can use just the major and minor version such as: http://ajax.googleapis.com/ajax/libs/jquery/1.9/jquery.min.js (Note: google doesn't yet have the 1.9 series up; however the 1.8 series is up to 1.8.3) Since these get updated periodically for bug fix releases they don't get cached like the version specific releases
In this era we cannot be predictable about the stability of the any software versions. Few years Before the versions of software and services releases after a year or two year. But at this time the versions of the services are updating rapidly and frequently.
So if you are using any service with your service you have to use Agile Development. By this development method you can easily make changes in the new requirements and change the required methods according to you.
And please don't use depreciated methods because they are not suitable for long-time service versions. And make libraries of the used services of library of your own service function that are using other services so that you can easily change them according to your new version.
For example : like you have a method name update_var(); it is calling a another method of other service like $a = newlib::check_update();. Then by creating libraries you have to change the main library of the function of your and the core library of the involved service
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.
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.
Ext.js is of interest to me because it appears to have a fairly complete widget set (though I've certainly run into shortcomings of the widgets after a very short time). The problems I potentially have with it, however, include these:
in my opinion it's very ugly, and looks like a cross between a Windows UI and some PHP content management system (yes I know I can write my own theme, but there may be limits to what I can change, and it may not be as easy as it should be, and I'd rather work with something that is clean, elegant, and attractive out of the box.)
the graphs currently use Flash, which limits the clients it can be useful on (version 4 promises to resolve this problem)
the license is a bit restrictive, which is not an issue now, but it makes me think twice about becoming intimately familiar with a tool that I may not be able to use in the future.
Honestly the look & feel is probably the biggest issue to me: I've seen in the past that developers (or companies) who don't place a high value on aesthetics often can't be bothered by other 'details' either.
So: is there a other better alternative?
UPDATE:
Another problem with Ext.js, is that it seems to be an all-or-nothing proposition. That's one reason I'm not looking seriously at SproutCore, which in other respects is awesome. (Well... it needs some performance improvements, but it'll get there eventually I think...)
Cappuccino seems to be the same way: you're not using it on a web page, rather you're building a Cappuccino app that just happens to use the web as its runtime environment.
In other words, ideally I don't want a JS version of Flex: it's own little walled garden. jQueryUI would be ideal if it were more complete, since it doesn't break with normal web development methods and paradigms. But if walled gardens are all there are, I'll live with it.
If you are looking for a RIA-Framework you shouldn't use jQuery(UI). Instead use one of the following frameworks.
Qooxdoo (www.qooxdoo.org): Pure Open-Source RIA-Framework with the most of the features of ExtJS. There were coming up some interessting new themes in the last weeks
Cappuccino (http://cappuccino.org): Nice framework with a nice GUI
ZK (http://www.zkoss.org/): ExtJS like RIA-Framework
SproutCore (http://www.sproutcore.com/): Apple-Style RIA-Framework
I undestand your pain - I use to got same - in ExtJS I saw only problems (those what you mentioned, and belive me much more others), however because I was a little forced to use it, I started to use it and I followed in love - It very complex and optimal solution for javascript driven apps.
You can go and look for alternatives like jQuery (I was there for 1 year), dojo, and others frameworks, but whoever says that they are better than ExtJS, he rather did not have ..... time to know ExtJS
It my very subjective opinion
I dont know much about PHP, and I am using ExtJS with ASP.Net MVC, they fit well. I wish I could use an integrated JS Widget set, but Jquery UI widget set was not rich enough when I last evaluated and I dont think it still is. But it is at least included in the last version of MVC.
My only complain about ExtJS would be the number of user extension controls that you need to use, I'd like to see those as part of ExtJS core widget set, but they are not, but still distributed with the library. ExtJS is a very nice fit for a cross-platform Rich Web Application. I would recommend trying ExtJS, I have really no complains about it other that what I already said above.
Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?
The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.
Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe
"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.
We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).
I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?
Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.
We currently have a quite complex business application that contains a huge lot of JavaScript code for making the user interface & interaction feel as close to working with a traditional desktop application as possible (since that's what our users want). Over the years, this Javascript code has grown and grown, making it hard to manage & maintain and making it ever more likely that adding new functionallity will break some existing one. Needless to say, lots of this code also isn't state of the art anymore.
Thus, we have some ongoing discussion whether the client-side part of the application should be written anew in either Flex or Silverlight, or written anew with some state of the art JavaScript framework like jQuery, or whether we should simply carry on with what we have and gradually try to replace the worst bits of the existing code. What makes this even harder to decide is that writing the UI anew will probable cost us 6-12 person months.
I'd like to hear your thoughts on that issue (maybe some of you have already had to make a similar decission).
EDIT: To answer some of the questions that came up with the answers: The back-end code is written in C#, the target audience are (usually) non-technical users from the companies we sell the software to (not the general public, but not strictly internal users either), the software 'only' has to run in desktop browsers but not necessarily on mobile devices, and the client app is a full-blown UI.
In all honesty, I would refactor the old JavaScript code and not rewrite the application. Since you are asking about which platform to put it in, I would guess that your team isn't an expert in any of them (not slamming the team, it's just a simple fact that you have to consider when making a decision). This will work against you as you'll have double duty rewriting and learning how to do things on the new platform.
By keeping it in JavaScript, you can slowly introduce a framework if you choose and do it iteratively (Replace on section of code, test it, release it, and fix any bugs). This will allow you to do it at a slower pace and get feedback along the way. That way too, if the project is canceled part way through, you aren't out all the work, because the updated code is being used by the end users. Remember the waterfall model, which is essentially what a full swap out of will be almost never works.
As much as I hate to admit this, as it is always the most fun for developers, shifting platforms, and replacing an entire system at once rarely works. There are countless examples of this, Netscape for one. Here is the post from Spolsky on it. (I would also recommend the book Dreaming in Code. It is an excellent example of a software project that failed and how and why). Remember to rewrite a system from scratch you are essentially going to have to go through every line of code and figure what it does and why. At first you think you can skip it, but eventually it comes down to this. Like you said, your code is old, and that means there are most likely hacks in it to get something done. Some of these you can ignore, and others will be, "I didn't know the system needed it to do that."
These things spring to mind:
As you have a .Net backend and you have some ability to force your customers onto a specific platform, Silverlight is an option;
Since your client is a full-blown UI you want widgets and possibly other features like Drag and Drop;
I haven't seen any requirements that to me would justify starting over (which often doesn't work out) in Flex/Silverlight (eg streaming video, SVG support. Added to your team's familiarity with Javascript, I think you can't make a compelling case for doing it in anything other than Javascript.
But of course Javascript is lots of things and there are [lots of Javascript frameworks1. The most important divider is whether your intent is to "decorate" a set of Web pages or you need a full set of Widgets to create a desktop-like application on the Web. Your question indicate it is the latter.
As such--and I may get downvoted for saying this--I don't think jQuery is the answer and I say this as someone who loves jQuery. jQuery (imho) is great to enhance Webpages and abstract cross-browser low-level functionality but the most important factor for complex UI developer is this:
It's all about the widgets.
And yes I'm aware of jQuery UI but it's a lot sparser than the others when it comes to widgets. I suggest you take a look at the samples and widget galleries of some frameworks:
YUI Examples Gallery;
ExtJS demo; and
SmartClient feature explorer.
The others (jQuery, Dojo, Mootools, Prototype) are more "compact" frameworks arguably less suited to your purpose.
Also consider the license of each framework when making your decision.
My thoughts on the above three are:
ExtJS has somewhat angered the community in that it started out as LGPL but had a controversial license change (that thread is at 76 pages!) to GPL/commercial at version 2.1. The problem with that the community no longer has an active participation in the framework's development. Not the mainline version anyway. This means it's being developed and supported by a small team (possibly one person) rather than the community. IMHO it's not worth paying a commercial license for that and GPL is probably prohibitive in your situation;
YUI is supported by Yahoo and available under a far more permissive and far less invasive BSD license. It's mature, well-used and well worth serious consideration; and
SmartClient impresses me a lot. It has perhaps the most permissive license of all (LGPL), is roughly seven years old, has an incredibly impressive array of widgets available. Check out their feature explorer.
Your decision should be based on how you get as much of your application "for free" as possible. You don't want to spending valuable developer time doing things like:
Coding UI widgets like trees and accordions;
Testing and fixing cross-browser Javascript and CSS issues;
Creating homegrown frameworks that greatly duplicate what existing frameworks do and do well.
I would seriously look at one of the above three as your path forward.
This decision is usually less about the technology, and more about your skill sets and comfort zones.
If you have guys that eat and breathe Javascript, but know nothing about .net or Flash/Flex then there's nothing wrong with sticking with Javascript and leaning on a library like jQuery or Prototype.
If you have skills in either of the others then you might get a quicker result using Silverlight or Flex, as you get quite a lot of functionality "for free" with both of them.
My opinion on this one's pretty simple: unless the app needs to be accessible publicly, unless it needs to be search-engine optimized and findable, and/or there's an otherwise compelling case for its having to remain strictly text-based, then the chips are stacked in favor of rich-client runtimes like Flash or Silverlight right out of the gate.
A big reason, if not the biggest, is that they eliminate the complexities of developing for multiple browsers and platforms. Again: they eliminate the runtime-environment variable. No more debugging old versions of Netscape and IE, no more object detection and consequent branching, no more wacky CSS hacks -- one codebase, and you're done. Offloading the runtime environment to Adobe or Microsoft will save you time, money and headaches, all else equal. (Sure, there's YUI, JQuery, etc., but they don't eliminate that variable -- they just abstract it. And they don't abstract all of it, either -- only some of it; ultimately, it's still up to you to test, debug, retest, debug, repeat.)
Of course, your situation's a bit more complicated by the existing-codebase problem, and it's difficult to say definitively which way you should go, because only you've got the code, and we're just geeks with opinions. But assuming, just by your asking the question, that a refactoring of your existing codebase would involve a significant-enough undertaking as to warrant even considering an alternative (and probably comparatively foreign) technology in the first place, which it sounds like it would, then my response is that your curiosity is well-placed, and that you should give them both a serious look before making a decision.
For my part, I'm a longtime server-side guy, ASP.NET/C# for the past several years, and I've written many a text-based line-of-business app in my time, the last few with strong emphasis on delivering rich soverign UIs with JavaScript. I've also spent the last couple of years almost exclusively with Flex. I've got experience in both worlds. And I can tell you without hesitation that right now, it's everyone else's job to beat Flex: it's just an amazingly versatile and productive product, and for line-of-business apps, it remains leaps and bounds ahead of Silverlight. I just can't recommend it highly enough; the data-binding and event-handling features alone are incredible time-savers, to say nothing of the complete freedom you'll have over layout, animation, etc. The list goes on.
So, my advice: take a long, careful look at Flex. In the end, you might find a ground-up rewrite is just too massive an undertaking to justify, and that's fine -- only you can make that determination. (And to be fair, you've just as much ability to make a mess of a Flex project as you do with a JavaScript project -- I know. I've done it.) But all told, Flex is probably the least-limiting, most flexible, most feature-rich and productive option out there right now, so it's certainly worth considering. Good luck!
Any javascript you have that has been developed 'Over the years' probably doesn't look anything like what's possible today. You undoubtedly have a lot of useful code there. nonetheless. So my recommendation would be re-write in javascript using jQuery and make use of one of the available GUI add-ons, perhaps look at Yahoos stuff. You will also be targeting the widest audience this way.
The GUI technology should be first and foremost determined by your target audience. For instance, if you target englobes iPhone users, I would not recommend Flex, because iPhone doesn't have a flash player at the moment.
Bear in mind that if you switch to a full fledged GUI toolkit like Silverlight, your users may find the L&F unnatural, since the usual request-reply cycle is not so evident with client-side frameworks.
After that, it is your developers that should have a word to say. Every toolkit needs maintenance, and if you are switching to a whole new toolkit the developers will have to familiarize with the new toolkit, which can be costly.
My suggestion is that you stick to javascript, since your devs are familiar with it, and gradually replace the old javascript with a new toolkit like prototype, jQuery or any other. You will probably redo some of the old stuff faster using a state-of-the-art toolkit. Remember that you can build beautiful apps with any tookit.
We have developed an extremely rich application using EXTJS with C# and a some C++ on the server. Not only do we have clients who are happy with the interface in their desktop browsers but with very little tweaking to the Javascript we were able to provide web browser support. Also, we have clients in third-world countries who cannot use Flash or Silverlight apps due to their field personnel using kiosks in internet cafes (many of which don't have Flash installed - forget Silverlight!). I think these issues and others make up for the difficulty of coding a complex app in javascript...
Check this comparison table for Flex vs Javascript: