Search This Blog

Wednesday, February 7, 2007

Flash vs. AJAX – Which to choose for Internet Based Communications ?


There is no dearth of articles on the internet about the virtues of Flash over AJAX or the other way around. Arguments range from “proprietary plugin vs. open solution”, “performance vs. bandwidth”, “download size”, “availability of skillset”, “security” and much more. However, the focus of my topic is very specific. What is the right RIA platform/technology to use for ‘Internet Based Communications’ related development ?
In Summary,if you want your product be successful in the market in 2007-2010 and if you need real-time voice, video and animation Flash may be a better choice today. If you need to support mobile clients, stick with Flash. AJAX is great for semi-realtime solutions like IM chats, Web Based Desktop experience, document collaboration etc. Infact, I blogged about it’s promise earlier. But not for voice/video/animation intensive operations.

Here are the details (PLEASE NOTE – all of this is in context of building ‘Communication Applications on the Internet’)

First, let me classify what I term as ‘Internet Based Communications’ (IBC) and the primary components that need to be considered there.

My definition of IBC is ‘a multi-dimensional mode of communication, where one or more users interact with each other and or innovative services using a combination of, but not limited to, voice, video and multimedia messaging in a way that enhances their user experience for interaction’ (no, I am not a lawyer - it is just so hard to get all dimensions into a sentence)


Before we discuss the right RIA choice for IBC, let us first look at the primary components and their nature as far as ‘load on network’ is concerned (click image to see larger version). The 'bandwidth' understanding is useful to judge whether it is better to do this locally, using local CPU power, or remotely and then have it 'sent to you' as 'frames'.




Within IBC, what are you making and what is your target market ?

Deciding on a target market and what you plan to do is critical to decide whether you should go the AJAX way or the Flash way. For example:

  • Is your browser going to be your only client ?
  • Do you expect voice and video to be a part of your service ?
  • How important is security to your product, in a span of now to 5 years down ?
  • How important is ‘animation’ and ‘interactivity’ in your product ?
  • Is making your IBC product available on mobile phones important ?
  • What OSs do you need to support ?
  • Is ‘plugin vs. no plugin’ , ‘open vs. closed’ a big deal for you ?
And so forth…

Unless you have a good feel about the nature of your requirement as well as the ‘load factor’ of the components within your product (see table above), making a choice to go with AJAX or Flash is like walking into a bull fight, blind-folded.

It is important to understand where Flash and AJAX match, and where Flash and AJAX address completely different needs.

The best way to do the onion ring comparison is to put it in ‘context’. So why not answer the above questions ?

Is your browser going to be your only client ?

RIA is not only about your ‘browser’ ! The Internet is not your browser either – it just so happens that a browser is an important tool in the overall environment. However, depending on what you are building, you may need a standalone client, which has all the richness of mashable-ness, web services interface etc. but does not run in the context of your browser. The entire concept of AJAX is that your ‘user experience’ is responsive right within the context of your browser. Flash on the other hand has a concept of a ‘standalone player’ or a ‘browser integrated plugin’. So before you choose one or the other, consider if using a ‘browser as a client only’ meets your business requirement. For example, a using a browser, you cannot have a server directly contact your client, unless the client first made an outgoing request to it (which is why in the AJAX world, you may be aware of techniques such as Polling, Comet, Piggybacking, to simulate such requirements). So if your application needs to go beyond a browser, AJAX may not be much of a choice.

Do you expect voice and video to be a part of your service ?

I get confused when people tell me they want AJAX to do voice and video. Voice and Video are CPU intensive operations – most voip solutions use at least some form of a codec which needs to be de-compressed in real time. In addition, if you add video to voice, there are further operations such as audio-video-lip syncing, and many other operations which adds to CPU utilization. In other words, if you are using voice or video, you need local power – it cannot be 100% server based ! For example, if you go to Youtube.com and see a video, the video is being streamed to your local flash-plugin which is an authorized plugin in the context of your browser, and that is doing the heavy lifting of voice and video encode or decode. If you use Wengo Viso to auto-magically insert a video call widget in your website, you are using your local computing power for capturing your video and voice, encoding it and transmitting it to the remote side and vice versa – courtesy of your flash-plugin. So while you think ‘there is no download’ , there is actually a ‘download’ – your flash-plugin that was packaged as part of your browser distribution !

