Why use Robotlegs? - more elaborate explanation than the book gives needed.
Support Staff2 Posted by creynders on 30 Apr, 2012 07:43 AM
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
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.
> 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 :)
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.
4 Posted by Michał Dawidowicz on 30 Apr, 2012 04:47 PM
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?
5 Posted by Michał Dawidowicz on 30 Apr, 2012 05:05 PM
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
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.
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 :)
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
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.
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.
Support Staff10 Posted by creynders on 01 May, 2012 09:25 AM
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
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.
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
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.
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
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 !!
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.)
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.
One very simple point that was probably missed as most of the RL
adoptee's have probably used this technique without thinking about
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
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.