Earlier today, Stuart Langridge—who I worked with on WaSP’s DOM Scripting Task Force and have the utmost respect for—published a blog response to my last post. In it, he made some good points I wanted to highlight, but he also misunderstood one thing I said and managed to avoid addressing the core of my argument. As comments aren’t enabled on his site, I thought I’d respond here.
Let’s start with the good stuff:
In this passage Stuart also highlights the quagmire that is CSS support. This is a great point to hammer home: we have no assurance that the CSS we write will be understood by or interpreted the same in every browser. This is why it is so important that we provide fallbacks like a hex value for that RGBa color we want to use. It pays have a solid understanding of how fault tolerance works because it helps us author the most robust code and ultimately leads to fewer browser headaches (and happier users). I devoted a huge portion of the CSS chapter in my book to the topic.
I also loved this passage:
I’ll admit I got a little teary-eyed when he said
The Web has trained its developers to attempt to build something that is fundamentally egalitarian, fundamentally available to everyone.. Stuart is bang on with this passage. Building the Web requires more of us than traditionally software development. In many ways, it asks us to be our best selves.
The one thing I take issue with is that last sentence, but again, I’ll come back to it.
In the middle, his post got a little off-track. Most likely it was because I was not as clear in my post as I could have been:
I am not at all sold that “we have knowledge of [the server environment] and can author your program accordingly so it will execute as anticipated” when doing server development. Or, at least, that’s possible, but nobody does. If you doubt this, I invite you to go file a bug on any server-side app you like and say “this thing doesn’t work right for me” and then add at the bottom “oh, and I’m running FreeBSD, not Ubuntu”. The response will occasionally be “oh really? we had better get that fixed then!” but is much more likely to be “we don’t support that. Use Ubuntu and this git repository.” Now, that’s a valid approach — we only support this specific known configuration! — but importantly, on the web Aaron sees requiring a specific browser/OS combination as an impractical impossibility and the wrong thing to do, whereas doing this on the server is positively virtuous. I believe that this is no virtue. Dismissing claims of failure with “well, you should be using the environment I demand” is just as large a sin on the server or the desktop as it is in the browser. You, the web developer, can’t require that I use your choice of browser, but equally you, the server developer, shouldn’t require that I use your particular exact combination of server packages either. Why do client users deserve more respect than server users? If a developer using your server software should be compelled to go and get a different server, how’s that different from asking someone to install a different web browser? Sure, I’m not expecting someone who built a server app running on Linux to necessarily also make it run on Windows (although wise developers will do so), but then I’m not really expecting someone who’s built a 3d game with WebGL to make the experience meaningful for someone browsing with Lynx, either.
Here’s what he was reacting to:
If we’re writing server-side software in Python or Rails or even PHP, one of two things is true:
- We control the server environment: operating system, language versions, packages, etc.; or
- We don’t control the server environment, but we have knowledge of it and can author your program accordingly so it will execute as anticipated.
In this passage, I was talking about software we write for ourselves, our companies, and our clients. In those cases we do—or at least we should—know the environment our code is running in and can customize our code or the server build if a particular package or feature is missing. In fact, this is such a consistent need that we now have umpteen tools that empower us make recipes of server requirements so we can quickly build, configure, and deploy servers right from the command line. I would never write server-side code for a client running Windows without testing it on a carbon-copy of their Windows server. That would be reckless and unprofessional.
If, however, I was writing code to sell or license to third parties, I’d fall into the second camp I outlined:
In the more traditional installed software world, we can similarly control the environment by placing certain restrictions on what operating systems our code can run on and what the dependencies for its use may be in terms of hard drive space and RAM required. We provide that information up front and users can choose to use our software or use a competing product based on what will work for them.
Lots of people who offer software in this way provide an overview of hardware and software requirements for using their product, and that’s fine. But I feel Stuart was incorrectly lumping the two camps together. He asks “Why do client users deserve more respect than server users?” I agree with the sentiment—the lack of requirements documentation for some third party server utilities is certainly appalling—but if I choose to try installing a given utility or program without knowing if it will work on my system, that’s my choice. And, moreover, failing installs of server-side utilities is a concern that I—a technical-savvy software developer—can readily deal with (or at least that I am competent enough to solve with Google’s help). I don’t think we can expect the same of the people who read our content, check their bank balances on our systems, and whose experience and capabilities may not be the same as ours.
Stuart brings his response to a close with the gloriously uplifting statement—
[B]y any measure the Web is the largest, most widely deployed, most popular and most ubiquitous computing platform the world has ever known.—before declaring, unequivocally,
The first part is dead-on: the Web absolutely is
- Browser Add-ons: We can’t control which add-ons or plugins our users have installed on their browser, but each and every one has the ability to manipulate the DOM, insert CSS, and inject scripts. If we don’t code defensively, we can spend hours trying to replicate a bug report only to ultimately discover the person reporting it had an add-on installed that was causing the issue. I’ve been there. It sucks.
And I, for one, enjoy sleeping.
Note: I no longer use “native” in this context, but it remains in quoted material.