Simply put, if you need Voice or Video, Flash beats AJAX hands-down. Infact, AJAX really does not play in this space, since it really does not offer a voice or video solution – you pretty much need to craft the solution on your own, which could work, but would be rather onerous, and not as optimized as the flash voice/video experience.

Also, you must have read about the much blogged about Flash-VoIP effort. I think it makes fabulous sense. If Adobe were to utilize its excellent distribution channels and bundle in a SIP UA and standard voice video codecs in the plugin, the entire browser world automatically gets voip and video enabled and writing web-widgets to activate that functionality becomes trivial. And like I said before, it effectively results in a 'no download' experience, because the download already happened one time before, as part of the 'platform update' and users had no ide
a of it. So you can walk into a web-cafe, grab an available browser, and start voice/video chatting. Why would you need a local download of another 10MB voice chat software ?

How important is security to your product, in a span of now to 5 years down ?

It is commonly known today, that Javascript has several security issues that could be compromised by ‘script-kiddies’. This is of course a function of the maturity of AJAX vs. Flash. As I discussed in another article, this will change over time. But based on my assessment of security, it looks like Flash has a lead in security when compared to AJAX, at least today, and I think for the next 2-3 years. When I searched for flash-exploits, most of them were to do with buffer overflows, and less to do with malformed-script parsing attacks.

So while Flash is ahead of AJAX here, you need to look into your crystal ball and see what you think your future holds for AJAX and weigh security along with other needs. For example, if you were making a solution like online office productivity, expect the browser as a client, and don’t think you are venturing into the ‘streaming intensive’ applications, AJAX may be a safe choice too.

How important is ‘animation’ and ‘interactivity’ in your product ?

If you are building a ‘virtual community’ or an ‘interactive social networking site’ which needs a lot of animation and fabulous transitions in real-time, you would notice Flash to be almost pre-dominant there, with new entrants also showing how AJAX powered interactive sites can also be made, for example, hive. But here is the catch, when you are building animation, you not only need to see the final product, but also need to ask the developers how simple it is to build such a solution. In addition, you need to keep a keen eye on the amount of ‘internet bandwidth’ you are consuming with this animation. The problem with AJAX is that while it has a benefit of ‘truly no plugin required’, it also means that whatever is needed, needs to be sent from the server to the client. If you run a network traffic monitor on graphics intensive solutions using AJAX, you would notice that there is a significant amount of backend downloading going on for supplying image frames as well as a large quantity of controlling logic code (JS, primarily) from the server to your browser. Solutions such as integrating SVG (Scalable Vector Graphics) into AJAX into a usable solution are too premature and only exist as proof that it can be done today. If you have developed in Flash, you would notice that ‘action script’ is only a small part of the overall solution. Flash offers a fabulous graphical animation studio, with easy to understand concepts of timelines, layers, frames and such which make animation really very simple. And the fact that you can control them all using actionscript, makes it a wonderful platform for creating interactive applications. And the other thing is when it comes to effective animation, I truly feel a plugin is a good thing. The server based model cannot beat local graphic-crunching, and the optimized flash plugin, which is written in native language, does a great job in rendering locally, within the frame of your browser if needed. And to boot, my personal experience has been that the file size, if written appropriately is really very small.

For example, I spent last week reading about flash programming and then wrote a tiny ‘superman’ game for an interactive sidescroller show. It is buggy, but that is due to my own lack of time to make it robust – I just wanted to see how it worked , how simple it was, and how optimized it was. This flash game is a measly 9KB in size.

Here goes:






