Looking at WPF and JavaFX, thinking on SWT

Definitely, 2D primitives exist everywhere, so scene composed from 2D primitives can be rendered on any platform you can imagine (including your printer firmware). Rendering subsystem can also adapt rendering parameters to concrete platform capabilities (such as mobile phone, fridge screen, or high-end desktop box). For slow CPUs renderer may disable antialiasing, choose faster algorithms with worse result, replace gradient fills with solid fills, discard opacity, etc. Such adaptation can be very dynamic, depending on your *current* CPU load. If we'll have EMF (or something else)-based UI model in memory - we do not bother with any "UI thread" issues, flickering, etc - Rendering thread is just repainting our UI scene as fast as it can (showing FPS counter in top-right corner :))... So if your button floating off the screen very fast (with some animation effect) and on slow CPU - that's OK, end-user will just miss effect but will not wait hundreeds of repaintings until message queue fully processed. OK, I'll stop for this moment, since the time that I started to think more about all this stuff things become more interesting.

OK, point #1: If I understand SWT main goal right, SWT's main purpose is to run fast enough on supported platforms (comparing to Swing). After 9 years (I do not know exact SWT age) we have no such problems. Canvas is much portable and fast enough.

So we'll have almost the same look-and-feel on all platforms (depending on their capabilities in terms of canvas size, color schemes, input devices, and computing resources available). This approach looks to be more visually cross-platform comparing to SWT (just run Eclipse on Motif to ensure). Technically, SWT runs on all platforms where Java exists. Canvas is the same - you may find it everywhere.

As for web, of course you can expose such 2D-based UIs with web-brower using Java, SVG, Flash, WPF/E, and other capable runtimes (I mean runtimes which can render 2D graphics fast)... But I think you are wondering about exposing this UIs to non-capable runtime, such as HTML document (assuming there are no capable runtimes embedded). The answer is clearly NO. From my perspective exposing something like SWT GUI to AJAX can not be named "cross-platform". This is something I'd like to name "trans-platform".

Folks, let's look from another perspective: projects, which try to expose traditional desktop UIs to the Web exist since Web became popular (90yy). I remember that there was 4-letter acronym Apache project targeted to this goal, tens of projects from universities, and works of hobbyists exposing AWT controls as HTML forms. I remember demos of UI forms developed in early Delphi 2.0 and exposed to the web, etc. They all did not succeed (is anyone know popular website developed with such technology before AJAX?).

With XMLHttpRequest flaw discovery and after AJAX invented it's possible to expose desktop UIs to the Web better. For example CodeGear implemented VCL (which is BTW the best UI library I saw in 90yy) with AJAX, and developed "Delphi for PHP". After product unveiled, I suppose there was a lot of smiles on engineers' faces  regarding such strange mix of technologies. Do you know any website developed in "Dephi for PHP"? Or have you even heard about this product? So you can understand how popular it is. But... "Delphi for PHP" is conceptually identical to Eclipse RAP. Technically I'm impressed with Eclipse RAP. RAP did a tremendous and *valuable* job in that domain. A great value of RAP that I can expose existing RCP apps to the web very fast. That's exciting...

However, I will not choose neither "Delphi for PHP" nor Eclipse RAP for my new project. The reason is simple: "I do not want my application to behave similar on the web and on the desktop. I remember all those universal UI projects telling: "we'll render your UI to environment of any type". My answer is: "please do not render my UI to any environment"... cause they're too different. And I love my UI look-and-feel, and I want the natural fit of my UI into target environment.

Starting with interface design I have different goals in mind. Some basic things: I will fit my UI on the desktop (which is limited area, so I'm layouting application appropriately). To the contrary I want to see my web-based application to look more like printed document - I do not want to see scrollbars everywhere and other stuff like that. I will use screen flow (perspective switch extensively). When I open a browser I have no the intention to spend hours in editor view, but to surf though my data and information with a comfort. I believe (but I have not tried yet :)) if you ask experienced UI designer to develop and interface for your web-based app (say bug-tracker) and ask another one to design UI for your desktop bug-tracker - you'll see very different results.

There is nothing about technical possibilities and limitations, it's all about how people feel and sense different enviroments (either web, desktop and mobile). Personally I think unified, trans-platform UI frameworks is just a misidentification. I do not talk about MDA, there are a lot of senses transforming UI models to implementations, which are relevant to target environments, but there is no sense in developing my UI logics on top of unified interface (SWT+).

OK, point #2: Great engineers built Eclipse, it's comparable to art to see tens of layers within eclipse, how they're communicate, and how I can plug into any layer and expose new higher-level functionality to the outer world. It's really about software genesis (I can't say development, as eclipse is more than development). When it comes to UI, as Eclipse consumer I'd like to see the same picture - correct abstractions and well-designed layers. SWT is true cross-platform (it supports all the OSes where Java runs). SWT + RAP approach is to make it trans-platform. That's defenitely sounds cool, but I'm afraid it may be misidentificated target.