flensed FAQ
- Why flash, what's wrong with Javascript/CSS only solutions?
- Don't users have to "click-to-activate" with SWF's on a web page in certain browsers?
- What about the people whose Flash Player plugin is really old/out-of-date?
- What about the people who don't have Flash Player plugins installed, or who have them disabled?
- Isn't the Flash Player plugin really memory intensive on the page, especially multiple instances of it?
- Is it secure to use Javascript-enabled SWF's on a page?
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) 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) 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,
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 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,
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,
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.