Usability: phone numbers and special characters

Why do so many web sites insist that, when entering a phone number, you not type any non-digits such as spaces, hyphens, parentheses or slashes? The structure that these characters bring to phone numbers help humans considerably and computers can easily filter them out. So what is the harm of allowing them? I would even store phone numbers in a database as they were entered.

Seven don’ts for websites

Source: xkcd

The following is a list of seven things that frequently bug me about websites.

1. Intro page where you have to choose your location or language. If I go to foo.com then the .com indicates that I want to see the American version of the Foo Inc. website. I do not want to see a map of the world where I need to click several times to finally get to my destination. Example: gilette.de. A better solution is to put a link somewhere that allows you to jump to other versions. Flag icons work well here, because you don’t need to understand the language of the current version to jump to a different one (e.g. finding “Germany” on a Chinese website is difficult if you don’t read Chinese).


2. Site version determined by IP location. If you use a web browser, the websites you are visiting know your IP address (five digits such as 127.0.0.1). In principle, this address is completely abstract (as opposed to, say, ZIP codes which can be mapped to a location), but there are databases that allow you to map it back to a location. This works pretty well, but is sometimes abused to automatically switch to the language of your location. But what if you are an American who is abroad and wants to access an American website. Or if you are German and want to check out an American website (not its German version). Example: eonline.com. Solution: A small note in the language the site thinks it has detected. Something like “Click here to see the English version of this page”.


3. Skippable intro page. Often such a page shows a movie that tells you what the website is about. By all means, link to introductory information on the home page, but don’t force me to watch/read it, every time.


4. Complete site implemented in Flash. I don’t particularly like Flash. It still has its uses for video, but most other things can now be done in HTML5. With Flash, you cannot bookmark pages or copy text. The website’s content cannot be found via Google and it won’t work on (most) mobile devices. Furthermore, most Flash websites make up strange new ways of navigation. Why change something that people know and that works well? Example: gilette.de.


5. Ugly URLs. URLs should be compact and easily understandable by humans. That is, one should be able to figure out what a page is about by looking at the URL. Thus, if the page ever goes away, one has a greater chance of finding out where it went. Amazon is both a sinner and a saint here. Some Amazon URLs have a lot of ugly pieces in them (“ref” and such). On the other hand, book URLs sometimes include the ISBN and an abbreviation of the title. This is a great practice, because the ISBN is a unique ID that is useful to both machines and humans and because the title allows humans to figure out what is there. Lazy programmers sometimes let the fact that there is a single script that displays all web pages show up in the URL: www.example.com/display.php?page=start. Even worse are meaningless page IDs (?page=17). Both can be avoided by putting in a little more effort.


6. Content is hard to find. Often, a website shows all kinds of details, so that the things that people are most frequently looking for are hard to find. Especially expert-designed web pages suffer from this, because it is often difficult to focus for experts (in their area of expertise). Examples are bank and government websites. But food websites are also often problematic: I don’t want to play a game, I want to find out about the products and/or their ingredients. Example: See picture above.


7. Error page discards original URL. This is fortunately rare, but every now and then, I discover an error page in my browser that says “page does not exist”. The problem is that the original URL is nowhere to be found: The error page URL has replaced it in the browser address bar (=history cannot be used) and it isn’t displayed on the error page. If there are many tabs open then it’s really hard to figure out what went wrong.

Bonus: Forbidding or enforcing characters in passwords. As if passwords weren’t annoying enough on their own, some sites decide to make handling them even more complicated. Hassles I’ve experienced so far were: At most 10 characters allowed, no punctuation allowed, must use a digit.

Inconsistent information in your database

The blog post “Rethinking Form Validation” describes an interesting idea (apparently inspired by one of Alan Cooper’s books): While developers are fond of only storing information that is fully validated, it may help end users if they can store inconsistent data. Related examples include forms that force you to only enter digits for phone numbers (no spaces, dashes, parentheses, etc.) or some obvious characters being forbidden from passwords. Validation should be unobtrusive, because there are always going to be unforeseen cases where rigid control works against the user. Eclipse’s handling of Java syntax errors is exemplary: You are warned about them, but you are not prevented from continuing your work.

