Related
If the framework manages the HTML/ CSS/ javascript, does a programmer still need to know the javascript language? Or is that taken care of in the abstraction of the framework?
I wanted to make a graphical game/ application using the html5 canvas/ webgl/ whatever other libraries are available to do so. Would it be more effective for me to go through a web framework such as django? I'm not really sure what advantages it offers. I think that if I wanted to create a well designed dynamic site in an effective way, I would use a framework. But if I didn't care about appearance, or if I'm just learning, then am I better off just playing with javascript and html5 first?
In my opinion, you could easily use a framework to simplify your development but remember this: With every framework or tool that simplifies development, you lose a bit of control.
Eventually, you will come to the point where you need to understand css/JavaScript, or whatever the underlying technology is, in order to accomplish some task. In that situation you'll be at a point where you need to learn the "hard" stuff.
Even before you get to that point, however, I'd strongly recommend learning the basics of the underlying technology so that you can see what the tools do. There are many reasons for this, but the most important ones are:
As mentioned previously, sooner or later you'll need to anyway.
If you don't know the underlying technology, you'll struggle and waste a lot of time trying to understand why the pages/apps generated by the framework don't behave the way you want them to.
Troubleshooting is harder
It's really easy for a novice developer to pick up a framework and start doing really stupid things with it. Things that can lead to security holes, leaking sensitive data, exposing yourself and customers to risk.
Some frameworks, of course, protect novice developers from things like SQL Injection, etc, but not all. It takes someone who understands what the tools are doing "under the hood" to tell the difference.
Of course, there is a limit to how much you need to know.
As an analogy, it would be foolish to drive a car without taking the time to learn the basics of how it operates, and how to be safe with it. But to drive a car, you don't need to know how to take apart the engine. If you're one of the guys who wants to be able to take apart the engine (and put it back together), great! You'll be one of the experts in at least one area of the automotive field.
The same goes with development. Different people need/want different depths of knowledge...
But for the web, at least knowing the basics of HTML, css, and JavaScript is a must. It's like learning the difference between Diesel and Gasoline before filling up your tank. It's basic knowledge every web developer needs.
A framework is often developed for the purpose of making larger tasks easier by taking several steps and making them user-friendly. In addition to this, you'll often find that they include configuration files and auto-installers to ease the setup of server components (databases, for instance) so that non-technical users have an ease of use.
The largest issue with this, however, is when users run into errors or warnings that they are unable to debug because the basis for the problem can only be acknowledged with (often) small amounts of expertise in the core languages that the framework was based on.
Quite simply put, you may not need to learn Javascript to use your said library, but it is highly suggested that you understand the inner workings so that you may easily debug and solve problems you have in the near future.
Enjoy and good luck!
When I search for performance of Javascript libraries I get many sites showing the comparision of performance between the following popular libraries
jQuery (pretty slow)
Prototype(very slow in IE)
Dojo ( fastest when comes to DOM )
ExtJs (average)
Micro JS( slow but OK )
But in any of the benchmarks, Google Closure Library is NOT included. Is it not like any other standard library for it is said that it is a procedural style library.
I need some benchmarks on the performance of Closure library. And would like an advice on "Is switching to Closure library good when using dojo at beginner stage and jQuery at some intermediate stage"
Google posts that it uses the closure library in all its apps like Gmail, etc... The performance is very good. Is this because of the library ? Can an intermediate javaScript coder who can write OO code in JS use Closure library to very high level, or is it advisable to continue using DOJO.
On Closure Library
The Closure Library is pretty close to Dojo in style -- actually, when it was first developed, the authors took inspiration from Dojo.
However, the speed and power of the Closure Library came from the Closure Compiler, which heavily optimizes a JavaScript program in order to remove all the bottlenecks (such as navigating chains of namespaces).
I personally don't like it a single bit as it detracts from the beauty of Dojo class-based constructs (simply to satisfy the compiler) and all those goog.kitchen.sink.getMeACupOfTeaSoICanRelax() long namespaces make writing (and reading) JavaScript programs a royal pain -- the fact that long namespaces are all optimized away by the compiler does not make it pretty (to me) to overuse them because you can.
In addition, its obsession with trying to make JavaScript programs look as much OOP as possible (perhaps because there are tons of Java programmers in Google) means over-reliance on OOP concepts like property getters and setters and the avoidance of many useful (and unique) JavaScript features like mixin's. If you are a Java programmer learning to program in JavaScript, you'll be right at home using the Closure Library. That doesn't make it any bit elegant.
It does, however, offer an industrial strength environment that is rock solid -- since Google has built HUGE sites with it. It is something that (in my personal opinion) is solid and works well, but looks ugly.
However, Dojo is rock solid as well, but more volatile since it is an open-source development project. You decide whether you'd like to switch.
On the Closure Compiler and Dojo
Actually, you can use Dojo with the Closure Compiler in Advanced Mode also. See this link for a description on how to do it. Based on my own tests, a program compiled by the Closure Compiler is typically around 25% smaller than minified versions (due to dead-code elimination) and runs about 20-30% faster for simple pages and more for large pages.
On Speed of Libraries in General
Other libraries all have their own characteristics and quirks, and each balance useability, flexibility and power with performance. For example, jQuery creates many many jQuery objects on the way and has a performance penalty, especially on older browsers. However, modern browsers, esp. Google Chrome, actually does optimizations so that the performance hits of using jQuery is minimal.
You actually need to ask yourself why you need JavaScript to run fast. Most modern browsers are already quite fast so that it is really not a very important consideration regarding choice of library. Better choose your library based on whether it suits you or not (and the task you're at hand) instead of whether it runs 10ms faster in a browser.
If you are writing a web site for mobile devices, or writing an HTML5 game for instance, you may need to squeeze the last drop of performance (in games) and/or save as much resources as possible (in mobile). In such cases, I find that using Dojo and then compiling with the Closure Compiler yields one of the best combinations for such scenarios.
Would be nice to back this up with some data. There's lies, statistics and benchmarks. You may for example ask yourself why framework x is slower then framework y. In general though, benchmarks do not reflect real world scenario's, and end to be fun, but useless. I've worked with jQuery for a few years now and I've not encountered situations where it's slow, or that it had any effect on the usability.
I your code is too slow and you need to optimize it. Then you may benchmark, profile and debug the sweet jesus out of that code. Things like gmail are likely to have had that kind of treatment. So gmail is probably not fast because of closure, but fast because of intelligent programming.
If you're affraid of slow code, you might want to learn generic javascript optimization methods, and you'll be a happy camper with any framework.
edit: on closure
Choosing closure might have several advantages when you're building big and complex: there are some nice bandwith optimization tools, tools for managing more complex applications. There is a good guideline on how to write proper code, and tools to check that you followed these guidelines (closure linter, quite interesting). There's a nice templating system (probably won't improve your performance per se) and dependency management stuff. If you wish to integrate these tools, or build upon it, I would say go for it, otherwise, you may rest easy and be happy with your choice for dojo.
using dojo at beginner stage and jQuery at some intermediate stage
You've got that the wrong way around. Dojo is far more advanced than jQuery. jQuery itself is for beginners.
Can an intermediate javaScript coder who can write OO code in JS use Closure library to very high level, or is it advisable to continue using DOJO.
Either library will work. Spend a few hours playing with google closure and see how you find it. I doubt there's that much difference apart from general easy integration with google libraries like google charts.
I'm curious what's the view on "things that compile into javascript" e.g. GWT, Script# and WebSharper and their like. These seem to be fairly niche components aimed at allowing folks to write javascript without writing javascript.
Personally I'm comfortable writing javascript (using JQuery/Prototype/ExtJS or some other such library) and view things like GWT these as needless abstractions that may end up limiting what a developer needs to accomplish or best-case providing a very long-winded workaround. In some cases you still end up writing javascript e.g. JSNI.
Worse still if you don't know what's going on under the covers you run the risk of unintended consequences. E.g. how do you know GWT is creating closures and managing namespaces correctly?
I'm curious to hear others' opinions. Is this where web programming is headed?
Should JavaScript be avoided in favor of X? By all means!
I will start with a disclaimer: my answer is very biased as I am on the WebSharper developer team. The reason I am on this team in the first place is that I found myself a complete failure in writing pure JavaScript, and then suggested to my company that we try and write a compiler from our favorite language, F#, to JavaScript.
For me, JavaScript is the portable assembly of the web, fulfilling the same role as C does in the rest of the world. It is portable, widely used, and it will stay. But I do not want to write JavaScript, no more than I want to write assembly. The reasons that I do not want to use JavaScript as a language include:
There is no static analysis, it does not even check if functions are called with the right number of arguments. Typos bite!
There is no or a very limited concept of libraries, namespaces, modules, classes, therefore every framework invents their own (a similar situation to that of R5RS Scheme).
The tooling (code editors, debuggers, profilers) is rather poor, and most of it because of (1) and (2): JavaScript is not amenable to static analysis.
There is no or a very limited standard library.
There are many rough edges and a bias to using mutation. JavaScript is a poorly designed language even in the untyped family (I prefer Scheme).
We are trying to address all of these issues in WebSharper. For example, WebSharper in Visual Studio has code completion, even when it exposes third-party JavaScript APIs, like Ext Js. But whether we have or will succeed or fail is not really the point. The point is that it is possible, and, I would hope, very desirable to address these issues.
Worse still if you don't know what's
going on under the covers you run the
risk of unintended consequences. E.g.
how do you know GWT is creating
closures and managing namespaces
correctly?
This is just about writing the compiler the right way. WebSharper, for instance, maps F# lambdas to JavaScript lambdas in a 1-1 manner (in fact, it never introduces a lambda). I would perhaps accept your argument if you mentioned that, say, WebSharper is not yet mature and tested enough and therefore you are hesitant to trust it. But then GWT has been around for a while and should produce correct code.
The bottom line is that strongly typed languages are strictly better than untyped languages - you can easily write untyped code in them if you need to, but you have the option of using the type-checker, which is the programmer's spell-checker. Why wouldn't you? A refusal to do so sounds a bit luddite to me.
Although, I don't personally favor one style over another, I don't think that abstraction from Javascript is the only benefit that these frameworks bring to the table. Surely, in abstracting the entire language, there will be things that become impossible that were previously possible, and vice-versa. The decision to go with a framework such as GWT over writing vanilla JavaScript depends on many factors.
Making this a discussion of JavaScript vs language X is fruitless as each language has its strengths and weaknesses. Instead, do an objective cost-benefit analysis on what is to be gained or lost by going with such a framework, and that can only be done by you and not the SO community unfortunately.
The issue of not knowing what goes on under the hood applies to JavaScript just as much as it does to any translated source. How many people do you think would know exactly what is going on in jQuery when they try to do a comparison such as $("p") == $("p") and get back false as a result. This is not a hypothetical situation and there are several questions on SO regarding the same. It takes time to learn a language or framework, and given sufficient time, developers could just as well understand the compiled source of these frameworks.
Another related aspect to the above question is of trust. We continuously build higher level abstractions upon lower level abstractions, and rely on the fact that the lower level stuff is supposed to work as expected. What was the last time you dug down into the compiled binary of a C++ or Java program just to ensure that it worked correctly? We don't because we trust the compiler.
Moreover, when using such a framework, there is no shame in falling back to JavaScript using JSNI, for example. It's all about solving the problem in the best possible manner with the tools at hand. There is nothing sacred about JavaScript, or Java, or C#, or Ruby, etc. They are all tools for solving problems, and while it may be a barrier for you, it might be a real time-saver and advantageous to someone else.
As for where I think web programming is headed, there are many interesting trends that I think or rather hope will succeed such as JavaScript on the server side. It solves very real problems for me at least in that we can avoid code duplication easily in a web application. Same validations, logic, etc. can be shared on the client and server sides. It also allows for writing a simple (de)serialization mechanism so RPC or RMI communication becomes possible very easily. I mean it would be really nice to be able to write:
account.debit(200);
on the client side, instead of:
$.ajax({
url: "/account",
data: { amount: 200 },
success: function(data) {
..
}
error: function() {
..
}
});
Finally, it's great that we have all this diversity in frameworks and solutions for building web applications as the next generation of solutions can learn from the failures of each and focus on their successes to build even better, faster, and more awesome tools.
I have three big practical issues I have with websharper and other compilers that claim to avoid the pain of Javascript.
If you won’t know Javascript well you can’t understand most of the examples on the web of using the DOM/ExtJs etc., so you have to learn Javascript whatever. (For the some reason all F# programmers must be able to at least read C# or VB.NET otherwise they cannot access most information about the .net framework)
On any web project you need a few web experts that know the DOM and CSS inside out; would such a person be willing to work with F# rather than Javascript?
Being tied into the provider of the compiler, will they be about in 5 years’ time; I want full open source or the tools to be supported by Microsoft.
The 4 big positives I see with these frameworks are:
Shareing code between the server/client
Having fewer languages a programmer needs to know (javascript is a real pain as it looks like Jave/C# but is not anything like them)
The average quality of a F# programmer is a lot better than a jscript programmer.
My opinion for what it's worth is that every framework has its pros/cons and a project team should evaluate their use cases before including one. To me any framework is just a tool to be used to solve a problem, and you should pick the best one for the job.
I prefer to stick to pure JavaScript solutions myself, but that being said I can think of a few cases where GWT would be helpful.
GWT would allow a team to share code between the server/client, reducing the need to write the same code twice (JS and Java). Or if someone was porting a Java client to a web UI, they may find it easier to stick to GWT ( of course then again it may make it harder :-) ).
I know this is a gross over-simplification, because there are many other things that frameworks like GWT offer, but here is how I view it: if you like JavaScript, write JavaScript; if you don't, use GWT or Cappuccino or whatever.
The reason people use frameworks like GWT is not necessarily the abstraction that they give--you can have that with JavaScript frameworks like ExtJS--but rather the fact that they allow you to write web applications in something other than JavaScript. If I were a Java programmer who wanted to write a web application, I would use GWT because I would not have to learn a new language.
It's all preference, really. I prefer to write JavaScript, but many people don't.
I am likely to be part of the teaching team for the web programming course at my University next semester and I was wondering what kind of Javascript assignment to hand out to the students. The course is not an introductory one from a programming perspective.
It is assumed that the students are familiar with OOP, data structures and algorithms, functional programming concepts and working knowledge of networking protocols (HTTP included). This is the first course in which they come in contact with JavaScript
I was thinking to give out something framework-specific (using jQuery perhaps) that involves DOM traversal, some animations and AJAX. The three questions I have in mind are:
should they use a framework or should I have them write vanilla JavaScript?
should I focus more on the functional programming part and on the prototypal inheritance part (more on the language than on working with the DOM)?
how do I automate testing for this? It's better if they have a clear idea on how they will be evaluated. Also, automated testing ensures objectivity and saves me time :).
Outcome
I made them do Tic Tac Toe as a jQuery plugin and the results were mostly satisfactory (70% of the students submitted, generally the submissions were ok).
To prevent copying code from the net, I thought out an API which they had to implement. At least, they'd have to understand the code they found on the net before copy&pasting it into the methods :).
I used QUnit for automated testing, but I also tested each assignment manually because this was the first JavaScript assignment they'd had and I wanted to give relevant feedback.
Thank you all for your ideas, they all helped a lot.
Cheers,
Alex
I think its useful for the students to know fundamentals about the language before working with frameworks. They need to know about JS Scopes, closures, prototypes, the memory model, and everything that makes JS unique.
After that, introduce them to frameworks and the DOM. They'll appreciate them much more since they'll be able to understand the implementation.
As for testing, automated testing might be easy if you have them generate a DOM that you can walk and validate. Mozilla might be able to help you out, esp with JSUnit. You can find info here
I always like the idea of making games to learn new programming concepts. You get a well-defined problem domain that's as simple or complex as you need it, and it's usually more interesting and fun to implement than other problems.
When I wanted to learn Ajax programming I used jQuery and Java server-side to implement the game of chess. It was a fun project, but pretty complicated (at least for me, but I'm primarily a server side programmer). I think something like Tic-Tac-Toe would be substantially simpler, and might be a good idea for a project assignment.
As for the 3 questions:
If this is the only JavaScript assignment, then I'd probably use vanilla instead of jQuery. But if they have a chance to do some assignments before this, I'd consider jQuery, because it just makes JavaScript so much less annoying, and it's also good to know jQuery for future employment possibilities.
I'd place an equal emphasis on both the language and the DOM, because the primary purpose of the language IS to work on the DOM, and the DOM does take some getting used to.
I think Selenium might work for the testing you're trying to do. JsUnit could also be used for unit testing the individual methods.
Start off with vanilla JavaScript to learn the basics. You don't want to create a group that relies on any particular framework that wouldn't know how to do things without it.
I would most definitely have them write vanilla JavaScript. It will encourage all students to better understand the abstractions that frameworks/libraries provide in particular environments i.e. for the most part, in the browser working with the DOM.
I highly recommend having a good text for the course. Object Oriented JavaScript by Stoyan Stefanov is in my mind a great text for learning the language, including some of the topics that many people have difficulty with (prototypes, objects, closures, inheritance, etc). I've read numerous JavaScript books and feel that this particular text best balances the core of the language and it's application in the modern client-side development realm.
You may then want to look at dissecting certain pieces of the source of a particular JavaScript library to gain insight into patterns and practices used in a real-world scenario.
I would have them write vanilla javascript AND also learn how to use jQuery. jQuery is javascript after all, and they need a working knowledge of the language anyway. They'll also need to become SWAT (skills with advanced tools), and I believe anyone not using one of the JS frameworks (or at least their own!) in today's environment is at a serious disadvantage.
See answer 1. I'd teach them about prototypal inheritance in vanilla JS, and about DOM manipulation in jQuery.
Automated testing could be achieved in several ways. 1: produce the correct output given some sample code to start with for the parts that deal with learning JS. 2: for the parts that deal with jQuery, you could provide a reference image for how you expect the result to look, provide an original document, and have them recreate the reference image using jQuery manipulation... sort of like the ACID tests http://acid3.acidtests.org/
Should they use a framework or should I have them write vanilla JavaScript?
To me, it is overwhelmingly import that people new to the language start with the language proper, not modified versions or advanced/fancy libraries that do a lot of the work for you. Besides, if you're starting off not working with the DOM, then you're not getting much benefit from using almost any library, as the bulk of most JavaScript libraries has to do with handling the DOM. Also, it's easier to spot "bad" or ill-performant code when teaching and learning in a "vanilla" environment since you don't have libraries abstracting away the nitty-gritty.
Should I focus more on the functional programming part and on the prototypal inheritance part (more on the language than on working with the DOM)?
Yes! On one hand, the DOM is not not that big of a deal; yet it is also the core of what JavaScript is used to interact with. For starters, I suggest that if you're going to be using a browser environment, you should initially avoid the DOM by using Firebug's console.* methods for output so that you can focus on the "functional programming part and on the prototypal inheritance" and other core concepts. After these core concepts have been covered, then start introducing the DOM. It's best to introduce the DOM later as time will need to be dedicated to cross-browser compatibility, which will only confuse the subject if you are trying to teach the core concepts in tandem.
How do I automate testing for this? It's better if they have a clear idea on how they will be evaluated. Also, automated testing ensures objectivity and saves me time :).
Before (and after) the DOM is introduced, you could use something like JSUnit. Also, see this question: Automated Unit Testing with JavaScript. Once you introduce the DOM, you may want to have the students generate a document that you can walk and validate as SB suggested.
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: