For most of the desktop computing era (ca. 1980-2010) software creators have had to grapple with decisions of which operating systems to build their software for. This century, any desktop application with a user interface has been a choice of Windows/Linux/MacOSX, with relative importance being dependent on the industry. Since mobile devices turned into real computers, and HTML5 found its way onto mobile browsers, the decision has moved up a level: software creators now have to start by deciding which meta-platform, i.e. desktop, mobile or web. And it’s not always an easy choice.

Desktop. Building software to run on desktop/laptop personal computers brings the benefit of software design best practices that have been worked out over a long period of time, and also the incredibly large amount of computing power that can be crammed onto the same device that provides the interactive user experience.

While it is my belief that the desktop computing platforms are on a slow but sure route to obsolescence, most professionals will continue to own and regularly use a personal computer for many years.

In an industry like cheminformatics/computer aided drug design, it really is necessary to support all the 3 major platforms that are in the hands of users: Windows because it has the largest number of enterprise users; Mac OS X because, lets face it, even if you hate Apple, their computers are seriously awesome compared to what else is going on; and Linux because, even though it has relatively few desktop users, those users tend to be very import must-have types in highly technical fields like molecular modelling, so leaving them out is not a real option.

This means that if you want to support the desktop metaplatform, you need to have your software running well on three operating systems that are quite different. In this day and age there are many cross platform tools, and some of them are excellent (e.g. Java), but when it comes to providing a user experience that makes optimal use of the platform, fitting in nicely with the standard UI/UX paradigms and making use of all the various ways to integrate into the graphical operating environment, can you think of any pure cross-platform applications that do as well as a carefully written native equivalent? I use a number of applications interchangeably on Win-Mac-Lin, and not one of them is entirely satisfactory.

The other big problem with desktop software is deployment. While the constituent platforms will linger on for a good while, the notion of inserting a CD/DVD (or downloading an executable) and running through an install process has very limited time left for this world. The practice simply has too many problems, such as inconvenience, security, the million ways that a uniquely customised install can go wrong and require troubleshooting, and the barrier to updating being so high that most people basically don’t bother. The introduction of desktop “app stores” seems like a solution, but there are so many competing platforms: introducing these 30 years after the fact has thus far not worked out very well.

Mobile. The other main class of computer that people interact with are tablets and phones. These are mostly highly locked-down devices, with very restricted development tools and deployment methods, which is a mixed blessing. On the one hand having a single standardised development environment removes a huge number of headaches, and the appstore-style deployment of software makes buying, installing, running and upgrading software into something so painless that it seems like it’s an invisible non-issue that doesn’t even need to be thought about. Mobile apps also have the benefit of being very trendy, upcoming, and cool: people still get a buzz out of a good mobile app, whereas even the most ardent computing enthusiast generally thinks of desktop software as being about as exciting as a tool-shed full of gardening implements.

The price is fairly steep, though. Mobile platforms are evolving fast, and it’s not clear which are going to be the most important from one year to the next. iOS and Android seem fairly entrenched in spots #1 and #2, but a couple of years ago BlackBerry was still important, and if Windows Phone followed Microsoft’s history of always winning by leveraging various unethical business practices, you would be foolish not to consider the possibility of having to rewrite your apps from scratch 4-5 times over the next decade. And with zero-lines-of-code compatibility between the development platforms, that really does mean rewriting from scratch, which is a terrible burden. Building apps for small touchscreens is also really hard to do well, and while mobile devices have enough power to provide excellent visuals, if your product needs access to any serious number crunching or large-ish databases (usually the case for scientific computing) then you need to figure out how to implement your product by splitting between local & remote functionality, accessed via a network API. And that’s rather hard, too: or at least, it’s a lot of work.

Web. The two obvious advantages of web applications is that there is no installation process required, and that a single codebase can be used to target essentially all modern platforms, be they desktop or mobile, since HTML5 is somewhat ubiquitous.

