We Keep Coding

Language to choose for a board game (flash or HTML5/JS)

I am developing a web based multi-player board game and wondering what the best language for the UI would be? Its a board game similar to Go but a lot simpler.
I have two options flash or the much touted HTML5 with JS. I have to learn both though I have basic knowledge of JS.
The problem with flash is I have to pay for the server component but the UI development could be easier and have a richer look and feel to it. With HTML5 + JS there is no cost involved but the UI development I feel will be clunky and not smooth. This I am not sure. Any experienced devs out there care to give some advice? Are there any particular issues to worry about, look into?
EDIT: Thanks for the comments. I will go with HTML5/JS.
As far as the server side goes, I have not yet decided what to use but want to look into node.js. May be I need to post it to programmers.stackoverflow.com about how it handles load and concurrent users.
Thanks,
Pav

Go with HTML and JS, you said your game was similar to GO, well check out http://govsgo.com/.
The site is written in JavaScript, well there's not much on the front end, the backend is based on Ruby on rails, check out Railscasts #237 (http://railscasts.com/episodes/243-beanstalkd-and-stalker) for some background info on the Ruby part.
You can even do really heavy stuff these days in JavaScript, like multiplayer asteroids (http://bonsaiden.github.com/NodeGame-Shooter/), so a "simple" game like you want to build, shouldn't be problem at all.

HTML5/JS will be less compatible with your audience. A lot of people still have non-compliant browsers.
That being said, HTML5/JS would be more fun I think. :)
http://html5readiness.com/ Provided by Robert Pitt

Is your game meant to be used on the iPhone? If yes, Flash is a no-go, as it is not available on the iPhone.

My vote: HTML5/JS.
Why? Consider:
Flash is fading away. On the other hand, you will enjoy a growing audience for your game (including iPhone, iPad and Android).
Flash is more expensive.
I am confident that you can create any UI in HTML5 that you can in Flash. In fact, and presumed limitations of HTML5 may actually force you to refine your UI in a positive way.
Have you seen Grooveshark since they recreated their entire application in HTML5 instead of Flash? Check it out as a proof of concept.
HTML5/JS is easy.
Flash requires a third party plugin, HTML5 only requires an up to date browser- which requirement is better for the user? Personally, I'd rather update my browser than install a third party plugin.

Since your making a multi-user game flash is the way to go. Multi-user stuff is possible with html5/js but as Chuck says its not available in all the browsers. For the multi-user side of things you can use Red5 (which is free) or SmartFox which is not free if you have more than 100 concurrent users. I built a big project with SmartFox awhile back and I found it really easy to work with. Depending on the simplicity of your game you could roll your own socket server code with a language of your choice.

Flash is pretty hard to learn unless you know Java or classic OO (I could add a lot to that comment). I would go with JS/HTML/CSS. As Chuck said, it would be more fun.
The server is only an issue if you plan to use Flash Interactive Server which is pricey. There are open source alternatives. But you say that as if JS has this built in - it doesn't. If you want real time updates, you'll need a CometD server and those are not easy to implement. I'd go with a short poll regardless of whether it's Flash or JS.

RIA Technology of Choice

I'm looking into creating a Rich Internet Application. For the interface, I want something smooth, fast, and robust. I realize there are several technologies out there to do just that (Flex, standard HTML/Javascript, Silverlight).
After using Grooveshark, I am very impressed with its interface (written in Flex). Personally, I don't think I have seen an interface written in standard HTML/Javascript that is that visually stunning, smooth, and fast.
However, I have heard many arguments against using Flex with many believing Flash will eventually fade away.
Anyway, I have seen solid applications built with each, and I know a decision can depend on many things. But, in general, what are the pros/cons for each technology and which one would you ultimately choose for your RIA?
NOTE: This would be an open web application with the intended audience being anyone. It's not being built for specific client(s).

I would make the decision based upon my client(s). For general "web stuff", I still am opposed to RIAs (I think they have more of a purpose in a rich client to a particular market, e.g. business -- or filling out online taxes returns -- and not general pleasure/browsing/navigating/site).
As far as Flash "fading away" -- haha. Yeah, right. We still have COBOL and Shockwave. A product with 99%+ market dominance (depends on market, of course) is hardly bound to "fade away" overnight. When the "eventual" does come, nobody will care about this next RIA project of yours anyway :-)

