Windows

Does Cross Platform Programming Matter?


Recently, there was a very interesting and heated discussion on TechRepublic concerning what the best programming language for cross platform development is. I weighed in, of course (my vote went to Perl and standard C/C++). Afterwards, I began to ask myself, "does cross platform development even matter?" The answer to this is "maybe," and "yes."

Where cross platform development might not matter much is in the desktop application space. Most large enterprises have standardized on the Windows platform. If you are a Windows application developer, you can sell your product over 90% of the desktop users out there. As frequent readers know, I am not fond of the idea of locking yourself out of a market. Obviously, if you are writing a Windows system utility, UNIX and Macintosh users are not important to your strategy. But if you are looking to write a general purpose application, you may need to ask yourself if losing 5% - 10% of potential sales outweighs the efforts of writing your program in a cross platform manner. Even in the cross platform space, there are pure desktop applications, where the data is stored in files, and client/server applications that require some sort communications between the desktop application and a backend server of some sort.

Cross platform development definitely matters in the server application space, though. Windows does not command the huge market share in the data room that it does on the desktop. It is very difficult indeed to justify being able to sell your product to 40% - 60% of the potential market. This is one reason why I am not a fan of using either .Net or Java on the backend. .Net, unless you are using the portion of the .Net Framework that Mono supports, is hardly cross platform. And most of .Net's advantages stem from its tight integration with Windows. I still do not trust Java's cross platform portability. I have simply had too many problems with it in the past. Many of the portability problems I have had with Java stem not just from the JVM, but from the application server itself. Targeting a particular application server cuts you off from potential sales even worse than targeting a particular operating system. And using only standard Java reduces its usefulness on the backend significantly.

Web applications require still more cross platform considerations. Internet Explorer on Windows no longer holds the 90% of the market like it used to. A few years ago, you could target a Web site towards IE on Windows, and allow for it to gracefully degrade for UNIX, Apple, Netscape/Mozilla, Safari, Opera, and so on. This is no longer the case. The front end needs to work just as well over various browsers running on a multitude of operating systems. And the back end is subject to the same OS considerations as other server applications, with even more problems: you cannot rely upon a particular Web server being installed (let alone a particular application server). Even worse is depending upon specific backend technologies such as Windows Indexing Service or a particular vendor's RDBMS.

Taking all of this into consideration, we have the following grid of application varieties:

Application Type

Dominant Environment

Market Share of Dominant Environment

Desktop Applications

Microsoft Windows

90%+

Server Applications

UNIX

~50%

Web Applications (front end)

Windows + IE 6

75%

Web Applications (back end)

UNIX + Apache

60%

Looking at the grid, we can see that there are some tough choices to be made. Even when writing a desktop application, if that application requires communications with a server, the server backend will probably need to be written in a cross platform manner, even if the client portion is strictly Windows only. With Web applications, the choice becomes even more tricky: you have to account for a wide variety of Web browsers on the front end, while simultaneously writing the backend components to be used in many different environments.

It is also very difficult to choose between the headaches and hassles of writing cross platform code versus non-portable code. With Web applications, if you follow my "running water Web design" theory (to be discussed in an upcoming blog), your only cross platform concerns occur on the backend, reducing the number of platform combinations that you need to support. If you are writing a desktop application, your choices are really limited to the following development strategies:

* Java

* A cross platform language such as C/C++ to be compiled into libraries and wrapped in a platform-specific front end such as the Windows API, X, .Net, etc.

* Something such as Tk which allows cross platform GUI design

On the backend, you need to decide how much advantage leveraging server specific functions can give you as opposed to writing generic code in Java, C# (using Mono), C/C++, Perl, or some other highly portable language.

Unless you are willing to sacrifice potential sales, you are really forced to be writing your code in a cross platform manner. As the market shows, most desktop application developers are willing to give up about 10% of their sales in order to target Windows systems; only the truly large projects (or popular OSS projects) get aimed at multiple platforms on the desktop. The backend story is much murkier. If you have a high profit/low volume sales strategy, targeting a particular OS or combination of OS, Web server, and application server is a viable strategy. You cannot ignore cross platform code if you are shooting for a low profit/high volume sales strategy, particularly in a commodity market.

J.Ja

About

Justin James is the Lead Architect for Conigent.

0 comments

Editor's Picks