Lessons on Mobile Platforms from an Ancient JavaScript Game

I recently realized that I’ve been continuously programming in JavaScript for about 16 years. That is, I’ve been writing at least little snippets (and sometimes heaps) of JavaScript at least once a month for 16 years. 16 years! That’s insane. That’s a much longer run than I’ve had with any other language, and it doesn’t look like it’s going to end anytime soon. The funny part is that I’ve never been particularly fond of JavaScript as a language, but there is just no way around it as long as I continue do some sort of web development. I suspect that a lot of other developers who came of age in the late 90s have reached similar accidental JavaScript seniority and that would partly explain why by some metrics it’s on track to become the world’s most popular programming language.

Reminiscing about my early exploits in JavaScript, I searched through my backups to unearth a game I wrote in 1998 and included in my very first application for a paid programming job (I got the job). I was shocked to discover that in a modern browser the game still works exactly as intended, with zero modifications to the code. Here it is, in all its original low-res 90s glory: AsteroidMan, a PacMan clone written in JavaScript.

Screen Shot 2013-11-10 at 1.39.29 PM

In 1998, Netscape 4 and Internet Explorer 4 were the browsers at the cutting edge. They didn’t support much manipulation of the DOM yet, but it was possible to dynamically change the value of a form field — and the source of an image, which enabled games like this one based on a grid of images. One other neat technique for client-side apps I remember from that time was to use frames (yeah, frames, not those new-fangled iframes) to keep global JS state in the parent document, which was preserved across page navigation in the child frames. In my backups I also found a LucasArts-style adventure game I wrote that way. No, it’s too embarrassing to post now.

What do we learn from this exercise in JavaScript archaeology? The web is an insanely good application distribution and execution platform. I opened that HTML page from my backups in a browser and it looked and worked exactly as it did 15 years ago. There was zero installation or configuration required. The game does not only work in recent Chrome, Safari and Firefox on my laptop, it runs on my Android phone and on my iPad. I doubt any more traditional client software written 15 years ago would still run in a modern incarnation of the target platform, especially with zero installation and configuration by the user. Imagine a Windows 98 app running on Windows 8 (that’s a brilliant versioning scheme right there, Microsoft). The web platform is singular in how extremely portable and backwards compatible it is.

Here’s what this means for today. In case you hadn’t noticed, there is currently a big trend away from web apps towards native apps, namely iOS and Android apps. I seriously doubt a native iOS or Android app written today will work in a modern iOS/Android environment in, say, 4 years from now. I can guarantee you that neither iOS or Android will even still be around in a recognizable form 10 years from now. As platforms they are very likely a dead end while the web has a proven track record of being very open ended.

Unfortunately the current trend is unlikely to reverse soon because for now those platforms are a very profitable dead end, both for the platform stewards and for the programmers who serve them. If you have only rudimentary Android or iOS skills you should have no problems finding a well-paying job right now. The trend is a bit less profitable or downright onerous for creators of consumer products (that would be me and also my employer) because building natively for both iOS and Android and maybe even Windows Mobile is an expensive time sink.

I don’t expect any innovation from Apple in this regard since they have always been all about user and developer lock-in. But in my mind Google has a huge opportunity here. Google should push to make web apps first-class citizens in Android. Basically, an Android app may be a light-weight wrapper around a web app with some JavaScript APIs to call out to device APIs. This isn’t a novel idea, Phonegap and others have been trying to tack something very similar on top of Android, but it would help immensely if this approach was sanctioned and widely promoted by Google and ideally developed into an open standard. Such a fairly simple extension to the web has a much better shot at a long shelf life and at getting adopted by other mobile environments. It should also dramatically smooth out the pretty steep learning curve for Android development and thus increase Android’s developer mindshare.

The lesson for developers should be obvious: Think twice before you embark on a mobile-first strategy with native apps only. Consider Phonegap or other hybrid frameworks. Especially if you’re building for longevity or for low maintenance cost, for heaven’s sake, just build a web app.