Fri

Jun 23
2006

Tim O'Reilly

Tim O'Reilly

FJAX: Ajax with Flash

O'Reilly editor Brian Sawyer pointed me to this interesting webmonkey article on FJAX, a Flash-powered variant of AJAX.

"Fjax is an alternative method for doing the kind of Web 2.0 builds that are currently done in Ajax. The advantage is that it does it in a fraction of the size, and requires no code forking to work in the different browsers. It's a streamlined way of doing asynchronous content updates with XML...
 

Fjax uses the Flash Player to load a 1 pixel by 1 pixel transparent SWF to simply get XML from the server. Once it has the XML, it parses it into HTML and then lets JavaScript know it's ready. JavaScript then gets the HTML from Flash and DHTMLs it into the web page — it uses JavaScript to write (X)HTML/CSS onto the page.

In the end, Fjax gets XML and delivers HTML. It doesn't collaborate with Ajax. It doesn't need to. It doesn't load data visually into a Flash movie for presentation. It could, but that is not the point. It doesn't generate SWFs or require a server side component. It is its own thing. Oh, and did we mention it's only 65 lines of code? And it's free."

This does sound interesting, since Flash is indeed ubiquitous and powerful. Using the Flash engine to enable portability without requiring too much in the way of changed development practices and tools could be interesting. (Although to be fair, Flash Actionscript is really just Javascript with some extensions, and for many uses, many of the constructs that Flash provides for animation, like the timeline, which was a struggle for many developers, are not needed.)

But does it work? I just went to the Fjax site (using Firefox on a Mac) and got this message (from vbscript no less): Error parsing XML Data Error parsing XML Data Error parsing XML Data [Note: Jay McDonald writes in the comments below that this was an overload on the server host website, and has been fixed. The site now works fine. In any event, not a problem with fjax. The site is quite snappy now.]

Disclosure: I was formerly a director for Macromedia, but since the acquisition by Adobe, I have no relationship to the company beyond those of a publisher on Adobe technologies.


tags: web 2.0  | comments: 23   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4754

Comments: 23

  Josh [06.23.06 10:56 AM]

Hasn't AFLAX (http://www.aflax.org) been around since last year? Looks like the same thing.

  casey [06.23.06 11:28 AM]

why waste our time with posting about something that is broken? the webmonkey article sounds like someone trying to build hype for existing common technology.

Besides AJAX.

  chromatic [06.23.06 11:45 AM]

I don't consider Flash "ubiquitous". Even on Linux/x86, it has a lot of limitations. (Good luck getting it working at all on another architecture.)

  Tim O'Reilly [06.23.06 12:45 PM]

Casey -- I posted because I do think flash has great potential. And Chromatic, while there may be limitations on Linux (say more), flash is more widely deployed than any other multimedia technology on the net. According to Adobe statistics admittedly, Flash is available on almost 98% of all deployed PCs. It's also available on an increasing number of cell phones. It's got a small footprint and a lot of power compared to competing multimedia platforms, so the combination of Flash and Ajax seems like it ought to be a good thing.

  jay mcdonald [06.23.06 01:10 PM]

Tim,

I just ran across your post. Thanks for the writeup on Fjax. Unfortunately, the problem you experienced was due to a major misstep by our webhost as they were trying to help us accomodate all of the traffic that was coming in. A lot of people experienced the same problem this afternoon. It's nothing to do with your browser, but rather that the service temporarily broke the site. Please try again... and let us know if you have any questions.

Thanks!

  Steve McDonald [06.23.06 02:06 PM]

(Steve McDonald here: co-author of Fjax along with jay mcdonald) I am excited about everyones interest in Fjax (remember it is just a discovery -slash- methodology) and wanted to add to the discussion just a bit and explain what happened with our site today.

Why the down time? In short, we have some .NET on the back end of our site (not required in Fjax and not included the SDK) and our hosting service bumped us over to a PHP server for a few hours by accident. This killed the whole darned site for a bit and we apologize about that. Again, Fjax does not require backend-tech, but our DB and email functionality does.

Fjax and Aflax? Aflax basically uses XML to render vector art inside of the visual side of Flash. This is a very cool tool that does a lot of what Flash does best in a very creative way. I am probably not doing it justice in my description. Follow the above link to investigate more. Fjax does pretty much the opposite. We simply promote the idea of using Flash in a non-visual way simply to gain access to its XML library. The end result is that xml is grabbed up from the server, parsed and ker-BLAM, plopped back on the client-side page in HTML.

