As with many technical decisions you meet when creating applications for the web, you need to let your context by your driver. Trust me, I wanted to take HTML Hill and dig in for the victory-or-death battle, but the client liked a couple of Flex sites. I mean really liked them. So, rather than just fight the “but that doesn’t look like Flash” battle constantly (even though I think we could win…let it go…let it go…) we are using Flex.
So, I am a lot like my kids eating their spinach. They get why they have to do it, but they do it begrudgingly and with a nasty look on their faces. And, much like the vegetable-hating youngsters, I am reaping some benefits:
- Knowledge is Power. Learning a new language is always a good thing. One of my favorite books, The Pragmatic Programmer, encourages developers to learn a new language each year.
- Somes things are easier. Some stuff is easier in Flex/Flash. The best example is probably cross-domain URL access. If you want to allow a Flash object to access a URL, you put an XML file (crossdomain.xml) in the root of that site. You can allow access to anyone, or domains, or all kinds of options. Having struggled mightly with AJAX/REST scenarios involving the same-origin policy, this was really, really great. Also, the UI is just easier to create. Sexy, translucent panels and easy drag/drop capabilities come to mind.
- Flex tries. Flex does it’s best to use some web paradigms, like CSS stylesheets. Many of the style properties are specific to Flex, and I don’t profess to understand even half of them, but it made me feel a bit more comfortable.
Now, from the “I told you so” vault, some of the cons:
- Accessibility (duh). If we want this web application to be usable on multiple devices (iPhone, screen reader, etc) then we are gonna have to write a totally different interface. I understand that even in HTML land there is some of that, but it’s easier and allows for more UI code reuse.
- Unit testing. While there are a good number of Flex unit testing frameworks (FlexUnit, ASUnit, Fluint, FlexMonkey, and even RIATest (commercial)) they are all difficult to use in my opinion. Now, part of this reason is because the map is a custom component and is not friendly with the Flex Automation Framework out-of-the-box. We have struggled finding a unit testing framework that we like, but I think we’re about to settle on Fluint.
- Continuous Integration. After unit testing, the next step is continuous integration, and I have no answer for this one yet. Yes, I know there are things out there like Hudson, Maven, flex-maven, as well as a series of posts on CI with Flex using CruiseControl. I think my main issue here is my .NET bubble. We have other services and applications under development for this client, all of which are .NET based. We have CruiseControl.NET for these .NET based items (thanks CIFactory!) so I have spent much of my time trying to figure out how to integrate our Flex app into that CI setup. I think this is the wrong approach and we’ll ultimately have to create a separate Flex only CI server.
The best part apart this project has been actually working with a team of developers again. My projects before this one were cowboy-ish in nature, so I was doing all the nerd stuff. We have some crazy-smart people where we work, and it’s fun to tackle this new stuff with them.