DRY: Do Repeat Yourself

I am increasingly of the opinion that the general software engineering adage “Don’t Repeat Yourself” does not always apply to web development. Also, I found that web development classes in CS academia are not very realistic.

These two problems turn out to have the same root cause: a lack of appreciation of what browsers do to software development. Browsers, to misquote Douglas Crockford, are the world’s most misunderstood development platforms.

Repeat yourself!

Web developers have been proudly repeating themselves for fifteen years now. Who remembers this bit of JavaScript?

if (document.layers) { // do this } else if (document.all) { // do that }

Or take CSS prefixes:

background: -webkit-linear-gradient(0deg,red 10%,yellow 30%,green 60%); background: linear-gradient(90deg,red 10%,yellow 30%,green 60%);

Repeat, rinse, repeat. You will say: “Yeah, but that’s just because of browsers.” And you are totally right. It’s all about browsers. But it’s not just about browsers. The fact that they’re different is not an aberration; it’a the keystone of web development. The variety of browsers is what requires us to repeat ourselves. But CS people don’t understand that.

Repeat yourself!

There’s another way of repeating ourselves than just different lines of code — a more conceptual way, if you like. Some progressive enhancement strategies consist almost exclusively of repetition.

Take a product list page on a site. Often it’ll show twelve or so products, and when the user scrolls or clicks a button more products are loaded. This load process uses some sort of Ajax call, and that is fine by itself.

However, we also want to be able to load the next set of products without JavaScript — not because people turn off JavaScript (they don’t) but because the script may have gone missing because of a network hiccup (especially on slow mobile connections), or because the user’s uncommon browser does not understand one line of code.

Again, we must repeat ourselves by creating a server-generated template in addition to the Ajax script. The button will link to the template, although Ajax will override that if the JavaScript is fully loaded and supported. This is a requirement, by the way, and not a nice extra. It’s the fundament of web development. Not repeating yourself is unprofessional in this situation.

Then there’s the question of the initial set of products. Once you’ve created an Ajax script it becomes tempting to use that script for loading the initial set as well. Hey, we already have the script, we shouldn’t repeat ourselves, so why not use it?

Well, it could take quite a while for the script to load (especially if it has those silly dependencies) and then load the product set. Thus, the user could be staring at a blank screen for a few seconds, which is bad web development.

Instead, we should make sure that the HTML page itself as generated by the server contains the initial set of products. Once they’re being shown on-screen the Ajax script can kick in for the updates, but using it for the initial set as well is a bad idea.

You see? Repeating yourself is fundamental to web development.

Web development in academia

Let’s take a quick detour to a related problem. A while ago I asked:

Why is web development in academia taught as a design discipline instead of a computer science discipline?

This elicited a few interesing responses. I had a short but useful discussion with Dan Nguyen, who lectures at Stanford, and who pointed me to a Web Applications course description that states:

For this class, the reference browser is Chrome: your project solutions must work on Chrome, and the CAs will use Chrome to test them. Your solutions need not work on any browser other than Chrome.

This is not web development. It’s a sanitised, abstracted form of quasi-web development that does not prepare students for real-world web development in any form. Also, too, Angular.

Dan’s counterargument was that many other CS classes define an IDE in order to simplify things for the students. And isn’t simplification and concentrating on principles the purpose of university courses? I suppose so, but in this particular case the students are learning the opposite of what they’re supposed to. (Also, Chrome is not an IDE. It’s a browser.)

If it were my course I’d take a big bag of mobile phones, each with several browsers, and I’d test each classroom project on two randomly drawn phone/browser combinations over the worst available network connection. The classroom projects do not need to work perfectly — instead the student would have to explain why the way the site works in this particular browser is the best way it could work. Of course they’d be free to test on the phones as often as they like and I’d help them work around browser incompatibilities.

Another problem I found is that university courses try to teach too much at once; this curriculum from Prague reinforces that. They want to go full-stack, i.e. teach both front-end and back-end development in the same course. Despite the fact that both have to do with websites they are totally different disciplines: back-end development does not deal with browsers while front-end development does. It’s far better to teach the principles of each form of development separately.

Unconscious assumptions

Why is web development so misunderstood? And why are common principles like DRY invalid? I said the answer is browsers, but I didn’t yet explain why that is. Let’s dig a bit deeper.

The “Don’t Repeat Yourself” principle (and, I suspect, other software engineering best practices), as well as the CS web development classes we reviewed, rest on the unconscious assumption that the platform the software will run on is known exactly. But, as I wrote before, that is not the case on the web.

On the web you never know what you’ll get. The latest Chrome on a modern Mac? Or an outdated UC on a vague Chinese Android? Your site should work in both (though that doesn’t mean it should work the same).

Where other platforms consist of one rigidly defined environment, the web consists of thousands of related yet different platforms, and you can test on only a few of them. We web developers have known that for years (or, at least, we should have), but software engineers from other disciplines are frequently confused by this state of affairs.

Instead, they think the web is just one platform, and learning JavaScript is enough to get started on the web. And that’s object-oriented JavaScript, mind you, because that’s the only proper way of doing things. As to browser incompatibilities, they will say their app is far too advanced to run in older browsers anyway — or similar nonsense.

It’s easy to make fun of such people. It’s far harder to teach them proper web development. That’s partly because “real” software engineers are convinced that only they know how software engineering “really works” and don’t want to listen to a bunch of jumped-up hippie pixel pushers without a CS background that refuse to bow down to the eternal beauty and truth that is object-oriented programming.

Still, another part of the blame must rest with ourselves: we’re pretty bad at explaining our craft in terms non-web developers can understand, and we use impenetrable jargon as well as any other type of specialist. Pseudo-class? Haha, it’s a pseudo-element, you silly amateur!

This article, in fact, is a first attempt to find a line of argument to convince non-web developers, though you’ve probably noticed it still needs considerable work before it will appeal to them.

CS thesis topic

As we’ve seen the “Don’t Repeat Yourself” principle does not always apply to web development. I’m fairly certain that other principles of software engineering or computer science have a similarly strained relationship to the reality of web development.

Problem is: I can’t tell which ones because I don’t have a computer science background. (In case you’re wondering, my degree is in ancient history, specialisation Later Roman Empire. Precious little software around in those days. Lots of Huns, though, who can also be fun.)

I would very much like some sort of computer-science person to take a good look at web development, accept that it differs from other forms of software development because of the myriad platforms, and help us out on a theoretical level.

So if you’re a CS student looking for a good thesis topic: hey, you found one!

And don’t hesitate to ask for help: despite appearances web developers can be pretty friendly to people who want to really learn web development — and if they notice you’re working on embedding web development theory in a CS context they’ll be even more excited.

The only real requirement from your side is that you’re willing to jettison theoretical considerations that don’t make sense on the web. In other words, you should be willing to think outside the CS box and learn.