This article is sponsored by Adobe.

A Conversation with Frank Sommers

---

Advertisements

Interested in Flex graphics? Check out the new book Flex 4 Fun by Chet Haase, available as a paper book and an eBook from Artima Press. ...

Bill Venners: Can you give an overview of your company's product?

Frank Sommers: Our company focuses on the automotive financial services industry. Our application helps automate the loan underwriting and loan processing part of that business. In that sense, it's a fairly typical "enterprise" app. Our customers use our tools to make it more efficient for them to work with loan applications that come into the office and are being processed for approval. That includes loan processing workflow, document management, loan decisioning, risk management, finance company and auto dealership communication, executive decision making, and sales support.

Bill Venners: How did you end up using Flex?

Frank Sommers:We started using Flex about three years ago. Prior to that we had a Ruby on Rails app and, before that, parts of our application were written in Java, using Swing on the client.

The Rails version of our app was fairly successful: Rails worked very well for our purposes, in an enterprise setting. As with many projects, what often happens is that as users start using an application, they see more uses for that application, and they suggest more features they want that application to have. Customers are often willing to pay for features that serve their complex business needs, and our application evolved over the years with increasingly sophisticated capabilities.

In the process of implementing those features, of course, you have to modify your code base. Not only do you add code to implement new functionality, but you also refactor existing code. It was in that process that Rails started to show some problems in our case.

Although Rails caters to the needs of an agile development process, with excellent support for database migrations, built-in tests, and so on, we had difficulties performing larger refactorings of our code. Larger refactorings—where many code artifacts change names and are moved and reorganized—are sometimes necessary as you gain better insight into the problems your app is trying to solve. The alternative is to live with a codebase that reflects an early, and possibly incomplete, understanding of your application's current purpose. That latter option is the basis for Ward Cunningham's notion of technical debt: it may sometimes be the right choice—for instance, to meet deadlines or to show rapid progress in a consulting situation—a product-based company, however, can't afford to pay for long the constant overhead of that debt.

Even though Ruby and Rails IDEs support code refactorings, performing larger code reorganization was a big challenge for us. Coming from a Java background, I was used to IDEs enabling me to move classes across packages, rename classes and methods with ease, update my test cases to reflect refactorings, and to do all that without having to worry about inadvertently breaking something. And if something did break, the Java compiler was there as a last resort to pinpoint refactoring errors. Ruby and Rails just didn't have that, and we started to miss that functionality, and would have traded off some of the Rails and Ruby agility for the confidence to reliably mold and shape the codebase as our product evolved.

Next to refactorings, our other issue with Rails stemmed from the requirement to add greater interactivity to the UI. Part of Rails' magic is that if you follow the beaten path, your job is bliss: You can take advantage of Rails' generators, migrations, and everything just works out of the box. At the same time, though, the more you deviate from that path, the more you have to roll things on your own.

In our case, we wanted to provide greater interactivity in the UI. For example, we wanted to add a datagrid that could be sorted and re-arranged on the client. Our users were business managers, and their world of tabular data was firmly rooted in Excel. They expected to be able to have several thousand rows of data in a browser-based datagrid, and be able to sort and filter and re-arrange that data with the same ease they were used to in Excel.

We looked at several client-side components, and settled on YUI (the Yahoo User Interface toolkit). YUI has an excellent datagrid that can present lots of data. YUI's datagrid is based on other YUI libraries for some of its functionality, such as loading and filtering data on the client. Integrating YUI with Rails was fairly easy: We incorporated the YUI datagrid into a Rails view, the datagrid loaded into the page and invoked a Rails controller to obtain its data in JSON format.

A couple of months, a few more features, and a handful of additional JavaScript libraries later, we noticed that we had two independently developing codebases: One based on the client-side JavaScript, and one based on the more traditional Rails controllers, views, and models. That just doubled our codebase complexity problems: Evolving a client-side JavaScript codebase is even harder to do reliably than refactoring Ruby and Rails code. While we liked Rails and even JavaScript and the client libraries we used, taken together, we were facing a complexity explosion.

We were a small company and could ill afford to live with that sort of accidental complexity—the business problems we were trying to solve were complex enough already. It just came to a point where we started looking for alternatives. But we also didn't want to go back to Java, JSPs, and JSF. Having used Swing extensively before this project, I also couldn't go down the Swing path, given the client-side installation issues that persist to this day in the Java world.

We could live with the compromise of having separate client- and server-side codebases only if the client-side code lent itself easily and reliably to refactoring, presented a seamless end-user experience, shielded us from browser idiosyncrasies, and offered a lightweight communication model with the server.

Flex met all those criteria, and we quickly prototyped some of our application's features in Flex. While we liked Flex from the start, it was our users' reaction that really convinced us to go the Flex route: The users we showed our early work to just loved the Flex UI. It seamlessly ran inside the browser, looked professional, and was fast—displaying several thousand rows presented no challenges to Flex's DataGrid component.

