Write once, run everywhere…. suboptimally

hsoi blog, talk 0 Comments

Being a graybeard, I’ve seen all sorts of computing fads come and go.

Unfortunately, after so many have come and gone, people still chase this notion of “write once, run everywhere”. That they can write the piece of software once, and it’ll (magically) run everywhere. It’ll run on Windows, it’ll run on Mac. And these days, it’ll run on iOS and run on Android, and run on the web, and on desktop computers and mobile devices, and the list goes on.

Alas, this never really works out. There’s always a shortcoming somewhere, and what usually comes up short is the quality of the software, and then the user satisfaction.

A most recent example is Facebook’s app for iOS devices. I could tell it was not a native app but a web app. Not because it was abysmally slow, but by the designs and other behaviors. But yes, what makes the app horrible to use is that it’s so wicked painfully slow. Yes it gets quirky at times too, but it’s the glacial speed that kills it. Given it’s one of the most popular and widely used apps, and people spend a long time in the app (relatively speaking), performance matters. It might be one thing if it was some throw-away app that someone uses for 2 minutes once a month or never again, but this? No… bad choice.

And Facebook now realizes their mistake. Apparently they are rewriting the app as a native iOS app because of the speed problems.

One of the Facebook engineers said the new application has been built primarily using Objective-C, the programming language used to build applications for iOS. Many of the components of the current version of the Facebook app are built using HTML5, the Web-based markup language.

The current version of the app is essentially an Objective-C shell with a Web browser inside. When it comes to speed, this is like putting the engine of a Smart Car in the body of a Ferrari.

Applications that are predominantly HTML5 render most of the components of an app as a Web page, pulling images and content from the Web directly into the application. Objective-C takes the opposite approach, taking full advantage of the hardware in the iPhone and then building most of the functionality directly into the application so it has to collect less information from the Web.

The technical explanation isn’t quite right, but it’s good enough for a non-technical article.

Why did Facebook choose to write this way? The panacea.

In late 2011, Dave Fetterman, an engineering manager at Facebook, told an audience at Facebook’s f8 developer conference that the company had chosen to build its apps predominantly using HTML5 so that it could take advantage of reusing programming code across multiple mobile platforms.

This proved to work for developers at Facebook, reducing the amount of work they had to do across mobile apps, but has backfired for users, who have seen the app stretched to its limits as more functionality has been added over time.

HTML5 has a lot of promise. Since the earliest days of the Web, people have sought a way to make the Web THE platform and be able to have full-on apps like Word or Photoshop exist on the web… thus they could charge subscription/service fees (i.e. farily consistent and predictable revenue stream), plus access anywhere. But web technology just isn’t up to that task. Sure we’re far better now than ever before and HTML5 gets us closer, but it’s still not there.

And look what it caused for Facebook. Tons of ill will, unhappy customers, and now they have to spend lots of time and effort to write the software again the way they should have done it in the first place. While perhaps it was a good and needed technology exploration to help us learn the limits, it was a costly one. Only time will tell if it was worth it.

But this is generally what happens. Everyone wants to write once and run everywhere in hopes of reducing development cost. But in the end it only increases it, beyond simple financial cost. It creates a lesser product. It creates reduced satisfaction in customers. Yes sometimes you can kinda sorta pull it off. I look at apps like Poser, and the unique nature of that product requires its own environment so you can get away with it, tho it gets kinda quirky. Moneydance is written in Java, and while it works for the most part and you can tell the engineers strive to be as non-quirky as possible, it’s still quirky and not really savvy to the platform; many “normal” things I do as a Mac user just aren’t there, but I still use the software because under the hood it’s solid financial software and I just have to live with the less-than-optimal experience.

I can understand the costs with iOS and Android. It’s not too horrible on Mac and Windows because you can write code in a manner where core engine logic is shared and only what must vary can vary, like the GUI. But iOS is mostly a C-based system whereas Android is Java, and it’s quite hard to share code between the two. There are engines that try to, mostly for games, but most others takes a HTML/JavaScript-based approach and well… it just yields a less than optimal product. It’s possible it might work out for your needs, but you’ll never have a “best of class” product with this approach. But for some, being crappy is acceptable… I just have higher standards.

It’s a good thing to minimize development cost. It’s good to share code. It’s good to be efficient. It’s good to keep cost down. But remember, cost isn’t just in the accounting ledger. Time. Resources. Customer satisfaction. Company, product, and brand reputation. These things are costs too. The siren song of “cross platform” and “write once, run everywhere” is a seductive one, and there’s always some new technology or SDK trying to answer the call. Could it be the right answer? Maybe, just don’t be blind in your assessment.

Leave a Reply