Virtual Panel: State of the Art in Enterprise Flex Frameworks
Flex 1.0 was released in March 2004 by Macromedia (acquired by Adobe in 2005). Since then, the Flex based rich internet applications (RIA) development has been increasingly gaining momentum; and RIA has become a well accepted web application development approach. Recently Adobe released Flex 4 along with Flash Builder 4, as part of the Adobe Flash Platform technology.
To assess the state of Adobe Flex for enterprise adoption, InfoQ has conducted a virtual panel with the creators of some of the most popular third-party flex frameworks.
The participants were:
- Chris Gross from the Potomac Framework,
- Jeremy Grelle from Spring BlazeDS Integration,
- Zoltan Csibi from FluorineFx,
- Laura from Mate,
- Dima Berastau from RestfulX and
- The Swiz framework team
InfoQ: What was the purpose of developing your framework and what need does it try to satisfy?
Chris (Potomac): We created Potomac because we experienced the difficulties of developing a large modular Flex application first-hand. Coming from a Java background, we were familiar with OSGi and the Eclipse RCP platform and how those frameworks made developing these kinds of apps much easier. So we created Potomac to bring those capabilities to Flex.
Zoltan (FluorineFx): The purpose of FluorineFx is to provide an open source alternative for Flex/Flash Remoting, Flex Data Services, Messaging and real-time messaging functionality for the .NET framework. Additionally the framework provides client side libraries, like FluorineFx for Silverlight, bridging different RIA platforms. Its key advantages are low total cost of ownership, reduced dependence on software vendors and easy customizability.
Laura (Mate): The main purpose of Mate was to make our own life easier by making applications easier and faster to develop, by being able to open the code of an application and understand how it was constructed and by making it easier for us to teach junior developers how to create complex applications.
As most other frameworks, it tries to give you the tools and guidelines to help you developing applications that will scale and have clean and clear code. Mate also has a focus on simplicity and non-intrusiveness.
Dima (RestfulX): RestfulX was developed to facilitate integration between Flex-based clients (in browser or AIR) and various server-side technologies (such as Ruby on Rails) using REST pattern. In particular, RestfulX focuses on providing a consistent data model abstraction layer in Flex to perform CRUD against multiple back-ends using multiple messaging solutions (XML, JSON and AMF). While Ruby On Rails remain a popular back-end choice for people using RestfulX, the framework can be used with Google App Engine, .NET, PHP and so on. One of the interesting features of RestfulX is ability to synchronize between remote and local data sources, meaning you can pull records from Ruby On Rails and push them to local SQLite database when running in AIR and visa versa.
Swiz Team: The framework was created as an effort to bring as many of the benefits and development principles of Spring to the world of ActionScript and Flex. As such, it aims to satisfy developers' needs in the form of a lightweight, non-prescriptive set of classes that make them more productive, help them write cleaner code, and provide some optional hooks and mechanisms to write powerful custom applications.
InfoQ: What would be the main challenges and obstacles that a team would face while trying to implement an enterprise scale Flex-based solution? What are the common pitfalls and how would one avoid them?
Chris (Potomac): The primary challenge is the overall architecture and organization of code and modules. When developing a small application with perhaps only one or two modules, organizing your code is easy. But imagine a project where you have anywhere from 10 to 50, or 100 modules. And what if there are multiple teams collaborating on the same project? Those questions of how to organize your code, how to manage dependencies between teams, and how to architect the main application to load these modules only when needed, become much harder to answer. Potomac gives you the tools to answer these questions. The Potomac plug-in for Flash Builder enables you to split your large Flex application into a number of smaller module projects. Then it allows you to declare dependencies between these modules. Finally, Potomac’s metadata-based extensibility system enables you to create a loosely coupled collection of modules. By comparison, using the basic modularity features in Flex feels like the stone-age.
Potomac also provides a UI composition framework that handles all the module loading and management for you. On top of the modular features, there a tons of other features that speed up development of business applications. These include dependency injection, save/close management, busy animations, and more.
Jeremy (Spring BlazeDS Integration): The main challenge that I see people dealing with frequently is figuring out the right way to deal with the organization, modularization, and testability of a large enterprise Flex code base. Flex is extremely easy to get started with, but as is common with many other technologies the patterns used when you're just learning and developing as a one-person team do not scale well to large teams and large code bases. Fortunately there has been quite a lot happening in the Flex open source community over the last few years and some great projects have emerged that help solve this problem. I am (obviously) a big fan of Spring ActionScript for this, which is an open source project under the umbrella of the Spring community extensions. It brings a lot of the familiar style and idioms from the Java Spring Framework to ActionScript, enabling looser coupling and better testability through the use of dependency injection and some nice clean abstractions for common needs such as event handling and asynchronous communication. It does not prescribe any particular structure and can be used to build applications with a number of different MVC or MVP style approaches. I personally really like the idea of keeping things simple and applying the MVP pattern yourself with the aid of a framework like Spring ActionScript without being forced to extend any additional framework-specific classes. It also compliments Spring BlazeDS Integration particularly well as it provides a clean way to externalize configuration details such as the URLs that the Flex client is using to communicate with the Spring-based server side, thus avoiding the need to recompile if that information should ever change.
Zoltan (FluorineFx): FluorineFx tries to follow the APIs, best practices of the equivalent (Java based) tools from Adobe so new users of the framework should meet a familiar API or configuration environment. However a good Flex RIA based background is recommended, especially for large applications that require more than simple client-server remote procedure calls.
Laura (Mate): One of the main challenges faced when developing an enterprise application is that - and this may seem obvious - it is large. There are too many classes, too many requirements, too many relationships between all the parts. You need to think on a global scale to make sure those parts will not be so tied together that whenever a requirement changes - and they do change! - nothing will break. You need to compartmentalize while at the same time, have certain specialized components that can put it all together to make a cohesive application.
Dima (RestfulX): Compiler speed is probably one of the big annoyances with Flex for me. While Flex 4 compiler is faster than Flex 3 compiler it is still a drag particularly for larger projects. There isn't any way to avoid this but certainly something you should be aware of when starting a new project using Flex. The other aspect that I'd emphasize is code organization and modularity. Flex encourages a more traditional client-server application programming paradigm. What you end up with is a standalone GUI application and a server that you send messages to as opposed to client and server code intertwined in one app. As such there are plenty of opportunities for code reuse beyond standard MVC and you might find it useful to look at lessons learned with OSGi on the desktop (e.g. Eclipse IDE) and potentially apply those to your Flex app to make it easier to maintain and extend.
Swiz Team: Common challenges for Enterprise Flex applications are often the same from project to project. How do you keep the model from becoming a giant monolith of data? How do you route events to and from disparate parts of the application? How do you define your service layer and the interactions with it? Swiz provides tools to help you solve all of these problems. Swiz's Inversion of Control container and Dependency Injection mechanisms make it easy to provide data where it's needed, regardless of the source, which encourages smaller, more focused models. Swiz provides a central event bus and dead simple [Mediate] metadata for dispatching and handling application-wide events, respectively. Swiz provides helper classes and methods that reduce the effort involved in interacting with remote services to little more than writing your result and fault handlers. These are just a few examples, but the point is that Swiz helps you write good code fast, and then it gets out of your way.
InfoQ: Do you think that the Flex framework and the surrounding ecosystem is mature and complete enough to be considered for enterprise solutions? How well do you think it competes against other solutions like HTML 5?
Jeremy (Spring BlazeDS Integration): Absolutely, I think the Flex ecosystem is extremely mature, as is evidenced by the number of great open source projects that have emerged and continue to emerge, and I have seen some really impressive examples of enterprise Flex applications in production. I am an equally big fan of HTML 5 and look forward to the day when it is just as easy to build some of the more advanced things people are building in Flex today using native browser capabilities and have it work across a large variety of browsers. Technologies like Canvas, WebSockets, and CSS transforms hold quite a bit of promise, but I think it's going to take some time yet before all of the specs under the HTML 5 umbrella are finalized and available consistently across browsers, and before the tooling reaches the point of maturity necessary for widespread enterprise adoption.
Zoltan (FluorineFx): HTML5 may change the RIA landscape when it will be more mature and available, whereas Flex actually exists. The Flex framework and the surrounding ecosystem is mature enough, and there are thousands of production Flex enterprise applications out there.
Laura (Mate): I strongly believe so and don't think HTML 5 is up to par yet. I remember when we were moving from HTML tables to CSS layouts. Your CSS had to be full of hacks to make it work everywhere. With HTML 5, I think it is even worse at the moment with its lack of cross-browser compatibility and support.
Dima (RestfulX): Despite all the recent controversy around Flash on iPhone/iPad Flex is actually one of the more mature and complete frameworks for developing Rich Internet Applications out there and is well suited to developing enterprise applications. It has a large component library, top notch data visualization options, consistent rendering across browsers and platforms, test automation support and great tooling. All the things that will save you time in the long run, particularly if you aren't targeting mobile devices with the same GUI code base.
As far as HTML 5 is concerned the competition is mostly with Flash not Flex. SVG, Canvas component, local SQLite DB and audio/video components is something that will put HTML 5 on par with Flash. Flex is at a higher level of abstraction focusing on component driven UI development. As such it is best compared to frameworks such as SproutCore and Cappuccino. Regardless, it's great to see the drive towards making HTML5 final and supported by all major browsers.
Swiz Team: Absolutely. Everyone on the Swiz team has experience creating enterprise Flex applications during our careers, and that experience is what inspired and informed the framework's philosophy and architecture. Particularly for applications that need a richer presentation layer, whether that be for data visualization, engaging and captivating users or providing a high degree of interactivity, Flex excels over traditional browser based solutions. Right now, in June 2010, HTML 5 is not a viable solution for any public facing work, enterprise or otherwise. Depending on which features you want to include in the malleable definition of the "standard", you are looking at a solution that will work consistently for 30% of a general public audience, tops. If you have clients that are willing to pay for work that turns away 70% of their potential audience, more power to you. We have not met any of those clients. If consistency, relative ease of development and audience reach are important, Flex is the logical choice, hands down
InfoQ: What were your favorite new features in Flex 4? What would you like to see in future versions?
Chris (Potomac): My favorite feature of Flex 4, specifically Flash Builder 4, is the enhanced Package Explorer. We also offer a Flash Builder 4 add-on called SourceMate that brings many enterprise features to Flash Builder including code generation, refactoring and more. The productivity of a Flex 3 developer after upgrading to Flash Builder 4 + SourceMate will be double.
In future versions of Flex, I’d like see a better HTML control. Many enterprise applications need to show full HTML markup in their Flex applications.
Jeremy (Spring BlazeDS Integration): The most impressive and most shear fun-to-play-with features in Flex 4 are the new graphics effects and animation capabilities and how easy it is to apply them to any visual element on the screen. I am also quite pleased that there seem to be some notable speed improvements in the compiler, making the code-deploy-refresh cycle quite a bit quicker. Things I would like to see in the future have less to do with the framework itself than with the Eclipse-based tooling for it in Flash Builder. The tooling is great, and in general is a nice productivity booster, but there are still a few gaps that need to be filled in comparison with that to which a typical Java developer is accustomed. There is another great plugin called SourceMate that adds a lot of what a Java developer might consider "missing features" such as improved code generation and refactorings, but it would certainly be preferable if those features were incorporated directly into the Adobe tooling out-of-the-box.
Zoltan (FluorineFx): My favorite features are the new Spark skinning and component architecture and performance improvements (compiler). As an open source developer I would like to see in future versions of the framework the availability of persistent connection infrastructure (RTMPChannel).
Laura (Mate): I love the new skinning and component paradigm. It makes creating custom components that are easily skinnable so much simpler.
I would like to see printing much improved, as that is one of the things that always appear as a requirement when you build business applications.
Dima (RestfulX): My favourite feature in Flex 4 has to be the new component architecture. It's significantly easier to extend and style existing components (compared to Flex 3) and create your own. In the future I'd like Adobe to focus on making Flash and Flex leaner and faster. I'd like Flex apps to have a better memory footprint and faster loading time out of the box.
Swiz Team: I think the new component model will be beneficial in the long run. Right now there are still lots of rough edges and tools like Flash Catalyst are not ready for prime time, but the general approach is a good one. States have also become fairly useful in Flex 4. FXG in general also opens up some interesting possibilities. Most of our hopes revolve around language and run-time evolution more than Flex features. Support for more advanced features like abstract classes, method overloading, multi-threading and of course better metadata support would go a long way to enabling some of the ideas we have.
InfoQ: What are the future directions of your project?
Chris (Potomac): It’s an exciting time for Potomac. We’re seeing significant uptake and we’re pushing out many new features. More importantly, we’ve recently had discussions with the Eclipse Foundation to bring Potomac to Eclipse.org. Eclipse is quickly becoming the center of the universe for Java modularity thanks to its use and promotion of OSGi. With Potomac, we hope to start a new a branch of the Eclipse ecosystem in the Flex world.
One notable feature on the Potomac roadmap is support for loading bundles from other sites. This will open up a whole new realm of possibilities for web applications. Imagine developing a public web application that can be extended by others. Take a photo editing application for example, today many of these applications when on the desktop provide a plug-in capability to add new palettes and new editing features. But when these applications are moved to the web they lose that ability. Potomac will make that possible on the web. Instead of your user downloading a plug-in, they simply type the URL of the add-on provider. Developers will be able to enable a rich ecosystem of add-ons around their applications just like they could on the desktop.
Jeremy (Spring BlazeDS Integration): The main thing we've been focused on is a Spring Roo addon that will configure Spring BlazeDS Integration remoting destinations and scaffold a Flex-based user interface. It handles automatic generation of ActionScript classes that mirror the Java domain model and keeping the two in sync via Roo's signature round-tripping capabilities. We have been working on this in parallel with the next major release of Spring BlazeDS Integration (version 1.5), and as such most of what we've added to the core project, such as support for proper AMF serialization of Hibernate proxies and lazy associations, has been in direct support of the needs of the Roo addon. We expect to have an M1 release of both the core project and the Roo addon available very soon.
Zoltan (FluorineFx): FluorineFx will evolve to implement all the features that a messaging, streaming server has to provide for a Flex based solution. It will also focus on developer productivity by providing templates, plugins and other productivity enhancements.
Laura (Mate): We would like to create a lighter-weight version that does not depend on the Flex Framework. We are planning on adding some compile-time checking to the tags we use to make it easier to catch errors.
Dima (RestfulX): Quite a bit of work has been already put into the upcoming version 1.3.0 of RestfulX with a general emphasis on performance. Faster/easier data synchronization and native AMF support are some of the primary features of the upcoming release. After that the target will shift towards better Rails3/Flex4 compatibility.
Swiz Team: Right now we are focused on getting a solid 1.0 release out the door, but in the future we hope to continue empowering developers to write clean, powerful code, and to write it quickly. We want Swiz to remove as many of the tedious, boring tasks for the developer as it can. We want it to continue to provide a robust, extensible base on which developers can write their own reusable power features. We want it to help create and drive a vast collection of community created Swiz extensions that make creating enterprise Flex applications with Swiz even better.
Re: State of the Art in Enterprise Flex Frameworks
Re: State of the Art in Enterprise Flex Frameworks
Re: State of the Art in Enterprise Flex Frameworks