SWT's road to 'super-portability'

| | Comments (0) | TrackBacks (1)

Jochen Krause from RAP disagreed: "In essence that is the Swing vs. SWT discussion again, and this has been discussed for ages. There is more to this discussion than performance. I agree that SWT needs more *sexy* animations, but this can be (and is being) adressed without moving away from native widgets. New platforms like WPF and AIR offer new capabilities that we can take advantage of."

Actually identical look does not matter. Fact that only matter is "SWT is a redundant technology".

I'm telling about L&F in terms of cross-platforming: I won't recall SWT vs. Swing discussion; I just wanted to state some facts, making me think on SWT as on redundant technology:

  • It's harder to look identical of you do not control all the aspects of rendering (e.g. delegate some parts of the process to outer world like SWT does to underlying OS UI layer).
  • It's easier to stay cross-platform with 2D-approach: this approach supported on all the platforms where Java runs with zero efforts.
  • There are no performance issues anymore. Now it's hard to argue why we need SWT from performance perspective.
  • Native OS components are deprecating. WPF already render .NET objects to DirectX canvas. At which layer of "supported" enviroments will SWT map (or render). Which layer of "supported" environment custom SWT components will use for rendering 2D primitives? Do you have an example how custom SWT component will be rendered to WPF and to AJAX? If WPF styling/templating if going to be supported, how do you going to support cross-platform look and feel (e.g. same look on Linux/GTK for WPF-styled component)?

I do not want to say we shall replace SWT with something, initially I was asking for SWT plans to understand concepts behind SWT for next say 10 years. Just like every eclipse user understanding past challenges (performance, better OS integration) and all we know the great SWT response to those challenges during past 10 years...

Regarding different approaches in UIs for web and desktop applications Jochen disagees as well: "because that strong split between browser and desktop will very likely vanish. And there is no problem in driving a Silverlight client from RAP. E4 is about offering more choice, so if you don't like "widget-based" (SWT / RAP) style web applications, you simply go and use what you like and attach it to the workbench backend."

I'd like to enforce his prediction and would like to say that split between browser and desktop already vanished. I'd like to focuse on desktop-capable runtimes and non-capable ones (I can formalize my understanding of desktop capabilities, but let's continue intuitively for now :)

I have no contras to run my desktop-oriented UI in browser with Silverlight (WPF/E), Java, or Flash VM runtimes. Moreover I would like to argue that we shall desktop-oriented applications in these (desktop-oriented) environments, but... I'm contrary to transposing my desktop application to unnatural environment (HTML + AJAX + embedded flash, WPF, applets or whatever else). I like "component-based" style of applications (actually, I do not know any alternatives to this style yet - Scene decomposition down to 2D primitives will not eliminate composition techniques).

But if we'll forget about marketing efforts, technology distribution across the world, etc and will ask ourselves as an engineers: "what is the great idea behind all that AJAX stuff?". The answer is nothing. If you remember AJAX history Internet Explorer was hacked by Google. They discovered they can query server from JavaScript using XmlHttpResponse object. Based on this knowledge Googlers added "code assistance" feature to their Search EditBox, which was excited millions and millions people around the world. That was a Great Hack, adding new capabilities to the environment (DHTML) which were not existed before. In other words they have learned how to force webbrowser to work as ANSI terminal or DOS application, just querying server and changing content appropriately [far from conceptual revolution, is not it?]. During next years all the AJAX companies employed The Great Hack to build more complex libraries, frameworks, and applications on top of it. Hell, this looks like web browsers was invented on Mars. Later Earth scientists found Alien Technology, Googlers hacked it, and millions of engineers worldwide invest all their time managing Alien Technology to behave like native Earth desktops...

Another question: Not so many years ago there was a shift from ASCII terminals to pixel-oriented grahpics. Let's imagine "standard Earth desktop" (like Java or WPF based) will be 3D or (more likely) 2D *vector* based in few years from now. Do you think people will invest more and more resources adding 3D or vector-based capabilities to unnatural environment, or finally will abandon hacks and will switch to natural ones?

I know there are many things, which forcing the world to use the Great Hack. And the Hack will be popular for a long time. RAP Technology itself is a great response to today's challenge... But why we shall support this Hack and other unnatural environments at the foundation layer (SWT)?

Another aspect I'd like to focus, is clear separation of things in web space: I'm considering Silverlight/Java/Flash as natural desktop-style environments, and HTML + AJAX as unnatural. Again in respect to DHTML UIs, I believe there will be very long life of HTML. But DHTML applications are very different and people have another requirements for that applications. For example: 

  • To be search engine friendly, and REST-styled to identify piece of information, for cross-linking, etc 
  • Information-oriented layouting I mentioned before. 
  • I guess many more...

And final aspect:

Flex/AIR, JavaFX, and WPF's approaches for cross-platforming (and for spreading the world) are identical: they just distribute runtime to as much platforms as possible. All three technologies are self-sufficient and they do not need anything besides runtime to run. These runtimes are: Flash VM, Java, and WPF (Silverlight = embedded versoin of WPF, initially named WPF/E).

E4 intention (as I understand it) is "super-portability" and "super-spreading": let's support all of them... and beyond (like HTML/AJAX). Is everyone here thinking this is reasonable decision? Can anyone propose a name for "support everything" programmers in addition to Ed's Teflon ones? 

1 TrackBacks

Listed below are links to blogs that reference this entry: SWT's road to 'super-portability'.

TrackBack URL for this entry: http://blogs.xored.com/mt-tb.cgi/10

I feel myself like heretic when posting to E4 mailing list, so my last posts did not went there (this one regarding OSGi/SWT/EMF Trinity looks to be a straight road to anathema). But I'm already on this road, so I'd like... Read More

Leave a comment

About this Entry

This page contains a single entry by Andrey Platov published on April 16, 2008 6:55 AM.

Looking at WPF and JavaFX, thinking on SWT was the previous entry in this blog.

What SWT/RAP can't address to survive in future? is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.