The most obvious down-side of webapps is that they are delivered over the web, which means that they need an internet connection, and they typically communicate with servers hosted by the company that produces the app. There has been work on making offline webapps viable, and the servers can be redeployed elsewhere if necessary, but these kinds of variations usually involve some fairly major headaches that erode the primary benefits of having a web-based application.

The biggest problem, though, is if you are producing sophisticated and powerful and demanding software products (e.g. scientific computing and visualisation interfaces), the JavaScript + kludged together collection of mismatched hacks that is the web platform is simply not adequate for producing top notch software. Depending on what you are trying to accomplish, HTML5 as a platform is between 10 and 20 years behind what the computers are actually capable of natively. The reason we are impressed when a webapp turns out to be quite good is that we’ve had a long time to be conditioned to having very low standards: in the 1990’s, interactive web pages involved crude forms. In the 2000’s, web pages could do some simple things without having to go back to the server. In the 2010’s, web pages gained limited (but problematic) ability to draw their own graphics, and interact with the platform (e.g. using the clipboard properly, or making use of the right mouse button: cutting edge stuff!). But if you have ever tried to build a webapp to do something that would have been considered moderately challenging 20 years ago, and do it in a way that has few compromises relative to what you know the computer is capable of, you are in for first: a world of pain, and second: either giving up in frustration or accepting that the product just is not going to be as good as you had hoped it would be.

That being said, I do believe that the web has a good chance of being the development environment of the future, but as long as the primary language is still called JavaScript, it will continue to be second rate, and only suitable for some kinds of applications.

So what’s a software developer to do?  The three major options have significant pitfalls… desktop because it’s semi-obsolete, mobile because it’s moving too fast and has too many compatibility issues, and web because the quality is just not there.

For what it’s worth, I think that what will happen over the next half decade or so is that desktop computers will be increasingly made obsolete by mobile devices evolving into desktop devices. Imagine that your phone/tablet/phablet is your basic computing core, but whenever you need a bit of something extra, you plug in a keyboard, a mouse, a bigger screen, another bigger screen, some more memory, a bigger CPU, some storage space, a network cable to get faster access to your cloud-based data and computing resources, etc. Or for people who don’t travel so much, maybe all this stuff sits on a desk and stays plugged in. Maybe it’s inside a beige box and looks exactly like a contemporary PC. The significance of mobile evolving into desktop is that the current desktop operating systems (Win/Mac/Lin) are a deprecated dead end, and same goes for all the software that runs on them. People will be sitting in front of their big screens and keyboards and mice using apps that are memetically descended from current day apps designed for touchscreen operating systems that have been retrofitted to handle “retro” hardware as well as the stuff that can be fabricated into a slab that fits into your pocket.

I don’t claim to know what will happen with the web as a development platform. Will these apps of the future be written for the web, or for whichever mobile operating system dominates and starts eating into the desktop market? If the platform is the web, then JavaScript first has to be flushed away with all the other turds that make up the platform, but it’s already clogging up the drain, so hard to tell if anyone has what it takes to plumb the thing. Maybe Google Dart will solve it: it’s technically possible, but politics and economics will be the decider. If mobile platforms like Android and iOS give in to developer pain and open up to a larger variety of development tools, and more choices for deployment, that could make the primary complaints go away.

One way to hedge is to invest a significant amount of effort splitting your codebase into two parts: one half provides the user interface and whatever calculations need to be carried out in real time; the other half provides blocks of functionality that can be initiated with well defined parameters and operate independently with little-to-no user intervention on the seconds-to-minutes timescale. By splitting the codebase in half and designing an API to connect them, your options are open: you can combine the two halves into the same executable when designing a traditional desktop application; and you can design a native mobile or web-based interface that accesses the back-end functionality through a network protocol. That way at least half of your code will have a long life expectancy, and also the discipline involved in creating such a configuration tends to lead toward code that you actually want to keep around for a long time.

But I doubt there is any way to avoid having to rewrite the user interface a few more times.