with many believing Flash will eventually fade away
Sure, just like any technology, Flash will fade out at some time. But that won't happen in the near future, so it would be a stupid argument not to use Flash (in the same way you could stop developing things for »insert any technology here«).
I know this won't be a real answer as you want some more comparison of the current RIA technologies, but it is hard to do that anyway. In some way, you can build any application with both Flash and JavaScript. For more complex application both will require quite a lot customization to get the application running the way you want it. At that point Flash might have a small pro point given that you have a bit more powerful language with it than JavaScript (which still has performance problems depending on the browser, while Flash is more or less stable), and generally don't need to build anything on HTML's elements. But in the end, you can stil do it with both, so maybe you should decide based on your actual knowledge with the respective language instead (or base the decision on the client).

I think you are right in saying that Flex/Flash applications far outshine their HTML/JavaScript counterparts as far as UX is concerned. However, the main drawbacks are mobile and accessibility. Flash currently has poor reach on mobile platforms, but that shows signs of improving. Also I don't think most screen readers can deal with Flash. Silverlight is probably just as good, but it's not used as much and does not have nearly the user base of Flash.

I don't think I have seen an interface
written in standard HTML/Javascript
that is that visually stunning.
I'm not a big fan of writing raw HTML/JavaScript because it's SO much effort to make it look as slick as some of the Adobe stuff. However, there are some pretty decent frameworks and abstraction layers that let you get a visually stunning front-end, and let you write the while thing almost exclusively in Java. I've had success with SmartClient/SmartGWT in the past to make an iGoogle-esque portlet web application.
Pros: Google Web Toolkit + Eclipse is free, don't have to write much raw HTML/JavaScript, saves a TON of dev time, aren't locked in to an Adobe product, GWT compiles to HTML+JavaScript and is absolutely universal
Cons: the high-end professional and enterprise versions are not particularly cheap (~2K USD)

HTML+CSS+Javascript is a good solution. And maybe you should consider your RIA can across device and platform. Test some javascript framewoks first, especially those with RAD UI Tools, For example, CrossUI.

Nowadays, RIAs should migrate to full JavaScript UI with CSS skinning.
The task of building the UI should be analogous with these of the old tools like Visual Basic or Borland Delphi. This means almost entirely configuration instead of hand-writing the interface code.
You should also consider choosing a consistent widget set the follows the way of web components, i.e. inheriting from Element to always stay in sync with browser technology changes.
Here is a tool to help you evaluate several frameworks:
https://sourceforge.net/projects/jul-designer/
Remember, following the standards and eventually anticipating them, is the best way to go.

How often do you find javascript disabled on browsers?

I have started using ajax/jQuery in our websites / application. There are many plugins that support degrading the javascript to browsers that dont have javascript enabled and techniques to support this. What are peoples thoughts on javascript support, we build applications rather than just websites and are looking to just support javascript enabled browsers as a pre-requisite assuming that most people or companies have javascript enabled.
Do you find most people have javascript? do you monitor the percentage of javascript/non-javascript browsers (I guess this can be done with website stats) and what are the numbers regarding this?

