Write Once, Run Anywhere

May 3, 2010 Will Read

In response to some recent web browser related debates:

The web has long since tried to help developers realize the [perhaps misguided] promise that you can write software once and run it anywhere without modification. This might have even seemed feasible when the only real consumer web-enabled device was a desktop or laptop PC with a fairly standard monitor resolution, keyboard, mouse – predictable. You could even bank on IE probably being the browser of choice at one point, like Netscape before it.

But then we started getting choices. Your screen might be 17″, it might be 27″. You might be using a keyboard and tabbing around, or you might only have a finger for input. Both hardware and software have been bringing their A games. Meanwhile web developers cried out for standards adherence in an attempt to create the One Ring to rule them all (but with less fiery eyeballs and dead hobbits).

Then phones made us wake up. The iPhone made the first strong compelling argument to target your web app for a specific resolution, input mechanism, and browser. Now we had two views for our website, the iPhone, and the ‘everything else bucket’.

The ‘everything else bucket’ is probably as good for the web as the No Child Left Behind program is for public education. Sure it has merits, like getting stuff out the door, but for tailored user experience, you’d need a lot more teachers and class rooms, or in our case developers.

Subsequently, yeah iPhone, iPad, Android, WebOS apps rock for UX when you do ’em up right, but only because a business has placed value in that UX. Conversely, they’ve said that the UX between Firefox and Safari on a desktop is “pretty much the same” and there’s not a lot of value in differentiation.

What I would be curious to see is how much MVC the Rails Way has paid off in this time of many platforms. My guess is that it hasn’t been nearly as helpful as having an easily consumable API. Yes, there’s overlap in those two areas, but picture an API written without knowledge of the MVC pattern and a well structured MVC web site where you now want to add specific view code for PlatformX. I think nine times out of ten you’ll see the API gets more mileage because the views aren’t one-for-one on different platforms.

What might be a separate menu on a phone, could also be part of a side be on a desktop-like presentation. Now you find yourself writing new controllers, so all you’ve really saved on is the model code, which Rails writes most of that for you – you are only slightly better off than if you decided to write the thing from scratch.

It’s easy to argue for this implementation, or that, or ‘…if you rearrange things, then you can…’, but the problem is that there is a cost associated with catering to any specific platform. Developers have to know the nuances of those systems and be able to test in that specific environment. Then you have to balance that cost with the user base you can expect to gain. Until it becomes so cheap to know all the differences and simulate the all combinations of environments, targeted UX will continue to be a low priority for businesses.

Since I know we aren’t all holding our breath for that day, let me pose what may sound like an even more ridiculous solution: What if you could only get to certain parts of the web using a certain browser? Just like some software isn’t written for the Mac, or Windows, or Linux today, what if you could change the expectation that I can surf to any web site with any browser? What if we went to google.com and it said “Sorry, please use Chrome” would that be so awful? Or I went to cnn.com and it said “This site requires Firefox.” Would you do it if the user experience was amazing?

The two expectations, ‘I can go anywhere’, and ‘I can run my software anywhere’ are what cause us developers to beat our heads against the wall when a new browser comes out, or one deviates from the standard. I think if you can find a way to manage those expectations you can get down to brass tax with your users.

About the Author


CIMonitor (née Pulse)
CIMonitor (née Pulse)

Because of a conflict with another similar application, we've renamed our CI Monitor application (which I b...

BDD-style testing using Objective-C
BDD-style testing using Objective-C

As we've grown our mobile practice at Pivotal we've tried to apply to it the same principles and discipline...

SpringOne 2021

Register Now