We initially decided to use our existing Rails backend with Flex: Our Rails controllers interacted with the new Flex UI via JSON over HTTP. That worked very well, because Rails models can easily present themselves in JSON format, and Flex can consume JSON quite well.

We later replaced our back-end with Scala. Scala runs on the JVM and performs as well as Java does, but is a more elegant programming language, with a more modern feel to it. At first, we implemented the same Rails controllers in Scala. The Flex UI was agnostic to that change, since the UI only cared about invoking HTTP endpoints and sending and receiving JSON.

Later, we moved to using the open-source BlazeDS tool for communication between the Scala backend and the Flex UI. BlazeDS provides a native serialization format between Java classes and ActionScript, Flex's programming language. Because Scala code is compiled into Java classes, BlazeDS works with Scala as well. We wrote a few filters that convert a more idiomatic Scala API to the Java-like equivalents that BlazeDS expects—converting Scala Nones to Java nulls, Scala Lists to Java Lists and Arrays. But that was not strictly necessary; BlazeDS just works with Scala as is. Because BlazeDS uses a binary on-the-wire serialization format, it is several times faster than sending JSON across the same wire. BlazeDS also bought us a few additional features, such as Comet-style messaging.

Bill Venners: How did your jump to Flex come out of your problem doing larger refactors with Ruby on Rails? I can see how a jump to Java or Scala would. Does Flex help you with large refactors?

Frank Sommers: Flex uses the optionally statically typed ActionScript 3 language. It's some kind of a cross between Java and JavaScript. They added Java-like classes to JavaScript's prototype-based object model, added interfaces, optional static typing, and a large library. Flex is an API implemented on top of ActionScript 3.

Optional static typing is an interesting feature. We almost always use static typing—except in some places where dynamic code is truly just very handy. To be sure, we could use a carefully crafted type system in those situations, especially if Flex's type system was as rich as Scala's. It isn't. Lacking that, we found that in practice, it's convenient to have dynamic typing in small areas of our code, especially in some our UI implementation. That code will almost never be exposed to larger refactorings, is very isolated, and is mostly limited to populating UI components with server-side data.

Flex also defines a DSL for UIs, MXML. MXML is an XML dialect to define hierarchical UI container layout and positioning. MXML also understands CSS-like styling directives. The Flex compiler first translates MXML into ActionScript, so anything you do in MXML can also be done with ActionScript. In practice, Flex applications are built with a mix of MXML and ActionScript. That may sound like a source of complexity, but it works out OK most of the time.

Because ActionScript code can be statically typed, that helps with refactorings. We have been evolving this Flex codebase for almost three years now, and we always have confidence that the compiler would catch most refactoring errors. The Flex IDE, Adobe's FlashBuilder, also helps with refactorings and evolving the code, although its refactoring support pales compared with Eclipse or IntelliJ Java refactoring features.

Bill Venners: What are some pluses and minuses about using Flex? What is the best thing and what is the worst thing?

Frank Sommers: The biggest plus is that, in general, Flex UIs can be pretty out of the box. Many years ago, David Gelernter lamented in his book Machine Beauty that businesses shun elegant and pretty UIs because goods looks on the screen are somehow anathema to business objectives. The image of the grey, boring-looking IBM PC comes to mind.

That has changed in the past few years: In the age of the iPhone and the iPad, users expect the same level of fit and finish in business applications. That's not self-serving: all of our customers expect UIs to be functional and elegant and interactive.

We don't have designers on staff, and I just don't have "it" when it comes to graphic design and custom CSS. I always had to rely on ready-made CSS templates, and had spent considerable time tweaking those templates to make my Web apps look nice. Even Swing required custom skinning to make a Swing app look more polished.

With Flex, you can leave components at their default look and feel, and you'll get fine result. You can incrementally add a few lines of CSS styling. And, if needed, you can develop entire custom skins using PhotoShop or Illustrator; each of those tools have wizards that make that easy. Flex 4, the latest Flex release to date, takes the separation of visual component design and logic to a new high, especially to facilitate an even more seamless skinning experience. But, again, the default is often sufficient.

Although it does rely on the Flash Player browser plugin, Adobe—and Macromedia before them—somehow figured out how to make that plugin install and work fairly seamlessly on end-user systems. Although not perfect, I wish the Java world had something as well executed for the client: We're a product-based company, and we actually have to support our end-users. It's very important for us to minimize, or even eliminate, client-side installation and setup problems. Flex and the Flash Player really hit that mark. I had supported a client-side Java application before, with very different results. At the same time, you also don't have to worry about browser versions: Flex works almost identically across the most common desktop OSs and browsers.

Next in the list of pluses is what I mentioned before already: With Flex, you deal with one environment, one language, one API on the client. That directly and measurably reduces complexity as your application grows, compared with using several JavaScript libraries in conjunction with server-side page layout generation code or a Web framework. That benefit is the most direct when you use the one-page-per-application pattern and do all UI-related work inside the Flex code.

Also, you can use FlashBuilder's debugging and profiling tools, which sometimes come in handy. FlashBuilder has improved a lot in the latest release, although it still lags behind state-of-the-art Java IDEs.

There's also a vibrant Flex ecosystem: You can take advantage of numerous open-source and proprietary Flex libraries. BlazeDS is one of them, but there are thousands of others, all the way from fancy dashboards to small widgets and utility classes.

On the downside, Flex requires the Flash Player to be present on clients. That may not be a big deal, unless, of course, you have an iPhone or an iPad. However, Flex apps work out of the box on the latest Android release.

Also, while ActionScript will be familiar to Java developers, it may not satisfy everyone's linguistic taste: it's an amalgamation of Java and JavaScript features, and combines functional and OO concepts in a way that some may consider overly pragmatic.

In addition, some may object to mixing MXML and ActionScript, and Flex apps, especially before Flex 4, just invite a cozy mix of these two in the same code file. What's more, you can also sprinkle to the brew a hearty portion of CSS inside Style tags or, worse, directly apply CSS to MXML tags. While such mixing can be kept to a minimum in Flex 4 apps, it can still be an issue if developers don't exercise enough discipline. Flex prior to version 4 makes these poor coding choices easy, and a cleaner separation harder.

In addition, if you really wanted to take advantage of ActionScript you would need to know about functional programming. Several Flex APIs support higher-order functions, such as Array. Flex doesn't force you to use these, but you should be comfortable passing functions as parameters into methods and receiving functions as method return values. That may be new to some programmers.

The problem is compounded by the fact that ActionScript doesn't define an elegant fusion of OO and functional programming in the manner of Scala, for instance. ActionScript obviously evolved from its JavaScript roots, catering to the needs of client-side Web developers and designers working with Flash movies early on. Only later did it add features that application developers are accustomed to. That evolution has the benefit of some ActionScript features being just very pragmatic—for instance, optional static typing. Pragmatic is not bad, and you can take advantage of those features when necessary; but, as is often the case, in less experienced hands those features can become problematic and create a mess of a codebase.

Finally, Flex is a client-only environment. That's a plus and a minus. On the plus side, you can use any server-side technology or language with Flex: Java, Scala, Rails, PHP, whatever. On the minus side, that forces you to deal with two completely independent codebases, written in different programming languages and requiring quite different coding skills.

Bill Venners: Is it hard to find Flex programmers?

Frank Sommers: Although Flex is not a standard in the sense of, say, J2EE, it's a fairly well-defined technology. That allows you to narrow down the skill-set you require, and it also makes it straightforward to evaluate the past work of job candidates.

While the Java community dwarfs the size of the Flex community, the Flex community is growing and vibrant nonetheless, with numerous conferences, publications, user groups, and Web communities. Because of high demand from enterprises, Flex is now among the more desirable skills to have for enterprise developers. It's important to remember that Flex has been a truly viable enterprise technology only since Flex 2, which was released around 2007. Developers even with a few years of hands-on experience are relatively rare—it's somewhat similar to finding Java developers in, say, 1999.

Another thing to note is that, unlike with Java, where many of the early adopter developers started with years of background in C, C++, or some other feature-rich programming language, Flex's Flash background means that some developers come to it with less grounding in developing serious, enterprise-ready software. At the same time, developers coming from a design background to Flex are typically more familiar with the animation-related aspects of Flex, skills hard to find in traditional enterprise programmers. It's perhaps ideal to have mix of enterprise and design expertise on your team.

Because collective wisdom about effective Flex design is just maturing, managers must be vigilant and enforce good coding practices and design. Flex's relatively new status in the enterprise also means that this is an exciting time for Flex developers who desire to learn and contribute their experience to the emerging Flex coding wisdom.

Resources

ActionScript can be found at:
http://www.adobe.com/devnet/actionscript.html
http://www.actionscript.org/

Flex.org
http://www.flex.org

Flex 4 Fun by Chet Haase
http://www.artima.com/shop/flex_4_fun

JavaScript can be found at:
http://www.javascript.com/
JavaScript Tutorial can be found at:
http://www.w3schools.com/js/default.asp

JSON can be found at:
http://www.json.org/

MXML can be found at:
http://www.adobe.com/devnet/flex/articles/fcf_mxml_actionscript.html

Ruby on Rails can be found at:
http://rubyonrails.org/

Ruby can be found at:
http://www.ruby-lang.org/en/

Scala can be found at:
http://www.scala-lang.org/

Programming in Scala can be found at:
http://www.artima.com/shop/programming_in_scala_2ed

Technical Debt can be found at:
http://martinfowler.com/bliki/TechnicalDebt.html

YUI can be found at:
http://developer.yahoo.com/yui/

AutoSpaces, Inc. is at:
http://www.autospaces.com/

Talk back!

Have an opinion? Readers have already posted 4 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.