Whether you should be worried about this really depends on what sort of website you are creating. For instance, if you're creating a rich javascript app, you have to ask yourself if it's worth your time & effort to worry about javascript disabled browsers, as these users are probably not too concerned with using rich user interfaces anyway. Also do you have time to put in the extra work for these browsers as there will be little extra traffic and profit gained (if it's profit making website).
Also note that if javascript is disabled in these user's browsers, there will be much on the web these people cannot use. So in all likelihood they're not heavy users.

According to these metrics, the following percentages of users have JavaScript disabled:
EU: 1.4%
US: 3.05%
But the numbers are from 2007, so they are rather old. I would think the percentages are a bit smaller by now, but who knows?

I know this is a very old thread, but I thought I'd post this for reference:
According to this website, only 0.4% to 2.4% of users had JS turned off. The first test they ran was with about 13,500 users, which is admittedly small for the interwebs, but it's still quite a large amount of people. This data is from 2009

I really feel quite strongly that a well designed web site should remain functional with or without JavaScript switched on. JavaScript, in most cases, is there to enhance existing functionality.
This can usually be achieved by following a few simple rules.
Use unobtrusive JavaScript, avoid in-line (certainly) and in-page JavaScript whenever possible.
Anchors should always link to somewhere, not to # or to JavaScript. If you can't get around it, the link should be created dynamically.
Use forms correctly. A button should always be wrapped in form tags, this way the your functionality can always degrade to the server.
I believe that following these rules makes for a more robust site that is more accessible across multiple platforms. Not to mention the benefits to search engine optimisation, if you rely on JavaScript, the search engine will only see half your site.
I prefer the idea of progressively enhancing rather than planning for degradation. I'm absolutely not developing for the minority that intentionally sabotage their Internet experience by switching JavaScript off. A site built for progressive enhancement will work better on mobile platforms, screen readers and search engines.
Rich

As a whole, I think you can expect any browser that supports CSS will have JavaScript enabled.
However, it's not always a question of JavaScript being enabled/disabled on the browser entirely. Most of my friends/coworkers use NoScript to only allow JavaScript on specific sites.

It depends on what you are doing.
Is it a website or web application?
A website can be done with just static html and, if needed something a little more complex, a little bit of server side programming.
A web application, today, is all about javascript.
So if your visitors have js disabled, they are likely not interested in your application nor any other. So why bother with them?
Just concentrate in the other 98%, where your potential customers/audience is.

It deppends on the size,
Big applications like Gmail often have 'basic html' versions to support old and secured browsers. If you code your ajax with this in mind, you might be able to reuse most of the code.
Medium sized applications, especially if the user uses them regular, will probably not find it worthwhile to support the few percentages.
Small sites / sites that mostly uses basic html navigation, should try to do without javascript. Most of the time, modern css tricks will do better, faster and make more sense codewise.

Best Technologies for AJAX Web Development

I have some experience in AJAX development, mostly on .NET and MooTools. However, I want to learn more and see what others out there thought about the various other options available. I am looking more for advice about the front end. The back end, I will most probably be coding it in .NET using c# and WCF services.
Please feel free to provide me as much information as you can. Also, I would appreciate any links to resources.
List of Options (feel free to add)
Write my own Javascript
Use a framework like MooTools, JQuery, etc. Which one is better?
Use Google Web Toolkit. Am I tying myself to the limitations of GWT? Or are there not limitations?
ASP.NET AJAX
WPF (Will this run on non-IE browsers?)
Flash (it'll be a pain to learn action script)
Thanks
Jaspreet

Writing your own Javascript often means reinventing the wheel when it comes to trying to attain cross-browser compatibility. Frameworks such as jQuery and MooTools take care of much of that grunt work for you.
Personally, I would suggest picking a Javascript framework or using GWT, but really it's just a matter of personal preference at that point, much like choosing a programming language. Pick that one that is best for your purposes, or that you're most familiar with.

I'd go with jQuery.
jQuery will be bundled with the next version of Visual Studio. Google uses jQuery. jQuery has the largest user-base of any of the frameworks out there.. And speaking of not re-inventing the wheel: jQuery also has the largest plugin-repository of any of the frameworks out there.. Including its own official UI library which is in constant development.
.. And if you're a fan of books; there's 3-4 books about the framework out currently.
Oh, yeah! Check out Douglas Crockford's website for great vanilla JavaScript tips and tricks.
Just my two cents :)

jQuery
prototype
MooTools
dojo
GWT
ExtJS
Those will all have you working with very solid code, which is usually the best way to improve your own skills. And don't forget all their extensions/plugins.

I would recommend jQuery. It's more extensible and light-weight than most other JavaScript libraries I've seen (and you can have it Google-cached with the AJAX APIs).
For Flash-based AJAX web apps, Flex is a better solution.

Since this is a fairly subjective question I will put in my 2 cents.
I've developed using the Dojo toolkit and found it very well rounded. However, if you don't do a custom build on your library it slows everything down. It has a steeper learning curve than other frameworks, but seems to sit pretty close to heart of Javascript.
But this isn't an advertisement for dojo. I'm working on a Ajax web app currently and my goal is to try and avoid using a framework. Why? A few reasons.
The biggest reason is complete control over the code. Not that I don't trust toolkits, I just like my custom code. I don't have any code that I don't use, and all of my abstractions are custom made for my purposes. At times I am in fact reinventing the wheel*, but its always a bit different because it's purpose built.
The other big reason is the amount of knowledge I gain. I'm confident that I could pick up any framework much faster, because of not using one for a project. I understand so much more than I did previously. Before It was more like a voodoo mystery box, and now even frameworks make more sense to me.
The fact of the matter is if you do any non-trivial javascript you will end up with a framework (or a mess). In reality it may not be the fastest way to write web apps, but it isn't all that hard with a little practice. You can be amazed at what creative things you can come up with that didn't exist before.
*Reinventing the wheel is a terrible analogy that we all use. We reinvent wheels all the time. First made of stone, then lighter wood, tires, etc... My truck doesn't have the same wheels as my sedan.

Like other responders I prefer to use frameworks, but my favorite is dojo -- clean and well-designed architecture, good books (my favorite being Matthew Russel's), and a particularly impressive approach to using browser extensions (such as Google Gears or Microsoft Silverlight) if the user has them installed, while falling back gracefully (e.g. to Ajax-interfaced server-side storage) if no suitable browser extensions (or sufficiently advanced browsers, with HTML5 support) are present.
Dojo is, currently, slightly less popular than jquery (e.g., [jquery ajax] has 8.4 million hits on Google Search, vs 4.3 million for [dojo ajax]), but that's still way popular enough to ensure it won't go away any time soon;-).

You must check ExtJS.
Most libraries I've seen have usable core but lack the widget/control library that will blend-in with each other. Sure you can get a vast number of controls for jQuery, but do you have the time to find out which ones have intended functionality and tweak their visual appearance to match the rest of controls? ExtJS gives you just that. Core is core. It works and it works great. But the vast selection of compatible and functionality rich controls is the main driver that will make your life easier.
I've used ExtJS with Asp.Net and WCF services and it was a really nice experience overall. You will need some time to get to know ExtJS component model to extend it even further (as you would need to do the same with other libs), but when you do, you start loving it even more.
One more thing: since MS ships jQuery with MVC it doesn't mean it's the best. It only means it's one of the best (and much better than Microsoft's in-house Ajax) but with the most relaxed open source license.
Edit: Now that Silverlight 3 has shipped it became apparent it will shake things a bit with its offline support and rich graphics support. As well as standalone desktop like web apps. Definitely something to consider...

