How the Flex Framework Cairngorm 2 Died

When a new version of a software is released, the old version lives for a while and its creators usually care about supporting it. Yesterday, after reading about the release of Cairngorm 3, it’s clear that Adobe Consulting ignores this rule.

For those who are not following Cairngorm evolution, I want to remind that there was a framework called Cairngorm 2, that was a library of classes (built on Model-View-Controller architecture) to be included in the Flex application. I never agreed with the architecture of Cairngorm 2 which was acting as a Crazy Glue and lead to generation of monolithic applications based on global singletons. People who follow my writings or were attending my presentations at various conferences know that during the last four years I was openly stating that Cairngorm 2 has more cons than pros. For example, here’s the just one of of these occasions – a video of the panel on enterprise frameworks at Adobe MAX 2008 (after this blog, I doubt that I’ll ever be approved as a MAX speaker again).

Now, when I looked at the design of a product that’s now branded as Cairngorm 3, it’s clear that Adobe assigned to this project the right engineers (i.e. Alex Uhlmann) and there is hope that this methodology (it’s not an MVC framework any longer) may produce or include useful component libraries.

My first problem is that the Cairngorm 2 has literally disappeared from the face of Earth (the only trace found is the site that has some old documentation).

My second, and more serious problem is that Adobe Consulting up till today has never made a statement that selecting Cairngorm 2 was a wrong path. There are lots of enterprises that some time ago started using Cairngorm 2 (recommendation by Adobe Consulting) just to find themselves with a large monolithic application at hand that took long to download and was difficult to modularize.

A couple of years ago, I lead a large enterprise project for a customer that I won’t name, but will provide some relevant technical details. When I joined, the team was already 5 months into the project. This consumer facing application was producing one 5Mb SWF file. Just recompiling the application in Flex Builder was a lengthy project. I started to look at ways of modularizing this application so the first screen would come up sooner than 90 seconds for customers sitting on DSL connections.

Sure enough, the project has been built with Cairngorm 2 by advise of some engineer from Adobe Consulting (not to be confused with Adobe Flex team). The Cairngorm’s global class FrontController is expected to be a registry for all possible events that travel through the system let alone tons of classes and boilerplate code written just to support that life cycle of the framework itself.

My first suggestion was to start modularization with removing Cairngorm. They asked, “How much?” It would take two man-weeks worth of work, but they didn’t have time for this. To make the long story short, we had to modularize the application in a non-kosher way – the main SWF had a knowledge about all events in every module. Changes in a module’s code can lead to changes in the main applications. Tight coupling in action.

I’m sure there are lots of enterprise teams that were similarly misguided and were marching in a wrong direction under the Cairngorm 2 banner.

With the release of Cairngorm 3, the Cairngorm 2 has vanished. I’m sure, if you’ll hire a private eye, you’ll find its code (has not been updated from about three years) in some SVN repository. But this is not how the new version of the enterprise software should be released.
I’d like Adobe Consulting to state loud and clear, “If your team started development of a large enterprise project with Cairngorm 2, please stop. This was our mistake, and the sooner you switch to Cairngorm 3 or any other lighter framework the better.”

Will it happen? Let’s wait and see.

Yakov Fain
P.S. The views and opinions expressed in this blog are purely my own and don’t represent views of my employer

