Home >
Well kids, it's been a wild ride. We've looked at five implementations of a simple Twitter client built with no framework, Cairngorm, PureMVC, Swiz, and Mate. We've talked about important things like pronouncing the framework's names, architectural patterns, Inversion of Control, and programmer joy.
In this last part, I'm going to turn off any semblance of objectivity and let you know what I think about these frameworks. If you're not interested in what I think, I don't blame you, but I also don't want anyone to take my word for it and blindly choose which one I like. Take a look at the examples and see which one you'd rather work with. Come up with a simple application and build it four different way. In other words, try before you buy.
Ok, here we go. First, in prose, and then with some numbers.
CairngormAs I mentioned early on, I've been using Cairngorm for a while now. Does that make me want to stick with it or try something new? Well, I've liked using Cairngorm. I also like to use Christophe Herreman's Prana to help out a bit with sequences of commands and IoC. In fact, I wanted to have an article on Prana in this series, but I just ran out of time. You can settle for this blog post about delegate factories, which shows how we might have made our dummy data solution a little more palatable.
The thing I like most about Cairngorm is the command pattern. I really like having commands that are named with a description of what they do, and I really like that everything to do with getting that specific task done is inside the command.
Cairngorm, though, being around the longest and the loneliest, has attracted criticism. It’s surprising to me, because I think it’s not a bad framework, and not even that heavyweight. Even so, I came into this article to try out these other frameworks and see if one struck me as something I’d rather work with from day to day. Let’s have a look at some criticisms.
Some people don't like Cairngorm’s verbosity when it comes to defining a new command. I don't think there's anything wrong there that can't be solved with some code generation, but I agree that it’s pretty verbose.
Other arguments against Cairngorm are usually leveled against its use of a Singleton model. A Singleton makes unit testing hard, and sometimes people say it's just a glorified "global variable". Let's take these one at a time.
Singletons are not "global variables". People make fun of using global variables because it's a rookie way of getting around building a good architecture. It was the way we built Flash apps before we knew how to program. That's true - global variables are unsafe because there's no guarantee who's accessing and changing them. In short, there's no encapsulation. But with a Singleton, there is encapsulation, because what you're dealing with is still an object. There's nothing stopping you from using read-only getters instead of public properties.
Singletons do, however, make it harder to unit test, because a simple test that, say, runs a command sequence and tests that a property on the model changed as expected, changes that model instance of which there is only one. The more tests, the more the model gets into a strange initial state. I think that’s not that big of a deal if you just take the time to reset the model to a known state before each test. If you have to have a “logout” in your app anyway, you’ll need to do something like that anyway (unless you cop out and just refresh the page with javascript). I agree, though, that it’s extra code to maintain.
One last problem people have is that Cairngorm has you putting Cairngorm events on the view. That means you have to make a Cairngorm event, first, and second it means that you have framework code on the view that makes it hard to refactor away from Cairngorm.
Now, look. How many times in an app do you just scrap it and switch frameworks? I never have. I agree that componentizing is great when you really have a view you can turn into a blackbox component, but if you have a view specific to a certain app I really don’t see that it’s anything but bikeshedding to try to make the view code re-usable. There’s a point of diminishing returns, and at that point or even a little before, you should just move on and get the app done. That’s why I don’t care that much about Flex framework code in a Flex application. I’m certainly open to the idea of using regular Flash events, though, so that brings us to PureMVC.
PureMVCOne way I describe the difference between Cairngorm and PureMVC to people is that Cairngorm doesn’t have much to say about your view code, and PureMVC doesn’t have much to say about your service access code. That’s why you see the BusinessDelegate pattern in PureMVC and Cairngorm - because it works well.
What PureMVC tries to fix, though, is having the view cluttered with PureMVC code. It fixes that well - the only place you have to put PureMVC code is on the root application. As far as that goes, I like using Flash events instead of Cairngorm events. What’s nice there is that if I’m using a blackbox component that emits Flash events, I can still easily respond in a Mediator whereas in Cairngorm I’d have to catch and re-dispatch an event as a Cairngorm event if I wanted to take action.
One other important PureMVC goal is to be an Actionscript framework, not a Flex framework. That means I can’t (or shouldn’t) use Flex binding to wire up a view to a Proxy, I need to have the Mediator do it. Is that a win? I think binding is great, and I also think it needs special understanding to use it correctly. In a medium to large sized application, by using binding right out of the box, you can cause a really huge event storm whenever any bound property changes and bring performance to a halt.
I think binding is good when used responsibly, so when PureMVC says to skip it, I’m interested, but I want to know what it costs to use. So what I don’t like about PureMVC is how much boilerplate code there is. I like the idea of a mediator for views, but there is so much set up to do. The constants, the viewComponent wrapper, listNotificationInterests, handleNotification, there’s a lot of stuff it takes to set up a Mediator. I like PureMVC in general, but I’ve never gotten up the energy to use it on a project because of inertia. It feels like it’s a big investment to do things the PureMVC way.
Contrast that with the lightest weight framework, Swiz.
SwizI have to be honest, when I wrote this article because of the buzz and Laura’s presentation at 360 Flex San Jose, I was really prepared to like Mate hands down. (BTW, here’s Chris’s presentation). When I started using Swiz, though, I immediately felt the joy. You know what I’m talking about - that sense that you’re in the groove and building something and there’s not much work between having an idea and implementing it.
I’m going to make a distinction that I haven’t heard before, or at least don’t remember hearing. I think there are proscriptive and prescriptive tendencies to software frameworks. On the one hand, proscription means saying what you can’t do, and on the other, prescription means saying what you could do. Whereas PureMVC says a lot of things you shouldn’t do and some things that you can do, Swiz almost completely sticks to saying what you can do.
Swiz leaves a lot up to you. All it does is provide some easy ways to do things like inject a controller or a model into the view and to easily wire up events with the Mediate metadata tag. From there on out, it’s up to you. Swiz is the laissez faire framework, and I really like that.
The only thing is that all the service interaction stuff, the
dynamic delegates and command all expect you to be using RemoteObjects and
delegate methods that return AsyncTokens. I’m sure this could be fixed, but
unless I’m missing something until it is fixed Swiz is less useful to anyone
not using AMF services. Since I’m used to using RubyAMF,
that’s great for me, but I can’t always count on it or BlazeDS or ColdFusion
being on the server side. You can work around it, but it’d be nice to have
those tools available for other types of services.
As mentioned in the comments below, HTTPService and WebService DO use AsyncToken, and should work find with Swiz. The only time you need to hack around it is when using a service wrapper like we're using in the example code.
One thing I’d also like to see is an easy way to use the command pattern where logic is actually written in the commands. I really like that pattern because I think it’s cleaner to have logic in commands instead of in controller files that have to do with more than one type of data or view. Controllers tend to get a little big, especially with callbacks.
That said, I really like Swiz and I think Autowire and Mediate are enough incentive to use it over Cairngorm or PureMVC. Swiz is the style of programming that those three frameworks represent done right. Mate, however, is a different, hmm... what should I say... cup of tea?
MateMate is picking up a lot of steam lately (these puns are going to keep on coming, people, you may as well just laugh now). Everyone I talk to lately loves it. I think it’s a shame that some of those people aren’t really getting a chance to try Swiz too, but when you feel what it’s like developing with Mate, you’ll see that it’s not that big of a shame.
The way I make a distinction between Swiz and Mate is that Swiz is the Cairngorm style done right, while Mate is a completely different style. The big difference, I think, is the declarative versus programmatic style of Mate. Since a lot of what we do in Flex is in MXML, using MXML to set up framework interaction makes a lot of sense, and also just seems to really fit alongside the view code.
PureMVC and Mate both want you to use regular old Flash events instead of framework prescribed events. Swiz wants that too, but sometimes you need to dispatch through its dispatch system. What makes Mate so elegant, though, was the insight of just using the event-bubbling to catch them with the EventMap without defining a bunch of wiring code. Of course, that breaks down when you want to use a service delegate and have to pass in the dispatcher, but it doesn’t break down as hard as Swiz breaks down when you don’t use RemoteObjects.
Mate is also really flexible. There are probably more tools there than you need, and not only that, it has a plugin structure. I don’t understand it yet, but that’s kind of nice. I also like that Mate has a way of using Commands, although I’m not sure it would be worth it to just turn your EventMap into a Cairngorm FrontController.
I like Mate a lot and I can’t find anything to pick on. Really. The only thing is I don’t think I fully understand how it scales, and the way it does view and object cacheing is a little bit of magic. Magic isn’t bad, but again, I just don’t know what pitfalls await me while using it. I hope to find out, though, and I’m really excited to use Mate.
Framework SmackdownNow is the time when I give you my subjective rating system to give a bit more quantification. Below is a table rating the frameworks on five variables from 1-5, 5 being high:
1. Conciseness - How little it takes to get something done in the
framework.
2. Familiarity - Once you get past the initial learning phase, how
easy is it to fall into the pattern of using the framework. How easy is it to
think in the framework?
3. Flexibility - How easy it is to work with exceptions to normal
development patterns.
4. Power - The tools to get the job done
5. Programmer
Joy - Is it fun to use the framework? Is
it rewarding, or does it punish you when you have to use it?
|
Conciseness |
Familiarity |
Flexibility |
Power |
Joy |
Total |
|
|
Cairngorm |
2 |
4 |
4 |
3 |
3 |
16 |
|
PureMVC |
1 |
2 |
5 |
3 |
1 |
12 |
|
Swiz |
5 |
5 |
2 |
2 |
4 |
18 |
|
Mate |
4 |
4 |
4 |
5 |
5 |
22 |
Well, there you have it, folks. I’m riding into this one with
flame-proof-pants on, but I hope I’ve done a little good by giving the
reasoning behind my thinking. I welcome any critique of my reasoning, and if
there’s a better way to do something in my example code please put comments on
the code in Github and leave a note here as well. I hope
the example applications help, and I hope that you’ve all learned a little bit
about yourselves on this journey. Viva Flex.
Read the rest of FrameworkQuest 2008:
Tag Cloud
InsideRIA Conference
Learn more about the conference at http://training.oreilly.com/insideria/
Podcasts & Screencasts
Development Series
Get an overview of the tools and technologies that work together to allow developers to build Rich Internet Applications (RIAs) quickly and easily.
Facebook Application Development@InsideRIA on Twitter
Follow InsideRIA on Twitter
Thank you, Tony. This was an incredibly helpful and informative series. I'm glad to see you picked Mate, as I would have hated to have to change frameworks already since I just started working with Mate a few weeks ago :)!
Thanks for the info. It was very informative, particularly about Swiz and Mate. I went with PureMVC early on because its not just a Flex framework, but can be used in Flash or Flex, and they also have a AS2 port which was great when I worked on a FlashLite project.
The payoff on PureMVC comes through continued use. The framework is simple to understand, and though I admit initial setup seems a little large, this can all be automated with Sprouts or RubyGems...
Nice work on noticing it's flexibility. The strength in PureMVC lies in the creating mediators to control completely decoupled components. And because the mediators are only loosely connected to this reactive system code in one area should never break code in another.
In a team environment this is a dream come true, and thus I would argue that flexibility is everything.
I would also argue that this strongly encourages code reuse and therefore, over time (and not that much time I might add) development time increases rapidly giving the developer more time to do amazing and cool things.
Great finale =) Superbly even-handed and the parallels drawn between frameworks were very helpful. As for Swiz and services did you see MockAsyncToken or Sönke's test utilities? And thx a lot I'm conflicted about Mate again ;) Its power and community relative to Swiz are just overwhelming. Did Mate ever feel like tag soup when you started it? Do you have any CF background?
@Jon - I have a background in CF many years ago. The last CF project I was on was when CF MX was new. I moved on to Java and then Java and Flash and then Flex, and then Rails with some forays back into Java-land for Android.
I wasn't familiar with either of those utilities - I'll check them out.
I think I know what you mean when you say "tag soup", but I don't mind MXML. I don't have special love for XML, but MXML is superbly well suited to what it does. One thing that I may like about Mate is the parallel with Ruby - most Ruby "configuration" is done in Ruby itself (unless of course yaml is used, which is generally for data, not configuration). That's because of the way Ruby makes that really easy with metaprogramming and so forth. When it comes down to doing configuration in Flex, stuff like wiring the output of this thing to that thing, it makes a lot of sense to do it in Flex and make use of the power of binding to make that configuration mean a lot. Mate does that well, and while of course XML gets verbose, Mate still makes it easy to get a handle on that.
Just a shout out to Swiz, though, which does a very good job at configuration with metadata.
Either way, avoiding doing a bunch of this.foo = that.foo or constructing objects you don't otherwise care about and wiring things together in Actionscript are what makes Swiz and Mate stand out.
And to anyone on the fence about Mate v. Swiz, or Cairngorm v. PureMVC or whatever combination, don't take my word for it, and don't think that you need to make a final choice and stick with it. Play with them all. Live with them and see how it feels. It may be that one fits the style of certain kinds of projects better than others. They're also still growing, so keep tabs on them as they improve.
I don't know where all the buzz around Mate was happening - your article was the first I'd heard of it. Having checked it out with a couple of small projects I really like it, but one drawback you haven't mentioned is the need to use key strings with no compiler checking on tags like PropertyInjector (similar to when setting up bindings in AS with BindingUtils). I am getting around this by putting key-name constants in place on the relevant classes, but this is a slight extra hassle. Also, it would be great if the event object in an event handler was actually a flash.events.Event rather than a SmartObject (whatever that is) because then you could cast to the type of event you are handling and again get compile time checking of property names - I haven't figured any solution for that at the moment, and am expecting stuff to break if I ever rename an event property. Other than that Mate is really cool, and fits well with the nature of Flex.
I look forward to hearing whether those classes compensate for the AsyncToken token issue in Swiz.
"Tag soup" was poor terminology but I was referring to (as I think you correctly inferred) Mate looking somewhat verbose (e.g. PropertyInjector vs. curly brace binding or Invoker tags versus Mediate annotations). The Ruby parallel was a helpful explanation though.
Ultimately I think your final advice is right. I'll try to do a little project using each in a couple months when I have some time. Maybe I'll even blog about it ;)
Anyone else looking for helpful resources:
It looks like an active member of the PureMVC (MultiCore and Pipes) community has also implemented a little AIR app (using the AIR SQL framework) in parallel between Swiz and Mate.
Also, as I mentioned on the Swiz article comments, I was wrong: WebService and HTTPService do use AsyncTokens. My example with a service library is odd enough that it breaks Swiz's normal flow, but those should work ok.
To say that Singletons aren't global variables because they provide encapsulation is a false argument, because encapsulation has nothing to with it.
To explain I would like to quote Miško Hevery's Root Cause of Singletons (from the Google Testing Blog), who explains it much better than I could:
http://googletesting.blogspot.com/2008/08/root-cause-of-singletons.html
I should probably add that the reason why encapsulation has nothing to do with global variable-ness is that a properly encapsulated object can still be mutable. Encapsulation only means that you bundle data and the actions that work on that data together in an object, and in a broad sense (but more commonly known as Information Hiding) it also means that the data can only be manipulated through actions (e.g. the methods). If the object is globally accessible, and has the methods getName and setName, the "name" of the object is most definitely a global variable.
@Theo
I'll concede the point that singletons are global variables - I don't really care whether they're global or not. Globally accessible most definitly.
The point I'm making that they're not mere global variables in the same way as was possible in the Flash days, e.g. some property on _root. As long as there is encapsulation, although any part of the code with access to the singleton class can access the object, the object in the case of a Cairngorm Model Controller has encapsulation and can control what happens to its data.
This was a really informative series, very nice.
I am a little confused as to why Swiz was rated so low on Flexibilty and Power vs. Mate.
And I recall Mate seeming to have much more boilerplate than Swiz.
With Swiz, I'm not worried about the service/delegate layer stuff. But I do think I recall seeing DynamicEvents being used, which is bug prone. Adobe (in ASDoc) recommends that DynamicEvents are converted to Event subclasses 'eventually', so that you don't run the risk of property name typos or misspellings. i.e. Run-time vs. compile-time error safety checking (also speed they claim). I think that was the only thing that bothered me about Swiz. Of course, it also bothers me creating a crapload of events for every little thing too, heh. So I'm not sure how I feel about that.
Also I'm not a fan of code generation to solve the boilerplate problems. It's still more code to maintain down the road. And what about when you have to refactor and change things? Nightmares!! This is probably the #1 reason I'm ready to try dumping Cairngorm (and def not try PureMVC) to try Swiz or Mate.
@Ansury - I rated Swiz low on Flexibility because I thought that the service stuff only worked well with RemoteObject. I was wrong about that, because WebService and HTTPService both return an AsyncToken on a call, so they should work. We can ding up the Swiz flexibility a point. My mistake.
I rated Swiz lower than Mate on power because Mate has more tools for you to use. Saying that Swiz is less powerful doesn't make it worse. More power means you need to make more choices on how to use it, which could lead to different styles and differences of opinions which negates some of the benefits of using a framework, especially in a team environment.
In fact the same is true for flexibility. Given that the standard, prescribed way of doing something is good for most cases, I'd rather not have a flexible framework, or at least I'd rather have a flexible framework that hides the flexibility until I need it.
This is one of the main arguments that DHH, the creator of Rails, makes about Rails. Rails says up front here's the way to do it. If you agree and follow the Rails way, you're rewarded with not having to make arbitrary choices like how to name your database tables or what to call the method to update a record. If you *need* to, generally to integrate with some legacy system, you can override the defaults. This concept is one of "sensible defaults".
That's just a caveat about flexibility. I still think Mate is flexible in a good enough way that I'd ever so slightly as a framework since, for example, it would easily allow me to use Commands whereas Swiz wouldn't. Again, that's a subjective assessment since not everyone I work with would like that ability.
@Tony
I do agree that it's much better to have an encapsulated object that keeps track of your data than a bundle of unchecked variables on some untyped global object, but the lack of encapsulation is not the problem with singletons, and saying that singletons aren't bad because of encapsulation is misunderstanding the arguments against them. The problem is that they are used like global variables, which makes code that use them less reusable and harder to test. Being properly encapsulated does nothing to alleviate those problems.
@Theo - Let's leave it at this: In my experience a Singleton is not a problem in team development - I don't care much about the arguments against them since I've never run into a case where it burned me. I'm more pragmatic about it. That being said, I'd be happy not to use one given a framework that gives me a better way to do it.
I think this singleton thing is one of the strong points for Mate. It creates (internally) "singletons" in that a single instance of an object exists, but does not give you any way to access them, except through an EventMap. So the "global" values are only injected into views etc. from externally - making the view components reusable within a different application that has different Managers and EventMaps but the same core Value classes.
Mate definitely takes the sane approach to singletons, it's true. However, it can get very confusing when talking about singletons and Singletons. Mate helps you enforce the singleton-ness of a class, i.e. that there is only one instance of it. This is also one of the rationales behind the Singleton design pattern, but in reality classes that follow that pattern do so almost exclusively for the other reason: to provide a global access point to the single instance.
Again, Miško Hevery of the Google Testing Blog says it best:
Have you taken a look at aconcagua (IOC and MVC framework for Flex)?
http://code.google.com/p/aconcagua-flex/
@Chris - No I haven't. I'll look at it.
Very interesting articles! I question however: I have used Ciarngorm and PureMVC in the past and one thing I ran into was the clash of the singleton model locators (or proxies in PureMVC) when building multi-document interface applications (where there are multiple documents open each with their own state). Do any of these frameworks handle this type of applications well?
there was another reveiw recently
http://www.summa-tech.com/blog/2009/01/14/selecting-the-right-flex-application-framework/comment-page-1/#comment-49
I'm still trying to work out the best way to write Flex applications. The reason it's still a problem for me is that I am committed to developing modular software (see http://www.arum.co.uk/solstice.php ). Thus, the problem with most of these frameworks is that they can't be modular because they depend on singletons. :(
For instance, in Solstice modules share the same loader context, so if more than one module wants to use Cairngorm things can get a bit weird and I don't really want to want to make any framework part of Solstice or re-implement the patterns of those frameworks in Solstice as this reduces flexibility for developers a little more than I am comfortable with.
So far I have simply been using my own interpretation of the J2EE View Helper pattern combined with sensible coding and haven't found a need for a framework at all.
However, this series has been invaluable as it has saved me a lot of time and investigation of my own, so thanks.
@ChrisBrind
Mate has support for modules. I don't know how well it works, but it's mentioned in the docs.
Ditto on the kudos, this is a fantastic resource and one that I'll be sharing around. Great comments from the readers, too; very low heat level for a subject that often gets very hot.
I'll echo Chris Brind's experience with developing modular applications--it was the need to introduce modules into a large and configurable application that finally drove me away from Cairngorm, although I had already become a bit weary of the boilerplate code (and this was a couple of years ago when there were no viable code-generation tools for it that would have worked with my application stack).
Even when not using mx:modules, I have a strong desire to organize my applications along feature lines, and to have everything particular to that feature in a given package. With Cairngorm and, I believe, PureMVC, the framework rather insists that you have a small number of global (or, okay, singleton) classes in which all of your MVC(S) interactions are defined. What I'd like to do is to be able to drop a feature in and "publish" it to the framework--nice as a programming practice, essential if you're building a truly modular app.
If I could somehow invent an extra 20-40 hours that I don't have, I'd love to be able to run this type of an experiment but with Modules or Marshall Plan subapplications. I get the impression that this is more of an edge case for a lot of developers, but I've had multiple occasions to build modular apps, and would like to be able to evaluate the various frameworks on those merits as well.
Hi
Nice work Tony.
Have you gone through prana framework?
Interesting article! It's good to see an overview of all the frameworks, quite difficult to keep track of all of them at the moment.
I tend to use PureMVC for most projects, so can't comment on other frameworks. Flexibility for me is most important, along with a clean, well-structured and easy to understand architecture + support for AS3 and Flex and PureMVC scores highly on that point. As for boilerplate code, there are ongoing efforts in the 'Fabrication' project to hide most of it from the developer.
Now what I would really like to see is a generic AS3 IoC container that can be reused with all of the frameworks. I'm hoping that the Spring container will do that!
@ChrisBrind
PureMVC also has full module support in its multi-core release.
@Tom Van den Eynde
PureMVC's Proxies are not singletons but separate instances, so you could create an instance of the same proxy class for each document. Another proxy could then manage those instances. Alternatively use a single proxy to store a collection of value objects describing each document.
GraniteDS Tide also seems a good UI framework to be investigated, though I think it integrates only with GraniteDS on the server side
I tend to use PureMVC for most projects, so can't comment on other frameworks. Flexibility for me nakliyat is most important, along with a clean, well-structured and easy to understand architecture + support for AS3 and Flex and PureMVC scores highly on that point. As for boilerplate code, there are ongoing efforts in the 'Fabrication' project to hide most of it from the developer
Tony,
So how is the Mate experiment going? Try anything serious on it yet?
Given that Mate also loses some compile time error checking (it's mapping file), that evens things up for me with Swiz, so I may try the Swiz out here.
@ansury - I think it's a choice between Mate and Swiz. My experience is that if you're cool with the Mate way, it's great. If you want a little more flexibility, use Swiz.
Very very nice article..
Yesterday i was in México giving a conference in the Flex Tour and i was talking about, Cairngorm and PureMVC the frameworks that i have used. Another friend talk about MATE and i was surprised about the power and flexibility but MATE itself i think it mix some things, and in a pure architectural way there is some issues about that for example in the remote calls, i prefer to have a command and a proxy class to do the job.One thing that i have to say in favor in pureMVC is taken from the best practices document. "Commands are stateless; they are created when needed and are intended to go away when they have been executed." which means more efficient way to work with objects, memory etc. that Swiz it seems to be nice, i have to try it..and MATE i have no doubt to implement in small -medium size projects it seems relly nice..
thanks for your article it was really helpful :D