I’m glad to see your project uses SWFObject, but you don’t properly (as far as I can tell) expose one of its most important features — ExpressInstall (“XI”). The entire “CheckPlayer” part of flensed was actually conceived to wrap swfobject with an API which could better expose that functionality to dynamically embedding SWF situations.

Namely, swfobject assumes a SWF will *always* be visible and big enough to hold the XI downloader — but in your case, and mine, this is not at all true, as the SWF is 1×1 and hidden.

The problem is, without some robust support like XI, users with an older flash (a little more common), or no flash at all (rare) will be stuck, and won’t even particularly know why. So one of the big pluses that flensed/CheckPlayer will give is that it provides a slick way to help users know about the flash dependency and makes it as painless as possible for them to get it installed/upgraded.

————————
Also, just like with other JS frameworks… you “load the whole thing” for a small task, true, but you also get all the beauty of the “whole thing”, which makes other tasks, either now or later down the road, much easier, too. For instance, any SWF operations you may want to do, you get all of CheckPlayer which is like SWFObject on steroids for that, with tons of useful features like callbacks, timeouts, EI detection, etc. And with the flensedCore, you get really robust UA detection, some helpful things like event binding, etc.

So, you have the potential to save in other areas of your page code, by relying instead on stuff you get “for free” by using flensed.

I’m not trying to argue here… I think you have a perfectly valid viewpoint on the overhead. But I’d also encourage you to take another look at flensed/flXHR if it’s been a little while since you tried it… being that it was in alpha, and is now about to hit full 1.0 production readiness, there’s bound to be improvements now which possibly could sway your opinion a little bit.

Either way, good luck with this project, glad it’s working so well for you! (and thanks for having given flXHR a shot)

http://www.flensed.com/fresh/2008/12/changes-and-new-features-in-flensed-1-0/

It’s a fully XHR-API compliant drop-in replacement for native XHR (including JSON request/responses) that utilizes an invisible SWF for the communication layer. The wrapping javascript implements an identical API to the native XHR object, so it’s easily used in place of native XHR, including easy integration with major JS frameworks, but with cross-domain communication ability.

And btw, on the specific topic of the encodings through externalinterface related to JSON… I ran into these same hiccups with earlier versions of flXHR but they’ve now been fully addressed and flXHR is able to pass JSON bi-directionally just fine.