Will Fjax replace Ajax? We aren't so silly to think that. We expect that macro-dobe might be able to team up with us (we have some ideas- we just don't know anyone over there) to make a few Flash augmentations so that people continue to "think Ajax" but "do Fjax", since it has a lower cost of support, hence higher ROI. But all in good time (all in good time).

Thank you, Tim, for checking us out. We have been listening to you for some time now and it is an awesome privilege to have Fjax catch just a little attention.

  chromatic [06.23.06 02:45 PM]

The last time I tried Flash on Linux/x86, it only supported one version previous to the current released version of Flash and tended to crash the browser a lot. I haven't seen or heard of any updates to fix either. (I welcome any corrections.)

I have heard (but can't immediately confirm) that the plugin doesn't work on 64-bit platforms.

Also the last I looked, there was no Flash plugin for any other processor, just like there's no Flash plugin for the *BSDs. (The Linux emulation mode version doesn't really count; again, x86 only.)

In my mind, that's fairly unimpressive cross-platform ability and just barely Linux support.

  Dave [06.23.06 04:31 PM]

Wow, this has to be the modern definition of evil spawn.

Take Flash, the first technology to break the web, and slow down access by forcing users to do gigantic downloads in order to obtain tiny amounts of information and sometimes even basic navigation, and marry it to AJAX, another technology that breaks the back button and alows web designers to create mostrously complex web sites where a simple, fast design is more productive for users.


Contemplating the result makes me wretch. Or maybe it's the flu bug I'm just getting over that is making me wretch. Either way, this sounds like yet another way for bad web designers to make the web less accesable, less predictable, and less useful.


Why do we keep taking faster/better/cheaper hardware and putting onto it slower/less useful/more bloated software?


Someone please stop the madness.

  jordan [06.23.06 06:37 PM]

Flash may be popular enough that it's okay to call it "ubiquitous", and certainly it does have all the positive characteristics you mentioned, Tim. However, I submit that there should be a higher criteria for the technologies on which we base our Web apps than just widespread availability, efficiency, and consistency.

What happens when someone writes and releases a new Web browser? HTML is an open standard, as are CSS, HTTP, JPEG, etc. It is because these technologies are open for anyone to implement (patent issues notwithstanding), that they -- and the Web itself -- are able to remain ubiquitous even when new platforms arrive. But Flash is not an open standard that anyone can implement, and as such, any new browser or platform has to wait for flash to play catch-up.

Certainly, we have widespread availability of Flash on most platforms and browsers now (well, at least on the desktop; mobile is another story), and it would seem to be in Adobe's best interest to keep releasing its player for as many platforms as people use. But so long as it's up to a single entity to decide whether or not to develop something like Flash for each specific platform and plugin interface (based on economic reasons or other motivations), is it really smart to march toward standardizing on it? Moreover, should we really be accepting as a de-facto standard for our open Web a technology that requires authoring tools that many people cannot afford or do not want to purchase?

If Adobe really wants to see Flash become a standard, they would at the very least need to open up the specs to allow others to implement Flash players and create and edit Flash files without needing Adobe's tools and blessing.

It's for this reason that it's generally a bad idea to use Flash in applications where other technologies that are open and built right into the browser would serve just as well. Honestly, I'd have expected you to be on the other side of this, Tim. I'm sure there are not a lot of people reading your blog who haven't had to roll their eyes more than once upon hearing someone utter the phrase, "Well, everyone has Flash."

  casey [06.23.06 10:17 PM]

Ok, ok, now the demo is working and delivers the goods. I must concede Fjax does look very interesting :)

  Sean [06.24.06 10:25 AM]

I went to the FJAX site, and it worked very well... it is very pretty. I then downloaded the SDK and it doesn't work as well... though it should. The problem is with flash... it blocks all of my attempts to use the demo files that were included because of an unsafe operation that is trying to be preformed... ARGH! It would be nice if this wasnt the case, as it makes it very difficult to create a website if it is untestable.

--Sean

  Tim O'Reilly [06.24.06 11:08 AM]

Jordan --

First off, for the use that fjax makes of it, none of the issues of "flash catching up" to new releases are relevant. And you're not doing flash authoring, so you're not locked into the flash development tools either -- just using the flash executable to do some work for you. It's acting more like a bootloader or JVM. The code that it executes can be open or closed.

As to the issue of standardization. De facto standards are what they are, and it seems to me prudent to make use of them. "Open" and standard is never pure and unalloyed. That PC that runs Linux has a mostly open architecture, but it also has components that are controlled by a single player. And just as many PCs carry the label "Intel Inside," the internet could be stickered "Cisco Inside."

