When Thin Clients Grow Fat

The great flex framework from Adobe lends itself to writing “real” applications in flash. By this, I mean large, real, fat clients, filled with business logic on a large domain model. There are already examples of this around, including Adobes own Photoshop Express. This is a clear shift in movement, when compared to what flash was used to before flex came around.

The Needs of a Fat Client

But when you do start to write such fat and rich clients in a new platform, you will quickly grow into the needs of support for something more, including:

  • The need for a system architecture framework to drive the structure of where to place code (avoid unmaintainable spaghetti)
  • An application framework, to help with life-cycle, larger ui components, helpsystem, …
  • Real domain modelling, to express the domain of the business you are making an application to support
  • The ability to perform extensive, automated testing of the application

These are the exact same requirements that you have when developing large, fat, rich clients in Swing, .Net Forms or your client-side technology of choice.

Is Flex There Yet?

So, does flex have an answer to your needs on these areas? I would say yes and no. The platform is still so new, that there are plenty of room for improvement. Luckily, someone are trying to solve those problems for us:

  • Architectural Frameworks: As the big contenders there is Cairngorm from Adobe and there is PureMVC from Cliff Hall and FutureScale . But there are also new kids on the block, like Mate. Even though the current frameworks are better than nothing, I think there still is plenty of room here, to think new and do better.
  • Flex Developer Understanding: Another, and maybe even more important aspect, is the general understanding in the flex developer community, for the need of applying such frameworks on ones codebase, when applications grow large. Given that the platform is still so new, and many are “jumping onto the wagon” from different camps, it is my gut feeling, that not many of these new applications are architected very well, in their initial versions.
  • Domain Modeling: Like the above statement, I think that many are missing this area, on their first go. The language, AS3, certainly does not need anything more. You can do all kinds of domain modelling in AS3, and even feel comfortable while doing it.
  • Testability: This is a black hole in flex. Sure, there are flexunit and projects like it, but the integration into continous integration buildsystems, running headless, are weak (if at all existing). And if you need to do automated testing out at the user-level (clicking around in the application, putting values into input fields…), you will need a license, to even get near the mx.automation package.

So, is flex there yet? I would say no, but it is getting close. And I am sure it will get there, eventually.

June 4, 2008  Tags:   Posted in: Design, Rich Internet Applications

3 Responses

  1. Tigran Najaryan - June 5, 2008

    Won’t comment on the rest but the automation support is quite good in Flex. All the components co-operate nicely with automation tools and the automation API is well designed making it easy to create testing tools (I speak from first hand experience, see http://riatest.com ).

    As for the requirement for the license to enable automation it does seem logical to make it a property of Professional edition only. Something has to be exclusive if you have editions after all! :-)

  2. polesen - June 5, 2008

    As for the requirement for the license to enable automation it does seem logical to make it a property of Professional edition only. Something has to be exclusive if you have editions after all!

    Yes and no. I would say “it depends”. It depends upon the model they (Adobe) want to apply, to make money while still being open source.

    One would be to sell “specially tested” versions (eg. for FDS) or specially licensed versions for license indemnification.

    Another would be to sell addon services, like consulting.

    I don’t think any of these apply for what Adobe is doing, but please correct me if I am wrong. What it does look like, is Adobe trying to make money from the IDE, FlexBuilder. In addition to this, they have some extra components (Data Visualization), that they think are special enough to not be open-source and to be payware.

    Now, why on earth they have chosen to bundle it all together with the IDE, so I have to buy a license for all of it, to get at some of it, I don’t know.

    Another thing is: Why is the main API for doing automated testing not part of the platform? Development on earth have come to a common understanding, that automated testing is a good thing. Hence, it needs to be part of any development platform with respect for itself. When automated testing isn’t part of flex, they should not tell us, that one can chose the free SDK and develop flex for free.

    That is my opinion!

  3. Tech Per » Blog Archive » Patterns of GUI Architecture in Cairngorm and PureMVC - June 9, 2008

    [...] I previously wrote about in my post When Thin Clients Grow Fat, developing flex applications quickly reveal the need for the same kind of architectural guidance [...]

Leave a Reply