To Flex or not to Flex.
Recently at FuseTalk, we did some research on building our presentation tier for an upcoming project in Macromedia Flex. If you’re not aware, Macromedia Flex is a presentation server that serves up Rich interfaces that are generated by server side XML and compiled then presented in the Flash Player. Macromedia Flex makes a bold statement that the future of Web UI development is Rich & Ubiquitous. Having built many an interface using CSS/JS, the day where the developer can forget about the cross-browser issues that plague us all, will be well received.
One could say that Macromedia is taking a leap with Flex, is the world ready to develop interfaces in this way? Well, the product is realistically targeted at enterprise developers, so no, it isn’t the answer to everyone’s dreams right now. But, it does make a statement about their vision of the future of Web based applications.
We spent about a month with Flex, making mock-ups of various screens that the application had. The user interfaces you can build are impressive, they look very “Mac’ish”, but can be fully customized via CSS to look however you want. We figured that Flex would save about 2-3 months work on building a similar interface using straight ASP.NET/CSS interface. Most of the UI components that Flex provides can be done using ASP.NET minus drag and drop, and some of the behaviors like minimizing panels etc. Those we would have to write JS libraries for, and would probably not work on every single browser out there (although they would function on the major browsers we’d support).
So, the decision of whether to use Flex or not came down to a few things for us. One was the IDE. The strength of a language is tightly coupled with it’s IDE, if the IDE isn’t strong then the language suffers. I’d say this was probably one of the biggest reasons we decided to stay with the “old school” way of doing things for now. The IDE that is shipped with Macromedia Flex is called “Flex Builder”, it’s essentially a re-skinned Dreamweaver with some Flex specific widgets and a debugger. The debugging is a bit on the weak side, sometimes it wouldn’t stop at breakpoints, it was slow and if you wrote your own controls the debugger wouldn’t see them. Overall the IDE seemed like an afterthought, “heck we built a language, let’s patch up Dreamweaver and use that”. An IDE architected and coupled with the language is a necessity, having been used to Visual Studio my expectations were high.
Besides the IDE issues, the $12K price tag per server and lack of native .NET support also played into our decision to stick with an ASP.NET interface for the time being. Another factor was performance, particularly the Grid component. If you moved the scroll bar on a grid up and down, you could watch your CPU usage spike at 30%+ depending on the machine. Maybe Flash Player 8 will address some of these performance issues.
Overall, Flex is an excellent first attempt and shows a heck of a lot of promise.