The Flash Art of War

This is a really really sad day but I am declaring FDT 3 DOA. I have been patiently trying to run the updated Mac version on a vanilla build of Eclipse with no other plugins and it has not been fun. I have prepared a few screen shots and specific instances where FDT is still letting me down and I can’t continue to use it in my production environment. Here is the deal:

Apparently my post about FlexBuilder 3 vs FDT 3 gained a little attention and I was contacted by a Product Manager for FDT to encourage me to continue to retest the new Mac update. I have to say they did an excellent job and at first FDT 3 was noticeably faster. I began testing it when I started doing documentation for my Sumo Framework on my plane ride to/from Ft. Lauderdale. In a single project and out of the box clean install everything was working great. It wasn’t until I returned to work on Monday, dedicated to run FDT through its paces, and I run into the same issues that have always plague FDT 3 since I tested the public beta.

When you start working in a project containing a shared (linked) library with a complex Framework under a solid layer of application logic FDT starts to choke again. Rebuilding workspace, slowdowns with error checking and subtle annoyances began popping up almost immediately. I thought this was just me but Flex Builder 3 runs silky smooth with the same code. Here are some screen shots of the strange things I started to see.

This is my workspace with 2 projects open, 1 is a CBS Video Player and the other is my Sumo Framework. This simple set up started choking FDT and it was having problems keeping up with my code edits throughout the day.

To most people this isn’t a big deal but I hate when the error highlight can’t figure out what to correctly underline as the problem.

This one is even worse. My color hinting is off. This happen a lot when I am adding strings and the lines below can’t auto correct their colors. Even when I save it takes a few seconds for it to correct itself or it just stays messed up until I close out and reopen the class.

Next up are the little details that show the “home grown-ness” of FDT 3. One of the features I was happy to get back was Templates. I really hate not having them in FlexBuilder and whoever over at Adobe that decided to leave them out made a big mistake. Its the single most helpful native feature of Eclipse. In FDT the template I used the most is systrace, if you are not familiar with it when you type this shortcut and call up the code hinting FDT creates a new trace action with the name of the function and any properties that are passed into it. I can’t tell you how helpful this is but for some reason in FDT 3 there is a problem. In AS 2 this template works fine, but in AS 3 its doesn’t. When I went to look at the templates this is what I saw:

I have highlighted the AS 2 template and take a look at the output in the preview - this is correct.

Now look at the AS 3 template and notice the output is just a generic trace.

I can’t believe this is still wrong from the beta. I really hate to rip into FDT like this over something trivial but this isn’t an open source app; FDT 3 is a $519.22 (Basic) - $1,040.19 (Enterprise) application. I expect a lot more for my money. This brings me back to what I have learned from using FlexBuilder 3 and I still hold on to my views in my original post about FlexBuilder 3 vs FDT 3.

At the end of the day I need a super fast and lightweight editor. Eclipse is a monster app to begin with so what ever sits on top of it has to be very optimized and make me efficient. FDT 3 still can’t keep up with me. I type fast, link lots of classes together and build very large and complex apps. I can’t keep waiting for the workspace to refresh itself after I type something in. If FDT would just drop the “real time” error checking and only do it when a user saves like it does in FlexBuilder it would be a lot more usable. FDT as an editor and its features beat FlexBuilder hands down and I found myself really missing all of the cool things FDT has to offer. I really want FDT to work and that is probably why I made it through about 3 solid days of small to large issues, but speed is a real concern and I just can’t accept a slow, buggy editor.

I did notice one subtle detail in the error checking that really puts FlexBuilder on top. When I moved over to FDT I had insane amounts of errors then I had in FlexBuilder. I thought maybe I set FDT’s error parser to strict but it was at the default value. It was then that I realized that FlexBuilder only error checks Classes used in your app. FDT look at any class you had in the “src” directory. I often keep a lot of partially completed or sketches of classes laying around my app as I organize, refactor, and cleanup my code. Its silly that I am getting double penalized by FDT for incomplete classes never used in the compile. FDT should ignore them as well to keep the parser running faster and also keep me from going insane when I see 100+ error in classes that aren’t being used. What happens is that I start to ignore the problems panel in FDT and never see the real problems until I am in the class or the compiler throws me an error.

I only have 1 error in FlexBuilder (Ironically I can’t seem to fix it but the app still compiles).

Here I have 118 errors all found in 4 classes that I am not even using in my application.

I am going to keep playing with FDT and seeing if the problem is me or just the application. I will continue to let you know what I find but as far as my day to day editor goes FlexBuilder is the winner. Sorry Power Flashers, I am really looking forward to FDT 4. Hopefully you can fix my performance concerns. If anyone else is torn give FDT a try, I hear its great on the PC but then again I heard amazing things about FlashDevelop and that app is free. Heavy is the only company I have not used FDT at¹ so this round all my developers have FlexBuilder 3 licenses.

1. New York Jets, Deep Focus, AKQA, and MLB all use/d FDT [↩]

Bookmark It