Servlet sessions and automatic login: standard Java EE might not be enough for you

Java servlet session management works well for basic requirements, but has limits when it comes to advanced features:

• There is no standard global view of all the sessions, since HttpSession.getSessionContext() has been deprecated. If you want access to all sessions, you have to set up your own registry.
  
  


• You have relatively little control of when the session expires. For example, there is no standardized way of accessing the session cookie and extending its lifespan beyond browser restarts.
  
  


• Any kind of server access keeps the session alive: Long-pull is still a common technique for sending events from the server to the client and prevents a session from being inactive.
  
  

These kinds of limitations become relevant when you need to implement automatic login. There, you have the following options:

• Store user name and password in a cookie: This is inherently unsafe and should never be done.
  
  


• Let the browser remember user name and password: Firefox does this, but only for forms the exist at page load time. It is thus very complicated to get to work for Ajax dialogs.
  
  


• Keep the session around longer: One needs to control session timeout (after a given period of inactivity) and possibly cookie expiration (the session ID is normally removed once one quits the browser).
  
  

Simple solution, standard Java EE:

• During login, ask for the period of time one should stay logged in (if there is no activity).


• On the server, use HttpSession.setMaxInactiveInterval(). Beware: Some servlet containers seem to create a new session when this method is invoked.
  
  


• Problems: (1) Long-polling is registered as usage. (2) You cannot extend session lifespan beyond the next browser termination (because the cookie with the session ID will be removed).
  
  

Comprehensive solution, manual session management:

• Manage your sessions yourself. The client initially receives a session ID from the server and then sends it with each request to the server. The login security FAQ [1] has more details.


• It would be interesting to integrate this kind of session management with Google Guice which currently supports servlet sessions via a dedicated scope.
  
  

Related topics:

• [1] Google has a nice login security FAQ.


• [2] HttpSessionListener allows you to get notified of session creation and destruction.


• [3] HttpSessionBindingListener can get you notified when a session expires (and is simpler than HttpSessionListener).


• [4] “Google goodness: using GWT with Guice” (mentions session management with Guice).
  
  

Google wants us to print to the cloud

This is an interesting announcement. In Google’s vision of the future, a printer can make itself available to the cloud and then be used from any internet-connected device. This includes cell phones, but also web applications. While I like the idea, I wonder if people will be willing to take the security risks. Discovering printing services in a LAN (via zero-configuration service discovery, as implemented by Apple’s Bonjour and Microsoft’s Universal Plug and Play) might be more palatable.



Update 2010-01-26: Google brings Cloud Print service to mobile Google Docs, Gmail

Running a WAR as a desktop application

If you have written a web application, the next logical step is to make it available offline. The long-term solution is clear: You give your web application an offline mode, which will hopefully be complemented by explicit application management in web browsers. Short- to mid-term, though, that is often not feasible, because the server provides crucial functionality to the client. Thus, I was looking for a different solution.



One option I had seen was Hudson’s self-executable WAR file: When you execute java -jar hudson.war, an embedded web server starts and you can immediately try out Hudson. This approach had two limitations that I didn’t like. First, I wanted my solution to be acceptable for end users, so I wanted a graphical user interface. Second, the embedded web server extracted the WAR file to a temporary directory and did so again for each startup, wasting time. In contrast, my solution does the following things:

• The application is a JAR file, the WAR is embedded inside. I opted against a single binary for JAR and WAR, because packaging the JAR as a nice desktop application adds platform-specific data, anyway, and makes it often impossible to deploy the result as a WAR.


• When the JAR starts up, a Swing user interface is shown. If this hasn’t been done before, the WAR file is extracted to a directory next to the JAR file. The idea is that there is a dedicated folder for the application in which the JAR resides. The location of the JAR is determined via this trick. The WAR file (=ZIP format) in the classpath is extracted to the file system using the standard Java API.


