Power of the platforms

Uncertainty is a feature, not a bug.

Image: CC BY 2.0 NASA's Earth Observatory via Wikimedia Commons  http://commons.wikimedia.org/wiki/File:Southern_Lights.jpg#mediaviewer/File:Southern_Lights.jpg

After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.

Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.

Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.

Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing?

Absolutely. That barely functional but unstyled approach made it possible for many many different people to create many different tools for creating and presenting that content. The web crossed platforms rapidly, as environments rushed to add browsers; browsers started running across multiple environments; and many environments found themselves with multiple options available. It wasn’t all just browsers, either — writing code that scraped or otherwise interpreted web content wasn’t that hard.

Two decades of almost continuous adding and tinkering brought us a much more powerful web, an environment that makes it hard to remember the tiny beginning. Though web standards are as driven (and riven) by committees as anything in the programming world, the separation between the creators of the rules and the platforms on which they run gives web technologies much fruitful space for experiment. The pacing has been uneven, with the browser wars rush followed by a long fallow period and then a race forward into HTML5. As devices have evolved, web technology has found ways to include new features. The competition many of us feared we’d lost when Internet Explorer ruled the roost is back.

But yes, this makes things complicated. Programmers who work in a world where they can control the execution environment often expect the same control on the web. As much as I like “the Web Platform” sparing me syllables over HTML, CSS, JavaScript, and more, Jeremy Keith is right: treating the web as a platform with all the brittle expectations of a platform is a terrible idea.

So stop being brittle. The web bends with the wind, supporting incredibly diverse use cases across a wide variety of environments. Your code should, too.

Editor’s note: If you’re ready to scrap the rules you’ve relied on all these years and embrace uncertainty as a core tenet of design, check out The Uncertain Web, by Rob Larsen.

This post is part of our ongoing exploration into the explosion of web tools and approaches.

Cropped “Southern Lights” image by NASA’s Earth Observatory, licensed under Public Domain via Wikimedia Commons.

tags: , , , , , , ,

Get the O’Reilly Web Platform Newsletter

Stay informed. Receive weekly insight from industry insiders—plus exclusive content and offers.

  • Geoff Butterfield

    As a long time webdev, I totally relate to your desire to use the best tools, or the tools you find most interesting, but as a site manager, with a site with over 15 years of web content and hundreds of projects, I can’t recommend this approach. I agree that there will always be a level of uncertainty and we should embrace this, but I also believe we need to be more thoughtful about the longterm ROI of our technology choices. As an example, I contracted a developer to build a small report site, and that developer’s tool of choice was Rails. Rails was not a good choice for us, as we had no other Rails sites running, and little to no experience deploying a Rails site. In the past, I might have agreed to just go for it, but my reality is that I have no budget or time for this kind of exercise. Instead, they built it in PHP. Not as sexy, but frankly, its a better long term decision for the organization (lower support costs) AND the audience, who could give a rats ass about whats on the backend.

    There are two camps of web developers in my view: the short-term deliverable folks (contractors) and the long-term, in-house folks (any site with a lot content like newspapers, magazines, etc). I suspect each group would have a very different perspective. This is a good topic though, I want to agree with you, but I feel like its self-indulgent.