Devil’s Advocate – Why You Shouldn’t Use SWFObject

Monday, January 14th, 2008

Categories: SWFObject

RSS Comment Feed


AddThis Social Bookmark Button

Devil’s Advocate Series This is a forewarning that this is an article that I made to see other people’s points of view that differ from my own. I take the opposite standpoint and make an effort to defend it.

This article will deal with why you shouldn’t use SWFObject to integrate your Flash piece into your website. If you’re interested in having a look at the original article where I highly recommend SWFObject as being part of all Flash Developer’s toolkit, click here.

In brief, SWFObject is a Javascript file that allows you to easily insert your SWF file into your webpage. It avoids the debacle in Internet Explorer where you “Click to activate and use this control“. It makes Flash more usable and more attractive because there are no longer any foreign or worry-some warnings for the user.

Adobe CS3 Accommodates This Problem

Adobe Dreamweaver CS3 and Flash CS3 already insert the required code to bypass the problem described in the introduction paragraph. Why should we worry about a problem that’s already fixed. If they’re taking care of all the nitty gritties, why download 3rd party scripts?

Adobe takes care of making the directory and throwing in the Javascript file. I don’t have to copy and paste SWFObject.js, make sure I have it in the right directory, read it in as code, etc.

If It Doesn’t Work, I Won’t Know Why

Adobe CS3′s solution will always work and takes care of auto-detection and errors I might make. If SWFObject goes wrong, there’s not much I can do apart from commenting on blogs and posting on forums. That could mean days until I find a solution.


Adobe’s solution likely had more research and people working on this fix to get the best results. When you really look at the code, they took everything into consideration including visitors with Javascript disabled.

One Less CSS Element

SWFObject requires you to make a CSS element for your SWF file to target. That’s an extra element you need to make sure functions correctly. CS3′s code lets you plunk your SWF without any hassles from CSS.

That’s everything I can think of, does anyone have anything else to add? :)

Bookmark this blog using any bookmark manager!
Subscribe to via RSS

Error. Page cannot be displayed. Please contact your service provider for more details. (18)

Related Posts

Subscribe to this Post

3 Responses to “Devil’s Advocate – Why You Shouldn’t Use SWFObject”

  1. Kyle Simpson Says:

    1. Adobe CS3′s embed solution may be improved, but it is in fact not at all equivalent to SWFObject’s offering. SWFObject allows the power of choosing static embed syntax (for standards compliance), or dynamic embedding for truly dynamic flash enabled pages where the SWF can come and go at the will of javascript. There’s nothing even close to that in Adobe’s CS3 version of their script.

    Moreover, with CS4 and onward, Adobe dropped their AC_xxx scripts in favor of SWFObject flavor of doing things. It’s available via a plugin in Dreamweaver CS4, and probably will be directly included automatically in the future. There’s a good reason why Adobe adopted SWFObject as the solution of choice. You probably should think about that.

    2. We have a vibrant community of SWFObject enthusiasts and developers, many of us who use SWFObject in dozens of our own sites on a daily basis, and so there’s a great chance that we’ve seen 99.9% of the problems you may run into. And even if we haven’t at least you can talk to us (who actually write the code) directly and we can tell you why or how or whatever. Try getting directly in touch with an Adobe dev on why/how/where their script does something. Give our mailing list ( a chance, or check out the issue/bug report system, or even check us out on Twitter now @SWFObject

    3. This is just patently false to claim that Adobe had more research and development, and thus “quality”, than SWFObject. The original developers, Bobby and Geoff, have been at this for years now, and started doing so mainly because of gaps in what Adobe had put out there. Over the years, naturally, the results have been refined, but (as noted earlier), Adobe and SWFObject have now converged on a very strong, stable solution. Adobe certainly wouldn’t have dropped all their “quality” code in favor of poor quality SWFObject. Our project is of very high quality, and has passionate support. And that’s the reason why it’s a top-10 downloaded open-source project on the internet. SWFObject has a lot to offer, and lots of people are starting to realize it.

    4. This statement is somewhat misleading. The true fact is that with 2.x onward, SWFObject replaces a *DOM element* with the SWF embedded object, as opposed to earlier versions which simply appended into a container. The reasons for this change are numerous and solid. Most importantly, it’s to remove “alternate content” once that content is no longer necessary, which gives

    However, this has nothing to do with a CSS element. You need not (unless design/authoring requires it) have any CSS applied to the DOM element you use as a placeholder for your SWF.

    Moreover, separation of markup and code is generally considered a good thing. In this case, using the Dynamic Publishing option, the best-practice is to create a DOM element which has no knowledge or specialty as a SWF, with just basic fallback alternate content, and then elsewhere (in your Javascript code, namely) target that DOM element for enhancement via replacement with your SWF. This makes your page code cleaner and more sensible, not only to developers but to search engine crawlers and screen readers.

    Of course, you can do Static Publishing, where you instead put in your full swf embed markup, in a certain form, and then optionally decide if you want swfobject to “enhance” that embed markup with version detection and express-install capability. If you don’t (or if the user doesn’t have Javascript), then markup only is a perfectly sufficient, and cross-browser) way to tackle your embed needs.

    Contrast this with Adobe’s previous approach, which was to drop script and markup all mixed together in place, sprinkled throughout your document where you wanted your SWFs. This offered poor separation of markup and code (and CSS for that matter), and was also more brittle to more complicated use cases, such as when CMS’s were involved, etc.


    All in all, SWFObject is a very mature, complete solution for SWF embedding needs. And there are a number of companion projects which have sprung up to help with deeper niche cases, such that just about anything you want to do with a SWF on a web page, there’s a script for it. That’s the goal — Adobe realized how powerful that approach was, and now tens of thousands of sites have realized it too.

    I hope you will reconsider your stance, and join the cause! :)

  2. Kyle Simpson Says:

    to finish the sentence previously that somehow got cut off:

    …once that content is no longer necessary, which gives the user a better enhancement user experience when possible but falls back gracefully when not possible.

  3. Patrick Burt Says:

    I am indeed an avid SWFObject user. I refuse to embed anything without it. This article was written with me trying to see the other person’s point of you. I’m already a convert, don’t you worry.