I got an email from an enterprise architect considering Adobe Flex as a platform for Web application development in their organization. This email contained a well prepared list of questions/remarks/concerns that many of enterprise Web architects may face. That’s why I decided to publish my short answers to these questions. I didn’t change the wording of the questions/ statements.
Language:
ActionScript3 is a weakly typed language
This is true, and when I started using it I was also getting angry with Flex compiler that wouldn’t catch my obvious mistake. But as you get more comfy in this environment, you’ll appreciate more and more the flexibility of this language. Most of the developers understand something like
var myCustomer: Customer=new Customer();
myCustomer.lastName=”Mary”;
But look at the following notation:
myCustomer[“lastName”]=”Mary”;
The latter instruct the AS3 compiler, “Don’t bother checking if the Customer class even has a property lastName. I know for sure that it’ll be there during the runtime”. Does it look scary? Don’t use it!
Adding a keyword dynamic in the class definition allows you adding properties on the fly. Looks scary? Don’t use it.
To get a better feeling of pros and cons of using dynamic features of the language, read this blog on different styles of programming.
But applications written in dynamically typed languages do require more testing than those written in strongly-typed ones.
AS3 has no support for generics, method overloading, threading, enums, synchronization (handling of a resource e.g. file), annotations.
You need to use a different approach while evaluating domain specific languages vs. the common-purpose ones. Flex is a domain specific language that is not used for developing powerful scalable multi-threaded solutions on the server side. With Flex you are developing just the front end for the applications that are being used by a single user working on his/her computer.
The lack of generics is not a serious drawback (I can live without them in Java too).
Method overloading is not the feature of AS3, but it can be emulated using so called …rest parameter. This is not a showstopper.
From the developer’s perspective, Flex is single-threaded which minimizes the number of mistakes of unskilled (say Java Swing) developers who didn’t put code to refresh the screen into a proper thread, which causes unpredictable results.
Flex has so called metadata markup, which can play the role of annotations. Kinda.
Flex doesn’t support enums, but if this is important for you, consider using a solution offered by Farata Systems in this blog.
For security reasons, the reading/writing in files from Flex application is restricted. In some SharedObject’s may help, but if you need to have full file I/O support consider Adobe AIR.
Difficult to program to enterprise patterns: dominated by event model
While implementing design patterns you should account for specifics of the particular language/environment. Creators of one of the MVC frameworks shoot themselves in the foot by trying to avoid Flex specific event model by introducing more generic Notification class and by implementing Observer design pattern instead of using Flex-specific binding syntax. This approach resulted in creation of overly-engineered and convoluted framework that can be used in several languages, but doesn’t take advantage of goodies available in Flex. You can find some good examples of design patterns implementations in Chapter 2 of the book Enterprise Development with Flex currently available online.
Idiosynchratic binding restrictions and difficult two-way binding; may have been addressed with Flex v4?
The two-way binding is introduced in Flex 4. While being an excellent mean for increasing the productivity of Flex developers, don’t abuse binding. Nothing comes for free and just placing these elegant curly braces actually translates to a bunch of generated AS3 code and may lead to some performance issues in UI-intensive applications.
Poor Collection framework
Yes, AS3 collections are not as advanced as in Java, but they do a decent job if you take into consideration the small size Flash Player where they have to operate.
Generally immature API with numerous traps / pitfalls
ActionScript3 is more than a ten year old language and its current version is stable and doesn’t seem to have more bugs than other languages.
No support for XML schema validation
True. On the bright sight, Flex offers very easy syntax (E4X) for XML handling. But in general, I prefer minimizing using XML, if possible. Sending strongly-typed DTO’s from the server is a lot better way to architect applications.
Platform:
Validation implementation too simple and not extensible
Consider using validation solutions from Clear Toolkit described over here. Validation solutions are extensible in Flex.
Poor error handling due to asynchronous event firing and separation of MXML and ActionScript in components
I wouldn’t use the word poor here. When you work in asynchronous mode in any language, techniques for error handling are different. When an asynchronous callback is invoked in Flex as a result of the server side call it comes with an argument containing the error information similar to FaultEvent.
Limited printing support
True. Consider using extended Flex components from Clear Toolkit that offer PDF generation on the client. Read more in Chapter 11 of the book Enterprise Development with Flex.
FlashPlayer 10 does not run on Windows 98 or Windows ME
So? Would you stick to Java 1.1 just because Internet Explorer doesn’t support any further versions of Java? Stick to Flex 9 if supporting of older versions of Windows is a must.
Flash Player upgrade/compliance to potentially address bugs etc … is an overhead and will depend on customer willingness to upgrade with any frequency. If a customer refuses to upgrade then what?
As of today, there is no other software in the world that can compare with Flash Player in terms of the speed of penetration. The upgrade is extremely easy. The customer doesn’t want it…This is a problem in a democratic society. If this would happen in Soviet Union, KGB would simply send him/her to a labor camp in Siberia. This technique won’t work in the current enterprise environment though. Just ignore such customers. I know that some people turn off JavaScript support in their Web browsers, but this is not a good reason for not using JavaScript for Web development.
Testing:
Poor / complex unit testing of component behaviour
FlexUnit 4 adds a lot more flexibility for those who want it.
Absent integration testing between Flex client and middle tier
This is not true. The proper use of build scripts (Ant or Maven) in conjunction with such continuous integration tools as CruiseControl allows you to set up an environment that fits your needs.
Absent test automation
This is not true. Look at the open source FlexMonkey or commercial tools like QTP or Neoload
Lack of available testing tools
See above
Build:
Unimplemented build process automation
You might be tired by now by my suggestions to look at the Clear Toolkit, but it includes Fx2Ant tool that automatically generates Ant scripts for your Flash Builder projects.
Complexity:
Asynchronous platform difficult to code safely to resulting in unpredictable/inconsistent behavior
I see no grounds for such accusations. Asynchronous way of communication with the server side components is implemented in an easy to understand and consistent manner.
Complex event driven MVC model overlayed upon Flash’s own event model
Internal Flex MVC model implemented in some components is typically built using binding and is not complex.
Mixing ActionScript and MXML -> complex, unstructured code (flabby code) – not dissimilar to coding JSPs with moderate to large amounts of JavaScript per file
MXML and AS3 code can be completely separated using various techniques. If you are into design patterns, read about the Code Behind over here.
No automated XML serialization support -> complex error prone data mapping and in some cases tests are the only mechanism to capture errors
I recommend minimizing use of XML in favor of strongly-typed data transferred using AMF or RTMP protocols.
No coding standards/guidelines developed to instruct developer’s on how best to develop, what best practice is etc …
Read about coding conventions here. A number of articles/books on best practices in Flex is already available in this number is growing
Follows same paradigm as HMTL/Javascript
I don’t agree. The main difference is that MXML gets automatically converted into AS3, which in turns gets compiled into bytecode. The byte code runs in the browser-independent VM. This is a huge advantage over developing in unpredictable HTML/JavaScript environments.
Code duplication:
Duplication of model across tiers
I wouldn’t call DTO’s that are traveling between the client and the server code duplication.
Duplication of validation rules across tiers
You shouldn’t program duplicate validation rules on the client and the server. Ideally, your Flex RIA should be developed as a stateful client, and you should apply validation logic accordingly without any duplication.
Technology boundary -> business logic tends to bleed into UI
I wouldn’t use the word bleed in this context. RIA with Flex is like a different incarnation of Client/Server technology. In the desktop world, Visual Basic or PowerBuilder also included a portion of business logic. Popularity of thin Web clients was rather a result of the stateless nature of HTTP protocols then business-driven solutions.
Third party support and documentation:
Incomplete IDE support: no refactoring, poor search functionality, missing many productivity features
Agree. Flash Builder has room for improvements. IntelliJ IDEA may be considered an alternative IDE for some hard-core developers.
Few / immature third party library support
I know more than a dozen of third-party frameworks used by Flex developers.
Few written examples / templates – or too simple – of Flex in the enterprise
Agree, developers need more enterprise-level books and articles. Flex became a serious player on the enterprise market about three years ago and this explains relatively small number of non-trivial coding examples and case studies. Flex is very easy to get started with, but unless you have an experienced technical leader on your project the chances are that you may create a poorly designed and slow performing application.
BlazeDS has some problems in relation to session management. We would need to rework the code or wait for a release to fix these problems
Consider re-thinking what data should be stored in a session. Ideally 90% of your session data should be stored on the client.
Client / user experience:
Slower startups due to fat client
You need to learn modularization techniques of Flex applications. Unless you are developing a Hello World type application, it has to have more than one SWF.
Requires Flash runtime @ set version with OS support
The ease of Flash Player upgrade makes this a non-issue
General:
Much lower productivity compared to other frameworks; especially around XML transformation
I’d say that Flex is more productive environment than most others that I know about. I’d highly recommend avoiding using XML as a data format for client/server communications.
Much greater testing required due to asynchronous application behavior; testing is tricky as timing affects the results
True. Plan more time for testing of your enterprise Flex applications. On the other hand, you can extend and customize AMF and RTMP protocols (channels, endpoints, and adapters) and wrap them up into a separate layer to add more security, reliability or some business-specific functionality to create Web applications that are a lot more robust than HTML/JS ones.
Steep learning curve: significantly different programming paradigm to Java web development
I wouldn’t call it a steep, but it’s not as easy as Adobe is trying to present. Get the right instructor or mentor.
Code scatter and poor organization leading to poor maintainability
Any event-driven programming environment may have code scattered in several entities but this doesn’t equate to poor maintainability. Based on my real-world experience in such environments (five years in PowerBuilder, two years in Visual Basic and three years in Flex) I can say that they do not require higher maintenance than Java enterprise projects, which I’ve been developing for 10+ years.
Poorer coding experience
The syntax of ActionScript looks very similar to Java and having declarative language for the UI part (MXML) is a trend in all modern RIA tools like Silverlight or JavaFX.
Proprietary technology
I used to hear this argument a lot back in 2006 when I had to convince AJAX proponents that it’s not the best choice for enterprise application. They used to say that AJAX has lots of open source frameworks and they didn’t want to lock themselves in with a proprietary technology from one vendor (Adobe). It didn’t occur to them that with Ajax, they’d definitely lock themselves in with one of the small vendors of the selected AJAX framework.
Flex SDK, BlazeDS and AMF protocol is an open source software backed by a large vendor. If you don’t like something – get the code and modify it to as you see fit.
BlazeDS 4 has beta release; should we be investigating this version?
Abode has a history of drastically changing the API of the beta software. I wouldn’t advise to start any serious development with beta projects (the same applies to beta versions of Flash Builder 4 and LCDS 3.0). Keep an eye on the beta software but do not invest too much time in it unless you need some feature badly and are willing to keep modifying your application code with every new maintenance release.
Should we be using RemoteObject rather than XML and finding a workaround for the problem of passing nulls between Flex and Java?
Yes, you should be using RemoteObject not just to find a workaround for some problems, but to lower the network traffic, increase communication speed and work in a strongly typed environment.
Flex 4 has beta release; will this release address any of the issues raised above?
I hope that after reading my answers above you’d agree that the word issue is too strong here. Flex 4 will introduces a new set of components, Flash Builder will get new wizards (code generators) and Flash Catalyst that may improve the designer-developer workflow. But this version doesn’t introduce and revolutionary changes that would affect your decisions to use or not to use Flex platform for RIA. I personally try not to fall in love with any technology, and if I see a better RIA tool that can be used with enterprise applications, I’ll definitely consider it. As of today, I don’t see any serious competition to Flex in this space.
Those who are interested in learning/discussing Advanced features of Flex are invited to attend one of the technical seminars ran by Farata Systems. The closest ones are in London and Atlanta.
Disclaimer. I don’t work for Adobe and won’t be rewarded by them in any shape or form for promoting Flex. I was never shy before and will not think twice discussing real issues in the design/implementation of Flex framework, but since this tool is better than others in the RIA domain, it deserves appropriate credits.
Yakov Fain