By your argument, we shouldn't be using any Google services either, yet I'm bullish on services like Google maps as well as Flash, even though both are controlled by a single vendor.

That isn't to say that I don't wish Flash was more open. But I have often noted that "open" is science, not religion. It's a great strategy but not the only one, and not always the best strategy for a company. See the essay I once wrote for Nature, called Information Wants to Be Valuable, in which I argued that Bill Gates and free software developers have more in common than most people think.

  Julien Couvreur [06.24.06 06:30 PM]

There are many interesting uses of Flash to extend AJAX:
-cross-domain XmlHttpRequest (FlashXMLHttpRequest project)
-client-side storage (AMASS, dojo.storage and Flash4AJAX projects)
-browser socket
-cross-browser canvas (AFLAX project)

  Simon Willison [06.25.06 11:21 AM]

I was very, very unimpressed with Fjax - all it actually does is replace XMLHttpRequest with a Flash-based hack that offers no improvement in terms of performance, maintainablity or ever browser compatibility. I've written up my thoughts on this on my blog.

  Tim O'Reilly [06.25.06 12:44 PM]

Simon, based on your analysis (which I trust), I'm rather embarrassed to have provided this link, except to the extent that it provoked some useful discussion.

I'd love to see a response from Jay and Steve McDonald.

  Ori [06.26.06 07:52 AM]

Fjax is a nice solution for programmers.


At MuseStorm we are providing a service that allows people with very little Javascript knowledge to create Rich Internet Applications. We'll check Fjax to see if we can use it for our service.

  Alastair James [06.26.06 03:05 PM]

Well, simply loading XML documents from a webserver is not really going to set the world alight. The only logical use of flax would be comet-like socket based applications, where there is no need to hack http-keep alives. Thats what I will be looking at the technology for...

  Steve McDonald [06.27.06 08:45 AM]

Thanks to everyone who has provided thoughtful peer review. As a part of that process, we’ve had some questions come up regarding Fjax, and we wanted to take a moment to provide a response:

The business model: First, let’s start by saying that the only thing behind Fjax is two guys who are underwriting this time- and money-wise out of their own pockets – so we have no share prices to protect or anything like that. Some have wondered what our business model is, and the answer is that there is none. We’ve just wanted to share what we found to be a useful technique with the rest of the community. Our goal in making it available was to engage the open-source process and get the sort of useful feedback that we’ve been getting so that this idea can benefit web builders. Honestly, if something came along that was demonstrably better and made Fjax obsolete, we’d be all over it. Corporate inertia and ego just aren’t our bag.

Now, to the technical issues.

XML parsing speed in Flash: The issue surrounding slower external interfaces (as discussed by Brad Neuberg) has to do with the new interfaces created under the Flash 8 plugin – specifically the method of shuttling data back and forth with the ‘flash.external.ExternalInterface’ class. We opted out of using the external interface that Brad discussed. We are pulling HTML content by using the ‘getVariable’ API. This overcomes the 1024 kb data limit, and provides a different route for moving the data that does not appear to suffer from sluggish throughput.

Code-forking: Since the XML parsing under Flash is handled the same way between browsers, there is an inherent efficiency. In a simplified example like we have in the SDK, where we’re simply pulling CDATA out of a single node, the parsing process may not be terribly involved no matter how it’s done. However, in real-world applications with more complex parsing and manipulation of data, code forking is an issue. Take for instance, chapter 4 of Wrox’s “Professional Ajax”, which presents 41 pages of information and examples regarding the forked code required for different browsers.

We will concede that we might have over-estimated the percentage of relative savings. Since these are indeed variable, soft numbers, we have decided to strike the “90%” figure from the site.

Opera and Konquerer support: We talk about this in the white papers. Konquerer does not currently appear to implement some of the API hooks back and forth between the browser and the Flash plug-in, which means that we can successfully tell Flash to get data, but we haven’t found a mechanism to get the data back out of Flash due to the limitation in the API implementation. A number of people have written us about a similar issue with the final release of Opera 9. As soon as we have time (or as soon as someone who has downloaded the SDK has time) we hope to see this sorted out. Again, our goal in putting this out there and wrapping a site around it was to engage the ‘bazaar’ approach and not try to be the guys in the ‘cathedral’ coming forth with all of the answers.

