But they don't. Feel native, that is. Scrolling with the scroll wheel is horribly broken in Mockingbird. It does not work like a native control.

It's the details that get you. Sure, look doesn't matter (as long as UI "symbols" are not changed), but behaviour does. Where can I click the scrollbar? What happens when I click where? How fast does it scroll? And so on, and so on. Recreating the native experience is a horrible excercise and you will get yourself killed by thousands of small details you didn't even think of.

Besides the mouse scroll wheel hack (which is only necessary for Macs if memory serves), what other limitations did you need to circumvent in order to address scrolling in Flash? I've built more than my fair share of scrollbars over the years in Flash, and the JS-mouse wheel-mac hack is the only hack I've needed. I can imagine that building a custom scroll component in Flash would be easier to do, and the code would be far more clean, than implementing in JS. Am I wrong?

I had problems with clicking on the track to jump the scroller to a given position. Also, I find that the memory resources used by Flash when the scroller contains a lot of objects is unacceptably high resulting in slow scrolling; therefore I had to waste time doing some funky lazy-loading stuff also.

I would say that implementing custom scroller in JS is far easier (and reliable) that Flash. And there are plenty of frameworks (ahem Cappuccino) where such controls are included.

But scrollers are just one example of the UI controls the article talks about :)

Not to besmirch your AS coding abilities, nor to reopen old wounds, but the dev in me is begging some questions and debugging your comment. Your first issue seems like it was likely caused by using an incorrect ratio of viewable content to viewport height. I can't say I've ever seen the Flash player give erroneous info as to where the mouse was positioned, and Flash's Number type is accurate enough for this type of operation.

The second issue seems more likely to have been an issue with processor load rather than a memory, I'm guessing? I usually solve the issue with using TextField's cacheAsBitmap property. It uses more memory, at the expense of greater processor load. I develop on a low-powered Mac, and have never been disappointed by the tradeoff, but YMMV. Sometimes, playing with the AntiAliasMode of the TextField has unexpectedly good results (processor-wise), but I admit it's very fiddly :)

Completely agree on the framework front; Abobe's attempts to solve UI issues in Flash have lead to an even more fractured dev response. Cappuccino's UI looks extremely clean, and seem to function remarkably well, without sacrificing so much on the filesize/response vectors.

Again, just geeking out; I've been (and continue to be) in that position more times than I'd like to count in developing for Flash. Thanks for the great comment :)

When you write desktop apps, you have to do the same thing - usually (lazy loading). I'm not defending flash, I'm just saying.

When I used to do Win32 programming, I'd usually cache a bitmap and scroll that. For larger stuff though, lazy loading all the way.

I agree also. Francisco clearly has a vested interest in this opinion, and like you say he's absolutely right about implementation making the difference.

I have given a Cappuccino app to people to use, and they didn't even realise there was a difference from the native controls (after the widgets rendered - which DID throw them).

Even though I fundamentally agree that re-implementing UIs from scratch is not optimal, Cappuccino had a valid reason for doing so, and its implementation doesn't harm usability.

With the current 'jake' branch and its' imminent merging into master, the framework resources are sprited meaning they all load in one http request (rather than many). This eliminates the fragmented loading of the UI, which, I agree, can throw people at first!