The ECMAScript working group has started working on the next edition of the language. What can they learn from Ruby?
This is actually a much more challenging question than it appears at first.
The main reason for this is that it's been shown to be very difficult to force browser vendors, by way of specification, to implement the pet or favourite features of language enthusiasts, users, other vendors, or academics without very good justifications. This is how we ended up with the ES4 spec pretty much dead on the table, which yielded a much less ambitious (though still pretty awesome) ES Harmony. A language like JavaScript which has such insanely tricky political deployment and implementation issues is simply unable to be the type of awesome experimental playground that Ruby has been for much of its lifetime. Anyone who has followed es-discuss (the ECMAScript language development mailing list) has probably noticed by now that it takes many many months of debate and experimentation to merely articulate and agree upon common language features like, in recent memory, operator overloading, or short form lambda notation.
Perhaps it may be too much to ask of any working group to nail a spec that will target every device on the planet? On the surface it would appear that it's a very narrow band of lessons, even the social ones, that can be easily transferred from Ruby to the JavaScript.
To that end, and to ease the burden of Brendan Eich and his group:
One of the most urgently useful "lessons" to bring to the language from a perspective inspired by Ruby (or LISP) would be language malleability. The ability to introduce new features, syntax hacks and domain-specific languages not originating from a inner cabal of spec writers would be incredibly valuable. Allow the language to be a good place for modular extensions to the language to be made, and for those extensions to be self-hosted, so as to minimize fragmentation risks and to allow those changes to permeate and be mashed up, etc.
Such malleability would allow the community at large to apply lessons from all sorts of directions and allow the Internet to decide over time which lessons are worthwhile from which language, etc. We've already got a high rate of iteration and evolution happening at the other ends of this sandwich, i.e. in browsers themselves (eg: HTML5), and in js libraries. If that was able to happen more intimately at the language level, we could see some very interesting things happen very quickly.
[addendum/edit]:
The language has to be able to morph significantly because a small group of people is simply incapable of anticipating all the things it'll ever be used for. A theme that comes up on es-discuss often is that underlying current of designing "a language for the next 10-15 years". IMHO, this is an incredibly unrealistic goal. If you don't build it, the system will evolve an alternative long before spec's intended lifetime. With the immense speedup in javascript engine/JIT technology of late, we're already seeing the early signs of this happening in the form of new languages being written on top of JavaScript or being cross-compiled on the fly into JavaScript. Yep, even Ruby: http://hotruby.yukoba.jp/
Embrace function programming, don't try to bury it in static language constructs
Having a name that sounds like a gemstone is much better than a name that sounds like a skin disease.
But don't name your new language after today's hottest thing (that's how we all got into this "Java"script mess in the first place....)
build a standard library around the heavy use of closures, both for collection iteration and for the acquire resource/yield resource/dispose of resource pattern. that's one of ruby's biggest wins, imo. of course, part of what enables this is the brilliant decision to give every method one 'free' closure parameter, with syntactic support, so it's probably not going to look as nice in javascript. the techniques are still useful, though.
I can't see to much that it could learn from Ruby. The standards group has already given the language a mean to do resend messages, or messages to the protoype. The method_missing functionality might be cool to implement, but it isn't as necessary as better refelction facilities.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I'm fairly new to this whole web-development thing (2 weeks maybe, my 1st scraping of code exists here, I quite like it) and I ended up learning to use Adobe's Flash Builder 4, which I have come to quite like (although Action Script annoys me at times).
Recently however I've been reading a lot about "the future" of web development, RIAs, web 2.0 etc, and it appears the whole Flash/Flex/ActionScript frame work's main competition will be the HTML/CSS/JS stack (or "HTML 5").
So obviously I don't want to take the time to learn a language (Flash/Flex/AS3) that will end up dead in a couple of years and end up having to learn another one (HTML/CSS/JS), when I could just move over now.
My main interests are fairly information rich (database orientated) web sites, with high levels of user interactivity for customisation, uploading, etc. I like the whole mobile web aspect, and would like to have the capacity to also develop for that platform, as well as mobile apps etc. I love the whole "live" aspect (like the tour de flex light up map that shows user activity), not particularly bothered by uber complex animation and obviously want things to be responsive and user friendly.
So yea, any input on this would be much appreciated, I'd just like some advice for overall direction for my personal learning and development.
Thanks!!
You're making some basic mistakes in the question. The HTML/CSS/JS combination is different from HTML 5, That combination works just fine with current implementations (ignoring some of the annoyances of IE for the moment.) HTML 5 is a new extended definition of HTML with a number of new features like local storage.
HTML 5 is also not completely settled, nor completely supported.
You should learn HTML and CSS to start with; in general, you still need a web page in which to embed your Flash stuff. You should get some basic knowledge of Javascript for much the same reason.
Conveniently, the Javascript will carry over to Actionscript, which is a variant of the same ECMAscript standard.
Flash isn't going anywhere for a long time, and given the glacial pace that the HTML5 committee is working at, the HTML 5 spec won't be fully standardised for a while yet either.
Plus before all these lovely HTML5 web apps can become commonplace, the world's windows users will need to have a better browser than internet explorer 8. Given that 10-20% of web users are still stuck on IE6, i don't think we'll be seeing html5 becoming dominant for quite a few years. Of course then by that time we'll be seeing HTML6 and the slow painful process of getting the world to upgrade will start again.
Personally i don't do flash, because for what i do i really don't need it, but flash is a really useful tool outside of web development too. Lot's of triple A Games have flash built menu's and user interfaces for instance.
But really, become good at either/both technology, and you'll probably not be short of work
Learning a language like Actionscript can never be a waste of time , the mindset you will develop from it will enable you to understand the concepts of programming and it'll be easier for you to move to other languages if/when you so desire. Learning HTML & CSS is essential if you plan to develop for the web but it will not bring you the same type of knowledge, as it uses a very different logic. If you like the idea of developing web applications, one day you may want to develop desktop applications, HTML won't be of much use then, whilst the programming knowledge acquired with AS3 will not be lost.
Is this just for the fun of learning, or do you have any specific tasks to accomplish? I like to use the correct tool for the job. If you don't have a specific job to accomplish, or any constraints to work under, I would just pick the most marketable skill and go with that. Unfortunately, I'm not exactly sure which is the most marketable skill.
My recommendation would be to check out some JSON type stuff in JavaScript. That seems to be a pretty stable (might I even say fad-resistant) AJAX evolution which is pretty wide spread and likely to stick around for a while. If you focus on the high level theoretical concepts, the specific comings and goings of implementations won't be as important (in my opinion).
I think learning AJAX (using JSON rather than XML) is a good way to go so you learn about implementing asynchronous information rich sites. If you have to redraw the site entire site when you pull information, you're doing something wrong. The AJAX concepts will come in handy regardless of your platform.
Good luck!
-Brian J. Stinar-
Don't bother with flash.
Yes, it's pretty and powerful and fairly ubiquitous. It's also on its way out the door, as you observed in your question.
Let's compare Flash and its newly-arrived competitor, the HTML5 canvas element.
Flash is only supported by Adobe; if you want quality development tools or resources you'll have to buy from them (for the most part).
HTML5 canvas doesn't need proprietary development tools. HTML5 canvas is supported by every major browser vendor -- Mozilla, Apple, Google, Microsoft. All vendors will provide documentation and competition for each other, which should result in a more refined product.
When OpenGL support (direct gfx card access) was in discussion for HTML5 Canvas, guess who was the only holdout? Adobe, of course. Everyone else wanted hardware graphics support for canvas.
In other words it's Adobe against everyone else here, and Adobe's not going to win. They might keep the status quo for a while, but eventually they'll lose their foothold and canvas & co will take over.
tl;dr: No use learning the dying proprietary technology when you can learn the modern open technology that's going to replace it.
HTML5 is still very unstable, so you shouldn't try it.
For me, HTML5 is great, but some business haven't moved off of IE6, given its current state. Flash, while useful, can be very very tedious at times and other times it doesn't even work on some computers or makes some computers truly a pain in the "insert word here".
It's better to start with CSS and HTML4. Get the basics, then start going for more.
By then, you'll know what to want.
Personally I think all the answers here are overcomplicating things. Here's my take:
Use whichever technology excites you, and is best for what you want to build right now.
If the app you want to build right now feels perfect for Flex, use Flex. If something about HTML5 has caught your fancy and won't let go, dive into it. You can always change technologies in a year or three, and You'll be taking everything you've learned about design and architecture and usability with you - learning a new scripting language and some new tools won't be that bad. The only way you can make the "wrong" choice here is if you, for whatever reason, pick a technology that you wind up not enjoying enough to get anything built.
The reason I feel this is the best way is, nobody here can tell you anything useful about what technologies will or won't be around in a few years' time. Adobe could go bankrupt; Steve Jobs could die; Google could get broken up in an antitrust suit. Hell, Flash could be on the iPhone next year for all we know - or HTML6 could adopt a new, strongly-typed JITable programming language. Or a hundred other things could happen to render your (and our) predictions moot.
I mean, personally I expect that both Flash and HTML5/6/7 will be vibrant and flourishing in five or ten years - because they both have successful organizations behind them investing in their futures, and because I've never heard a whit of a meaningful argument why the success of one should require the failure of the other. But that's just a guess, and my guess is no better than yours. Focus on getting good stuff made now, and the technology road map of the future will come when it comes.
In my opinion – everything is worth learning, especially when it comes to HTML/CSS/JS/Flash, which are each completely different systems/skill pools tailored to entry-level developers.
HTML is tagged markup, and very important because it outlines XML usage. CSS is writing visual formatting rules. JavaScript is a scripted language, and a great way to get your feet wet with simple programming logic. And Flash is a great system in which to get into object-oriented programming within a compiled language.
As you keep venturing out, you'll find that a lot of technologies are really just different flavors of the same ice cream. While different languages have their own nuances, there are fundamental similarities between –say– most compiled languages. I came from Flash and got into iPhone development... while Objective-C is a way bigger and uglier system to dive into, I still generally knew my ass from my elbow while building my first app after several years experience with AS3. The same goes for .NET and Java. Also, I would second the notion that Flash is not dead, despite loosing traction in the wake of the iPocalypse. Whether it dies in a few years or not, it doesn't make AS3 any the less valuable to have learned in addition to HTML/CSS/JavaScript.
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.
Recently there is a lot of projects that pushes Javascript into other directions: as a general purpose scripting language (GLUEScript, Rhino), as an extension language (QTScript, Adobe Reader, OO Macros), Widgets (Yahoo Widgets, MS Gadgets, Dashboard), and even server-side JS & web frameworks (CommonJS, Helma, Phobos, V8cgi), which seems obvious since it is already a language widely used for web development.
But wait, everything is so new and nothing is really mature. However JS is around for almost 15 years, being as powerfull as any other scripting languages, being standardised by the ECMA, and being a mandatory technology for web development.
Why did it take so much time to gain acceptance into other domains than web browsers?
Douglas Crockford, who has done much to help people use JavaScript productively, also has a very clear picture of the things that hold JavaScript back. You can pick up a few of the points at JavaScript: The World's Most Misunderstood Programming Language. See also his lecture series Crockford on JavaScript.
The proliferation of Javascript as a viable language for heavy applications development isn't as old as the langauge itself... atleast it's definitely more recent than 15 years.
Mainly, it's popular and heavily-utilized right now due to the proliferation of AJAX and frameworks like jQuery/mootools/protoypes/scriptaculous and largely because browsers support is improving in compatibility, performances and whatnot.
Take, for example, Node.js which is built on V8 (which didn't exists until Google made Chrome) which strikes up the javascript performance bar so high that you can make high-performance networked applications on top of it dead easy.
So, IMO, it's because people jumped on the AJAX bandwagon that made JavaScript now suddenly becomes so much more awesome and spanning out to other areas.
There are some big flaws in the language surrounding code reuse - in particular, all code is executed in a single namespace, and there's no language-level support for importing other code. Plenty of enterprising library authors have worked around this on the client-side, due to necessity, but these problems are big ones to avoid when implementation choice is a language.
There is also not a single standard implementation of the language - Rhino is the most prominent, but it's not the most advanced in the days of SpiderMonkey, JavaScriptCore and V8. This shouldn't be as much of an issue with a standardized issue, but there's still a problem that non-browser JS code is unlikely to work with all JS engines, and very likely to be targeted to a single engine (Node.js depending on V8 is the most prominent example of this).
These problems have kept JS libraries from being written outside the browser, and since nobody writes non-browser JS libraries, writing non-browser JS becomes that much more difficult.
Things are changing - in particular, the CommonJS group has created a module spec that allows for better code reuse, which is already being used in Node, and are working on better specs for packaging JS code.
Language adoption is as much about the auxiliary libraries as it is the language itself. In the case of Javascript, there's a dearth of libraries for doing things like I/O and other standard requirements for fully-fledged use.
8 years ago I tried to have a brief look at JavaScript to see if I should learn more or not about it. I didn't. Why? I thought it would die within 2-3 years.
But thanks to JQuery and other JS frameworks it has gained very much reputation the last couple of years.
It's also associative. Do cars drive on water, do airplanes land on highways? JavaScript have always "belonged" to browsers, even though you could use it for non-browser related stuff.
Inspired by this question.
I commonly see people referring to JavaScript as a low level language, especially among users of GWT and similar toolkits.
My question is: why? If you use one of those toolkits, you're cutting yourself from some of the features that make JavaScript so nice to program in: functions as objects, dynamic typing, etc. Especially when combined with one of the popular frameworks such as jQuery or Prototype.
It's like calling C++ low level because the standard library is smaller than the Java API. I'm not a C++ programmer, but I highly doubt every C++ programmer writes their own GUI and networking libraries.
It is a high-level language, given its flexibility (functions as objects, etc.)
But anything that is commonly compiled-to can be considered a low-level language simply because it's a target for compilation, and there are many languages that can now be compiled to JS because of its unique role as the browser's DOM-controlling language.
Among the languages (or subsets of them) that can be compiled to JS:
Java
C#
Haxe
Objective-J
Ruby
Python
Answering a question that says "why is something sometimes called X..." with "it's not X" is completely side stepping the question, isn't it?
To many people, "low-level" and "high-level" are flexible, abstract ideas that apply differently when working with different systems. To people that are not all hung up on the past (there is no such thing as a modern low-level language to some people) the high-ness or low-ness of a language will commonly refer to how close to the target machine it is. This includes virtual machines, of which a browser is now days. Sorry to all the guys who pine for asm on base hardware.
When you look at the browser as a virtual machine, javascript is as close to the (fake) hardware as you get. That is the viewpoint that many who call javascript "low-level" have. I think it's a pointless distinction to make and people shouldn't get hung up on what is low and what is high.
A lot of people say this because the objects and structures provided in JavaScript are about as simple as you can get. To develop any sort of real functionality, you have to use an external library. Low level is a bad way to put this, because it already has a meaning in computer science. A better way to say it may be that it's without built-in libraries.
Compare this with Java, where the actual language really doesn't do a whole lot. Trying making an array without an ArrayList, or access the file system without the IO libraries. Most languages are more than just the basics, they come with this extra functionality.
With JavaScript, the only real power we get comes from the APIs that are introduced by the browsers and aren't part of the language. Things like DOM manipulation and Ajax are supplied by the browser.
It may be better to summarize all of this by saying that with a language like Java, you can get started doing some serious work without having to download third-party libraries, but with JavaScript, you either have to download a library or write a library of your own.
"Low" here has the same meaning as in the sentences "The number of casualties suffered in the first world war was low," and "Reduced-fat ice cream is low in calories." It makes sense when there's an obvious point of comparison, but out of context, it is simply absurd.
I don't view javascript as a low level language. A lot of functionality and user experience boosters are provided by it. Maybe others may view it as such simply because users can turn it off in their browser options, but it's a hugely robust language that virtually runs the web on virtually all types of browsers...
It's not, it may be as low-level as you can get in normal browser programming, but its on par with functional languages like Scheme or Python.
I think the great lacks of Javascript are lack of name spaces or packaging and no threads
It's low-level compared to the GWT and similar toolkits, but it's not a low-level language in the larger scheme of things. The features it offers are very high-level: closures, dynamic typing, and prototypical inheritance are just a few examples of its high-level features.
It's considered to be low level by a number of people who prefer writing java to generate javascript then writing javascript(ie they dislike it fairly or unfairly). A lot of people complain about java these days but despite the lack of static type checking most people would probably consider ruby and python easier to write in most cases (java being a fairly simple static language-which are much harder to design well without large built-in feature sets then a simple dynamic language).
Few people would call python or ruby low level compared to java and if people were forced to target a python or ruby vm its hard to imagine that a java to python/ruby compiler would become as popular as gwt.
In closing javascript has an image problem(people sometimes think of languages as getting more difficult as they become more low level and vice versa).
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: