This is basically the same old, same old x vs y, what is faster?, but I do hope my version is applicable. Also, React and Angular differ like GTK and Qt (or even more), and comparing them is stupid - one is an out-of-the-box can-do-anything framework, while the other is a View framework designed to only do that. If my question still is unanswerable or subjective and should be closed, please write me a comment how to improve it in the future, if possible. Thank you.
This is a question about Angular 2+ vs React in terms of performance. My team shall build one SPA for identical functionality with each framework.
Assume:
development time for both versions should be equal / similar
non-view related functionality (where Angular differs from view-only React) is unimportant to the measurement and development time, updates to the view happen frequently and are the bottleneck
measured is steady-state performance after initial page-load (so all data for the page is within memory)
both applications are built the way the relevant handbook would recommend
client-side rendering only, with mostly dynamic data (so not much server-side rendering or ahead-of-time-compiling)
Javascript VMs are difficult to reason about, but my two questions are exactly about their behavior:
Would there be a clear performance winner after current-gen JIT has done its part (optimizing as far as possible) or would the final performance be equal?
In the year 2027 we will still use webbrowsers (probably Chrome 256 or Firefox 384). Assume both frameworks still exist and kept their core strategy / mechanics the same as today. Browser Javascript VMs / JIT improved further and further, but I keep my current laptop to measure performance. Which framework would probably win in 2027? Or to rephrase the question: which strategy is theoretically more optimal / 'closer to the metal' (or in this case: closer to Javascript execution models)?
PS: I'm pretty sure in 2027 we will not use either, and this question is also not about which framework anyone should prefer, but only theoretical performance. The question about which framework would be 'closer to the metal' came up one night with friends and should not be used by anyone to make a decision. Never make important life decisions drunk or late at night.
My experience but not the final decision
I started with Angular and wanted to see what React could do. React is certainly not bad, but what I immediately noticed was the disorder that can prevail. That depends on the developer, of course, but with Angular and TypeScript everything looks more orderly and structured. Template and code are separated and with React you have the JSX, i.e. HTML in JavaScript which is JavaScript. Reminds me a bit of PHP and I never liked that, because when a project gets extremely big, you really lose track. For one component you could easily have 3-5 files and that is bad in my opinion.
With Angular you can also lose the overview, but you have a uniform structure with a few deviations.
If your application becomes really very very big then it makes sense to use Redux but why people making life complicated. If you just want to check if a user logged in or not for a middle large e-commerce site then services would also do the job.
In my opinion, the user should focus on working. Redux it is fine but we should not add every new tool which comes each week to our project either is reduce cost and time dramatically. But if you add new tools then you should also have people who can handle it later. It doesn't mean if you use every tool that your application is good or you are a good developer automatically. In my opinion, keep everything as simple as possible and use the tools you really need to fulfill your requirements.
And by the way I don't understand why the people still want to use Vaadin, Spring Boot together with Angular in combination. Maybe someone can explain it me?
Related
I have been using JavaScript and jQuery for quite a while now and want to extend my skill set further, during my search I came across two popular names Angular and Backbone and while reading about them I found one line common in both them which somehow also seems to be their USP i.e.
It is designed for developing single-page web applications
This makes my confused.
What is that I cannot do with JS or jQuery and I would require these?
I have created web application on single page, where users can perform CRUD operations on single page through asynchronous calls so why so much importance of for these others libraries?
And as a middle level web developer who has have good hands on JS is it right path to move to these two or here is something else I should look into before these?
Please help?
Structure.
In an ongoing project that started about 4 years ago we built the front end with jQuery. We were able to do just about everything that we needed creating several single page applications that were quite functional.
As the project progressed and the code base grew we started experiencing some major problems with maintainability of the code. We ended up with hundreds or thousands of lines of JavaScript code per page in a tangle that was almost impossible to navigate. This could have been avoided if we were more careful of course but at the time we focused on making sure the back end architecture was robust.
Many years ago the community learned that code needs structure to be maintainable. We developed MVC patterns, multi-tiered applications etc. But JavaScript was never a big player in the field and we largely ignored it.
Over the last 6 months or so we introduced Angular into the project and started sorting out some of the mess in the project. The results are remarkable. Not only is the code simpler and easier to create, the structure makes it easier to implement tests, easier to maintain and generally a huge improvement over what we had before. We still use jQuery but now we have been burnt by the lack of structure and know a thing or two about the architecture of a JavaScript application. Angular and its like provide you with the tools to architect a good application.
When you are creating larger scale web applications it is wise to check out Backbone, Angular or perhaps Meteor. jQuery supports neat tricks, but it does not help you structure your code in a maintainable way. Larger scale web apps build on jQuery need their own vision on how to separate the code into layers with their own responsibility.
The other frameworks give more support.
I would suggest checking out at least one of the libraries. Perhaps you eventually won't use them, but it will benefit how you work in jQuery.
Well Now a days there has been quite a hype about Angular.js and especially SPAs (Single Page Applications). Well to be honest, I had the same question in my mind about a month ago when my team decided to shift from Jquery to Angular.
Whenever it comes to Jquery, one of the first thing that comes in our mind is the DOM manipulation. While using Jquery we always think of manipulating the DOM. Show/hide elements, animating elements, getting data from tags you name it. But Angular offers something more than that. It offers you an architecture, a way to structure your applications at the front end.
So whenever you go for Angular.js, change the way you think about creating web applications (and believe me its worth it). Most of Angular's structure uses the concept of Dependency Injection which is a neat way to maintain your code.
Backbone is only a library whereas Angular.js is a complete framework to create and manage Single Page Applications
Talking about the fact that Angular.js should be used when we are creating large scalable apps, it is true. In my case the team I work with is full of Jquery Ninjas. We have been creating a great app for the last 3 years and believe me it became difficult for us to maintain and debug thousands of lines of Jquery. This is the main reason we have decided to revamp this app into Angular.
Kindly see some of these Helpful links. You will get a better idea.
http://net.tutsplus.com/tutorials/javascript-ajax/3-reasons-to-choose-angularjs-for-your-next-project/
"Thinking in AngularJS" if I have a jQuery background?
The previous programmer left the website in pretty unusable state, and I am having difficulty modifying anything. I am new to web design so I don't know whether my skills are a mismatch to this kind of job or is it normal in the real industry to have websites like these
The Home page includes three frames
Each of these frames have their own javascript functions ( between <head>, and also call other common javascript functions (using <script src=..>
Excessive usage of document.all - in fact the elements are referred or accessed by document.all only.
Excessive usage of XSLT and Web Services - Though I know that using Web Services is generally considered a good design choice - is there any other way I can consume these services other than using xslt. For example, the menu is created using the data returned by a web method.
Every <div>, <td> and every other element has an id, and these id's are manipulated by the javascript functions, and then some appropriate web service and the xslt files are loaded based on these..
From the security perspective, he used T-SQL's for xml auto for most of the data that is returned by the web service - is it a good choice from the security standpoint to expose the table names and column names to the end user??
I am a lot confused about the state of the application itself. Should I learn about the intricacies that he has developed and continue working on it, or should I start rewriting everything? What I am perplexed a lot is the lack of alternatives - and whether this is the common way web projects are handled in the real world or was it an exception?
Any suggestions, any pointers are welcome. Thanks
No, it is not acceptable in this industry that people keep writing un-maintainable code.
My advice to you is to go up the chain and convince everyone that this needs to be rewritten. If they question you, find an external consultant with relevant web development skills to review the application (for 1 day).
Keeping this website as-is, because it 'works' is like keeping a working model Ford-T car on today's highways, very dangerous. Security and maintenance costs are likely the most persuading topics to convince anyone against keeping this site 'as-is'.
Next, get yourself trained, it will pay off if you can rewrite this application knowing the basics. Todays technology (asp.net MVC) allows you to implement core business value faster than trying to maintain this unconventionally written app.
Tough spot for an inexperienced developer (or any) to be left in. I think you have a few hard weeks a head of you where you really need to read up on the technologies involved to get a better understanding of them and what is best practice. You will also need to really dig down into the existing code to understand how it all hangs together.
When you done all that you really need to think about your options. Usually re-writing something from scratch (especially if it actually works) is a bad idea. This obviously depend on the size of the project, for a smaller projects with only a couple of thousand lines of code it might be OK. When looking at someone elses code it is also easy to overlook that all that weird shit going on could actually be fixes for valid requirements. Things often start out looking neat, but then the real words comes visiting.
You will need to present the business with time estimates for re-writing to see if that is an option at all, but I'm guessing you will need to accept the way things are and do your best with what you have. Maybe you could gradually improves things.
I would recommend moving the project to MVC3 and rewriting the XSLT portions to function using views and/or partial views with MVC. The Razor model binding syntax is very clean and should be able to quickly cleave out the dirty XSLT code and be left with just the model properties you would need.
I would then have those web services invoked from MVC serverside and for you to deserialize the object results into real objects (or even just use straight XQuery or Json traversing to directly pull stuff out for your model) and bind those to your views.
This could be a rather gargantuan leap for technology at your company though. Some places have aversion to change.
I'd guess this was written 6-7 years ago, and hacked on since then. Every project accumulates a certain amount of bubble gum and duct tape. Sounds like this one's got it bad. I suggest breaking this up into bite size chunks. I assume that the site is actually working right now? So you don't want to break anything, the "business" often thinks "it was working just fine when the last guy was here."
Get a feel for your biggest pain points for maintaining the project, and what you'll get the biggest wins from fixing. a rewrite is great, if you have the time and support. But if it's a complex site, there's a lot to be said for a mature application. Mature in the sense that it fulfills the business needs, not that it's good code.
Also, working on small parts will get you better acquainted with the project and the business needs, so when you start the rewrite you'll have a better perspective.
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.
I'm considering to try out an idea, mostly for fun, and my question is if this is reasonable and if there are any libraries or frameworks that could make this experiment a little easier.
So, the idea: Basically it is to write a new UI for a website I've developed, but doing it with client-side code only. I can read/write data using ajax, since my existing website has an API that allows me to perform all kinds of queries. This allows me to use JavaScript for the whole thing and theoretically put all of the code in a single file.
Obviously there are limitations to circumvent; bookmarking, page refreshing, the back-button etc. But these limitations are what makes it interesting, right? :) I'm not so worried about search engine indexing, since one has to be logged in to use the site anyway.
The site itself is not overly complex, but it is not simple either. There are four different levels of users, multiple languages and quite a lot of data to be presented.
Is this a bad idea? If so, why would you advice against it? And do you know of any JavaScript frameworks or libraries that could make this easier? (And no, I'm not looking for an abstraction like Google Web Toolkit; I would like something purely JavaScript)
One of my coworkers did this. A nice feature of this concept was that you don't have a ton of POSTS whenever the user 'changes pages', since they are actually not ever changing a page until they submit their data for the final time. He did this for product registration software, which was nice. Our servers were only taking a hit when the user initially requested the page, and then when they submitted it.
The major, MAJOR downside to this concept is that most web developers are not expecting this. My coworker (and you) have a cool idea - but unless it is well implemented, with comments, 100% valid HTML, and a host of other good design principles in place, it can be confusing since most web developers have basically never seen this done before. His site was a nightmare to work with, as he did not actually know what engineering web software meant, and it was all slapped together. My organization never pursued this (potentially useful) idea because his implementation was so poor.
So, when I looked at this idea here were the trade-off I came up with:
1.) You cannot require any server-side interaction during intermediate pages.
2.) The initial page loading is longer, but there are no intermediate page requests (better optimization).
3.) This is vastly different than anything anyone usually does, which means you need to be especially careful with documentation.
4.) This design concept facilitates totally stand-alone web software to be easily deployed without the web.
5.) You might be increasing complexity for avoiding page loads, but maybe not. I'm not sure.
All together, I think it just depends on what you want to accomplish. My coworker really just wanted to see if he could do it, which he could. However, how he did it was really pretty bad, to the point where everyone else connected his poor implementation with a poor idea it was fairly sad.
Mostly, I think if you follow good web design practices this wouldn't be too bad of a thing to pursue. What are your goals though?
I'm sorry I couldn't directly answer all of your questions. I hope my experiences are still helpful in answering if I think it is a bad idea or not.
-Brian J. Stinar-
SproutCore is one of the best out there when it comes to really being built from the ground up for single-page, potentially complex applications. Unlike some others like GWT or Cappucino, SproutCore is really about using JavaScript directly. They aren't the only one though. You might also want to look at JavaScriptMVC and qooxdoo.
Personally, I've built an extremely large and complex single-page application using JavaScript. It is currently around 100,000 lines (including comments/whitespace). To give a sense of scale, jQuery is around 6,000. To reach that size, I built my own framework, build tools etc. and it is extremely maintainable. You're asking if it can work, and I can tell you that it does, but you do need a little infrastructure if you're looking at doing something big. (BTW, there's a lot of lazy loading - its not 100,000 lines all at once!)
I also wouldn't really recommend this method for anything other than a web application. As pointed out, its still difficult for SEO, and may be strange for some users.
You're looking for ExtJS
I did my site like that in jquery, backed by spring mvc 3. For me it works fine and you have a lightweight, flashy feling while on it.
If you have time to dig in javascript seriously... it is really good exercise.
The only thing I really need to add is SEO, since spiders see only intial html. If it is important for you, i think backend static files and sitemap would be good enough solution.
I found something very light-weight that provides the basic needed functionally without forcing you into a whole framework. It's called Sammy and is inspired by Ruby's Sinatra: http://code.quirkey.com/sammy/
Very recommended!
Alternative: code the same in Java. Take a look to ItsNat
Think in JavaScript but code the same in Java in server with the same DOM APIs, in server is way easier to manage your application without custom client/bridges because UI and data are together.
Regarding SEO, bookmarking etc in single page there are solutions, take a look to the Single Page Interface Manifesto
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: