I couldn't agree more with Francisco's comments - it's not native controls that users want, it's controls that feel "native". As someone who used to work extensively on an enterprise app in Flash, I can say first hand that users just expect certain behavior from the UI controls.

I have had to implement countless hacks to circumvent the (many) limitations of Flash; like getting the mouse scroll wheel to work in a scroll view. Once users realize the control conforms to certain usability and accessibility expectations, they are far more appreciative of the app design.

Cappuccino provides a perfect compromise, with controls that look consistent across platforms, but behave predictably, like so-called native controls.

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!

It really comes down to whether you view HTML/Javascript as source code or object code.

If HTML&JS is source code, you ought to keep it clean and minimal. You're betting that browsers will evolve to include desktop widgets and other aspects of the "native" experience in HTML tags and Javascript APIs.

If HTML&JS is object code, you're rooting for abstractions over HTML and Javascript, so that HTML/JS becomes assembly language.

I don't mind the extra abstraction. But it's unfortunate that we're adding so many layers of abstraction over a system that wasn't really designed to be used that way.

I'm curious as to why you feel it's unfortunate to add so many layers of abstraction over the system. Besides the "All abstractions are leaky abstractions" argument, is there any other reason you feel like this is a bad thing? Or is it ruffling your engineering feathers?

Primarily because it's an inefficient abstraction.

Yeah, Moore's Law and all that. But still.

It's a little early to tell for sure, but it might well be A Great Thing for JS+HTML/CSS to become the assembly language of the web. If Javascript engines get faster, and CPU speeds keep slowly inching up (looks like Moore's Law has temporarily been repealed ;-), and things like Web Workers become commonplace, ...

Good post, but I wish it addressed the accessibility argument a bit more thoroughly. Although in fairness, it does not seem that Mockingbird is terribly useful for visually-disabled users in any case.

I've been tempted to use (the impressive) Cappuccino for a couple of apps but based on its lack of keyboard tab focus and performance on slower systems I decided against using it. I like to build simple, accessible apps.

Somebody--Sofa I think--was using it for back-end administration while presenting a more typical interface to public users, and that may be a better approach.

Perhaps you should check out NOLOH, http://www.noloh.com. It's similar to Cappuccino in some ways, yet very different in others. For instance, NOLOH is lightweight and on-demand. It also fails gracefully when JS is disabled in most cases, and is faster overall (this is based on our internal testing. Not trying to start a war). Notice how noloh.com loads instantly without any loading, or delay.

NOLOH also works with tab focus, and is more accessibility friendly. You can read more about our accessibility features at https://www.noloh.com/#/faqs/. We'll be posting major updates to HN in the next week or two, we last posted around a year ago, in case you haven't heard of us.

I don't understand why qooxdoo http://qooxdoo.org/ doesn't get more attention. It's not as pretty as cappuccino, sure, but it seems a very nice set of tools.

What I find strange is that people have a tendency to compare Cappuccino to flash, way more then other web frameworks, and what that means.

What does command+clicking in the track do? It works the same way as just clicking for me, unless I'm missing something.

I think the author meant "option+clicking", which causes the scrollbar to jump to the precise location of the click (rather than a simple page-up/page-down, which is what it usually does on click).

Not sure what they mean, but if you give another window focus, you can Command+Drag the scroll bar, and the window won't receive focus.

Here only alt+clicking does something different, on tiger.