Approachability:
By approachability, we mean that a lot more people can implement the Fjax methodology because there is just a lot less to learn. Plus, if you need to change or add to your parsing procedures, you do it once inside the swf. We feel this unified codebase is a significant plus. All in all, the hope is that a streamlined, more approachable method would mean more players in the game, and more getting done.

And finally, for anyone still wondering about all of these things, the best test is always to try it out for yourself by downloading the sdk.

  DHTML lover [06.27.06 04:10 PM]

digg.com/programming/How_Does_AFLAX_differ_fron_FJAX


Thank you for this tool - added the samples to several websites - here is the digg link, hope others discover this resource

  ktec [06.29.06 07:39 AM]

This will really come into its own when the Actionscript 3/Flash Player 9 version is written. Steve....any plans???

However prior to that i have a couple of comments,
firstly, if you're using flash as your point of contact with the server, amf & remoting is a far slicker, more streamlined approach. What would really make this product impress me, would be to provide the browser with the typical AJAX type calls it needs, and convert those into amf calls. Admittedly this would require amf compatible server architecture, but its available for most languages now.

I did something very similar in the latest version of www.kitemap.com and its surprising how much of a difference it makes to the speed of the application.

  Steve McDonald [07.03.06 07:46 AM]

Interesting observations on amf and remoting. There are a good number of interesting ways to get data in and out of Flash, the slickest actually being in the family of remoting and the ActionScript Messaging Format. I have been thinking about kicking out some new advanced SDK examples that explain the techniques and benefits of persistent connections between the client browser and the server. I will mention one right here (and maybe it is a little Captain Obvious, but then again Fjax.net was created to help non-programmers approach Web 2.0 with a little more confidence).

More Connections equals more data faster: While one will likely bottleneck at the bandwidth faster than any other factor, more connections still tends to be faster. For example, the first iteration of the Fjax examples had an innumerable count of invisible parsing SWFs loading concurrently into multiple DIV tags on the page. This is hugely advantageous (I think I got 3 to 5 running concurrently in Firefox with no bandwidth bottleneck) in terms of performance. But on the IE side, the windows registry locks concurrent connections down to 2 comfortable (3 flaky) connections. While I like the idea of unlimited connections under the configuration of Firefox (not honestly sure if Firefox meant to do that, but it doesn't block concurrent Flash connections, even from separate multiple SWFs on a single web page) it is actually a part of the W3C standard to limit the connections in the manner that IE is doing it. (Funny how IE was enforcing compliance with this idea, and not Firefox... maybe someone else knows the history on this point.)

So, back to the bottle neck. Any who has done any network programming understand the "cost" of initiating initial client/server connections. After your computer is cut-loose on a connection, things speed up considerably. This is true for Flash and it's ability to connect to the server via a persistent socket. Once a trail to and from the server has been paved, theoretically, the bandwidth is consumed by very efficient requests and responses. That is just one benefit, not to mention the ability to "push" new data to the page. But now we are really blurring the line between client-side technology and n-tier architectures. I see Fjax-style methodologies implemented in those "neighborhoods" but I would like to focus time right now on getting these early techniques into the hands of people who are feeling the desire to get into "web 2.0"-esk site behavior, but who might have needed a very simple jumpstart into the realm.

As for AS 3.0 and Flash Player 9, I have only read about some of the jumps Adobe is making in this area of Flash. I have only made a small investment in that direction and while I am excited, I have some ideas (keeping them on the down-low for now) that I would like to talk with Adobe about in hopes that we -the grassroots- can take some of these techniques to the next level. Knowing Adobe, they are already working on them, but just in case they are not, well... let's all just keep dreaming out loud!

Thanks, ktec, for continuing to inspire people with your ideas and ambition. Good work on kitemap.

  Bashar AlTakrouri [06.27.07 08:33 AM]

The problem of all those technologies the incomparability with many browsers. E.g fjax dose not work with opera mobile 8.65 and i did some testing with other browsers as well.

Anyway, what is the advantage of creating new technologies that is hardly can be used.

  Kyle Simpson [06.18.08 11:46 AM]

The flensed family of projects has just release 'flXHR', which is similar to the above technologies, except that it goes further, by implementing (with the help of Javascript wrapper code) an XHR-compatible API, making it a drop-in replacement for the native XHR browser object. Moreover, it utilizes Flash Player 9's robust security model to allow direct cross-domain communication through the same interface, no server-proxying or inefficient IFRAME/script-tag mess.

Check it out at: http://flxhr.flensed.com

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.

RECOMMENDED FOR YOU

RECENT COMMENTS