Dr. Axel Rauschmayer is a freelance software engineer, blogger and educator, located in Munich, Germany. Axel is a DZone MVB and is not an employee of DZone and has posted 246 posts at DZone. You can read more from them at their website. View Full User Profile

What Should Be The Platform of Your Next Application?

04.13.2009
| 7983 views |
  • submit to reddit
I'm currently thinking about the next steps for my information manager Hyena. It exists in two versions, as an Eclipse plugin and as a GWT-based web application. Having to maintain two versions is a major burden, so I've been thinking: Would would be the ideal platform on which to base one's application? My wishes for such a platform are as follows:
  • Simple deployment: Nothing beats pure webapps in this regard. Having a webapp available everywhere is cool, too.
  • Extensibility: For larger applications, if you want someone to code new functionality, doing it as a plugin is very elegant.
  • Development tools: With inadequate tools, implementing and maintaining an application becomes much more work. It should be easy to find one's way around a platform and source code should be easy to change and navigate.
Technology-wise, times have never been better for developers. A lot of exciting stuff is available, for free:
  • Eclipse: I love its GUI (which is remarkably clean considering how much functionality it has), but am not too fond of its innards. They always felt harder to understand than necessary, slightly overengineered, and include anti-patterns that make it difficult to discover things (see “Eclipse 4 wishes: simplification first, then innovation”). I'm also not sure that the pride of amassing frameworks serves Eclipse well. This leads to design by committee, instead of a single tight overarching vision. Lastly, Eclipse seems to pin its hopes for web enabledness on RAP (or something like it). What I've seen so far of RAP did not instill confidence: It is slow, its UI awkward, and it will never work in offline mode.
  • OSGi: Very useful and powerful if you need extensible software. Still a bit complex but that will hopefully change as it finds its way into the Java language.
  • GWT: I was long very sceptical and wrote my own JavaScript, but now I am a convert, because having a single language and the power of the Java tools leads to a lot of productivity. Even though writing GUIs with GWT is almost as simple as with, say, Java Swing, one problem remains: layout. Many things that are easy in Swing or SWT are difficult or impossible in a browser.
  • DWR: Nicely done. But I've tried it (together with Dojo) and maintaining two code bases (client + server) is not much fun. Plus, JavaScript development tools are not yet at the level of the Java tooling.
  • Appcelerator: Intriguing option for turning a web application into a desktop application. I'm not sure coding the UI and the application in two different, usually not well integrated languages works. Thus, I can imagine using it with GWT or with JavaScript.
  • Trephine: Brings desktop features such as the clipboard or file system access to web applications via a small signed Java applet.
  • Bespin: Ajax application that draws its own UI via the canvas API (see picture below). Very impressive and indicative of web browsers soon being superior deployment platforms. I would also assume that by being canvas-based, rendering and UI differences between browsers are less of an issue.

So where does that leave one when writing the next application that should be web-deployable? I see the following options:

  • GWT plus
  • Running GWT on OSGi could deliver extensibility, but I'm not sure how well the client side could be extended, since GWT cannot currently dynamically instantiate classes. GWT.create() only works statically. That means that plugins cannot contribute code to the client side of a GWT application.
  • Pure JavaScript: That is client-side JavaScript and server-side JavaScript. Currently, neither language nor tools nor (non-canvas) browser-based UIs are there yet. But they probably will be eventually.
  • Applets, Flex, Silverlight: either don't integrate well with web browsers or have inadequate development tools or don't integrate well with web servers (meaning that it is useful if server and client can share data structures easily, having to define the same class and/or tool functions twice is unnecessary overhead).
Other inspiring technologies that are interesting, but not (yet) relevant for me:
  • Newspeak: Takes discoverability and clean but powerful language design to a whole new level.
  • Lively Kernel: Sun Lab's go at a pure JavaScript runtime environment. Still feels a bit strange to use and I'm not sure about their server story. But a cool project none the less.
  • Mobile webapps: When it comes to mobile devices, the predominant browser is Webkit, so it is really easy to write cross-platform applications as webapps there. Google leads the way via its mobile versions of GMail and GCal.

Am I missing something? Did I misjudge some of the technologies?

From http://2ality.blogspot.com/

Published at DZone with permission of Axel Rauschmayer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jim Wilson replied on Mon, 2009/04/13 - 10:51am

Hi Axel,

Great article, and thanks for mentioning trephine. Hyena looks like a good example of exactly the type of webapp that can benefit from trephine integration. I'd be happy to answer any questions you may have.

-- Jim R. Wilson (jimbojw)

Francisco Peredo replied on Mon, 2009/04/13 - 1:47pm

Have you tried AribaWeb or Capuchino?

 AribaWeb meta-ui makes it real easy to build data entry applications that can be redesigned interaticvely from within the browser, and  Capuchino brings a Coco/NextStep like API in to web development, making it real easy to create applications with very interactive interfaces.

 Another interesting option could be Jaxer, if building web applications is about javascript and html (after all that is what everyother framework generate...) why not turn the table and make javascript the source: "server side javascript", with it you can execute the code of almost any javascript framework on the server, improving performance in some cases, and easily and share data between the client and the server making it easier to validate stuff... I of course prefer Java but... but lately I have been wondering... is it really the right choice?

Axel Rauschmayer replied on Mon, 2009/04/13 - 8:04pm in response to: Francisco Peredo

Capuchino is exciting, but IIRC does not have tools as good as, say, Eclipse when it comes to refactoring and code navigation. The same holds for Jaxer. For me Eclipse has become very important: I used to prefer Python over Java, but Eclipse changed that.