Please note that WPF has nothing to do with ajax.
AJAX = Asynchronous javascript and xml
WPF = a windows-only UI display technology. The only option there for in-browser use is to create an Xbap. The more-suited-for-the-web counterpart is silverlight (say, like flash but from microsoft), so perhaps you should look into that as well... it's like using flash, but with familiar MS technologies.
Concerning your question about which framework to use in case of ajax: I prefer jQuery. It's short syntax and chaining allow you to reach your goals very fast in an intuitive way.
Also, GWT is a Java framework that also renders stuff on the client, as far as i know. So you would have the limitation of Java as backend language...

GWT has made considerable leaps and bounds over the past 7 months. The mutiple GWT widget libraries have received a good deal of attention, and Google's work on the library has been impressive. Going GWT limits you to:
Using GWT widgets
Possibly becoming a GWT widget developer
The benefits include:
Coding in Java
Debugging in Java
Skipping the parts of JavaScript that make you pull your hair out
GWT is the step past AJAX. It buries the HTML / JavaScript so that you don't need to deal with it, but also provides access in case you do want to deal with it.
Overall, you will spend less time trying to get small things working, and more time adding awesome to your application.

there is also prototype.js

Try the Yahoo! User Interface Library (YUI)

Pick a library to learn, then pick up the others--but I don't think I'd reinvent the wheel.
I picked MooTools and have picked up jQuery/Prototype since. (Picked Mootools because their site, at the time, was the only one that validated, figured clean html meant clean javascript).
Side note about MooTools:
An often overlooked feature of MooTools is the download builder. You can download just enough of the framework source to get your AJAX working, and nothing else.

There's the BBC's open source javascript library called Glow

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