Flex Layout: Absolute or Relative Positioning, Which is Better?

In Adobe Flex, there are at least 3 distinct ways of laying out (positioning) the elements of your application:

1. Absolute – using X and Y coordinates
2. Relative – using nested HBox and VBox controls
3. Constraints – using element attributes such as “top” and “bottom” to anchor controls within parents

How do you know which method to use when building your app?  Good question.  The answer is not easy to find, and my purpose here is to perhaps find the best answer from the available information on the net.

Common Knowledge

If you ask other developers, you will most likely hear that you should avoid a lot of relative positioning in your code because it’s “resource intensive”.  This seems to be the common knowledge, but how does anyone really know?  Are we all just parroting that which we have heard before?  Has anyone actually published any numbers on the subject, or is the “evidence” all anecdotal?

I will try to highlight some of the best information that I’ve discovered on the subject.  One key thing to note is the date of the information!  Flex evolves and processing power improves over time.

Case in point, check out this article that is published on the Adobe Developer Connection: “Flex Application Performance: Tips and Techniques for Improving Client Application Performance” (2004)

The biggest Flex performance danger is yielding to the temptation to use containers randomly. Using too many containers dramatically reduces the performance of your application. This is the number one performance danger that Flex developers succumb to—and luckily it is 100 percent avoidable. The performance penalty occurs because Flex layout containers and their children follow sizing and measuring algorithms that determine x,y positions, preferred sizes, and styles. These calculations are resource-intensive; it is these calculations, coupled with Flash Player drawing complex objects, that cause a noticeable delay when starting a Flex application or when instantiating a new view in a navigator container. One principle dramatically speeds up application startup and interactivity time: Avoid unnecessary container nesting.

A good rule of thumb is to avoid excessive container nesting. At first, you might find it difficult to pinpoint superfluous container nesting.

The quote above is just a tiny bit of the entire article.  There are two key things to note:

1. the article was written 5 years ago, and
2. it is tempting to take away the idea that nested containers = bad.

But that’s not what the authors are saying!  The don’t say that nested containers are bad.  They say that “unnecessary” and “superfluous” containers are bad in the same way that a slice of chocolate cake isn’t bad, but eating an entire cake by your self in one sitting is bad.

Personally, the nested containers that I use in my apps are downright friggin’ necessary.  So while it’s easy to feel guilty about using nested containers, it’s probably not wrong or detrimental unless you go a bit nuts with them.

Probably the Best Answer

Here’s a great quote on the subject from from Joseph Balderson (blog.joeflash.ca), co-author of the recent (May, 2009) book “Professional Adobe Flex 3″.  This nugget was picked off of Stack Overflow (from May 22, 2009) as an answer to a user with the same question that we are trying to answer here.

In this case, the user had a Flex application that had been converted from relative to absolute positioning.  His team was beginning to witness the obvious drawbacks of absolute positioning (which we will get to later) and had begun creating hacks to make the positioning dynamic while still using X/Y coordinates.  All of this because “someone told them” that relative positioning was bad.

Here’s what Joseph had to say:

I put this quote here because I believe it to be the best answer.  If you are in a rush, you can stop reading after the next paragraph.

Like most things it’s really just a matter of common sense.  Everything in moderation.  Use the right tool for the job (form layout tags when writing a form).  Use X/Y positioning when laying out content that will always be about the same size in the same place.  Use relative positioning when it makes your life easier (like when you are feeding in dynamic content of varying size and can’t allow spontaneous scroll bars), but don’t over do it.  And don’t feel bad about it.  Relative positioning is your friend.

Further Questions and Answers

Why do all of the Adobe example apps seem to use X/Y coordinates for layout?

Most likely because these example apps were built with Flex Builder using Design View (which I never use).  Design View drops controls on the screen by default using absolute positioning.  This makes total sense for demo applications, but I suspect that many Flex newbies start with Design View and therefore also default to absolute positioning in all of their apps.

Here’s a relevant quote from Dan Martin (dmartin.org) on tips for the New Flex Developer (May, 2009).

Avoid absolute layouts, using VBox and HBox to layout your MXMLs instead (or layout=”vertical/horizontal” on Application).  Absolute layouts are easy enough to develop but a nightmare to maintain.  When your business owner asks you to remove one thing, it takes seconds with a VBox/HBox design, and much longer with an absolute layout.   The only exception to this recommendation is when performance requires it.  VBox/HBox layouts require calculations to determine sizes.  Usually, this is no big deal, but sometimes can cause problems.  For instance, when you use item renderers with VBox/HBox layouts displaying dynamic data, the performance hit during scrolling can be unacceptable.

Learn to code without the visual designer. The visual designer seems like a good idea at first, but becomes impossible to use when you start loading in external data, using external css skins, and develop item renderers in complex list controls.  And the visual designer promotes absolute layouts (see 3).

I completely agree.