• Next, a web server is started and pointed to the web application directory in the file system (none of the web servers I’ve seen is able to serve a WAR file directly, let alone one that is embedded inside a JAR file). I used Winstone, because it is so small. There are even smaller ones, but those won’t allow you to use servlets. Obviously, any embeddable Java servlet container will do.
  
  


• A button allows the user to open the starting page of the web application in the default web browser. java.awt.Desktop (Java 6) allows you to do this. Currently, localhost and a fixed port is used. In the future, the port should be configurable and one could maybe automatically switch to a different port if the default one is occupied.


• Finally, I also produced a Mac OS X application. Such an application is a folder with the file name extension “.app” and the JAR file inside. This has the nice side effect of hiding the extracted WAR directory.
  
  

This is all there is to it. Now even non-technical end users can try out my web application without having to go through the steps of downloading and installing a web server. You can download the Eclipse project of my implementation (be warned, the code is quite experimental).



href="http://www.2ality.com/2010/05/running-war-as-desktop-application.html">Flattr

Google goodness: using GWT with Guice

The Google Web Toolkit and Guice are two very useful technologies. This post explains what they are, how they can be used together and what benefits this brings.



The Google Web Toolkit enables one of the most elegant ways of writing web applications. With version 2, it has reached a new level of ease of use: simple install, quick development turn-around, testing in an external browser, CSS-based layout that works even for complicated scenarios, etc. Guice is a lightweight dependency injection framework and helps with structuring an application. It also has one of the most elegant Java APIs around. Combining them means that Guice manages GWT’s services and server-side objects. These are the installation steps:



Step 1: Install GWT. Installing the GWT has become simple, because both the GWT SDK and the Google Plugin (with IDE support for GWT) can be installed as Eclipse plugins.



Step 2: Install Guice. Also simple. Download the JAR, drop it into the directory war/WEB-INF/lib inside the directory of your GWT project, add it to the Java build path.



Step 3: Let Guice manage all remote services, as explained in the article “Guice with GWT”. I needed aopalliance.jar in addition to the two JARs that were mentioned in the article. Unfortunately, the @RemoteServiceRelativePath is relative to the module path. The following is an example where this has been taken into consideration.

public class ServiceModule extends ServletModule {
@Override
protected void configureServlets() {
serve("/"+ServerConstants.SERVICE_PATH).with(MyServlet.class);

bind(MyService.class).to(MyServiceImpl.class);
}
}

@RemoteServiceRelativePath("../"+ServerConstants.SERVICE_PATH)
public interface MyService extends RemoteService {
//...
}

Benefits: As all services are managed by a single servlet, one just registers a new service with Guice and it becomes available to the client. No need to set up an additional servlet. To fully appreciate Guice, first learn about basic (constructor) dependency injection. Afterward, you are ready for an explanation of scopes: The Guice injector is a factory for objects. By default, it creates a new instance each time it is invoked. This can be changed by assigning scopes to classes. For example, the singleton scope means that a class is only instantiated once; if the injector is told to produce more than one instance, it will always return the same one. Each invocation of a service method is a separate HTTP request. Accordingly, classes in request scope are created freshly for each request. The injector has a binding for HttpServletRequest, and can thus inject it into an instance in request scope. A service method handles a request by asking the injector for a request-scoped instance and by invoking one of its methods. Scopes can also be used for session management, as there is a session scope. Instances are created once per session and can hold any kind of session data (who is currently logged in, etc.). No more direct fiddling with HttpSession! By requesting a Provider<MySessionScopedClass>, instances in singleton scope can access the current instance of MySessionScopedClass.



More Guice tips: If you want to extend a class Component with implementers of an interface Plugin, you can do so via multibindings. Interface Plugin is multibound to a set of classes and Component requests a Set<Plugin>. It is then free to iterate over all Plugin instances, in order to make them perform tasks or to inform them of important events. Guice also helps one with logging:

Guice has a built-in binding for java.util.logging.Logger, intended to save some boilerplate. The binding automatically sets the logger’s name to the name of the class into which the Logger is being injected. [source]

Thread safety: If you are in singleton or session scope, you need to be thread-safe. If you are in request scope or “no scope” (=created each time), you don’t. Interestingly, Crazy Bob Lee recommends:

If the object truly is stateless, it’s faster for Guice to create a new instance than it is to retrieve a singleton. If Guice creates a new instance every time, it can bypass the scoping layer entirely, not to mention the logic inside the singleton scope.

Moral: use the latter two scopes as often as possible.

File system storage and servlets

One of the blessings of the JVM is that there are many “pure” databases available for it; Sesame (RDF) and Apache Derby (relational) come to mind. Alas, these databases need to save their files somewhere. This becomes a challenge with Servlets: Where should one put these files? Pre-packaged, read-only, files usually reside in SERVER/webapps/app/WEB-INF/, but mutable files? Putting them in WEB-INF makes upgrading a web application more difficult. I can easily imagine myself accidentally removing such data during an upgrade. The best solution, that I was able to come up with, is:

• By default, the data directory of a web application “app” is SERVER/webapps/app.data/WEB-INF/ (WEB-INF is necessary to protect against serving secret files).


• This can optionally be configured via a file SERVER/webapps/app.properties. There, one can specify the servlet data directory via a relative or an absolute path. The former case is useful if you want this directory to be a sibling of SERVER/webapps. The latter case is useful for putting this directory anywhere on a system.

I do realize that there are security issues with this scheme: While it worked for me on Tomcat, I would expect other servlet containers to prevent servlets from writing files in this manner. Other options are:

• Make the data directory a servlet parameter in web.xml: Complicates upgrades.


• Specify a directory via the Java preference API: Prevents installing the same web application multiple times on the same system.


• Storing the data in a temporary (as in File.createTempFile()) directory: Not a solution for long-term persistence.
  
  

Are there other solutions out there? Let us know in the comments.



Update 2010-12-14: One of the comments already mentioned this solution: I finally opted for storing files in the home directory. In Windows, the home directory is rarely directly accessed, while under Unix you can hide your web-application-specific directory by prefixing its name with a dot. So this solution works out well in both cases and fulfills all of the above requirements.

Is it time for a JVM-based web browser?

Figure 1: Screen shot of JWebPane in action (source).

There are currently two exciting platforms for which one can develop:

• The Java Virtual Machine (JVM). Advantages: Great tools, hosts many languages, lots of free software is available for it (databases, support for many file formats, etc.), supports modularity (OSGi, Jigsaw).


• The web browser. Advantages: One can quickly try out an application without downloading anything, URLs encode application states and are bookmarkable, the ability to clone application states via tabs, integrates hypermedia and data streams of all kinds.
  
  

Then how about combining these two platforms? It seems like a missed opportunity for the JVM that all major browsers now have JITs for JavaScript, but none of them uses the JVM. What would a JVM-based web browser look like?

It would be modular, every aspect of it would be extensible in Java. It would be host to a new kind of web/desktop application hybrid. If the JWebPane technique of porting Webkit to Java2D really works, then it can even provide a perfect web experience (Fig 1, 2). Alas, it has been a long while since there was any news about JWebPane.

Figure 2: JWebPane is a port of Webkit to the JVM (source).

I do realize that applets go a long way in the direction of this vision, but several minor details add up so that one still feels the barrier between Java and the browser. I could never get excited about JavaFX, it always felt like Java was trying to be like Flash. But the idea of a JVM-based web browser, HotJava 2 if you will, does excite me in ways I cannot all explain rationally. I can see myself extending such a browser with many tools and writing all my future applications based on it.



Update 2010-03-02: See my comment below on a refinement of these ideas.

Update 2010-12-15: Oracle has granted my wish and turned JavaFX from a language into a library.

The next generation of web application UI layout

