expressFlow Designer:
evolving from Adobe Flex to ExtJS
Martin Vasko, 17.11.2011
@expressflow
The Beginning
When we implemented the initial version of our prototypical designer back in 2008, Adobe Flex dominated the rich internet application scene: Microsoft's Silverlight was released in version 2 and JavaFX was still stuck in it's infancy. Adobe Flex was available in version 3 and provided the most mature class library facilitating the deployment of desktop-like user-interface functionalities to web applications. Architectural paradigms like the separation of layout information in XML - files (MXML files in the case of Adobe Flex) and application logic in traditional ActionScript files were great and fresh renewals. But this separation had a downside (which later in history will be one point for our decision to change): The need for compilation. As all cutting edge rich internet application frameworks back in 2008, Adobe Flex, Silverlight and JavaFX had to be compiled to a binary representation. This significantly complicated a server-side generation and hindered a flexible and extensible designer architecture.
On the other side - back in 2008 - available JavaScript frameworks were not mature enough to implement comparable user experiences with justifiable expenditure - a driving factor for proof-of-concept implementations. We can summarize our decision for using Adobe Flex in the following points:
1.) Platform penetration: According to RIAstats - back in 2008 - the Flash player was available for a wide variety of platforms. Tablets like the iPad existed only in visionary minds.
2.) Framework maturity: The Flex framework provided - also back in 2008 - the most mature Rich Internet Application framework. Most of the available JavaScript frameworks focused on smoothing XmlHttpRequests - Canvas 2D support or SVG support was really limited. Remember: The first draft of HTML 5 was released back in January 2008 by the W3C.
3.) Development expertise: Some of our team members had already expertise in implementing Adobe Flex-based Rich Internet Applications. In the early phase of our implementation, a very important factor!
But things change! And so do we, as we want to stick to the latest technologies and provide our users the best experience in modeling business processes in the cloud. Today, our platform is maturing and beginning to build a community. This evolution requires a scalable and future-proof framework. As some of our adopters may face comparable changes in their architectures, I summarized some motivations in changing the underlying technology and reimplementing the expressFlow designer by the use of the JavaScript framework ExtJS 4.
Read more: Adobe ceases development on mobile browser Flash, refocusses efforts on HTML 5.
The old Architecture
The old architecture of our previous version of the expressFlow designer partly adhered to the principles of Cairngorm. We derived the principles of Cairngorm and built up a lightweight version of Cairngorm which simply divided layout rendering logic and MVC components. This significantly simplified the architecture of the designer: It deploys a client-side MVC microarchitecture which encapsulates model information in data transfer objects and propagates changes to views by the use of events.
But: The principles of the old architecture remain! And these fundamental principles formed the base requirements for the new JavaScript framework. In the search for a adequate framework replacement we always had this client-side microarchitecture of our old architecture in mind. And we tried to fit these concepts - which we knew by heart - to the new principles of the new framework. A time-consuming, but very important piece of work: Identify good parts of the old architecture and try to combine these with base principles of the new framework "best practices". But: Stay away of porting bad design decisions into your new framework! Yes, you need to balance on this fine line ;-)
The new Architecture
The new architecture of the designer adapts the MVC application architecture proposed by the ExtJS 4 framework. If you are new to ExtJS, I strongly recommend to read the "Architecting your App in ExtJS 4" Series (Part 1, Part 2 and Part 3). The new expressFlow Designer adheres to the proposed architecture and incorporates the RaphaelJS framework for the design area. As a deep dive into the architecture is out of the scope of this article, I will publish frequently architectural articles here. You are also very welcome to explore the code on our GitHub repository.
The dynamic aspect
JavaScript is not compiled in a plug-in! Our design decision was as simple as this. Digging deeper unveils a slightly different aspect: JavaScript frameworks are nowadays mature enough, to provide a comparable user experience as Adobe Flex did back in 2008. As we started to implement the designer, we analyzed the available JavaScript frameworks in depth and did not find a comparable framework to Adobe Flex - in terms of tool integration and maturity. Back in 2008, the smartphone and table heterogeneity aspect was not as obvious as nowadays. Remember: In 2008 Apple did not refuse support for flash and Microsoft started Silverlight as an alternative to Flash ;-)
The heterogeneity aspect
Today's web applications need to render on different devices: (Different) web browsers, smartphones, tablets and many more. To enable productive development, the framework in use needs to address this heterogeneity.
The first point (different web browsers) is sometimes still an issue in JavaScript, but most frameworks are now mature enough to overcome quirks-modes of some browsers. Still, user interfaces are rendered differently which requires developers to write bad code (browser-checks, CSS hacks, ...). But current JavaScript frameworks catch up with this and try to provide a homogeneous development environment. And they do great: Dojo, ExtJS or ZKoss - to name a few - provide productive ways for developers to realize unique user experiences in different browsers.
The second point (heterogeneous devices) came up recently and is still at the beginning. The number of Smartphones and Tablets is rapidly growing and web frameworks need to provide functionalities to ease the development effort for mobile web applications. Anyway, hybrid applications (like f.e. implemented by the use of PhoneGap) make this heterogenity aspect a little bit more complicated - but we focus on mobile web applications providing reasonable user experiences of our human tasks on smartphones and tablets.
The community aspect
Open source frameworks are great if they enable a community to grow. No question, GPL or other open source compatible license models provide the basis for a community. But this community needs be reactive, proactive, supportive, ... And it has to extend the framework. The Adobe Flex SDK is open source. But the Flash Builder is not - neither the Flash Player internals, nor the AMF internals. Did you get the point? Right at this point we want to mention the GraniteDS project, for making a great job on providing an open source alternative to Adobe's BlazeDS. You guys rock!
We searched for an open technology, which has GPL as the basis and searched for estimations of the size of the community. And we found this interesting blog post: Drew Conway and Jon Myles analyzed the social coding platforms GitHub and StackOverflow for the popularity of programming languages. And: JavaScript clearly dominates the scene. ActionScript is also rather popular, but with the previously mentioned trends I expect a falling popularity for ActionScript in future - and a rising popularity of JavaScript. So, we also decided for a more active community by answering the following question: What is social on a social BPM engine, when there is no community?
The integration aspect
We make a business process designer. One (big!) part of the designer is the integration of third party services. This needs to be as simple as possible. No, it needs to be more than that: It needs to be almost transparent.
The underlying architectural principles of web applications adhere to REST - REpresentational State Transfer. To enable a transparent development model, this principle needs to be supported transparently by the framework. Adobe Flex missed a seamless integration of the REST paradigm. ExtJS does a great job on integrating REST transparently to the developer: You are able to define models which are stored in stores. These stores (or also the models) are able to communicate by the use of proxies with server endpoints. You can read more about the data conceps in ExtJS here. We like this concept, so +1 for ExtJS on the integration of REST architectures!
The frameworks: Adobe Flex vs. [ExtJS | ZKoss | jQuery | MooTools | QooXDoo | GWT | ...]
Ok, i think you got the point. Although Adobe Flex is not limited to Adobe's Flash Builder and it's open source SDK - there are many open and proprietary alternatives out there - these two components are clearly dominating the scene. So if you decide to go with Flex, you are connected to one tool, with all advantages and disadvantages (vendor lock in, integrated developer experience, ...)
On the JavaScript-side you have to select, which framework fits best. They all have their advantages and disadvantages, so the decision phase is clearly more time-consuming than deciding for Adobe Flex. But what we can say up to now: This work is worth its effort! All advantages of ExtJS (stores-concept, integration of RaphaelJS, architectural documentation, license model, etc.) helped us in improving our development by decreasing our development time. We are evaluating this continually - and I will keep you informed.
Multimedia support
Well, Flash is leading in Videos. Undoubtly. And some signs indicate that this won't change so fast. And HTML 5 alternatives? Well, they are rising - but the Flash video format is definitely leading. But with the mentioned JavaScript Frameworks, the integration of Videos in Rich Internet applications is no big deal. There is only one aspect, you have to consider: Flash Videos are not supported on each platform (iPhone, iPad). But as all mentioned aspects previously: The concrete benefits of a particular framework need to be analyzed for your specific platform.
Conclusion
Things change - and so do we. We had a great time in developing Adobe Flex but we moved to ExtJS - and we fell in love. It provides very handy features (cp. the data package, drawing with RaphaelJS) and JavaScript is - in combination with a mature framework - a great development experience. It has a vibrant community and if you develop web applications with and for a community there is currently no alternative.
Beyond the framework discussion, a change of technology provides a very good opportunity to rethink your architecture. Focus on good parts! The change is worth it, if you reuse good architectural principles and throw away bad, time-consuming concepts.
About the author: Martin holds a Ph.D. in Computer Science from the Vienna University of Technology. He initiated expressFlow in 2010 and consults enterprises in the realization and implementation of BPM projects.
You can reach him by email: [click to unhide] or simply follow us on http://www.twitter.com/expressflow.