Or consider this fabulous new feature from Flash-8 that not only allows you to capture webcam detail, but process it as well within your actionscript to make 'motion detection' a reality using just a webcam. Apply this to an IBC application of a virtual chatroom. You are equipped with a web-cam, get into the virtual room, and bring your hand forward in front of the PC as a 'hand-shake' gesture. This is captured by your webcam, sent to the actionscript in the SWF that applies and appropriate algorithm to detect pixel changes in frames and evaluates this to be a handshake gesture, and your virtual online character automatically extends his hand to shake with the other virtual characters. And no, you are not using the Nintendo Wii. Just a webcam. Admittedly, detection motion vs. understanding motion are two different problem spaces, but Flash has the tools to make this happen. Like I said, when it comes to interactivity of this nature, Flash is simply fabulous.
One may want to keep a tab on interesting efforts such as OpenLaszlo's Digital Life and similar. The technology is still very beta and one would need to see how it would scale and fit large content intensive applications over a span of time. I have personally not used OpenLaszlo, but I've talked to ISVs who have used it, and the feedback I got is it still very limited and has a far road ahead.

Is making your IBC product available on mobile phones important ?

Here is the fact: AJAX supported browsers for mobile phones are almost non-existant today. Doesn’t matter what Google search tells you on posts about the ‘impending arrival of AJAX for mobiles’. I’ve talked to countless mobile phone ISVs and the story is exactly the same:
a) We don’t believe the browser is the only client
b) Most browsers for mobile-phones are ‘limited’ today. Support for AJAX within the ‘limited’ browsers is a double limited !

