Likes and dislikes about Eclipse E4

Update 2009-08-22: discovered Java2Script, added an item about it below.

E4 is the next generation of the Eclipse Rich Client Platform and brings numerous improvements in a bid to stay relevant as a platform. In this post, I’ll first summarize what I have already written on E4 and then make several suggestions as to where I think E4 should be heading. It is an extended version of a comment I added to the artice “Eclipse has a future” which explains what E4 is and how it improves on prior versions. The author finishes with the sentence “I really am psyched!” (regarding Eclipse’s future). I share that excitement, especially after I found out that Eclipse is looking at all kinds of technologies (RAP, Flex, Dojo) for web-enablement.

What happened so far

First, a recap of what I’ve already blogged about E4 (directly or indirectly), listed in chronological order:

• Eclipse 4 wishes: simplification first, then innovation: Initially I thought all Eclipse was going to do was to bolt on RAP. I’ve since been proven wrong, but the suggestions for improving Eclipse still stand.
• Online Eclipse E4? Lack of imagination!: I describe where I think desktop applications and web applications are going to meet in the future and what Eclipse should do to be there.
• What should be the platform of your next application?: A general look at what platforms to base one’s applications on, in this web-and-desktop world of ours.
• Eclipse E4 is getting interesting: Collects positive signs about E4. This is when my thinking about E4 started to change.
• Eclipse E4 is going even further in the web direction: Mentions Dojo being used by E4, server-side JavaScript OSGi modules, and SWT browser edition.
  

Bespin running on E4

More suggestions

Next, I’ll mention the main things I would tell the Eclipse team were I ever to communicate with them directly. Due to developing Hyena and Facetator, I have experience with the following platforms: Dojo, GWT, Eclipse RCP, jQuery. This puts my in a good position to judge were Eclipse wants to go.

• GWT: Talk to the GWT people as much as possible. They are doing incredible work, GWT version 2.0 is going to be amazing, also as a platform. They’ve already managed to make web programming in Java more comfortable than web programming in JavaScript. But GWT misses things that Eclipse could provide. I’ll list those things next.
  
• Client-side modules: One big thing that GWT is missing and that Eclipse has (via OSGi) is true modularity. Very useful when collaborating with other people on a project. Some kind of client-side modularity mechanism plus server-side modules would result in a great platform. As a starting point, this page surveys existing JavaScript module systems: Spidermonkey, Dojo, etc. Even E4 is mentioned.
• Browser widgets: Not enough standard widgets is another GWT problem. If GWT had the Eclipse community behind it, I’d suspect that that would quickly change.
• GUI layout: For SWT browser edition, the thing to watch out for is GUI layout. It is what bothers me most when using GWT. Help is on the way, until then, drawing to Canvas (like Bespin does) is intriguing. Unfortunately, MS Internet Explorer does not support Canvas, yet.
• More GWT wishes: More of my unfulfilled GWT wishes and a brief overview of 2.0 are posted here.
• Java2Script: looks like an interesting alternative to GWT that is already Eclipse-based. I’m not too fond of how the widgets look (especially on Mac OS X Firefox). But the technology is sound and the widgets can (and probably should) be replaced by a standard widget toolkit such as Dojo.
  
• RAP (a server-based technology that makes it relatively easy to add a web interface to an SWT application) is technically impressive. But the resulting applications are a bit slow, there is a limit of running only one application per browser and server at the same time, and you cannot do browser-only things like offline applications. As you can already guess, I would like E4 to focus on browser-centric technologies like GWT and Bespin and not on server-centric technologies like RAP.
• Take a look at server-side JavaScript: They are doing exciting stuff such as modules, file system access, and binary data objects.
• Client-side extensions: I would expect server-side plugins to provide client-side extensions. How can this be done? One possibility is to let the server-side plugin register a JavaScript URL with the server-side framework. This URL is sent to the client which downloads the script and executes it. The script then lets the client-side framework know about its services.