Then we chanced upon Flex. We were intrigued about the possibility of using Flash as a development platform but we were not absolutely sure that firstly, we could achieve what we wanted to do using this platform and secondly, whether we had the technical expertise to do this given that we didn’t have a single member in our team who had ever done anything with Flash previously.
We began testing the waters by building out a prototype of one of our applications. It was not difficult to reach feature-parity with our AJAX versions – we managed to do so in a matter of a few weeks and what’s more, the user experience was miles ahead in terms of richness, responsiveness and the general look-feel (compared to other RIA technologies, Flex apps can provide a more tactile interface and user experience). Once we reached this milestone and were convinced that Flex had passed the litmus test, so to speak, we decided to go the whole hog and pivot our entire front-end strategy on Flex and ActionScript. In due course, Adobe released AIR and this complemented our web versions to a T. Now, as we look back on our journey of roughly a year and a half of using Flex, we are completely satisfied with the decision to make this switch and believe that we will go from strength to strength from this point on. Here are a few salient points that we want to highlight that might help other folks who are in the process of choosing an RIA platform for their products:
- Don’t worry about lack of prior experience with Flash: When we started off, we had zero experience with Flex or Flash but the learning curve was not difficult to traverse – both our Java and our C++ developers managed to be proficient Flex and Actionscript developers in a short period of time.
- Judicious and pragmatic use of off-the-shelf components: One nice thing about Flex is that there is a huge library of easily-available components that make it easy to get started and develop prototypes quickly. However, one needs to be careful to avoid being over-reliant on these components as they will not pass muster in a production environments in dimensions such as performance and memory management. Most of our applications started off having a lot of MXML components but over time, were replaced with targeted, lightweight, custom components.
- Flex and Java is a match made in heaven: If you already use Java, Flex is an ideal partner. We use Java on the backend and it was a painless exercise to replace the front-end with Flex without having to tinker with the backend. This combination also makes it easy to leverage useful open-source collateral such as BlazeDS(which we use to facilitate real-time co-editing).
- Lock-in with Adobe (the lack thereof): Another aspect that influenced our choice was the fact that while these technologies were developed by Adobe, they are now in the open-source realm. So there is no overt lock-in with Adobe – granted that there is still a subtle dependency in that the roadmap for these technologies is largely determined by Adobe but the fact that there is now a large eco-system and considerable community involvement in Flex dampens these concerns considerably. The other nice thing in these tough times is that you don’t have to spend anything to use these technologies. In fact, our account with Adobe stands at $300 credit in our favor (we have not bought anything from Adobe but they graciously sponsored our code signing certificate!). Also, in general, we have developed our suite completely independently without depending on Adobe in any way.
- AIR makes it sweeter: AIR is, by some distance, the best desktop-web bridge technology platform out there in the market. We have spent quite a bit of time on Gears, Silverlight/WPF and JavaFX and can state with some authority that if you are developing a product that makes sense on both the browser and the desktop, Flex and AIR is the way to go.
Chanced upon an interesting blog post about Google Docs on ReadWriteWeb that evoked some equally interesting responses. One commentator in particular was very vociferous on how Google docs fails the cut in so many basic ways. To this, Ryan Stewart of Adobe came up with a riposte post that basically posited Adobe AIR as the solution for many of the noted shortcomings. While we at InstaColl are bullish on AIR, I am not sure if AIR can indeed be the “silver bullet” the way Ryan has laid it out to be.
For instance, Ryan states how the AIR version of Buzzword can support pasting images saved in the clipboard and concludes that Google Docs can achieve the same functionality aspect by moving to AIR. Unfortunately, this is not quite accurate.
While an AIR application does have greater control/proximity to the system clipboard, the individual application must be specifically programmed to handle clipboard content intelligently. I am pretty sure that, in the event, Buzzword is supporting seamless pasting of image content the way Ryan has described, the Virtual Ubiquity/Adobe team has had to do quite a bit of custom coding to support this.
Clipboard content can be quite diverse and complex – ranging from simple text content to formatted text to html content to images to proprietary content like autoshapes (for instance try copying and pasting a square or oval from a PPT to a Word document…it should work. Now trying pasting the same content in a browser…this will fail – Microsoft can handle this because each of the participating applications (in this case PPT and Word) can recognize and render these objects correctly) but other applications cannot make sense of this binary clipboard content.
AIR might be able to tell you what type of content the clipboard currently holds but managing this content intelligently (which is the true challenge) is beyond AIR’s purview. So extending Google Docs as an AIR application might be simple but it will not support this type of clipboard handling functionality.
Ryan is right on one count though – if the native web application was originally a Flex/Flash application as opposed to an AJAX application, programming for features like this is a lot easier. Ditto for capabilities such as dragging and dropping an image into an AIR application – a Flex application can be easily tweaked to seamlessly embed the image into the content frame but in an AJAX application, the most likely scenario is that the image will replace the entire content (irrespective of whether the AJAX application is running in a browser or as an AIR-enabled desktop client).
The other comment in Ryan’s post that I found interesting was this:
“If you want to “beat” Microsoft and desktop applications with online apps, you need a platform that provides more functionality but stays true to the web.”
He is obviously referring to Flash/Flex/AIR and interestingly enough, using the same technologies as pivots, Buzzword also attempted to portray their application as the “First true word processor for the web”.
Now, we are using these technologies extensively too but I will be the first to admit that Flash is not a “web technology” by any stretch of one’s imagination – the fact that the Flash player is installed on most people’s systems and thus Flash content can be played within the browser is the reason why Flash is wrongly assumed to be a web technology. The browser’s presence in rendering Flash content/applications is entirely incidental – which is ironically the primary motive why we chose Flash instead of AJAX as our RIA paradigm.
In any case, this is just a matter of semantics and in the final analysis, end users just want compelling applications – it does not matter what is a true web techology and what is not….
– Sumanth (for the Live Documents team)