34 thoughts on “How the Flex Framework Cairngorm 2 Died

  1. Cairngorm 3 came to prove that “Cairngorm 2 has more cons than pros”, I glad I never lost my time learning it deeply.

  2. Exactly, Jesse! It’s not fair to keep it quiet and let developers continue developing using Cairngorm 2, while they don’t recommend it any longer.

  3. I haven’t worked with Cairngorm 3 quite yet, but in my company all of our projects are based on Cairngorm 2.

    In the Cairngorm 3 documentation (, it mentions:

    “Before the transition to Cairngorm 3, Cairngorm was a specific MVC framework. The Cairngorm 2 framework remains as is and is not deprecated. It has been in use now for a decade and its simple, prescriptive nature allowed developers with a background in J2EE core patterns to apply it successfully.”

    Does this mean that the core Cairngorm 2 framework still exists within the Cairngorm 3 libraries??

  4. At my company Adobe consulting had been recommending Cairngorm 2, but recently they have started pushing for Cairngorm 3 +Parsley.

    What I fail to understand is what benefit cairngorm3+IoC framework offers over using a standalone IoC framework like Swiz or Parsley. Am I missing something?

  5. Erich — yes, the core Cairngorm 2 framework still exists; the title and tone of this post is a little alarmist (it’ll get a lot of hits though :) ) and I’ve asked Alex Uhlmann and team to respond more directly to quell any misconceptions or concerns.

    We’re ever re-thinking our approach to best-practices; as the state-of-the-art moves forward, we shall be there pulling as much of it behind us as we can, and sharing it every step of the way.

  6. There is such a great weather today here in Toronto.

    I guess I am lucky because honestly I don’t give a damn about frameworks and didn’t have a pain of learning, discussing and using them during last 12 years of career as a developer working on multiple projects of different complexity ranging from solo to enterprise (with team of developers). I hope this trend will continue since one day (a long time ago) I’ve decided on not taking “save-my-project” or “deliver yesterday” type of jobs. MVCS code organization (I want to stress – CODE ORGANIZATION) + design patterns without external maze of “supporting” code works great so far (even with multiple developers).

    I am going to have a pear now and probably take a walk in a park right after. Good luck…

  7. And the same documentation mentions that Cairngorm 2 “has not been updated”. I start thinking:
    a) original CG2, an MVC framework, has not been updated.
    2) that little that GC2 attempted to do had been completely replaced by Parsley
    3) CG3, standing on shoulders of Parsley, brings much more value then vanilla MVC issues.

    Rhetoric question: why call it Cairngorm? Of all the names and reasons, where it does not event depend on CG2, when in is much bigger in scope and brilliantly elegant, in comparison with GC2?

    My answer: Adobe Consulting ran out of names 😉
    What about Parengorm?

    BTW, I like Parsley a lot.

  8. Behind the “Adobe facade” of Cairngorm are individuals who care deeply about sharing learnings from our projects as near real-time as we can to the Flash platform community alongside their project commitments to customers. Many of us participate in various open source projects and efforts to document our latest thoughts on how to deliver Flash Platform RIAs in the most effective way. With Cairngorm 3, we publish more knowledge than we ever have before. I’m confident that with our new infrastructure, we’ll also be able to share knowledge earlier and more often than ever before, and to draw participation from the broader community of partners who are doing similar work to us.

    Regarding Cairngorm 1 and 2:

    Our goal is to promote a kind of application development that is clear, consistent, testable and scalable. These aspirations can be achieved with a variety of application frameworks, so the choice a development team makes depends on their own background and the scale and type of application being built. We believe the success of a Flex project depends on the way an application framework is applied, rather than the specific framework chosen. We focus on the latter with Cairngorm 3.

    The Cairngorm 1 and 2 framework implementation remain as is and are not deprecated. It is still available, very visible in the Tools>Framework section within the newly published Cairngorm 3 wiki. The Cairngorm framework has been in use now for a decade and its simple, prescriptive nature allowed developers with a background in J2EE core patterns to apply it successfully. Please consider how i.e. the J2EE core patterns and EJB 1 have evolved as well. There’s been movement within Software over the past decade and Cairngorm isn’t oblivious towards that. We still see many hundreds if not thousands of customers, partners and developers who are able to accelerate their learning and be more productive in their implementation by applying practices that were state of the art for us some years ago.

    While it’s sad to hear you’ve experienced one customer that applied Cairngorm 1 and 2 and also produced a poorly designed Flex application a couple of years ago, I don’t think it’s fair to blame Cairngorm for that. We’ve always said publically that Cairngorm is not an excuse to not apply principles of OOD , IoC and modulization.

    It is how you apply the Cairngorm framework that makes all the difference. Regarding your comment about the FrontController, you can use that very easily in a modulized application. Also, the concept of IoC is feasible. With the advancement of IoC frameworks, we found that it becomes more effective for us to apply the approach. Therefore, the majority of projects within Adobe Technical Services leverage IoC frameworks. But that wasn’t available a decade ago, not even a few years ago; also not on other platforms such as Java. You’re not seeing Sun apologising for EJB 1 either, probably also because there are customers out there applying it successfully. There’s no need to apologise for knowledge we’ve shared at a time where it was a very popular approach (which is how Cairngorm got so successful). Today, there are still customers and ourselves using it successfully.

    We are never beyond improving and learning, and as we build ever more complex applications with an ever evolving ecosystem of Adobe tools and technologies, we will unabashedly continue to share our learnings and our current thinkings. We will not apologize for taking a position that is contrary to a position when the state of the art was less mature, and our frame of reference was narrower. However, the spirit in which we do so should not be mistaken as an apology or retraction for what we consider best practice in the past, especially as we do with Cairngorm, where we feel that these approaches are still valid for a large number of projects.

    Regarding Cairngorm 3 recommending Parsley:

    With the abundance of high quality frameworks today, I don’t see how we as Adobe can have an interest in actively mandating developers to use one framework over the other. The reason that you see the Parsley focus with the current state of Cairngorm is that most of our large-scale projects use Parsley successfully – indeed we have welcomed Jens into our team, and he has been actively collaborating with us to improve our thinking about how our approaches can complement each other. In doing so, we have contributed improvements and ideas to Parsley, as Jens has contributed ideas and improvements to Cairngorm. When we collaborate, everyone benefits. We can only talk about what we use in production with confidence. That doesn’t mean developers cannot produce successful applications following other frameworks, see the paragraph above. We try to communicate this witin the Cairngorm wiki in i.e. Tools>Frameworks and the entry level page.

    If you watch the Navigation library, we’re also providing a Swiz version alongside Parsley and are currently talking to the Spring ActionScript team. Our interest is healthy competition in the framework space that drives innovation and advances or platform faster. This is what I see happening today and it excites me.

    Yakov, I’m happy you seem to be positively reacting towards the future direction. Let’s build upon that; together. If you feel so strongly about what we’re doing to feel compelled to make posts like this one, I’d equally encourage you to reach out directly to us and engage in ideas for improvement – it shouldn’t be either/or. I have had direct phone conversations with several of the framework authors to better understand how we collaborate, and would welcome the chance to do the same with you and your team.

  9. “The unofficial stance is that Adobe Consulting want you to use Parsley not Cairngorm”

    That’s not the unofficial (or official) stance. Alex covers it sell, but I want to address any misconceptions. On the most recent projects the teams have been driving, the collaborating between the Cairngorm and Parsley team (Jens from Parsley is working alongside us on these projects) can be seen in the collaboration between the frameworks. I’ll leave Alex to engage in the dialogue on the details; but it’s not a Good versus Evil story I’m afraid, much as the blogosphere loves them. Coming soon — Cairngorm 4 found in a German Beer house in Redwood City, California ??? :)

  10. Alex, I’m the last person to blame for being quiet. I’ve been always open about my view of Cairngorm 2. In particular, two years ago I was expressing the same opinion in front of 400 people at Adobe MAX 2008. I don’t think Adobe Consulting cared too much, and to be honest with you, I didn’t expect to make a revolution.

    I’m not asking Adobe Consulting to apologize to anyone, I’m asking to openly say to people who are using Cairngorm 2 to stop and switch to Cairngorm 3 or other framework (no PureMVC, please). This is what Toyota and other car manufacturers do when find issues in their vehicles. The fact that during 3 years your team didn’t want to build upon Cairngorm 2, and now made a decision (and rightly so) to switch to simpler and lighter frameworks speaks for itself.

    I really wish a success to Cairngorm 3, but would like Adobe Consulting to be proactive and help enterprise developers in making the right choices.

  11. Yakov.; so if I’m reading correctly here, you’re looking for a statement from the team here not to use Cairngorm 2. To be clear, that’s not our position … there are many teams for whom that is a path to success; the dealbreaker IMHO as to whether they will be successful is not going to be their choice of framework, but much more fundamental issues around software engineering and software craftsmanship.

    Your position on Cairngorm is very clear, and very much respected. But it’s not ours, and I’m afraid you’re not going to encourage us to take a public position that we don’t hold privately.

    With Cairngorm 3, the team are trying to take a position that states that “successful delivery of Enterprise RIA is not just about the choice of frameworks that you make – and we encourage you to understand all of them and make your own informed choices, and here’s our preference” and that there are a host of other considerations, patterns and practices that we believe – in addition or isolation of a framework decision – are things that we can share, and would love to share with the industry. Furthermore, though we have the privilege of working with our most strategic enterprise customers, though we have the privilege of being a team of talented individuals that gets to work with some of the brightest and sharpest partners and customers in the industry, we by no means expect to have a monopoly on good practice. So we are pushing for a collaborative approach that allows us to bring dialogue from across the industry, and provide a forum for knowledge share amongst the ecosystem.

    I think setting expectation strongly here, that we are not going to “retract” our thoughts on best-practices that have made so many of our projects, and of the ecosystems projects successful, because they don’t adhere to philosophical thoughts on best practice across 100% of the industry.

    We are an industry that generates a tremendous amount of heat and noise to difference of opinion. Perhaps that which separates us shouldn’t drive us apart, but should bring us together ?

    The only guarantee I can offer, is what we consider to be best practice in another 5 or 10 years, will be nothing like where we are now.

    That’s what makes our corner of the industry so exciting. That’s why I’m here.

  12. Steven,

    We see things differently, and it’s fine. But if Caingorm 2 was a successful project, why it was abandoned for three years and your team didn’t release any new versions of it?

    Also, I can’t agree with your statement “…we by no means expect to have a monopoly on good practice.” When an Adobe engineer visits a customer and suggests to use Cairngorm, it’s taken as a good practice cause it comes from Adobe. If a third party would suggest to a corporate client to use Swiz, Mate, or Parsley, it wouldn’t bear the same weight as Adobe’s recommendations. And during many years Adobe Consulting has recommended Cairngorm 1 and 2 (I know that it was not approved by Flex team, but most of your customers don’t) .

    I’m glad that your team made at least a first step forward and started recommending other frameworks even though it’s done in a special manner protecting the brand.

  13. Yakov; so last from me on this.

    Cairngorm 2 wasn’t abandoned for three years; it was fulfilling the specialized and straightforward task required of it and there was no need on our part to release anything additional. For three years we, along with a tremendous number of developers in the community, were using it as the core architectural approach to projects that we were working on…that’s critical mass adoption, not abandonment. I feel like you are using superlatives to provoke response…but I’m not sure really what response any of my team offer, is going to allow us to agree to disagree on the approach, but move on regardless. I’m afraid we aren’t going to say “we had it wrong”, because we don’t think we did. I’m afraid we aren’t going to say “we abandoned Cairngorm”, because we didn’t.

    You seem keen to see the worst in our approach, “..done in a special manner protecting the brand..” Our motivation is much simpler; Cairngorm has been synonymous for many years now with Adobe Consulting’s thoughts on best-practice approaches to creating Enterprise RIA. As we realized that instead of creating a bloated framework, that we wished to keep the (not abandoned) framework at the core of these thoughts on best-practices, but greatly enhance and enrich the knowledge that we were sharing with patterns and practices that are more than “just code in a framework”, we decided that we would do so under the same banner as Cairngorm, since it is what it is … an opportunity for us to build on the knowledge we share, and share it differently.

    We’re giving this stuff away. There’s no ulterior motives here. Where it doesn’t work, alternate approaches will emerge and the fittest ideas will survive.

    Can I ask that we step back here. For several years, Cairngorm 1 and 2 epitomised our thoughts on how to build complex Rich Internet Applications for the enterprise. It started life as a Flash-only framework, when integration between an application in the Flash Player with complex J2EE middleware was a hugely ambitious effort. As the platform has matured, as Flex has matured, we have continually simplified Cairngorm (we have removed more framework than we’ve added) and we’ve adjusted accordingly the guidance we’ve shared on how WE build applications. Cairngorm 3 captures our thoughts at a moment in time where Enterprise RIA is no longer a proposition but a reality, and where we believe the knowledge that can be shared is more than simply a pattern-based framework, but is a collection of patterns and practices, that allow us to solve enterprise challenges. As other, equally if not more talented developers also create their own frameworks that address similar or different problems, in similar but different ways, we have no issues or hesitancy in figuring out how “the whole can be greater than the sum of the parts”, and how we can use the best ideas together, to be better. And as we do so, we have no issue and hesitancy in sharing our thoughts as we go along — and sharing them as a consequence of having put those ideas and thoughts into action.

    So here’s my ask; can we solicit your support in collaborating towards the state of the art, in the absence of retractions or apologies for doing things differently in the past, when the past was so very much different from the present ?

    Innovation is a vector that points forward. That’s where we’re skating to. I’d love to have you on the team; we’re all part of the same community here.

  14. “So here’s my ask; can we solicit your support in collaborating towards the state of the art, in the absence of retractions or apologies for doing things differently in the past, when the past was so very much different from the present ?”

    Sure, I am always open to share my views if you want to listen. I prefer components to MVC frameworks in RIA clients. The Flex framework is a well designed product and all MVC frameworks (not just the Cairngorm 2) are pretty much useless and complicate the life of Flex developers. That’s why I was really happy to see some meat (read useful components) in Cairngorm 3.

    You ask about collaboration? I’m all for it. Just look at the open sourced Clear Toolkit (skim through the PDF docs over here:
    Check out this feature matrix: Do you want to collaborate on Clear Toolkit?

  15. I like Cairngorm. As a contractor, it has provided me lots of opportunity to clean up enterprise-class disasters. I am working on one such at this very moment.

    Clients/users are partially to blame and Adobe is partially to blame. No framework will cause a bad programmer to produce good code. Cairngorm 2 was an attempt to bring forward a failed J2EE architectural pattern into another language/runtime environment.

    I would appreciate dropping the BS (“micro-architecture? Please!”) Let’s concentrate on helping customers develop the simplest application via the simplest methodology that could possibly work yet still be maintainable and efficient to develop. Sometimes that means a framework, but often it does not.

  16. I think, the difference between versions 2 and 3 needs to be communicated to the clients.

    My understanding is that old Cairngorm is more about structuring the project in a way that allows easy location of the appropriate code. It was useful for some simpler projects and teams of new developers but would not go well IMHO for large projects. In fact, I was horrified during MAX 2007 when Steven said “when you have 30 people on the project I do not know what you do without Cairngorm”. In my experience, first tasks on the large project are to provide architectural design, conduct training and build code review process. Rather then isolating developers I make sure we have process that forces code reviews and collaboration at least weekly. Providing non-application specific framework on large project tends to increase the number of problems and move them toward the end of the development cycle. It also blocked native MVC features of Flex in mind of new developers forcing them to write more code then needed.

    Cairngorm 3 (Parsley and Swiz/Navigation) is more of declarative extension for common tasks you have on large projects. As such, it is welcome addition to make code simpler and easier to maintain. It has flexibility and learning curve, as you can use it in number of ways. That distinction IMHO has to be communicated as people would start/continue with version 2 and expect version 3 to be “compatible” unless a) difference in approaches/applications are clearly stated and b) no path for code migration is explained.

    IMHO, if done, it would lead to faster adoption of C3 and overall success of the platform. The way Adobe crafts that message is obviously up to them, but clear message works better.
    Anatole Tartakovsky

  17. Why so much hate on Cairngorm 2 ? It had and still have its own merits.

    From experience, I can say that GUI developers are traditionally less familiar with architecture and design patterns ( especially Flash and HTML+JS folks which is quite a big population of nowadays’ Flex developers ) and Cairngorm provided them with a base to work on, and eased project transitions because many project used it.

    Sure, Cairn2 implementation is not great, but it was available quickly when almost no alternatives was here. PureMVC always had been worse in my mind ( also relies on obstrusive inheritance, singletons, can’t use bindings efficiently, and mediator pattern goes in the way of Flex’s view livecycle paradigm )

    Yes, nowadays, developers have more choice and that’s great. I’ve seen huge apps being successful thanks to the use of a good IoC framework. BUT, I’ve also seen apps using IoC with crap code and architecture ( too much reliance on messages, direct manipulation of the context spread in the code is not any better than global state ) .

    You are less guided in an IoC environment and less experienced people might even be more succesful by using cairn2 than some of the IoC frameworks. To be able to leverage the greatness of an IoC framework, you need to understand many, many OO concepts and I’ve seen it’s not a given.

    • It’s not hate. I just don’t agree that to create a successful Flex application developers need anything else but learning what Flex has already. I’m against downgrading software developers to “framework coders” who just know were to put their code fragment rather than understand how the application works.
      To that end, I don’t see the need of IoC Flex frameworks either as Flex has already a nice mechanism (well designed event model) to create loosely-coupled components. But lighter and less intrusive than Cairngirm 2 frameworks are less damaging to the app, IMO.

      This Sunday, on the plane, will try to write a blog on IoC.

  18. Alex,
    I do not think the subject would be discussed at all if Cairngorm was not promoted by Adobe Consulting. As such it has more weight, especially with new developers. Use of singletons can be a good thing for some applications and promotes strong type checking, etc. The problem IMHO is that it was billed as “best practices” and was used more often then it should. As a result, real application architectural issues were not addressed till much later in the process and often had conflict with the C2 patterns used.

    The patterns used in C2 could be explained in 1-2 hours and implemented in application specific manner within few days at most. While providing code visibility for project managers Cairngorm promotes excessive coding, misleading metrics and complicates testing. More importantly, it shifted attention from learning Flex Framework to learning artificial extension and provide false sense of comfort. I personally was involved in redesigning and fixing number of Cairngorm-based projects and saw the productivity/quality gains by the same developers once they were able to work without C2.

    That brings to the main question – why IoC is different? It is just another pattern to support larger apps, and can be done just as well with proper use of event mechanisms. However, it is a bit more declarative and works better in modularization scenarios. IMHO, IoC frameworks, once accepted by community, should be promoted to the system level and be supported by Flex compiler in the same fashion as [Mixin] tag (ie injecting initialization code, code signed IoC container) to provide better performance/functionality. It can be as natural to Flex applications as [Binding] or [Event]. The same goes to Navigation vs viewstack/states. Again, it is decision for Flex Team, and not Adobe Consulting – there are usual conflicts in the model and application areas between product and services teams. Architectural Framework is part of the Product, specific combination usage of patterns for particular application/deployment scenarion is Services responsibility. Selecting certain combination of patterns and billing them as “best practices” is not a good idea. The same goes Mate and PureMVC – simple patterns over engineered and billed as “fits all” solution are not good for product success.
    Natural extensions to Flex frameworks to support larger applications are long overdue and welcome.
    Anatole Tartakovsky

  19. Anatole,

    You raised many interesting points.

    The reason I reacted is because after reading the article and comments, I didn’t feel like the writer was just asking Adobe to be more open and advise its Flex users more. While it mentionned that, most of the article is about :

    1) how cairngorm2 has been a failure since day 1
    and that in general,
    2) not using any framework is best.

    About 1) : It’s easy to say that Cairngorm2 is crap nowadays. In 2010, I could write a blog post about how EJB3 is a better approach than EJB2 but there is no value in doing that. It seems like the requirements and needs of applications have outgrown Cairngorm2 on a lot of projects, and that’s a good thing, that means Flex can help you create big applications, so big that they have to be modular.

    About 2 ) : I have to disagree. Surely, using no framework is better than using a bad framework for the task. BUT, a good framework can make development much quicker and the whole project will be easier to maintain. IoC frameworks decouple and remove so much wiring code. Flash’s events are nice but they won’t solve all your issues. OR you will have to write tons of “custom” stuff around it and well, that’s pretty much a framework again. Another pros of using a framework is that it will have a community with which you can discuss about best practises and good documentation. How well documented is your home-grown solution ? How easy it is for new comers on your project to understand why you dispatch those weird bubbling events all over the place ?

    I totally agree with you on this point : Before learning or even “mastering” a framework, surely developers should first deeply understand the Flex framework. Some developers will never bother though. It’s not just a Flex thing, I’m sure you can find tons of devs who “know” Spring but will fail on stupid JAVA knowledge questions. It just depends on how involved you are.

    About cairngorm2 in general: Back then, most Flex team did not have an “architect”. RIAs are not exactly new but many people have troubles when it comes to writing RIA code. Probably because of the mix of domain/application/infrastructure/view logic involved. Writing a backend service is much more straighforward. So, in the absence of architects, people starting following “guidelines”, Cairngorm2 “guidelines” ( Right, pretty much enforced ones ) . Were those guidelines stupid ? Not entirely… You ended up with business logic in commands. Service calls in separate classes. A domain model living on its own somewhere. That’s far from the one-tier “All-in-the-view” architecture many people used and more maintainable. Flawed ? yes, an improvement over the monolithic view ? yes. People discovered the separation of concerns principle! It’s a nice first step.

    So asking Adobe to be more clear on what cairngorm2 is and isn’t is one thing, but I think it’s time to stop writing about how cairngorm2 sucks… It’s old and not very useful 😉

  20. Yeah, I’m tired of this pointless bashing on Cairngorm 2… The quality of apps increased as more and more consultants started to use it.

    And yes, Cairngorm should be the standard for new devs from the HTML/JS world. New-to-Flex + IoC gives us code that is nearly impossible to parse.

    The problem, as i see it, is that Fain and others seem to think that every new person coming to flex has attained at least a mid-level engineer position, and can understand decoupling, IoC and why Singletons are bad. The reality is that the heavy-handedness of Cairngorm/PureMVC brings much-needed order to the rank-and-file recruits from the HTML world.

    Excluding the Java converts, I don’t know ANY single person that built an app for Flex 2 that they could say was well-engineered that wasn’t using Cairngorm. It was essential back then, and having seen the damage that newbies can do with IoC, it’s still essential now.

  21. The main problem that Anatole and Yakov seem to have is that Cairngorm 2 was recommended by Adobe Consulting. Had AC offered anything short of the software engineering equivalent to unified theory of physics, you would have still complained. We’ve all seen applications that have been architected or implemented poorly, be it in Cairngorm, PureMVC or anything else. Just because you’ve chosen what you think is the best framework it doesn’t mean you are ok. I could build a shoddy house in London or I could build it in Paris. It doesn’t matter – it’s still shoddy.

    The state of the art evolves in the same way we do as developers. I look at work from my early career and realise I’ve come a long way. I welcome Alex Uhlmann’s approach – walking around saying ‘I know best’ is clearly not how we improve. By the same token we can only offer the best of what we know today. They seem to be reaching out to the community, which I can only see as being a good thing. We all sit here and complain about things that frustrate us – but now someone actually wants to listen. Forget about the fact the you might have been ignored in the past – move forward.

    Having technical discussions about the pros and cons of different approaches is one thing, but this article does not do that. Of course Cairngorm 2 has its shortcomings, and no one is denying that. There was clearly a need for a framework, and Cairngorm 2 filled a gap at the time. Since then the landscape has changed dramatically, as has the choice. But I don’t see AC going around saying just use Cairngorm 2 for everything. In fact they are quite clearly advocating the use of other frameworks now. Why should they go around telling people what what not to use? Do you see them saying don’t use PureMVC? Would that even be a good thing?


    You state “why IoC is different? It is just another pattern to support larger apps”.

    The whole idea of design patterns is that we stand on the shoulders of giants. The Flex framework contains patterns in itself. Suggesting that people should just master the framework and not patterns is a bit of a red herring. Of course if someone calls themselves a Flex developer they should know the framework, but for enterprise development they also need to understand patterns and unit testing too. Patterns are a part of good object oriented design, if applied correctly. An IOC container solves a certain problem, one that cannot be easily solved using just the EventDispatcher mechanism, especially in a way that might be portable. We don’t want to re-invent the wheel for every client do we?

    You make some good suggestions about process and not just blindly follow a single a framework. But isn’t that exactly what Cairngorm 3 advocates?

    You also suggest that these problems should be solved at the framework level. Whilst it would be great to have language and compiler improvements, you can’t solve every problem this way. As well as making the framework more rigid you end up with less choice. You have to go with the implementation that has been given to you. Do you like the implementation of absolutely everything in the Flex framework? You don’t seem so keen on IOC, so how would you react if it was fused into the Flex framework? What’s the difference between a client blindly accepting AC’s advice to use Cairngorm 2, and you blindly accepting whatever Adobe gives you in the Flex framework?

    The fact the AC’s advice might have more weight than mine or yours is neither here or there. That’s just the nature of the market and marketing. We’d all love to have that kind of sway, but it doesn’t work like that. Consultancies offer the best of their current knowledge to their clients and you can’t fault them for doing that. I’m sure me and you do the same.

    Now excuse me while I go and apologise to my previous clients for not using today’s knowledge back then.

    • For technical comparison of various frameworks including Cairngorm 2 read chapter 1 of the book Enterprise Development With Flex.

  22. I have been a long time proponent of Cairngorm, since elements of it were first described in Steven and Alistair’s book on Flash/J2EE development when I was a Flash platform evangelist at Macromedia. Since then my company has implemented several very large projects in Cairngorm, including (since you mentioned them) a global car parts requisitioning system for Toyota.

    I still fail to understand why Cairngorm and Adobe Consulting’s stewardship of it is such a popular target for people in the Flex community (leaving aside the publicity/web traffic motivations). What became Cairngorm was developed and tested on real projects over many years by Iteration Two, who shared their experience in two books before the framework was even given a name. When the company was acquired to become Macromedia Consulting EMEA, why wouldn’t they continue to recommend an approach they were familiar with, leave it alone while it worked or modify it when new evidence from their engagements became available? To do anything else would in my book be reckless behaviour and betraying the trust of clients who engaged them for their experience (More than one Flex framework in the last few years has been published without being used on any production system – I think that’s criminal arrogance).

    I will also go out on a limb at this point and say that over all these years I have yet to read a critique of Cairngorm that I regarded as balanced and well-informed, or that reflected the way it is used on a real project, starting with the ol’ chestnut singleton model – it’s a marker interface, that’s all. How prescriptive is that? In fact if you took out all the code comments Cairngorm in it’s entirety is probably only a few hundred lines of code (and most of that in the ServiceLocator, which you don’t have to use if you don’t want to). If half the bad things attributed to Cairngorm were true, this must represent some sort of record achievement in evil per line (EPL) in the history of programming (well maybe second, the Mars probe metric/imperial mix-up probably pips it to the post).

    People expect too much of Cairngorm, a symptom of this cargo-cult mentality that your job as a technical architect is to select a framework and then switch off your brain, except to rant about the failings of other frameworks. Cairngorm helps you implement MVC separation / Service to Worker / Command in a reasonably light way, and that’s about it. It stays out of your way if you want to do DI, use mxml to configure the app mate-style (it took 15 minutes to write some classes to do addCommand() in MXML), instance-based models (the majority in our applications), plugin/extension point features or other things you need to implement.

    Regarding the dropping of Cairngorm 2 for Cairngorm 3, we’re now on our third project using Parsley with Dynamic Commands (which were added to support Cairngorm-like Commands) to take advantage of DI and it’s been pretty straight forward. The only change at the architecture level (the way we’re doing it) is a more defined separation between presentation and business models (the latter containing more of what we used to do in command result methods). Otherwise it’s the same old underlying patterns, and slightly more succinct boiler plate code with more metadata attached to it.

  23. Dusty,
    Thank you for your honesty. Your arguments are exactly the ones prevailing ones in the industry. I would just say I do not like heavy-handed approach and do not agree. Most of Flex developers I worked with had programming experience well beyond HTML/JS.

    I would also say this statement “The quality of apps increased as more and more consultants started to use it.” in my experience is not true – quantity of developers does not directly correlate to quality – testing and better developers have better track record.
    I think you meant “The quality of apps increased as consultants using it became more and more experienced (using Flex and Cairngorm)”. I would just add that it would be also true for projects not using Cairngorm. That is why we recommend to spend more time on training and application specific patterns rather then forcing framework at developers.

    While Cairngorm is beneficial to certain areas of consulting, its timing and area of application are limited. The marketing message and devotion are not.


  24. Alex,
    I think that history is not such a pointless thing. Is EJB3 better then EJB? Maybe – after reviewing specs, implementations I went with lighter servlet container/JDBC/DTOs approach and use it till now – with some injections form Spring and such. But 13 years ago Sun made a point that everybody has to be EJB in order to be J2EE compliant. It was religion first, jihad later. While no longer part of most JEE solutions, EJBs did it’s damage. And Sun paid dearly for that failure.


  25. @Robin,

    Your last paragraph rang especially true for me. We’ve been using Cairngorm2 successfully for quite some time now. After seeing this discussion, I decided to evaluate Cairngorm3/Parsley to see what the differences are. There’s not much we’d need to change in our code to port our apps over to Parsley. And while I’m sure I’ll upset the authors here, at first glance, the events/messaging service almost seems PureMVC-esque in their observer pattern usage. To me, there’s nothing new here, just a different way of implementing with some definite advantages of looser coupling.


    At my previous company, I ran the show. I tried to implement design patterns and best practices in my development, but fell far short. I now work in a situation with excellent mentors, and my pace of learning has increased many times. My point here is that while I tried to use frameworks, I didn’t have the knowledge of OO and patterns I needed to implement them properly. I did and could say I was still using the framework though. Is it possible that these projects that you are “rescuing” are butchering the framework rather than using it in the way it was intended? In working with different sizes of project teams over the years, I can definitely say that we’ve gained a lot of efficiency by employing frameworks and using them the same way for each project. It speeds development and debugging for us, and Cairngorm2 has been the basis of what we do for several years now.

    I agree that we should keep software development moving forward by adopting newer, better ways of doing things when the situation warrants it. IMHO, blanket statements about what to use and what not to use rarely have any benefit in software development.

  26. Hi Sir

    End of the day as a developer i am still confused which framework should be used.


  27. Flex is already a framework, don’t confuse your self learning some frameworks… Adobe consultants are insane why they recommended Cairngorm,.. why they tolerating to use singleton for data-binding?? How will you know where the update/change came from? Data Binding is usefull and also dangerous that may slow-down your application. It so ridiculous to have ‘events’ every command, its extra waste of time.
    Cairngorm gone to ver.3 while PureMVC still at its core version … see the difference??? and Cairngorm always gone for a lot of issues fixes and taking out of useless classes…

    Use Flex as a framework and use a GlobalVar as for your ModelLocator.. its perfect :)

  28. Hi,

    Question for all flex experts. We are going to start a new enterprise portal using Flex 4 + EJB 3 in the server side. So which flex acrhitecture framework you will recommend ?

    1) Presley
    2) Presley + Cairngorm 3
    3) Cairngorm 2
    4) Some other framework

    • Before asking this question, answer why you want to use one of these frameworks? Please write a comment that will start with the statement “I’m currently looking for an MVC framework to be used on top of Flex framework because…”

Comments are closed.