Resilience

lo

You probably heard that the Internet was created to withstand a nuclear attack, right? A network that would be resilient to withstanding a nuclear attack, and that’s actually not quite true. What is true is that Paul Baran, who was at the Rand Corporation, was looking into what is the most resilient shape of a network. And amongst his findings, one of the things he discovered was that by splitting up your information into discrete packages, it made for a more resilient network, and this is where this idea of packet switching comes from that you take the entire message, chop it up into little packets, and then you ship those packets around the network by whatever route happens to be best and then reassemble them at the other end.

Vague but exciting…

And that was the situation with a protocol that was invented called Hypertext Transfer Protocol. It was just one part of a three-part stack of a project called World Wide Web. Hypertext Transfer Protocol is the protocol for sending and receiving information, URLs for addressability, and a very, very simple format, HTML, for putting links together, basically — very, very simple. These three pieces form this World Wide Web project that was created by Tim Berners-Lee when he was working at Cern. What I kind of love is that at this point it only exists on his computer and he still called it the World Wide Web. He was pretty confident.

HTML

Just looking at one piece of this, let’s just look at HTML. It’s a very simple format. To begin with, there was no official version of HTML. It was just something Tim Berners-Lee threw together. There was a document called HTML Tags, presumably written by Tim Berners-Lee, that outlined the entirety of HTML, which was a total of 21 elements. That was it, 21 elements. Even those 21 elements, Tim Berners-Lee didn’t invent. He didn’t create them, most of them. Most of them he stole, he borrowed from an existing format. See, the people at CERN were already using a markup language called CERN SGML, Standard Generalised Markup Language. And so by taking what they were already familiar with and putting that into HTML, it was more likely the people would use HTML.

<div>
show me
</div>
<foo>
show me
</foo>
<main>
show me
</main>
<canvas>
hide me
</canvas>
<img src alt>
<img src alt srcset>
<picture>
<source srcset>
<source srcset>
<img src alt srcset>
</picture>

CSS

It’s similar with CSS. It has a very similar way of handling errors. Now CSS, I know a lot of people, especially from the JavaScript world, really like to hate on CSS, but I kind of love CSS and I’ll tell you why. If you think about all the CSS that’s out there, and there’s a lot of CSS out there because there are a lot of websites out there, and they’re all using CSS. The possible combinations are endless. Yet, all of it — all of it comes down one pattern: selectors, properties, values. That’s it. That’s all the CSS that’s ever been written — one simple, little pattern.

selector {
property: value;

Postel’s law

Be conservative in what you send. Be liberal in what you accept, because that’s what browsers are doing. They’re being very liberal.

JavaScript

Now, CSS and HTML, I think, can afford to have this robustness principle and this error tolerant handling built in, partly because of the kind of languages they are. CSS and HTML are both declarative languages. In other words, you don’t give step-by-step instructions to the browser on how to render something when you write CSS or HTML. You’re just declaring what it is. You’re declaring what the content is with HTML. You’re declaring your desired outcome in CSS. And it’s worth remembering every line of CSS you write is a suggestion to the browser, not a command.

<a href="javascript:void(0)">
Download Chrome
</a>

Murphy’s law

He was a real person. He was an aerospace engineer. And because he had this attitude, he never lost anybody on his watch. And like Postel’s law, I see Murphy’s Law in action all the time, and particularly when it comes to client side JavaScript because of the way it handles errors.

  1. Step two: Make that core functionality available using the simplest possible technology.
  2. Step three: Enhance, which is where the fun is, right? You want to spend your time at step three, but take a little time with step one and two.

Identify core functionality

Let’s go through this. Let’s look at the first bit. Identify the core functionality. Let’s say you’re providing the news. Well, there you go. There’s your core functionality: providing the news. That’s it. There’s loads more you can do as well as providing the news. But when you really stop and think about what the core functionality is, it’s just providing the news.

Make that functionality available using the simplest technology

Okay. Now that you’ve identified the core functionality, make that functionality available using the simplest technology. By the simplest technology, that means you’re probably wanting to look as far down the stack as you can go.

Enhance!

Now if you were to stop at this point, what you have would work, but it would be kind of shitty. Okay? The fun happens at step three where you get to enhance. You take your baseline and you enhance up. This is where you get to differentiate. This is where you stand out from the competition. This is where you get to play with the cool toys where you get to make something much nicer.

Scale

That’s how you make websites, that three-step process. And what I like about this three-step process is that it’s scale-free, which means it works at different levels. I’ve just been talking about the level of the whole service, the product or the service you’re building. But you could apply this at different scales. You could apply it at the scale of a URL. You could ask: What is the core functionality of this URL? How do I make that functionality available using the simplest possible technology? And how can I then enhance it?

This is too easy

But I do get pushback on this, and the pushback falls into sort of two categories. One that this is too easy. Or rather, it’s too simplistic. It’s naïve. It’s like, “Well, what you’re talking about, that will work for a simple blog or personal site, but it couldn’t possibly scale for the really complicated app, the really complicated corporate site that I’m building.”

This is too hard

But the other pushback I get is that this is too hard, it’s too difficult. And I have some sympathy for this because people look at this three-step process and they’re like, “Wait. Wait. Wait a minute. You’re saying I spend my time making this stuff work in the old fashioned client server model, and then at step three, when I start adding in my JavaScript, I’m just going to recreate the whole thing again, right?” Not quite.

Everything is amazing and nobody’s happy

We’ve seen this over and over again that we’re constantly complaining about what we can’t do. It’s like, “Ugh! We’re not there yet. The web — the web kind of sucks when you compare it to Flash,” or, “the web kind of sucks when you compare it to Native.” It goes back a long way, right?

--

--

A web developer and author living and working in Brighton, England. Everything I post on Medium is a copy — the originals are on my own website, adactio.com

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jeremy Keith

Jeremy Keith

14.2K Followers

A web developer and author living and working in Brighton, England. Everything I post on Medium is a copy — the originals are on my own website, adactio.com