AJAX is in the radar , but Flash-lite is the reality there.
What OSs do you need to support ?
Theoretically, AJAX implementations should work on all OSes that have browsers that support all the required JS/DHTML/CSS tags needed. Reality would depend on how good current browser support is in those OSes and the plans they have for full compliance. On the desktop/server market, the predominant OSs are Windows, MacOS, Linux and maybe SunOS/Solaris (not any longer though, I think). On the terminal side, the main players are Symbian, Windows Mobile, BREW and some new penetration of real time Linux variants. Flash and/or Flash-lite is available for all of the above. AJAX requirements should also be available for all the server OSs listed above. But if you need support for esoteric/less used OSs, then there is no telling when Flash would be available for them (neither is there any telling whether full AJAX support would be available, but since AJAX is based on open specifications, an enthusiast could craft an AJAX engine (!) for them. So as far as 'guaranteed platform support and if not, let me write it myself' goes, AJAX wins. But if your business is in the mainline supported OSs, flash is fine too. Also, do note that competition is always healthy. Adobe recognizes the emergence of AJAX in certain niche applications, which could have otherwise been served by Flash too (like collaborative documentation, etc.), which is why they have made small entries such as Flex-AJAX bridge to ensure that users have options to work them together, but this is currently limited. So be rest assured th
at a market leader can get as aggressive as needed to keep it's lead in the market. Adobe is no different.

Is ‘plugin vs. no plugin’, ‘open vs. closed’ a big deal for you ?

To be frank - I am often puzzled by this. Flash has a fabulous distribution channel. Almost every browser in the world has the flash plugin, and accepts signed updated from macromedia for flash player updates. Real time voice, video and animation needs local computing power. So what other solution is there, that is deployable en masse other than local clients (or plugins?). Infact, I think Flash has a great advantage here. Since the plugin is already a part of the browser, its ‘downloaded size’ doesn’t count. It reminds me of the argument of Firefox vs. IE. FF folks would always argue that the reason FF seems more sluggish than IE, is that Windows pre-loads parts of the IE engine as part of its OS initialization. So when the user clicks on the IE icon, only the remaining part needs to be loaded, unlike in FF, which needs to load the full she-bang, unless you use some pre-loader. Technically, I get it. From a user experience, I don’t think they get it. To a user, it does not count, if IE gets pre-loaded as part of the OS init. All he knows is that it resulted in a faster load time. The same holds true for Flash vs. AJAX. The plugin download just doesn’t count. If flash does a better job in local rendering of voice/video and animation, for AJAX solutions to play in the market, they need to compete and beat this by offer better performance, not more excuses. In addition, to do anything really useful in AJAX, you need more than just ‘bare-bones’ AJAX. You need to download and use one of the many ‘AJAX toolkits’. Depending on what they do, their size ranges from a few KB to a few mega bytes. So instead of downloading ‘flash player’, you are effectively downloading an ‘AJAX library’ (the innumerable .js script links in many AJAX pages). Alternately, you are generating gobs (hundreds and hundreds of lines) of JS/DHTML code which is being downloaded by your browser which was generated by some AJAX library you used for programming.

Finally the ‘open vs. closed’ thing. Why is having source code so important? Yes, it is always better to control your destiny. I get that. But in this case, you need to see whether the APIs exposed by flash are limiting you or not. If not, then you shouldn’t be complaining. Also,’open source’ may be important for you for cost purposes. While Adobe distributes the flash and flash-lite player free, they charge for macromedia flash 8, flash-cast and other development solutions. Remember that AJAX has freeware and commercial-ware too. It is all a function of ‘functionality vs. price’. You are the best judge for it.

10 comments:

  1. This is an excellent and complex piece.

    Thanks

    Howard Oliver
    http://prmeasure.blogware

    ReplyDelete
  2. Thank you for this superb post.

    I think that telcos should start to be afraid of the potential of flash when used to provide VoIP, because almost every browser have flash.

    I've recently tested the www.gizmocall.com, flash based VoIP service (similar to wengovisio)

    ReplyDelete
  3. Why are talking about AJAX if your post is about voice?!?

    ReplyDelete
  4. Please read the post again. It is not 'about voice'. It is about any RIA that has 'voice or video as an *additional* service'. If you are not aware, people have used AJAX+HTTP+XML+JS for video and/or voice streaming as well http://www.codeproject.com/Ajax/AJAXVideoPlayer.asp

    ReplyDelete
  5. AJAXVideoPlayer is only a 'theoretical possibility'. Better bandwidth - better resolution/quality... Hate to see some JavaScript chugging away bandwidth and computing power!

    ReplyDelete
  6. AJAXvideoplayer is a practical, albeit suboptimal solution. A 'theoretical possibility' is one that has not been implemented yet.

    ReplyDelete
  7. Possibility from a business perspective...
    Anyways. My point was AJAX in your blog was not necessary if you are talking business. And I assumed you are, as you call yourself corporate.
    For instance:
    "Is your browser going to be your only client ?"
    Just a question, why do you have to use the same solution for all sorts of clients?

    "Is ‘plugin vs. no plugin’, ‘open vs. closed’ a big deal for you ?
    To be frank - I am often puzzled by this..."
    Really? So, do you think this is not a big deal in the corporate world?

    ReplyDelete
  8. CMR, your post makes no sense. What do you mean 'from a business perspective'? The original post was a technical and product decision choice. And what does 'talking business' mean here ? He is talking technology. So please stop taking the refuge of 'business' when you don't have any other foot to stand on.
    And yes, if you ever ran a product business, you would know that making a decision on the solution is critical so that is can be deployed across multiple environments with minimum rework. Any product takes well over 'a few million' to actually produce and market. Imagine if you were to go back to your team saying 'Oh we did X with AJAX for the desktop market but let's rework it with Flash for phones'.

    And if you don't realize, this blog is a mix of technology and 'non-technology' posts.

    ReplyDelete
  9. Ann, I may not be completely aware of the business domain under discussion here. But providing a general solution based on partial view is not right.

    Two things:
    A. Here is my work scenario, and may be you might understand better.

    1. Where I work, it is very common to develop products talking different UI.
    2. I get instructions from my boss to be very cautious when I talk to vendors; simply because they are constantly looking at new ways to milk us.
    3. I would be very careful to choose a product, as once you invest into it, you are in a vendor lockin.

    B. AJAX's popularity was purely because of dynamically changing webpage contents, without reloading the page. Let it be that. IMO, well, you can build shopping malls with pocket knife, but that is not what is done.

    And, if you pause and see, the post says, "Flash vs. AJAX - Which to choose for Internet Based Communications?" So when I read it, my expectations were different to yours. My question here is, "are those it?", or "why are comparing them?"

    ReplyDelete
  10. I just got a data plan on my mobile. I pretty much do not need my computer anymore since I do so much with my mobile phone. The neatest thing is that I can even watch naughty movies:) It is pretty neat, it's called Mobile TV. All I do is point my phone to sexoncell.com and they have adult mobile movies in different formats like 3gp movies, symbian, pda or whatever. If you have any other cool sites, please let me know! This one, though, even has a free daily mobile movie.

    ReplyDelete