In a sense that list isn’t of different kinds of applications, but of different kinds of UI libraries, with the classification of applications being a mapping “the kind of application which needs the X kind of UI library”.
That’s fair. Let’s say I’ve classified applications by their requirements.
Could you say a bit more (you’ve mentioned a bit w.r.t. browsers and games) what the characteristics of the applications themselves are which lead to them having different requirements of their UI libraries?
I think applications in class 1 either only target one platform, or have enough resources to write custom UIs for each platform they target and deem it worth doing so to get the very best results. E.g. the applications OS vendors write for their own platforms.
Applications in class 2 are generally reasonably simple, or the complex parts can be factored out and handled some other way (e.g. writing per-platform UI in some places). They generally don’t require customizing UI components in deep ways (difficult to do portably). Lots of undemanding business applications in this category.
Applications in class 3 include browsers and other applications that need very precise control and customization of UI components. For example browsers need to implement CSS layout and theming, the DOM event model, the complex CSS rendering model, features like spellcheck, handle absurd numbers of form controls on a page without crashing, etc etc. A very long time ago all browser engines used actual native form widgets but they all transitioned to reimplementing everything because it was the only way to make things work (even browser engines like Webkit and IE that really only cared about one platform initially!). I guess applications also fit into this category if they want Write Once Run Anywhere and a broad feature set without doing a whole lot of work — by reusing an existing solution.
I think category 4 includes a lot of games because they tend to have limited UI needs; consistency with the underlying platform is not seen as an issue; performance is really important (and historically platform GUI toolkits have interacted poorly with high-performance graphics output); they don’t need to interface much with other applications in the platform; and the UI needs of games don’t generally evolve much over the maintenance lifespan of the game.
