Is there a trend for cross-platform GUI toolkits? [closed]

Question

What is the trend like for the usage of cross-platform GUI frameworks right now? Are more people starting to use cross-platform frameworks (such as GTK+, Qt and wxWidgets) or are there more who use more platform-tied frameworks (e.g. Cocoa or WPF)? Is it more or less stagnant? Is it like a rollercoaster? What do you think the trend will be like, say, 5 years from now?

The OS landscape is shifting with less people using Windows (personal observation). This should increase the demand for cross-platform toolkits, shouldn't it?

Edit: Also, which (cross-platform) toolkits are growing the most, if so?

Answer 1

It almost seems like there's a trend against cross-platform kits. If people want to write once, run anywhere, they tend to use HTML - make a web site. People are only using the platform toolkits when a native look and feel is highly demanded, for example on the iPhone. So if the whole reason you're bothering with the non-web app is to get native look and feel, it doesn't make a ton of sense to use a cross-platform kit.

Cross-platform toolkits have never worked all that well; the desktop platforms are not so similar, and it's hard to truly abstract them away. Adding phones and tablets to the mix makes it even harder. You end up with a very leaky abstraction (see http://www.joelonsoftware.com/articles/LeakyAbstractions.html). Often it's easier to just nicely separate your "engine" from your UI, and write the UI separately per-platform.

The trend for Mac to be more popular might make cross-platform kits less popular rather than more. I think often people used a cross-platform kit more to theoretically check the cross-platform checkbox than to get genuinely good results on all platforms. Once you actually care about multiple platforms... you start to see how cross-platform kits have downsides.

Here's a blog post from Alex Payne on those downsides: http://al3x.net/2011/01/15/user-hostile-platforms.html

I think it's telling that many of the large, popular cross-platform apps invent their own cross-platform approach (Firefox, Chrome, Eclipse, OpenOffice.org are examples that come to mind). By owning the framework they can punch down through the abstraction when required. Also these apps have all tended to look the same (and not especially native) on all platforms.

All this said, I don't have actual stats or anything. But I have done a lot of work on GTK+, and have some familiarity with codebases including Firefox, Chrome, and Eclipse. So I've seen the technical challenges here firsthand.

Answer 2

As a matter of fact there has been a trend towards a cross-platform UI toolkit in the recent years. That toolkit is HTML/CSS/JavaScript.

It's just sooo simpler to develop once and seen it run almost identically everywhere.

And yes, developments are massively moving away from desktop into the web. You see it yourself.

Answer 3

I tend to use cross-platform toolkits because they have better design, not because I'm trying to be cross-platform. For example, I work on projects written in C++ targeting the Windows platform only. Do I use win32 or MFC, pretty much the ONLY options available for native toolkit?

Holy fsck no! They're pretty much the worst heaps of spaghetti garbage I've ever seen! The direct coupling of the event system to the underlying OS's "messages" system is incredibly unintuitive and lacks expressiveness necessary to rapidly create UI programs. Higher level abstractions, currently only provided by cross-platform toolkits, are absolutely essential to the task.

That's just one example too. I could rattle on and on the list of things that are better done by cross-platform toolkits. The fact is that graphical interfaces are more similar to each other than distinct. There's very little different between a window program on Windows vs. one on Linux for example. The kinds of things that you do when making UI programs are almost always exactly the same no matter what OS you're targeting...and only minor differences between architectures like phone/palm vs. desktop. The field has simply focused on cross-platform methodologies because a) it's necessary for a lot of people and b) it's all the same sh!t.

Answer 4

One argument against producing a cross-platform framework is that it will always be targeted at the lowest common denominator - clients of the framework want to write code just once and it run 'everywhere' supported. So one awesome hardware platform would just look like any other platform that runs that framework as you can't leverage the platform-specific features.

Over time, this unfortunately results in frameworks leaning towards their most popular platform and hacking together support for the other platforms, or just lopping them off when the budget/popularity runs out.

One way to capitalise on the platform-specific abilities is to have something like a #if PLATFORM_FEATURE_X construct around all the specific code or equivalent runtime checks which results in code bloat. This gets tedious pretty quickly, as variants of the same platform will need specific handling. For example, some XBox v1's had no hard drive, so games using cross-platform tools couldn't use it for caching, compared to a PC version that where you can guarantee a hard drive.

For Desktop/Productivity applications, platform look-and-feel seems to be important, but many applications have their own style so its' no problem to look the same on all platforms, e.g. apps built with AIR.

Hardware vendors like Apple, Sony, Nintendo and Toshiba will want to ensure that their products do something to differentiate themselves from the competition, e.g. Touch, Accelerometers/Gryoscopes, Blu-Ray, 3D display. It's unlikely there'll ever be a platform with all the features of all the competitors rolled into one (due to cost and complexity), so one will win out.