User interface layout has been one of the main challenges that has held web applications back (desktop integration is another one). Especially vertical arrangements such as the following used to be next to impossible: Bars at the top and at the bottom contain widgets that take up minimal height, while the content is displayed at the center and takes up the remaining vertical space. Note that this is trivial to do in desktop GUI frameworks such as Java Swing. Recently, Ajax frameworks have made progress in this regard. Now you can implement the above mentioned scenario, but you have to specify fixed heights for the bars (the screen shot shows this kind of bar at the top of the window and above the email message). A small price to pay, especially as those frameworks do it in pure CSS (=fast). I am aware of three frameworks that perform this kind of magic:

• Sproutcore: Looks great, JavaScript-centric, borrows patterns from Ruby on Rails (project layout, models) and Cocoa (binding, properties). Sproutcore has a Ruby-based generator for code that makes it easy to get started and is itself easy to install, thanks to Ruby’s Gem packaging mechanism. Sproutcore is used by Apple for MobileMe. Current disadvantages: sparsely documented, relatively slow development turn-around (it takes a while to reload after changes). Demos.
  
  


• Google Web Toolkit (GWT): Java-centric, having a single code base on client and server is priceless, great tooling (Eclipse), fast development turn-around, well documented. The new kind of layout is a feature called “Layout Panels”. GWT is used by Google for Google Wave. Demos.


• Cappuccino: I have not tried this one out. I’m not sure that having a custom language (Objective-J) on top of JavaScript is the way to go, especially as Sproutcore does most (all?) of what Objective-J is capable of in pure JavaScript. Cappuccino has a cool browser-based IDE and GUI builder called Atlas.

So this makes full-featured web GUIs possible today. Regarding the future, I’ve written a blog post about what CSS might be capable of, one day.



Update 2010-12-13: I’ve heard good things about how Qooxdoo performs layout. Apparently they layout programmatically via JavaScript. This allows them to do more sophisticated things, but it makes layouting a bit slower.



Update 2011-01-24: The ultimate CSS layout spec for webapps

JavaScript will (probably) be moving forward

A quick recap of JavaScript history: For a long time, ECMAScript 4 was a really feature-rich proposal for a next generation JavaScript. It even included optional typing! Sadly, the involved parties prevented this proposal from ever becoming a standard. Instead ECMAScript “Harmony” was proposed that changed very little so that everyone could agree on it. In order to avoid confusion that proposal was called ECMAScript 5.
In the video “ECMA Harmony and the Future of JavaScript”, Brendan Eich talks about ECMAScript 5 history and possible future features. And this is where it gets interesting. Among the features that might make it are catchalls (functions that supervise how an object is accessed), classes as object facories, concurrency, iterators (to abstract iteration), generators, runtime type-like guards, versioning. Modules are being worked on at commonjs.org, as a library. More on the proposed features can be found at the ECMAScript wiki.

Canvas-based game: Ajax has come far

The online game “Berts Breakdown” is fun and there is no Flash involved! It is all done via JavaScript and the HTML5 canvas tag. Quite impressive. Warning: Canvas means that this game won’t run on Internet Explorer, only on Firefox and Safari (and possibly on Opera). [Source: Ajaxian]

[Update 2009-12-13] More pure JavaScript games are shown at EffectGames.

Mobile HTML: dial a phone number via a hyperlink

As HTML5 is becoming a really cool way of developing applications for the major smart mobile platforms (iPhone, Blackberry, Android, Palm Pre, all of them Webkit-based), it would be nice if one could invoke the dialer. It turns out, you already can, via URLs such as tel:+49/89/12345. Dots, slashes and a prefixed plus are all handled corrrectly. SMS URLs and Skype URLs are also possible.

CSS layout: soon good enough for GUIs

Update 2011-01-24: The ultimate CSS layout spec for webapps





One of the sore points of Ajax has always been layout: CSS is great for document layout, but sucks at GUI layout. Where Java layout managers such as the grid-based JGoodies FormLayout (PDF) work really well and can do things such as “make this grid cell as narrow as the content allows”, CSS currently needs absolute length specifications. Furthermore, letting an element fill out all of the available space is really tricky, especially when done vertically. Thus it is no wonder that layout was ranked high on the OpenAjax browser wish list. Thankfully, the W3C is hard at work at fixing this problem and it seems that all the major browser vendors are on board (if you look at the editors).

• CSS Template Layout Module: lets one specify grid-based layouts in a really neat ASCII-art-like way. Go to “CSS Template Layout demos” to see examples.
  
  




• css-template-layout: implements template layout in current browsers via JavaScript.




• Flexible Box Layout Module: is “based on the box model in the XUL user-interface language used for the user interface of many Mozilla-based applications (such as Firefox)”. To get a grid, you need to nest several boxes. I prefer template layout's more direct approach.
  
  


• CSS Grid Positioning Module Level 3: mainly for document layout (multi-column layout etc.).
  
  

According to sources of mine, the W3C will try to consolidate these three proposals as much as possible, but might have to keep two, because GUI applications and document layout have such different requirements.

Eclipse E4 is going even further in the web direction

The latest version of E4 contains “web components”. It warms my heart that they are using Dojo (=true client-side technology) for some of their experiments. JavaScript OSGi modules also look cool (don’t get too excited, though: they are for server-side JavaScript).
Update 2009-08-04: Check out SWT Browser edition. Its goal is to enable cross-compilation of SWT applications to something that runs in the browser. Flex cross-compilation is working, other approaches are under investigation.

Facetator: simple data publishing (with JSON and jQuery)

Facetator is an open source tool for publishing lists such as recipes, journal entries, favorite movies. With Facetator, this kind of data is easily browsable (via faceted navigation) and searchable. Because it is a client-only JavaScript application, you don't even need a special server to use it. A demo is online. The JSON data needed by Facetator can be produced programmatically or manually via Hyena.

Video: Requirements for web applications and GWT

The video “Google Wave: Powered by Google Web Toolkit” is a great overview of what features web applications need and where GWT currently meets the requirements or soon will.

What is the appeal of Ajax and GWT?

Ajax does have its detractors. Their argument goes as follows: Why reinvent everything that has already been done on the desktop on an inferior platform? I do agree that the attraction of Ajax is subjective (i.e., not based on technological arguments). This is obvious whenever I’m excited about something web-based, show it to non-developer friends and their only reaction is boredom. Then I realize that while I’m excited about what’s possible on the web, they have already seen it on the desktop. But—there are some good arguments in favor of Ajax. My reasoning goes as follows:

• I love web applications (because I use 3 different computers having data travel with me is great).
• I’ve always disliked Applets and Flash. With advanced browser use (tabs, drag&drop of links, etc.), anything that is not well integrated feels constricting.
• Mobile applications: Web applications are currently the best solution if you need something that runs on the smartphone platforms Android, iPhone, Palm Pre, and Blackberry. The browsers of all of these platforms are WebKit-based, making testing less of a chore. Windows Mobile 6 is out there, too, but feels dated now, and I'm not sure how capable its browser is.
  
• There is tremendous momentum behind the browser as a platform. New user interface ideas are constantly being tried out, JavaScript is getting really fast, gains lots of APIs (geolocation comes to mind), etc.

Using GWT to write Ajax applications has the following advantages:

• Compared to desktop Java: GWT makes programming web applications almost as simple (in some cases simpler) as programming Swing. So why not use it?
• Compared to other Ajax solutions: GWT has Java's superior tooling, one has a single code base for client and server, and GWT’s compiler produces highly optimized code (due to Java’s static nature).
  

[Further reading: “What should be the platform of your next application?”]

What should be the platform of your next application?

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: What 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
  
  


• canvas-based browser UI: would be a perfect solution for me (see “Project Bespin and the Future of Web UI According to Google”).


• GWT + XUL: would be Firefox-only, but still kind of cool. Last I checked, there was nothing usable out there apart from a few experiments.


• 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?



Related reading:

• Running a WAR as a desktop application.

Advanced HTML forms

The tutorial “Creating accessible Web forms” shows how much is already possible with HTML forms (even without XForms).