We Keep Coding

What is the difference between Cappuccino and Node.js?

I have been working with node JS for about two weeks and I am liking it a lot. I came cross something called Cappuccino; it sounds like what I want to use to develop a web application. As a beginner, can someone assist with explaining what exactly Cappuccino is and how it fits into node?
Really my hold up with developing an application is that I come from a VB background and I am use to forms to design my desktop apps. I do not want to be limited with a WYSIWYG type of IDE, that is why I started with node.

What sort of web application? There are... many JS libraries/frameworks. It's a jungle.
My strong advice is to build several things, from very small to less small, using pure Javascript. Otherwise you will, I promise, remain forever cloudy on what the language is vs. the frameworks layered on top. JS is very mutable and frameworks have a tendency to create new semantics on top of the core language. The downside of learning by using these is you ever fully understand the complexities and subtleties of the language itself, nor do you ever really understand what those frameworks are giving you (in many cases, things you don't need or that artificially constrain you). Be wary of framework entanglement.
As you get used to writing simple scripts in a text editor (try Sublime Text if you want something much better than that), you'll begin to appreciate when and why you might want help from a framework. Move on to jQuery, as it's the most widely used library and is either a dependency or heavily informs the style of many other libraries out there.
I'm working on a blog post about the topic of frameworks, by no means comprehensive as there are hundreds of them it seems. Specifically, breaking down about 20-30 major players by their intended domain (e.g. DOM manipulation, Single Page Applications, data-binding, MVC, etc.) and strengths and weaknesses.
There are some great books and YouTube videos going into many aspects of modern JS. Anything by Douglas Crockford I recommend (especially book or video "Javascript: The Good Parts". He's pedantic but wise and generally on the money. Then for more inspirational stuff about recent/upcoming changes to the language, watch some stuff from the Google I/O events. Check out HTML5rocks.com for articles on some cutting edge features available in the browser. There are many many more resources, but these are some good ones.
Oh and be sure you are familiar with the dev tools in the browser. I personally recommend Chrome as best of breed. Learn the keyboard shortcut to open it on any page, inspect, and noodle. There are some fancy things such tools support like live editing/saving of source, profiling and debugging, DOM/CSS inspection, and on and on. There are other free and non-free IDEs but IMHO they are too much overhead for someone just learning (and many advanced JS developers use Sublime Text).
P.S.: jQuery, per its design goals, is still going strong but is aimed for obsolescence as browsers increasingly are converging on true standards (ES5, HTML5, CSS3). Even so, for many apps, its shorthand semantics are much better than even the newly supported standards for many things. And it's not going away any time soon, just becoming less important. Like IE. Ignore IE unless you need to build things for work.

As far as I can see, Cappuccino is a client-side framework of some kind, in the same kind of vein as Backbone.js or Angular.js, and is in no way comparable with Node.js. They run in completely different environments (Node on the server, Cappuccino in the browser).
A client-side framework like Cappuccino would be used to implement web apps that needed to do a lot of work on the client side. For instance, if you implemented a real-time web app with Node, you might use it to simplify inserting new content into the DOM.
I haven't used Cappuccino, and it doesn't seem to be all that popular. It seems to be squarely aimed at people with a background in Cocoa development on Mac OS X, so if that's not what you're after I would recommend you look elsewhere. Client-side MVC frameworks are very useful for some use cases, and the big four seem to be Angular.js, Ember.js, Backbone.js and Knockout.js, so I would check out one of them before considering Cappuccino. Knockout is very easy to learn, but lacks routing, which was a deal-breaker for me, so I switched to Backbone. Considering how much mindshare it seems to have, I would probably now go for AngularJS.

Cappuccino is a client side framework built on top of Objective-J which in turn is a complete language built on javascript. It's intended solely for building desktop class applications that happen to run in a browser.
Objective-J adds features to javascript (like classical inheritance) in the same way Objective-C adds them to C. You can use Objective-J with node but probably not most of Cappuccino. Cappuccino is the framework that lets you build rich user interfaces in a way that allows you to completely ignore that you're working with html.
I would not recommend Cappuccino as a first foray into web development unless you really only want to build a business application and you are already a proficient Mac OS X or iPhone developer. It will not help at all to teach you about the web.
Cappuccino is (imho) head and shoulders above everything else in its league, but it is intended (or most useful) for a very tiny niche.
If you're still interested in Cappuccino (or Objective-J) you should really check out the learn section of the Cappuccino project website

Is there any IDE/Framework/etc to develop a complex web (RIA like) not using Flex/Flash Builder?

For a quite long time I was used to use the Flash Builder (previously called "Flex") enviroment to build complex applications, and in my current project (cant say what project is, sory) Im part of a RIA made in Flex, using mxml, AS3, some JS, etc.
The performance is below average.
The site feels like u need a powerful PC to run it something close to smooth.
And Im working with very talented ppl here, or at least thats what I can perceive.
So my question is, there is a posibility that the next version of the website will be made in pure HTML + CSS + JS, to obtain a more responsive feeling when u use the site, is something at least close to what FB can do for you in terms of a project-oriented enviroment?
On another hand, this general laggy and low performance thing is a programmer related issue, or it cant be avoided since "its just Flash" ?
Thanks!
(Im a big fan of flash tbh, but I try to keep my mind open in this)

Everything depends on what you're trying to do and if your programmers know how do to their jobs. If they don't take care, then it's very easy to create an application in Flash, and especially Flex (as you really need to know the internals of Flex to understand what it will do and when), that saps memory and power so that you need a beast of a machine to run it. Optimisation is a large topic, but fortunately, the web is covered in links on what not to do, or tips on how to use Flash to it's full potential.
As a quick test, open up the task manager, then run your app (close down all other programs using flash, including gmail, web radio etc), then watch the memory usage. If it's continually climbing, then there's a problem in your code.
Alternatively, if you have a bit more time, build some debug tools into your app so you can see what's going on in terms of framerate and memory usage - try the FlashPreloadProfiler for a quick fix: http://jpauclair.net/flashpreloadprofiler/
If your app shouldn't be complex but it's lagging (by complex, I don't mean the actual purpose of the app, but rather what it's showing on the screen, effects etc), then the problem is that there's misuse somewhere.
Go the HTML5 route if you feel it's the best solution for your site/app, but you'll probably encounter the same problems. In some situations, it's slower, in others Flash wins by a country mile. Again, it comes down to the devs

We built Dedoose in Flash Buidler 4, check it out... the performance is freaking great, and it's is a GIANT web app that handles an enormous amount of data. Flash Player in general does have performance problems, but with great engineering and knowledge of how to squeeze good performance out of it, I personally do not see a better alternative, excerpt for maybe silverlight if your requirements fit. For guidance on performance improvements a good place to start is all of Grant Skinner's articles over at http://gskinner.com/blog
Additionally, I can't really see what the actual question your asking is, what are the alternatives? HTML5+CSS is good, but good luck getting any good productivity out of your team developing a large scale web app in it. Silverlight is pretty dang good if you can force plugins down the users throat, Java is suffers the same dilemna. Personally I would read up more on getting good performance out of flash, then learn exactly how the flex framework works in terms of what it builts upon flash with, then... if u want real performance, ditch most of the flex framework and use things like MinimalComps and custom built components. Have you used the Flex Builder Profiler to analyze where your slow downs are occuring?
~ JT

If it's just an IDE you want, I'll give a nod to Flash Develop: http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page
Not all the power of Flash (Flex) Builder, and without the design view. But it's free, open source, and community driven. I personally prefer the style of context highlighting and code completion hints in Flash Develop.

Need help determining how to approach building my project

I'd like to create something similar to a family tree online app (like geni.com). I'm unsure what languages I should use to build it with. My IT strong points aren't in programming and this project is going to require me to sit down and learn some languages. My problem right now is that I don't know what languages I should use.
So with the idea of a family tree online app in mind here are some of the specifications.
- I do not want to use flash.
- The app needs to be zoomable and scrollable (sort of like google maps)
- The app needs to be able to add content without reloading the page. Perhaps there's a little "+" sign and when I click it, I can add a tag/title/description/picture
- The app needs to be able to save your work for that user to retrieve later on.
- The layout that a user is able to create in is sort of widget based where the user can add a new bubble and then in that bubble they are able to add text or content.
I started programming this with HTML5 canvas and Javascript, but I'm stuck on creating a connection to the database that isn't directly from Javascript (because that seems very insecure to me). But I'm not just stumped on how to interact securely with the database (I don't even have a database picked out), but also I'm concerned that I won't be able to build out the app with just javascript and may need something else like ajax or something but I'm unfamiliar with what each language does nowadays.

If you are starting from scratch, then the best language to use is the one you are most comfortable with. Alternately, if you don't plan to be developing the whole thing yourself and you already have some other interested parties on board then the best language to use is the one that the majority of you are comfortable with. If it's just you and you do not yet have any favorites, then look around and play with a few - it's the only way to find out if you will actually like / be effective with them.
That being said, a few of the more likely candidates these days are:
JavaScript: Long gone are the days when this language was simply a way to put the D in DHTML. These days JavaScript is a viable client and server-side language. (Others here have already recommended Node.js -- I'd also recommend NPM (node package manager) to handle your dependencies). With a little bit of planning you can reuse most of your application code on both the client and the server side. On the downside, most of the server side technology is very new (only a few years old at most) and so you may find yourself implementing tools for use in your application rather than your application itself. Finding servers that support it will also be harder, again on account of it's age.
Perl: At the opposite end of the spectrum of age, we find Perl - the first commonly deployed language used to make web applications it still powers a great variety of useful websites out there (include new ones such as Pinboard.) The tools that are popular on CPAN have been vetted under fire. The good news is that it is not going anywhere anytime soon. The bad news is, you might have to search a little harder to find a module that supports [that newest, baddest thing that just came out yesterday].
PHP: The BASIC (or Perl, depending on who you ask) of the modern web, PHP was designed from the ground up to do one thing - make building dynamic web pages easier. Its popularity means that there is quite a lot of server support (PHP + Apache + MySQL is the Model T Ford of web servers -- everyone can afford one) and an enormous amount of pre-built code available for perusal. However, like BASIC, PHP's strength is also its greatest weakness. Almost anyone can write something that works in PHP ... how well it works depends on who wrote it. The caveat emptor that applies to all code snippets found on the web applies in spades to snippets of code written in PHP.
Python: The language that made programing fun again (at least for those who can see past the significant whitespace and lack of blocks / anonymous functions and overlook < 3.x's issues with non-ASCII out of the box.) It's a general-purpose, flexible and multi-paradigm language with quite a substantial standard library (but without .NET or Java's incredible bloat). In addition, quite a large amount of work has been done in it, so there is a good chance that what you need has been already developed by somebody else. Plus, it can make you fly.
Ruby (with or without Rails): The language that made the web fun, coupled, if you so desire, with the framework that made MVC cool. There is lots of documentation out there, and a great community, with many prebuilt tools (called gems) from which to pick and choose - free and cheap servers are not as common as their PHP counterparts, but they are likely to be of higher quality (when chosen at random).
All that being said, they are all great languages for web development. What matters is not what we think you should use ... but what you are most likely to be effective with. All of the languages listed above are mainstream (or will be in the next two years), easy-to-learn and easy-to-write languages. You cannot go wrong, no matter what you choose to start off with.
Alternately, if you want something a little more difficult, or less mainstream ... I am working with .NET applications at work, and with Lisp (SBCL)-based services in my spare time. I have heard great things about Lua and Java too ... there are at least two C++ web frameworks out there ... and I'm sure that there is somebody is having fun building a web service in COBOL with a FORTRAN backend. ;-)

As someone has already pointed out, you will need to work with a server side language as well. (Ruby, Python, PHP) You are exactly right there you should not be attempting a database connection via javascript in the browser.
You'll need to build out a server side application to handle the basic operations of your application.
I'd strongly recommend reading up on the MVC design pattern, and possibly looking into Ruby on Rails as your backend framework, it plays very nicely with ajax like features, and has a somewhat shorter learning curve, I believe, than some other frameworks / languages.

You will need server side scripts in a language like PHP or Ruby on Rails to interact with a database.

If you're already familiar with HTML5 and JavaScript, may I recommend using Node.JS? It's about the closest you'll get to what you already know with browser development. It can also hook in with database systems which are closer to the HTML5-suggested IndexedDB.
with that in mind...
If you're inexperienced with programming and programming languages, then the app you describe will involve a pretty big learning curve. While Flash and Flex have really nice interfaces to build apps with click-and-drag, the tools for HTML5 are much less mature.
That's not saying it's not possible with HTML5. Just that there's still some time to wait before people create tools to bring the app building process closer to what Adobe provides.

JavaScript/CSS vs. Silverlight vs. Flex

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:

Why should I use Flex?

In a recent conversation, I mentioned that I was using JavaScript for a web application. That comment prompted a response: "You should use Flex instead. It will cut your development time down and JavaScript is too hard to debug and maintain. You need to use the right tool for the right job." Now, I don't know too much about Flex, but I personally don't feel like JavaScript is too hard to debug or maintain, especially if you use a framework. JavaScript is also one of the most used languages right now, so it would seem a better choice in that regard too. However, his reply piqued my interest. Would Flex be a good choice for a distributable web app for which 3rd party developers could build add-ons? What are the advantages of using it vs. a JavaScript framework? What are some of the disadvantages?

I have recently started to develop Flex applications, and I personally find it a refreshing framework for the web.
You get a state-ful application that runs completely client side. You get no worries about cross-browser portability that you do with JavaScript, and you get some really neat things such as effects, graphing, and rich user interface components.
Flex also makes it easy to communicate to webservices and the XML parsing via ECMA is insanely powerful and simple.
I'm glad I have made the switch. As far as how popular it is...I'm not really sure, but I am fairly certain that the developer base is expanding rapidly.
The only real disadvantage I can think of is a flash player requirement, but I would say it is pretty safe to assume that most browser support flash player; even konquerer in Linux is supported; much more so then a silverlight runtime (which I NEVER plan on installing)

Here is my experience: you really need to consider 2 things separately - development and the end-user experience. Flex shines in the first area:
ActionScript is a nice mixture of Java and JavaScript so you get a familiar language with strong support for OOP
debugging is far easier than what you can achieve in JavaScript
Flex framework is component-oriented and event-driven which helps in creating rich user interfaces (HTML was not really created to support application UI scenarios)
On the other hand, the end-user experience is worse when running a Flex app compared to an AJAX app. First, you need to have Flash Player installed but this is probably not an issue for most computers today. Bigger problems are with usability - Flash Player handles all UI interactions (instead of a browser) so the password manager doesn't work, text fields don't remember previous entries, Ctrl+T and middle-clicking doesn't work, text search doesn't work etc. etc.
My advice would be - if you are developing an application (rich UI, relatively separated from the rest of the web), go for Flex as it will save you time, money and will make your users happier by providing richer functionality and shorter periods between new versions. On the other hand, if your application needs to be tightly integrated with the web and you want your users to be able to use features of their browsers, go with AJAX.
Nice example is Google Docs vs Buzzword. Buzzword is much more feature rich (for instance, text can flow around an image from both sides which is something you could never ever achieve in DHTML) but Google still decided to go for an AJAX version because they are the "web company". There is no right or wrong in doing it the one or the other way, it's just different and it's important to consider who your end users are.

I would push you towards standard web development technologies in most cases. Javascript is no longer a great challenge to debug or maintain with good libs like jQuery/Prototype to iron out some of the browser inconsistencies and tools like Firebug and the MS script debugger to help with debugging.
There are cases when Flash is a better option, but only in cases where you are doing complex animations. And, if you are willing to invest the effort, most animations can be achieved without resorting to flash. A couple of examples...
Flash content is not as accessible as other content.
This will not only affect people with out flash, but also search engine spiders. There may be some hacks to help get around this now, but I think that most flash content will never be indexed by google.
Flash breaks the web UI.
For example:
If I click my mouse wheel on a link,
that link is opened in a background
tab. In a flash app there is no way
to simulate this behavior.
If I select text in my browser and
right-click I get options provided
by the browser that include things
like "Search Google for this text".
In a flash app those options are no
longer there.
If I right click on a link or an
image I get a different set of
options that are not available in a
flash app. This can be very
frustrating to a user who is not
"flash savvy".

GWT lets you do the same stuff as Flex for the most part, and handles all the browser compatibility issues, AND lets you code/debug in Java with your favorite IDE.
All without having to learn a new language (or pay Adobe $$$ for the flex IDE you'll need to do anything real).
Flex has some prettier UI widgets than GWT has out of the box, but there's a ton of 3rd party widgets (such as GWT-EXT-JS) you can use - or, you can use your existing favorite JS widgets with GWT.
Check it out if you haven't: http://code.google.com/webtoolkit/

I can't be sure if it was myself, or someone else who made that statement but I would definitely be one to say 'use the right tool for the job'.
Flex has a large community behind it, and is well hyped by Adobe's platform evangelism team. Now, as far as replacing JavaScript, that sounds like a very broad spectrum discussion point. Flex is not a replacement for JavaScript. What it does, it does well, however. That is, 3D, drawing, and data rendering whether in chart or table form. Flex also has the power of ActionScript 3 behind it which allows you to do much of what Flash does in cooperation with the MXML frontend components without ever touching the timeline or keyframes.
In a way, Flex is the .NET of Flash and Rich Internet Application development. It uses the same datasource concepts, and component focused design structures which make it easy, and fast to develop in.
The real question is, what are you trying to achieve? What is the end goal?
As to the debugging point, Flex has a true debugger and profiler within the Flex Builder IDE. JavaScript, unfortunately, has different syntax and execution between browsers due to the nature of JavaScript engines in modern browsers. Flex, because it is essentially Flash, uses the same rendering engine in all browsers due to the use of the Flash plugin.
Hope that clears a few things up. :)

Flex has a lot of extra overhead:
New language
Clients must have flash installed (might need to install, might not be able to)
Clients must download flex framework (few hundred kilobytes)
Flex content is not indexed by search engines (contrary to what Google might claim)
Flex has one main advantage:
- Better at building rich interfaces (see Picnik.com, etc)
For example, in Flex, it is easy to create a custom styled dialog box, complete with drop shadows, inner glows, animated open, whatever you might want.
In summary, use Flex if you need the extra richness.

Aside from what's already been mentioned here, another major difference is that JavaScript is dynamically typed and ActionScript is statically typed. Whether that's good or bad will depend on your point of view :).

If you want your web application to look like it's not a web application, Flex is pretty good. You also get to sidestep all the messiness of making HTML+JS look like a real app. For something which is essentially a website, Flex might not be the best choice, but if you really want to write an application which happens to be accessed through the browser, it's quick to develop with and gives great looking results.

You should try Google Gears instead. Create your application, add some Gears to it, and you can greatly increase the speed (and reliability) of your application.
http://gears.google.com/
Essentially Google gears gives you access to two useful things for any application: offline data storage, and native threading control (allowing updates/computations to run in the background and not slow down the users computer).
The really nice thing is, you can use whatever Framework you like for your application, as long as data storage/retrieval and server side communication is handled with JavaScript.
It also allows you to cache whatever files client side you want, which is especially useful when you want to avoid that 'flickering' look in the browser while some needed image is being downloaded by the browser.

A few reasons to consider Flex:
The control library is much richer in Flex than anything you can do with JS/DHTML. The charting controls are killer for business apps and things like the DataGrid / AdvancedDataGrid are pretty well ahead of anything you can do with HTML.
The Flex framework was designed for building applications. It abstracts away the "frame-based" concepts in the Flash Player to really make it easy to build apps. It has a well-designed component hierarchy that makes it easy to extend any of the standard controls. It also has a pretty intuitive event model for handles user inputs and makes it easy to have any of your controls dispatch custom events that can bubble up to parent components or get routed through a central event dispatcher. While it may be possible to do this with JS/DHTML, I don't think it's nearly as easy and it certainly wasn't designed for it.
You can take a Flex application and quickly deploy it to the desktop with the AIR runtime. AIR also offers additional APIs for things like local system access, embedded SQLite DB, etc. Gears offers something similar but it does require a browser. Granted, AIR requires the AIR runtime but at least it's purposed towards building desktop apps.
You can build a very rich, very sexy UI that will knock your users socks' off. As programmers we might not care about UX but our users do. Part of the reason why Apple is having a lot of success lately is because they really value UX and users/consumers are taking note of this.
The biggest con I think is that if you are really used to Java or C#, the ActionScript language will seem a bit limiting. If you're comparing it JavaScript, it's at par or maybe slightly better.
A lot of people will rail on Flash Player (or AIR) because it's not "standard-based." If we were only willing to use sites that were 100% standards compliant and free of plugins, we wouldn't have YouTube today. Or pretty much any other site that does interesting data visualization you can't do with HTML/JS (or at least, not with a sane level of effort). Adobe has been pretty progressive in opening up the Flex framework, Blaze DS (for backend Java development), publishing the AMF spec and starting the Open Screen Alliance to push Flash Player to mobile devices. Flash Player, Flex, Flex Builder and Blaze DS all have public JIRA bug trackers. I'd say there is a good chance that Flash Player itself will be open source within the next 2-3 years. I think Adobe is continuing to move towards being very open and that the criticisms of the platform being "closed" and "proprietary" are becoming less relevant. I think if developers approach Flex/FP with an open mind that they would really be impressed with how it all fits together.

This comparison table was good enough to make me decide what to use . I prefered javascript:)
http://askmeflash.com/article_m.php?p=article&id=11