Why use Robotlegs? - more elaborate explanation than the book gives needed.

Michal Dawidowicz's Avatar

Michal Dawidowicz

28 Apr, 2012 11:09 AM

Hi! I'm teaching programming and recently my student asked me about RobotLegs saying that it's popular AS3 framework in the industry and knowing it gives a strong 'cv boost'. I've grabbed a copy of "ActionScript Developer's Guide to Robotlegs" and started reading about the framework. I've downloaded the example projects, opened the Mosaic one and was terrified by the code complexity. 3966 lines of code across 145 files for such a simple piece of software. What are the advantages of using the framework than? You trade extreme amount of time wasted, enormous horizontal complexity (vertical complexity is small, with most classes having less than 100 loc) and possible performance issues for what gains? I've searched the book but it doesn't give one precise answer to that.

  1. Support Staff 1 Posted by creynders on 30 Apr, 2012 07:43 AM

    creynders's Avatar

    Robotlegs' advantages are mainly felt in large projects, but obviously when giving examples you need to restrict yourself to small, simple applications otherwise it gets too complicated to understand what's going on.

    The benefits are two-fold:

    1/ project setup: since RL follows the MVCS pattern it allows and encourages you to structure your project in a decoupled and organized way from the start. Where you see horizontal complexity, I see a table-of-contents that tells me what the application does, w/o the need to dive into the code (if classes are properly named of course).
    Obviously it needs a little getting used to and requires a proper understanding of the RL paradigm, but if you spend a little time on examining what the several tiers are, how they are represented in RL and how they communicate with each other, you'll get the hang of it pretty quickly.

    2/ and this is where RL really shines: maintainability, scalability and flexibility (and a few other -bilities). When a project really takes off use cases will change, technologies will be swapped, scope will creep and unforeseeable problems will arise. In my experience projects are like massive rivers that just keep on thundering on, and will follow the path of least resistance. In other words they grow, shrink and get stuck. RL helps you to easily adapt your code to these new challenges. In RL you should always aim not to rewrite parts, but to add new parts and swap the old obsolete ones with the new relevant ones. Due to the way everything is decoupled this is very easy to do.

    RL is for "real" medium to large projects with distributed teams and long timelines. Not necessarily so, but that's where it really makes a huge difference.

  2. 2 Posted by Stray on 30 Apr, 2012 11:32 AM

    Stray's Avatar

    Thanks Creyenders,

    > Where you see horizontal complexity, I see a table-of-contents that tells me what the application does, w/o the need to dive into the code

    Yes! I love this description :)

    Hi Michal,

    The Mosaic app was built as a skeleton that implements some functionality but is ready to become a much more sophisticated app - there's a limit to what you can do for a book, but we wanted to do something that was more realistic than a superficial micro app that wouldn't really justify a framework.

    I thought we'd explained that in the book, but I apologise if we didn't make it clear - it was certainly our intention.

    If you wanted to add printing, saving to a network, comments on designs, versioning, "likes", colour palate export, automatic order of supplies, pricing, quarter tile counts, special png-based tiles with flowers on... or pretty much any other feature, you could do so very easily (once you understand robotlegs).

    Also if you wanted to redesign the front end to have a completely different layout (for iPad for example) then you'd be able to do that without touching anything except the view tier (and as creyenders said, you'd add a new one, not change the existing one).

    Then you could continue to publish AIR for desktop, in-browser swf and iPad versions each with a custom front end.

    From your question:

    "Most classes are less than 100 LOC"

    yes... that's my aim. 60 is great, 100 is passable, 200 is a problem (except in classes that process long XML, or have internal styling, though even then I'm always looking to break things out and usually find that I'm happier when I do).

    It's a philosophy - many small, simple things, with defined single purposes, tested fully, and wired together using consistent rules and practices.

    If you don't buy in to that philosophy then it wouldn't make sense. For me, that approach has paid off. I'm now approaching 3 years into a huge and fast changing project (we release new features weekly) and we haven't hit that point where the code becomes brittle and hard to change yet.

    You made an assumption about the time involved. Actually I built most of this app in less than a day - I built it on my holiday in Spain, because I'm doing a large mosaic on our house there and I was finding the process of designing it on paper frustrating. To me, a day felt pretty quick!

    LOC is distorted for code that appears in a book, because you are limited to around 80 chars per line (sometimes less, depending on whether you also have annotations), and the code has to be manually wrapped, so we put a lot of time into splitting things over several lines that remain readable, where normally one 90 character line would have been more natural.

    But, total LOC isn't a useful metric anyway.

    Stats show that typically we spend less than 10% of our time actually writing code, and more than 90% of our time thinking about code and reading code. So - LOC doesn't really tell you much about the time involved in a project, because a 50% increase in LOC would have less impact than a 10% increase in time spent thinking about the code / reading it.

    One purpose of the 60-lines class is that you can see the whole thing in your laptop text editor in one hit. No scrolling. Instant mental digestion. As it turns out, it also leads to great separation of responsibilities. We probably pushed the mini-classes even harder for the book, because it meant I could reference a whole class within a page of the book - and that mental "open, read, close" process has been shown to be more useful to most learners. Still, I've enjoyed working with the code in that style.

    hth, thanks for asking - it's an important point!


  3. 3 Posted by Michał Dawidowi... on 30 Apr, 2012 04:47 PM

    Michał Dawidowicz's Avatar

    Thanks for the long and interesting answer. I agree with a lot of stuff both of you said, but I think you misunderstood me a little bit. I'm programmer with years of experience, so it's not a question about "Why should I use RobotLegs over my badly designed spaghetti code?" but "Why use RobotLegs over writing a well designed object oriented code?".

    So to re-iterate it, assume I already have a well designed code, that achieves maintainability, scalability and flexibility (and a few other -bilities). Deciding to use RobotLegs I trade code size (which negatively affects maintainability) and performance (plummets quickly in Flash, especially when you favour over-engineered cluster of objects, which is inevitable with that amount of classes and scales even faster than projects scope). What are the gains?

  4. 4 Posted by Michał Dawidowi... on 30 Apr, 2012 05:05 PM

    Michał Dawidowicz's Avatar

    So, while RL makes you 'think less', it has a dangerous negative effects. Instead of writing a well designed, efficient code, you hide behind layers of abstractions until you arrive at something moderately working.

    To use the specific example of the Mosaic app, seeing it's current features and features you write that could be added, it's the very basic form of a pixel-art graphics editor. The whole rendering (the 'view') uses 20 different classes and displays each 'pixel' as a separate object. If it used a simple bitmap and just displayed it scaled up it would not only be much faster and flexible, but also easier to maintain and scale.

    And to clarify my post, my goal is not to bash your code or framework. It's really popular, even got some awards, but I just can't see the reason to use it at all and I really want to.

  5. 5 Posted by Jos Yule on 30 Apr, 2012 05:18 PM

    Jos Yule's Avatar

    I'm not speaking on behalf of anyone other then myself. But, if you don't dig it, don't use it. If you are happy with the architecture you currently use, and it satisfies your needs, then awesome! For RL users, RL satisfies their use cases, and makes their code easier to use and understand.

    Apples and Oranges, they are both good, and neither is necessarily "better" then the other, other then to those that love one or the other :)

  6. 6 Posted by Michał Dawidowi... on 30 Apr, 2012 05:25 PM

    Michał Dawidowicz's Avatar

    Thanks for the clarification Jos, that's what I thought, but I was afraid I'm missing on something.

  7. 7 Posted by bulupe on 30 Apr, 2012 06:25 PM

    bulupe's Avatar

    Hello everybody,

    There are very good answers at the top by Stray and Creyenders. When you need to create projects that you will be responsible for maintenance for sometime or there are quite some interactions between views you will understand the need for a framework. However if you are still asking why to use a framework you are not there yet.

    I strongly suggest to give it a try but not with the book examples go with your own projects, you will see how it helps to solve your everyday problems.


    Note: I do not promise a rose garden, RL or any other framework comes with their own problems, learning curves etc.

  8. 8 Posted by Stray on 30 Apr, 2012 09:24 PM

    Stray's Avatar

    Hi Michal, one of the specific details of the mosaic app is that each "pixel" as you call it, can be divided into quarters, triangular quarters - my app actually does this (and it was stated in the book that this was the intention), and this is why you can't represent it as a bitmap.

    Here's what the image looks like of the mosaic that I designed with it and that I have almost finished tiling on my wall:


    As you'll see - it's necessary to display each 'tile' as a separate object so that it can be further divided into the triangles. And also so that you can - for example - have 'picture' tiles - for example with a flower on, or a spot in the center. These are requirements that I knew were there from the outset, especially the triangles, hence not using a bitmap.

    Robotlegs doesn't force you to make your code as granular as I choose to make mine. And the example app is not "moderately working" - the version I published with the book is "moderately featured" because there is a trade off between adding features and making it too difficult for the user to follow the examples through the code base. One purpose of the app was to illustrate how you can use Robotlegs to begin to build an app that has the capacity to grow and be maintained.

    As I said - we artificially further-divided the code and also increased the number of lines in order to make the code more suitable for printing. We also - for obvious reasons - had to figure out how to make sure that between the two examples we included every technique that a newcomer would need to be introduced to. I'm not sure how many books you've written, but writing code for books is slightly different to writing production code, but we put a lot of effort into making sure our examples were closer to the real world than much of the example code you see in books.

    I don't think I'm hiding behind layers of abstractions, but as Jos said, nobody is holding a gun to your head to use the framework. As you say - many jobs now request Robotlegs. Either you're the only developer who can see how dumb we all are, or some people are seeing merit in using it. I'll leave you to decide which of those is more likely! (I'm not suggesting that you're dumb for not seeing it, but that we can't all be using it out of stupidity - so hopefully if you keep looking you'll start to see what we're all seeing).

    There are many, many examples of apps built with Robotlegs in the examples section - perhaps you should forget the mosaic app, as you're clearly distracted by the idea that there are simpler solutions to the minimal set of features that I've actually included in the demo, and look at other code instead. For obvious reasons, unfortunately most of the code that gets written with Robotlegs is in large applications that aren't open source.



  9. Support Staff 9 Posted by creynders on 01 May, 2012 09:25 AM

    creynders's Avatar

    Just to clarify too:

    so it's not a question about "Why should I use RobotLegs over my badly designed spaghetti code?" but "Why use RobotLegs over writing a well designed object oriented code?".

    I didn't assume you're writing spaghetti code. In fact, RL will NOT save you from writing spaghetti code. Nothing will.
    I haven't become a better programmer by using RL (the tips and techniques I learned from Stray, Shaun, Till and fellow RL-users however DID make me a better programmer) and it's not the aim of RL. It's not the aim of any framework AFAIK.
    It aims to take away the necessity of writing a lot of boiler-plate code, to define an organizational structure for your code, to define conventions that are independent of organization, culture and background, to aid hooking up the various parts of your application and to enable the mentioned -bilities.

    Instead of writing a well designed, efficient code, you hide behind layers of abstractions until you arrive at something moderately working.

    No, that's just plain wrong. You still write (and are responsible for writing) well designed, efficient code. RL is not meant to replace your brain. Just as you can push a nail into a wall using just your fingers (if you're really patient and a ninja) you can also decide to use a tool to make your life easier. Whether you'll end up with a picture frame at the correct spot is up to you, not the hammer.
    It's exactly the same with RL.

    [...] when you favour over-engineered cluster of objects, which is inevitable with that amount of classes and scales even faster than projects scope

    Again, the number of classes has nothing to do with complexity or overengineering. On the contrary, the leaner and smaller my classes are, the cleaner and more maintainable my code becomes in my experience. It took me a while to accept, believe and experience this, but it's an undeniable truth.

    Overengineering has to do with adding levels of abstraction that are not necessary.
    (Find a nice example here: http://thedailywtf.com/Comments/The-Enterprise-User-Agent.aspx) But what does that mean: "not necessary"? When is something overengineered?
    It depends on 2 factors:

    • context
    • aim

    With context I mean: will it be developed as a team? Is it a distributed team? What is the timeframe and work distribution, ie. does it have a short and intense development time or is it spread over months, maybe years? Will you see the end of it, or will you set it up and move on? Are its dependencies (for instance remote services) in development or stable and tried-and-tested? etc.

    Aim: will the product target end-users? Or other developers? Is it the first building block in a family of products/modules/libraries etc.? Is it meant to be generic? Or is it a very specific solution to a very specific use case? Will it "live" on for years? Or is it a hit-and-run product?

    The answers to all these questions determine whether something is overengineered or not.
    In your opinion the mosaic example is overengineered, fine, maybe it is. However, the context and aim (a book with learning examples where abstraction is applied to the architecture, NOT to the example itself (ie. Car extends Vehicle and honks)) were direct triggers for the decisions made in the architecture and the architecture should be judged by that context and aim.

    Anyway, RL doesn't enforce such an architecture.

    In fact it doesn't enforce an architecture at all. There's no requirement to use commands, actors and views. It's set up to aid you if you DO want to, but it works perfectly without.
    If you're a MVC purist and want your controller to be exactly that, a controller class, not a collection of commands, no problem. It's up to you.
    Do you prefer MVP? Sure, why not.
    In fact, you don't even have to use it as an DI provider. If you prefer the service locator pattern, again no problem.

    RL allows for all of this.

    The problem with explaining the benefits of something like RL is the same as trying to explain the benefits of interfaces. As long as you don't use them you don't realize what it adds to your coding toolbox. It doesn't replace anything. It allows you to do things more easily and elegantly than before. Just as you can program in AS3 w/o using interfaces you can survive w/o using RL. But once you start using it you realize what it was you were missing out on.

    And there are domains in which RL is definitely not the right choice. I don't use RL for games. I use it for the system surrounding the game ("pages", leaderboards, etc.) but never for the game itself.

  10. 10 Posted by rideforever on 01 May, 2012 08:01 PM

    rideforever's Avatar

    Have to agree with Michal.

    In the Robotlegs documentation it says something like Robotlegs solves problems that GLOBALS and SINGLETONS create. You really have to ask who this crap is aimed at. I wonder what C#/C++/Python developers would make of it.

    The Flash community really goes bananas for this kind of stuff, endlessly discussion Cairngorm PureMVC etc... And gosh when MVC came out it was like the 2nd coming.

    MVC is natural pattern that naturally arises if you have a brain !!

    Yes, a brain - look up from your iPad for just one second.

    As for the Dependency Injection (tm) that occurs in Robotlegs, it just magically inserts into one object, some other objects. Great ... WTF for ? If the whole point of Robotlegs is so that you don't think - there are more permanent solutions ... I can get you a number on that !

    If you take a Flash job you never know what the developer has done. Has he used a framework ? Which one ? And how ? And that is before you even look at the code. It's just one mess out of another - forget about the AS3 / runtime documentation ... you have to look at the goddam Robotlegs non-documentation with real live non-working examples, and non-compilable source code available on git.

    I made a career on Flash ... but I just don't respect this kind of non-engineering, non-thinking, laziness.

    And the people who defend this kind of thing are the ones ( I guess ) who think Globals and Singletons are the bees-knees ... there you go, 90% of Flash devs offended !!

  11. 11 Posted by Stray on 01 May, 2012 08:36 PM

    Stray's Avatar

    You seem to be confused about what Robotlegs actually is.

    The DI container is only one aspect of Robotlegs. Mediator Map, Command Map, View Map, shared event dispatching, modular integration... these are partially enabled by the DI container, but if you think that DI is what Robotlegs 'does' then you're a bit confused. Automated-DI is the first principle, but it's not the end of the story.

    The whole point of Robotlegs is to reduce "WTF's per minute" - which, as Uncle Bob says, is the only codebase metric that really matters. It's not about not thinking, it's about not creating confusion - those are pretty different. Those of us who use it spend a hell of a lot of time thinking, but we're thinking about the interesting, unique aspects of the problem that get the job done, not wiring issues.

    Anyway - you're only the 3rd person ever to have made me sad on this forum. Thousands of other users have had respectful debates about all sorts of things, but you're coming across like a troll. That's not about the content of your opinion - I know some other great developers who don't go for frameworks either. But really, is the tone you used the one you want us to use to form our opinion of you? The message coming through loud and clear is that you have no respect for fellow developers.

    Even if you feel that way, making that attitude public, when many hundreds of users of this forum know many other people who may one day be choosing whether to work with you / for you / give you a job... well - that's an interesting choice.

    I'm not sure you've offended 90% of flash devs - probably just intelligent people who are embarrassed by your attitude.

    Please try to engage in a less confrontational, more respectful tone - whatever point you're making.



    (Btw - I don't have an iPad. Or an iPhone. But if I did, it wouldn't have any correlation to any other detail about me except for disposable income and taste in electronics.)

  12. Support Staff 12 Posted by Shaun Smith on 01 May, 2012 10:50 PM

    Shaun Smith's Avatar

    Robotlegs is just an Open Source project, some code on the internet, created and used by people who find this kind of thing interesting. Why bash it?

    It's like being invited to a party and then complaining about the music - instead of just leaving.

  13. 13 Posted by Rick on 04 May, 2012 02:50 PM

    Rick's Avatar

    I think you gals and guys on the RL team have done wonderfully presenting a clean set of patterns to follow that are easy to learn, easy to maintain while providing a friendly guide when developing. RL2 is looking great.

    I feel compelled say thank you. So...thank you!

    The fun thing about the world wide web are the ill-tempered drive-bys--as insignificant as they usually are.

  14. 14 Posted by Mike on 08 May, 2012 06:19 AM

    Mike's Avatar

    One very simple point that was probably missed as most of the RL adoptee's have probably used this technique without thinking about it anymore.

    I recently did architectural design work for a large enterprise app (1M+ rows of engineering data wasn't an uncommon requirement with 140+ columns) for a global manufacturer of heavy equipment. This isn't the point, the point is based on a team of 6 UI people, and a dozen or so middle-tier and back-end developers, we were actually able to work in parallel development. This has NEVER occurred in my previous 10+ years of Flash/Flex/AIR development.

    So how did RL help to pull this off so easily? Simple really, and that's the beauty of it - with the context doing all the wiring of the IoC pieces, I was able to meet with the leads of both the MT / BE, to develop the API in what service methods go with what parameters and eventual returns even though those services / databases didn't exist. By creating a testing framework which generated the VO/DAO on the fly, the 6 of us were able to advance our gesture / application flow irrespective of real data. Once the real service became available, it was A SINGLE LINE OF CODE, which allowed us to swap out the generated code (typically a responder for a service) for the real hookup.

    This is certainly possible with other frameworks and other languages, but every devotee of alternatives (that I have talked with) has usually dealt with a very integrated puzzle of test code sprinkled with production code.

    I find this to be the single most valuable piece in the project puzzle since man-hour effort is by far the biggest variable. Ways to predictably work in parallel will always reduce the level of effort to something more tangible, even in very large projects, and even small ones.

    -Hopefully this was enough a 'real-world' use of RL.

  15. Ondina D.F. closed this discussion on 27 Aug, 2012 10:37 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac