Does Write Once Run Anywhere Work?

Yes, and No.Write Once, Run Anywhere, a slogan created by Sun to evangelize the virtues of the Java Platform, is a controversial approach to software development.

Write Once, Run Anywhere (WORA) is accomplished through an abstraction layer between the 'compiled code' and the operating system and processor.  This abstraction usually takes the form of a Virtual Machine or Runtime, such as the Java Virtual Machine (JVM), Microsoft's Common Language Runtime (CLR), Flash Player (or Air runtime), or one of the many interpreted language runtimes (Perl, PHP, Ruby, etc.).  These runtimes convert the intermediate language into device specific code that can execute on the local operating system and processor.  While this overhead introduces extra steps, which slow down execution, they also provide features not (easily) available in native code, such as garbage collection and Just In Time (JIT) compilers which can optimize the code while it executes, as opposed to at compilation time.

So does it work?  Yes, and No.

Server

WORA languages have achieved a significant level of success on the server side.  Code that runs on large servers and interacts with clients over HTTP or other protocols is almost always written in some form of WORA, whether it is Java, .Net, PHP, Ruby, Perl, or other interpreted languages.  There is no advantage to using native code in these cases.  All interactions with the user are through an intermediate protocol/interface, such as HTML over HTTP for websites, XML over HTTP for web services, or various other formats and protocols used to exchange information between servers and clients or other servers.

There are certainly some applications developed for servers in native code.  Database servers are the most common example, but LDAP servers, webservers (Apache), and others are compiled to native code.  However, there are WORA versions of each of these examples, and many of the native applications were first written before WORA languages took off.

There is no denying that WORA is a huge success on the server side.

Client

Which brings us to No.
Client application development has struggled on the client side.  The biggest challenge is User/Human Interface Guidelines (HIG).  User or Human interface guidelines are published by various Operating System vendors (Microsoft, Apple) that define a set of recommendations on how an application should look and interact with the user.  Applications that follow these look like 'Windows' or 'Mac' applications.

With WORA, application developers have two choices.  Follow the guidelines of a specific platform, and ignore the others, or compromise between the various target platforms, creating an application that doesn't match any platform. 

Early Java desktop applications looked like Java applications.  They were obviously different from the other applications that users were used to interacting with, and were often shunned.  This has led to a negative view of WORA applications in general, as John Gruber comments on a Jason Kincaid article:

Jason Kincaid nails it: “write once, run everywhere” has never worked out. It’s a pipe dream.

In the context of client applications, I have to (mostly) agree.

There are exceptions.  In the Java world, nearly every developer uses an Integrated Development Environment written in Java, whether it is Eclipse, IntelliJ IDEA, or NetBeans.  But developers are a very different target audience than general computer users.

Another example is Flash and Flex applications.  Often delivered in the web browser, there are no real Human Interface Guideline that govern their interactions, other than the expected HTML experience.  This can work, but it can also be horribly painful, as many people have discovered trying to find a menu on a Restaurant's website. 

Mobile

There is a third act to this story.  Mobile.

Apple has take the mobile market by storm with its iPhone and App Store.   With over 100,000 applications written for the iPhone, the iPhone has become THE mobile development platform.  And every one of these applications was compiled to native code.

A consistent user experience is even more important on a mobile device with a limited display and user input capability.  Apple's success is in part due to its consistent device design.  Every iPod/iPod Touch/iPad version has a single home button, and a touch screen.  There are two screen sizes, the iPod size, and the iPad size.  While individual phone capabilities do very (memory, speed, GPS, Compas, etc.) the primary interface components are all the same.   By using a software keyboard on the devices, the keyboard is the same across all devices and applications.  All of this makes developing applications for the platform much more predictable and enjoyable.

The Windows Mobile and Android platforms both share a wide variety of device form factors, screen sizes, physical buttons, and device features.  This makes it much more difficult to build an application that is easy and intuitive to use across the platform.  And I think the quality and quantity of applications on the Windows Mobile and Android platforms demonstrate this point.

Solution

There is a solution, of sorts.  HTML in the browser is the most successful WORA language and runtime for client applications since the ANSI/VT100 terminal.  By creating a common language and interface, applications could be written for all operating systems easily, without the pain of violating their human interface guidelines.  The browser itself conformed to the local guidelines, and users expected the experience in the browser to be different from a native application.

It is time to evolve this paradigm to the next level.  HTML 5 is a good first step.  It provide the ability to display video, store data locally, and draw 2D graphics in a standardized way.  But to be successful, these features and more need to be implemented consistently across browsers, enabling developers to truly develop great WORA client applications.

As an intermediate step, frameworks and libraries that abstract the browser differences away is a short term solution.  JavaScript libraries such as Prototype and jQuery abstract the browser implementation differences while frameworks like Google's Web Toolkit (GWT) provide a platform to develop client applications that just happen to run in the browser.

Realistically, I think tools like GWT are the future.  As a Flex developer, I enjoy the ability to quickly and easily create rich applications that will render the same on ever user's machine.  But I would prefer that the Flex applications would compile to HTML and JavaScript, so they could be run native in the browser.

In the future, we will be developing using various language and platforms, but they will all compile down to code that runs native in the browser.  Or so I hope.

From http://blog.ericdaugherty.com/