flensed FAQ
Q: Why flash, what's wrong with Javascript/CSS only solutions? A: Well, first off, Javascript and CSS are highly fragmented among the various browsers. Some challenges have no good workable solutions cross-browser. The Flash Player plugin by contrast has a much higher rate of adoption worldwide (99% now External Link) than any of even the most common Javascript frameworks. It also almost guarantees a reliable, consistent presentation experience, and has an extremely powerful scripting language (very Javascript-like, in fact!) powering its functionality.
Secondly, there are several things which simply cannot be done only with Javascript, or at least cannot be done as reliably or securely as with the Flash Player plugin. Authors can spend endless amounts of effort trying to convince the browser vendors to find common ground for the benefit of all, but the history of these efforts is not all that fruitful and is likely to still be a long way off, if ever. flensed leverages existing technology and finds solutions that can be implemented right now.
Q: Don't users have to "click-to-activate" with SWF's on a web page in certain browsers? A: Not anymore. Firstly, the IE browser (as of April 2008 External Link) has now been allowed to remove this annoying "feature". But moreover, the revolutionary CheckPlayer project, powered under the hood by some ground-breaking code released by the guys over at SWFObject External Link, makes this frustration totally moot and avoidable now, no matter what browser or version your users are on.
Q: What about the people whose Flash Player plugin is really old/out-of-date? A: CheckPlayer implements Adobe's Express Install External Link feature to create a nearly seamless automatic-update path for any user with at least Flash Player v6, which is almost everyone by now. You decide what version is the minimum for your SWF content (flensed projects use CheckPlayer automatically and specify the minimum version for you) and then decide if you simply want a version check or if you want an automatic update. If you choose no auto-update, or the version check is not the minimum for Express Install, your code can still at least determine this case and handle it manually. In no case (except for broken or no Javascript support) should your page be left in a place where it is unable to determine the Flash Player plugin support available and thus make appropriate alternatives available as necessary. And even in this worst case, since CheckPlayer is based on SWFObject External Link, their useful concept of "alternative markup content" (static HTML in place of the SWF) is available if you so choose.
Q: What about the people who don't have Flash Player plugins installed, or who have them disabled? A: Every day, this number is shrinking. Flash has truly become a ubiquitous technology. I believe its very solid to rely on for a very broad audience. However, because it's not 100%, all flensed projects do their best to gracefully degrade in the absence of SWF support. The same argument played against Javascript is valid but moot because users without Javascript will not have any of the fancy website functionality benefits anyway, and most forward-thinking web authors are not targetting their content to such a small, limited group.
Q: Isn't the Flash Player plugin really memory intensive on the page, especially multiple instances of it? A: Adobe has made great strides on this front. The newest generations of their plugins utilize some very good and effective memory management/sharing techniques, which make this problem much less severe than it was previously. In addition, all flensed projects make minimal use of SWF's, only where absolutely needed, and with the aid of SWFObject External Link, keep very close track of their memory footprint and clean them up so as to avoid memory leaks and other such issues.
Q: Is it secure to use Javascript-enabled SWF's on a page? A: Beginning with the 9.0.124 version of Adobe's plugin, I believe they have achieved a very stable place in terms of the Plugin security model. Flash now utilizes several different author-controlled (that is, not vulnerable to on-the-fly hijacking) mechanisms, which flensed projects fully leverage, to provide a much stronger form of security than is currently available for many of the most common Javascript-only solutions out in the wild. The biggest place this shows up is in the flXHR project, which uses the concept of server-published policies for enabling otherwise restricted cross-domain communication. Because Adobe's model has been well thought out and securely implemented, flensed is very comfortable relying on this approach as a sensible means to achieving the project goals without compromising user security.