If JavaScript ever gets optional types (and hopefully other features such as generators, list comprehensions etc.) then I think it won't be long before JS IDEs are up to par with Java. Capuchino feels like an intermediate solution that improves on JS language-wise. I guess GWT is in the same league, but it has a very convincing server story.

Lastly, Java is unparallelled when it comes to libraries, especially for semantic web stuff.

I still can't form a coherent picture of all of this in my mind, because there are cool pieces everywhere, they just don't fit together (yet).

Axel Rauschmayer replied on Mon, 2009/04/13 - 8:21pm in response to: Jim Wilson

Thanks! I'm still not sure what the best way of layering and deployment is.

  • Option 1: Make the client offline capable. An elegant solution, but I need the RDF database Sesame which is Java-based. One would still want access to the local file system (which could be provided by Trephine).
  • Option 2: let users install Tomcat + web application. Same as above for the file system.
  • Hybrid solution: Download JARs to the browser, use LiveConnect (or something similar) so that one has a client-side Java backend. Again I would want to use GWT, but that does sound doable.
Is there a way to determine whether Trephine is running or not?
For the future, one has to wonder whether one will ever directly access server-side data or always synchronize a local repository with a server. An eye-opener in this regard has been for me how easy it is to switch mail clients with IMAP (which can be seen as a synchronization technology).

Francisco Peredo replied on Tue, 2009/04/14 - 10:13am in response to: Axel Rauschmayer

Well, if for the java side, AribaWeb looks very interesting, it demostrates that it is possible to do much more than what Ruby on rails do, and with 100x less code (something that according to some Ruby guys was impossible to do due to supposed "inherent limitations" in the Java language)

JavaScript already has  a dialect with "optional" types... it is called JavaFXScript. I wonder... if someone created something like Jaxer, but based on JavaFXScript... would it be successful?

Yes,  Java is unparallelled when it comes to libraries, and IDE support, but they are all server-side libraries, and, right now, everybody seems more interesting in client-side (RIA?) stuff, and there, JavaScript is the king, regardless of all its limitations.

IDE support for Javascript has improved, the JSDT looks promising (and the Aptana guys are also improving IDE support for Javascript), Flex is JavaScript (and the last IDE from Adobe looks nice), Flex is also much lighter to download than the JDK, and it is easier to achieve really good looking applications...

I do not like it, but it seems that the future will be coded in a javascript dialect... even Scala, with its functional programming support would be a better "source language" to be compiled in to JavaScript by GWT (less programming paradigm mismatch?)

Jim Wilson replied on Tue, 2009/04/14 - 1:17pm

Hello again Axel,

With regards to making the client offline capable: this is something that I've thought about quite a bit. I'm currently leaning towards writing some data (say an index.html file and other goodies) to a directory on the filesystem, then redirecting the user there immediately afterwards. From then on, the local html-based solution is both their online and offline destination in one. The site would then use asynchronous calls back to a central server to sync up or get new code when a connection is available.

I haven't used Sesame myself, but I have put together a persistent client-side database demo which shows how to use HSQLDB to have a cross-browser, cross-platform RDBMS. I believe the process would be very similar for an RDF database.

In answer to your question, trephine is currently a "per-page" kind of technology. The JavaScript method trephine.load() is used to launch the applet, and the boolean property trephine.loaded tells you whether this has yet occurred. It's possible to spawn background threads using trephine, but I haven't yet figured out a good, safe way to do this for say an HTTP listner. Research in this area is ongoing :)

-- Jim

Axel Rauschmayer replied on Wed, 2009/04/15 - 6:19am in response to: Jim Wilson

Users will probably want to run their webapp in three styles:

  1. Run remotely, no local data (=server-side DB).
  2. Run remotely, local data (=client-side DB).
  3. Run locally (=local data).

In order to minimize context-specific coding, I will probably initially focus on (1) and (3). Unfortunately, with (3) one loses transparent application updates and needs things such as an installer and an (integrated) updater.

But maybe having an explicit application to install makes things less confusing for users. For example, I would worry whether I really have the newest version of the app, whether all of it has been cached before going offline.

What does Trephine do if there is no Java available? "onload" just does not get called and one uses trephine.loaded to check whether one is in "trephine mode" or not?

Jim Wilson replied on Wed, 2009/04/15 - 2:14pm

If there is no Java available, trephine will execute the 'onerror' handler if one has been supplied.

Ex:

trephine.load( {
onerror: function() {
alert( "Sorry buddy. Get Java, then try again." );
}
} );

 

Markus Krüger replied on Thu, 2009/04/16 - 12:56pm

How about Java Web Start? It's included in the Java runtime since J2SE 1.4, and facilitates automatic distribution of software updates, giving you the rich user interface of a thick client while sparing you the hassle of manually distributing patches.

Axel Rauschmayer replied on Sat, 2009/04/18 - 9:29am in response to: Markus Krüger

JWS is really cool. Especially in combination with the updated applet API: You can drag and drop an applet to the desktop and it becomes a Java Web Start application.

With the new applets, there are only two problems: First, very often, Java is not installed or a version that is too old. Second, the UI will always feel foreign inside a web browser. Now, with Java being able to access the browser DOM, one could use Java instead of JavaScript to construct DOM widgets etc. It would have to work seamlessly, though (no JavaScript frontend, Java backend, it should all be done in Java) and I don't know of any project that provides the necessary infrastructure to do so.

Furthmore, with a solution such as Trephine, you have the option to fall back to a non-applet solution if the browser cannot do applets. Then I would use GWT to bridge the client-server differences.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.