In my recent Flasher Magazine interview I talked about how much I dislike the “advanced” classes in the Flex SDK that were shipped with Flex 3, namely the AdvancedDataGrid, the OLAPDataGrid, and the grouping and hierarchical collection classes. I also said that I thought that all the list-based controls (DataGrid, Tree, List, etc) were too bloated and slow and that they should all be rewritten from scratch. I realized that that sounds a bit harsh, so I wanted to try to back up those statements with some code metrics.
I’ve put together a spreadsheet that includes each class in the Flex framework, including charting and the advanced data visualization package. This shows the number of lines of code in each file, breaking down the total number of blank lines, comment lines, and actual code lines. I’ve colored the rows to indicate if the class belongs to the advanced data visualization package of Flex 3 (yellow), the charting framework (blue), the AIR SDK (red), or the open source Flex SDK (white).
Here are the top 20 classes, ordered by actual lines of code (not counting comments and whitespace):
To get these numbers, I used a free program called cloc to analyze the source code. Cloc is a perl script that analyzes a bunch of different languages, including ActionScript.
For the full list, check out the spreadsheet. This is for version 3.0.0 of the Flex SDK, it does not include anything released in SDK versions 3.0.2 or 3.2 or any of the new Flex 4 classes.
So just look at that list of top classes. Out of the top five, three of them are the new classes for the AdvancedDataGrid. It’s also worth nothing that AdvancedListBase and AdvancedDataGridBaseEx are not used for anything other than base classes for AdvancedDataGrid. If you look at the inheritance chain for AdvancedDataGrid, it looks like this:
UIComponent
ScrollControlBase
AdvancedListBase (4,553 lines of code, 8,573 total)
AdvancedDataGridBase (1,184 lines of code, 2,084 total)
AdvancedDataGridBaseEx (4,503 lines of code, 7,428 total)
AdvancedDataGrid (5,385 lines of code, 8,432 total)
That means that the entire codebase for the AdvancedDataGrid is 15,605 lines of code (26,517 if you include comments and whitespace). That’s 7% of the entire Flex codebase in those 4 classes. Note that this is not including ScrollControlBase or UIComponent, only the new classes in Flex 3. Also note that AdvancedDataGrid doesn’t inherit from ListBase or DataGrid at all, and ListBase is the second largest class in the entire framework.
So this means that when I run into a bug in the AdvancedDataGrid (which has happened a lot), I’ve got about 30,000 lines of code to wade through to try to debug my problem. No thank you.
The other two out of the top five are ListBase (which is why I said the entirety of the list classes is too big) and UIComponent (which I think is understandable, and I haven’t run into too many problems that have root causes in UIComponent, unlike ListBase which continues to be a big headache for me). Then number 6 on the list is DataGrid (oh, but don’t forget about #12 on the list, DataGridBase). If you group all list-based classes together (meaning the advanced classes and the original list/datagrid/tree classes), you’ve got 9 out of the top 20.
Code quality
This post is only about raw numbers. There’s an entirely different topic of code quality that I can write post after post about when it comes to the quality of the AdvancedDataGrid (and related classes). They use noticeably different coding conventions, they deviate dramatically from the best practices employed by the other components, and they are plagued by performance problems. But that discussion is for another post. For now I just wanted to point out the shear massive volume of code that you’re using when you use these classes.
Am I being too harsh?
Some would argue that the classes have to be big, given that they do so much. After all, it is called the AdvancedDataGrid, it’s doing crazy advanced stuff. I call bullshit on that argument. In my opinion, I just don’t think there’s an excuse for such massive classes. They make developers lives miserable when trying to debug, but I also think it is indicative of a sloppy coding style. The mentality sort of seems to be “throw more code at the problem until you get it to work.” Check out the expandItem method of AdvancedDataGrid. It’s 445 lines long – this single method is longer than 80% of all the other Flex classes in the framework (yes, I checked how many classes are under 445 total lines). That method even includes a spectacular commented out block of code with this comment:
// Dont know why this is done
// So, commenting it and using the rowHeight instead
Awesome. I guess as long as it passes the unit tests go ahead and ship it 😛
I used TreeGrid before, and I can say ADG is way faster than TreeGrid. Displaying 2,000 nodes of data could easily incur a script timeout with TreeGrid, while ADG didn’t seem to have such issue. Yet I would agree with you that ADG didn’t seem to be mature enough, and in fact it is one of the poorest documented component. I spent countless hours reading through their implementation to get little done.
@Tangent- yeah, the TreeGrid in FlexLib definitely isn’t better (and in fact simple things like sorting don’t work at all). I debated on removing the component after the ADG was released in Flex 3, since nobody has taken the lead on fixing any of the bugs in the TreeGrid.
For the current project that I’m on I rolled my own version of a hierarchical grid with expandable rows by extending DataGrid and implementing my own hierarchical model stuff.
Almost as though it was written by… an entirely separate team?
I agree that there’s a ton of bloat and questionable code in the Flex framework and core classes. I’m hoping that as the framework/platform matures, Adobe takes a step back and cleans some of this up.
It takes a lot of balls to open source a project, so you could say you have to give some credit where it’s due. Even so, I must say that seeing some of the code under the hood makes it a little more obvious to me why Flex often seems incredibly slow, memory bloated, and buggy for reasons that have nothing to do with the code I wrote with it.
– max
I’m glad you bring this up, and I definitely think there ought to be more of a discission about the quality of the Flex framework code. I think you let UIComponent off the hook a little too easily, 10 000 lines (including comments) is too much for any class, and this is *the* base class. All of Flex suffers for those lines.
It’s great that the Flex source is available so that we can have this discussion, and it doesn’t hurt that it’s open source too, so that we can participate in it’s development.
this is exactly why I don’t use flex.
Great post Doug – that expandItem comment made my day!
Not comparable at all, but a little side-story? In the AS2 days I rolled my own Datagrid that had all the basic scrolling, sorting, selection and that easily could display thousands of lines without choking. It couldn’t really be skinned, but you could set all props directly since the code base was so small. The total file size was 4Kb and it served me well for a long time 😉
J
Yeah, Adobe NA have basically disowned the ADG code.
I know its caused me a lot of headaches over the last year, and you can include in your quality post the Hierarchical classes (HierarchicalCollectionView for example) which are so bug ridden, it isn’t funny.
I’ve never found a valid reason for code that’s this bloated. If someone wants to argue that this class does a lot of things and that’s why it’s so big, then it’s time to break this class up into smaller more cohesive classes. This class clearly violates the Single Responsibility Principle. Hopefully with the Flex framework being open sourced now and under the public scrutiny of the development community things will get cleaned up, though I doubt it will be a fast process.
It’s not just these classes that are bloated, but the whole framework! I appreciate having access to the source, but I don’t think Adobe will have much success getting outside contributions to such huge classes. Small is beautiful, as they say, and they have some serious problems in that department.
Ariel
I think Flex has a lot of potential to continue to grow into a vibrant development framework. However, the dev team must get serious about it’s code quality and consider findings like this. There’s much irony in the thought that bad code could be the demise of the Flex development framework. Hopefully this won’t be the case..
Great article Doug! I just wanted to correct a small technical error in the closing sentence.
“…as long as it passes the unit tests…”
You don’t actually think there are unit tests supporting any of this code do you?
Macromedia gave the source for the AS2 components. They were very sloppily written, used poor coding conventions and lacked commenting. This practice of releasing low quality tools and then promoting those tools as viable solutions for folks problems does a world of hurt to their reputation. I figure the code that we don’t see is probably just as poorly written. When Flash 8 was released, there was little in the way of improvement to the component code base. So, should businesses use Flex? They should probably think it over carefully given that their customers may gain a measure of distrust for them as well.
WoW that’s a lot of hating 🙂 granted some well deserved. I’m just starting some heavy work with ADG and so far it’s been F&*k and WTF.
Has Adobe ever responded with the future of DMV? What will Flex 4 have?
You make a valid point about methods being too long and about base classes that are only extendable by one subclass. I do think these list classes have a lot of necessary code also. It looks like the framework is being rewritten for Flex 4, so maybe you will get your wish. My hope is that Flex 4 fixes scroll bars and item renderers.
Since I didn’t see anyone else say it..
I don’t think lines of code is a good judge of the code. I think that the file size of the components would be interesting, but I’m not sure that is a good judge either.
Things like lines with just curly braces can easily balloon up the number of lines without affecting the size. Comments would balloon up both.
If I understand, the Flex Compiler removes comments when creating a SWF. So a lot of comments in the code do not make the resulting SWC / SWF bigger.
@Jeff – note that comments are counted separately and are not included in the lines of actual code. I agree that things like lines with a single curly brace would inflate the count a bit, bit I’d be willing to bet that if you look at the resulting impact on swf size you’re going to get pretty much the exact same order as my list of classes ordered by number of lines of code. That would an interesting comparison, but my gut tells me that it would match up 98% of the time.
Pingback: Link: Why the Flex AdvancedDataGrid sucks | Psyked
There are an awful lot of developers out there that complain about the ADG (myself included) but I haven’t heard anyone talk about how they are creating something better themselves. Even in the case of the TreeGrid which was a first step at an ADG equivalent, as Doug said nobody is standing up to volunteer to improve it.
I have said to myself numerous times “I am just going to create my own lightweight datagrid” but it is a really daunting task. One for which most developers don’t have time.
Perhaps the community should come together and put together a project specifically to create a replacement. Doug I’m sure many developers would willingly follow you into battle on this one.
BTW – I’m not holding my breath for Flex 4 to fix it. I seem to remember reading somewhere that Flex 4 would not be replacing the DG or ADG.
@Rob – I completely agree with your comment. Clearly the DataGrid and the AdvancedDataGrid are non-trivial components that take A LOT of work to create (and even more work to create right). It’s much easier for me to bitch about the shittiness of others components than put my money where my mouth is and write good alternatives myself 🙂 I’ll be the first to admit that.
Flex 4 will indeed not contain any updates to DataGrid, Tree, or AdvancedDataGrid. I have been thinking about trying to organize a community effort to plan out new versions of some of these (with the architecture inline with the new Gumbo plans). Again, this is a large undertaking, and it’s much easier for me to rail on bad implementations that try to create a good implementation. But I do hope that within the next 6 months we start a community project to address the DG/Tree/ADG issues, even if that only means creating a spec and guidelines for HOW we want the components to work.
That sounds like a great start. I think part of the bloatedness of the existing components is due to the fact that there are some many different ways to customize it (item renderers, editors, renderer providers, etc).
I think a simpler version that performed better would serve the needs of a huge population of developers. I would definitely be interested in contributing to this.
Too be honest i am a bit releaved. Imagine if the code was great and still was this slow. Looking at the bright side, this means Flex has a lot of potential!
Dude, Nick just came out with a new light weight datagrid last week, http://www.elfgrid.com! He took it from 70k to 7k. It’s commercial but he’s one of the best coders I know. You can request a trial so you can test it out.
Now that the Flex SDK is open source we should be able to verify that the code going in to the next datagrid is going to be of high quality or upgrade it ourselves right?
BTW I don’t think the line count argument is fair. I wondered why the UIComponent had a lot of code I never thought I’d use, until I used it. For example, I was reading through the class and found “repeaterItem”. I didn’t know what that was until I read it and now I am using it in a few of my projects. It’s been a life saver.
But what about run time behavior injection? That would keep your class small but still let you add features as you need it. So in regards to your line count argument they could slim things down this way. For example, you could create a light weight datagrid and if you need drag and drop or you need life cycle data services then you can add that behavior in if you need it via runtime behavior injection.
I have hated the AdvancedDataGrid since the day I saw it. Buggy and bloated. Glad I’m not the only person that thinks that!
And if you want to see how those “fat” classes contribute to the size of compiled SWF, take a look at this one: http://www.kahunaburger.com/2008/03/08/air-link-report-visualizer/
Did you see the dependency graph I plotted for the Flex 2 frameworks “Hello World”?
This is one of the reasons why I created “-link-report”, the Modules system, encouraged the increased adoption of interfaces to eliminate unnecessary dependencies, and ensured that it was always possible to build pure AS3-based Flex apps that were utterly and completely Frameworks-free. 😉
To be fair to my former colleagues on the Frameworks team, they’re the victims of trying to create a system that’s a bit too helpful without any extra work for the developer. I believe that a lot of the bloat is due to crosscutting concerns (i.e. layout, automation, validation, etc) that should probably be refactored into some sort of aspect mixin structure. That’s a pretty huge project, though. I wouldn’t hold my breath!
Here are my thoughts are on making the Flex classes better in general by looking at some of the AdvancedDataGrid. I did this since I chirped about too. These are things that the Flex team could consider during development as they make improvements.
Keeping in the spirit of the AdvancedDataGrid..
1. Big class (actual code) sometimes means it’s trying to be or do too many things. This is why you get objects that sometimes include terms like “Advanced”, “Utility”, or “And”.. This generally leaves your code less cohesive then it could be and usually harder to follow.
2. Big methods = usually means it’s doing too many things. (Google Bob Martin’s Single Responsibility Principle or read the book “clean code”). Consider the method “applyUserStylesForItemRenderer(givenItemRenderer:IListItemRenderer)” that has four comments in the form of “steps 0-3” and an extra comment in step 3 to be clear that the developer new what was going on. I would use the refactoring technique “Extract Method” that most IDE’s support to move those things out of there. Which leads me to the next point..
3. Instead of inserting many times half truth comments everywhere use descriptive methods instead that do one thing. An example would be to take the step 3 comment and code (described in my point above) and replace it with the following getAndSetColumnStyle().. While we’re there we could do the same with the other steps.
4. It’s quite possible that this class wasn’t developed from a TDD perspective.. So there’s many places where if you were to refactor it you’d probably find that many of the things being instantiated inside the methods would be extracted out and made into instance variables. This would lead you to see that it’s possible that the class is trying to be too many things and since they are extracted out of the methods and into the class they could be refactored out of the class into a different class.
5. Cut down on the cyclomatic complexity.. Too many if conditions and nested conditions.. Use polymorphic transformation when possible. Refer to drawVerticalLine(s:Sprite, colIndex:int, color:uint, x:Number)
6. Misleading method names “getWidthOfItem”.. seems to have side effects.. The helpful method comment boldly states that it does more than one thing.. Here it is:
/**
* @private
* This grid just returns the column size,
* but could handle column spanning.
*/
7. Remove side effects from methods
8. Reduce the number of parameters that go into a method. Methods with more than 1 input argument are more confusing and take more time to understand and work with. The less the better.
9. I stopped about 1/3 the way down.. Don’t want to bore you guys any more.. 🙂
Thanks for the post. I have been shying away from Flex, though I use builder to write my AS3 files since I don’t expect to ever see an eclipse plug-in like ASDT for AS3. I only used Flash components long enough to realize how bloated my .swfs became when I used them. So when the Flex Framework came around, it seemed like complete idiocy. An entire development platform built on the back of non-specific, bloated components. What scares me is when I ask questions like: “if UIComponent is as bloated as it is, what about MovieClip?” I know I have to draw the line somewhere, so I try to forget I asked as I continue to create my own video player, combo box and radio button classes from scratch compiling my swfs with the Flash IDE. I know that general users have more bandwidth these days, but my clients still have to pay their providers for bandwidth overages. Requiring a 400k library must be Adobe’s way of saying they don’t care about my clients.
I don’t see how those above suggesting the breaking of Single Responsability Principle here really applies to such frameworks as this. Yeah, maybe SRP works for business rule validation. But personally, I’d rather have one BIG framework class that’s easy to search through, than having UIComponent broken up into 200 files…imagine trying to figure out what’s going on then.
Seriously, though, how big is the AdvancedDataControl when compiled? 32KB?
I’ve yet to see staunch advocates of TDD and SRP really deliver a system people wanted to work on and maintain. “What do you mean, I have to rewrite 10,000,000 lines of unit tests?”
I think its a whole lot easier to be critical of specific lines of code in hindsight. Sure, things can always be written better. But there are deliverable dates to be met. I’d really like to see what BJ’s refactored ADG code looks like. Somehow, I doubt it’ll be any less of a mess than what we have now, instead of linguine, it’d be fettuccine.
My coworker recently added a component to our project that used mx:List. Our filesize went up by about 26k.
I replaced the list with a repeater and it went back down.
I know that on its own, 26k isn’t that much. But we’re using Flex here, so that difference was pumping our app up from 402k to 428k. It’s already too big, in my opinion.
I really agree with BJ Allmon and Roger Gonzalez – a mixin structure would be really useful and save a LOT of headache and file size, and refactoring the code the way BJ suggests would make that whole thing easier AND make the components easier to use and customize. There are few things about Flex more disappointing than wanting to change a detail of some method and discovering a 200 line method with the detail buried two levels deep in conditionals.
Seriously, why do all components need to know how their appearance changes when they don’t pass validation? Why do we have to deduce how a container is going to be laid out by looking at explicit dimensions and checking to see if percent dimensions are NaN? Why does setting minimum dimensions prevent containers sized relative to their parent from forcing the parent to expand?
Most annoyingly, why were the CSS attributes allowed in mxml explicitly tied to the aesthetic decisions of the Halo theme?
Sometimes I feel like it would benefit us to roll our own version of the framework that is completely gutted of all the stuff we won’t use. We’d probably shave out half the file size by eliminating the parts of the Halo theme we’re not using along with a bunch of other stuff…
First, I completely agree with all concerns expressed around AdvancedDataGrid and on our project, we sort of stuck in “ADG doesn’t work, now what?” phase, after repeated attempts to make it work, it’s proving futile…
How about follow-up article to discuss alternatives to ADG?
Also, to all the bloated code “haters”, and Flex “haters”. Yes, SWFs are big, but that just means it’s more suitable for running in Complex Air applications, not page-embedded little things!
Todd – I try to refactor code in a way so that it doesn’t resemble any form of pasta. 🙂
Hey Paul, you could be using Flex (minus the frameworks) to build your app. It would be a better coding environment, in my opinion.
Just base your app on Sprite (or preferably, SimpleApplication) in as3, and go to town!
See http://www.insideria.com/2009/03/custom-edit-renderers-for-the.html
“As a very general word of warning, I’d advise you to be more careful and expect more pain when working with the following classes (and all associated base classes, etc): AdvancedDataGrid, OLAPDataGrid, GroupingCollection.
I’ll try to be extremely politically correct here, but I assume you’ll catch my drift… These classes were written by a different part of the Flex team, in a different part of the world, and they are quite different than the standard Flex framework code base. They often don’t follow the same coding standards, and in my opinion they are not up to the same quality level that I have come to expect from the Flex framework. I’ll stop at that before I make too many Adobeans mad at me, but just know that I’ve learned to expect a whole new kind of pain when working with those classes.”
ADG rules only bug I found was mouse scrolling when using summary and icon functions together
Everyone has made some great points and definitely valid, however, I just started using the ADG in a more intensive context and so far have not encountered any real issues.
The an HTPPService calls a PHP file that pulls data from a MySQL DB, converts it into XML and sends it to the ADG as an XMLListCollection (converted into HierarchicalData).
The first column has a tree, and the second column utilizes a custom itemrenderer that shows two checkboxes in the same row. The parent and child checkboxes are linked (so if you select a parent checkbox, all child checkboxes are checked and vice-versa). Also, the first checkbox in the row is linked to the second checkbox in the same row and only enables the second checkbox if the first one is selected. The same parent-to-child checkbox relationship then applies to all the second checkboxes.
So far, no problems at all.
I’m wondering if I’m missing something, or should be watching out for something in particular?
Where is everyone hitting a wall with the ADG mainly?
To replace one AGD you need a Tree plus a DataGrid.
The size of the AdvancedDatagrid=5385
On the other hand:
Tree=2078
DataGrid=3149
——————–
TOTAL=5227
Very similar. Why AdvancedDatagrid sucks? Do you prefer integrate manually a Tree and a DataGrid? then = 5227+your effort.
Do you want to manually add keyboard and sorting support to the Tree? Then= 5227+your effort+your extra effort -> I think yours sucks!
I’ve replaced a Tree by an ADG and ADG is better. Better performance, better functionality and I’ve replaced it with no cost (less 1 hour). Where is the difficult?
If you want “bloat” you should take a look at the Flex 4 SDK, any hopes of Adobe improving things have been thrown out of the window. I created a new Flex project and dropped a Button, CheckBox, ComboBox, and TextInput onto the stage and that alone generated a 1.06 MB SWF file.
Not only is the Flex framework seriously bloated it is also extremely slow and CPU heavy. The framework is a great idea and some nice features have been implemented, but Adobe seem to be screwing it up along with the Flex/Flash API. I pray things change over the next year or Adobe could end up killing Flex and the Flash Player.
Sometimes it’s really that simple, isn’t it? I feel a little stupid for not thinking of this myself/earlier, though.
I think the TweenLite project is a good example of responsible coding. It starts small, and the more feature you require you simply add the plugin. Adobe should take this approach to avoid bloated, slow components. I stopped using Adobe components almost immediately seeing a drastic performance difference between the DataGrid, and my own coded classes to perform the behaviors I needed in a DataGrid.
Just wanted to post this 🙂
http://blogs.adobe.com/flex/archives/2009/08/status_of_flex_data_visualizat.html
Seems like no one is listening … better styling hardly takes precedence over reliability … Hello, anyone there!!!
Pingback: Symmetri Developer Blog :: Flex AdvancedDataGrid issues and code quality :: September :: 2009
Pingback: Flex Pasta » Flex 5: AdvancedDataGrid
Hey Doug, just thought I’d share this: My buddy Jon Toland wrote a Javascript parser to run through AS and MXML files and count blank lines, comment lines, and actual code lines. Since it’s in Javascript, you have to paste in the source, but it’s handy to if you want to calculate one of these metrics quickly. Here’s the link: http://dnalot.com/SparkDataGrids/clocFx.html
Great article, i fully agree with your arguments. it also costs me some nightmares to work with the ADG, and the code quality is really beyond the other SDK quality. I hope Adobe take some effort to improve the architecture to break it down to smaller parts organizes by the features needed. there are different aproaches how to add functionality on demand and not to build all into one big thing, that is nothing new in software development. And if performance (method calls are slow in flash) was a reason why they use 400 lines methods instead of breaking them into parts, then please Adobe use some compiler optimisation strategies like haxe or joa ebert (http://blog.joa-ebert.com/) are working on. Flash and specially Flex would have so much hidden potential which is wasted…. For big projects its really a high risk that companies return to .net or java after a poor experience with flex regarding performance.
This is how I feel about OSMF. Adobe needs programmers who can write less code more beautifully. Too much commenting, too many features, and too much abstraction make their packages bloated & painful to use. Pisses me off really
“hmmm says:
February 8th, 2009 at 7:42 pm
Almost as though it was written by… an entirely separate team?”
Winner – IIRC supposedly it was outsourced to some developers in India based on a comment I read where someone (from Adobe) also mentioned that ADG “has problems”. Different team indeed – one wonders if they even spoke with the primary team (assuming they could communicate effectively).
Doug,
While the ADG is not the most elegant piece of code to come out of Adobe, it certainly is among the most functionally rich. It does many things very well, and it provides ways to extend it to do quite a few things you would need to. That said, just like any other off the shelf component, there are some features that I wish it had, that it does not, for example, it cannnot display nested datagrids very well. It was not designed to work in that scenario, and it will cause you all kinds of pain if you try to make it do something that the architechts did not envision.
Now – just a little perspective for you and those who agree with you, take it or leave it. I have read quite a few people b* and moan about the ADG and the part of the Adobe team that made it. What I have not seen, is anyone actually roll up their sleeves and write a replacement, or close to it.
Whining and complaining about not having everything just the way you like it did not get anyone anywhere. It makes us angrier, less productive, and further behind our rapidly advancing competition. We live in a smaller world, which has readily accepted our exported ideals of capitalism and free trade, and Doug, what goes around comes around.