# The Layers Of The Web - Jeremy Keith

{%hackmd j86FNbMoRoeN4Xn0pg5ofw %}

[簡報 (PDF)](https://s.itho.me/modernweb/2018/day1_keynote_Jeremy%20Keith%20-%20The%20Layers%20Of%20The%20Web.pdf)

## 逐字稿

It is an honor and a pleasure to be speaking here today. I've never been to Taiwan before, so I am really enjoying it.

It's a great honor to be the first speaker ahead of 2 days of facinating talks about technologies possibly of the future.

I want to talk about where we are now, the present, and where we are going, the future. Now, trying to predict the future, that's very hazardous. That's not something I would try to present.

But other people have taken a good attempt at predicting the future.

In science fiction, this is something we do all the time, looking into the future says something about our present.

A good example of this would be the film, "2001: A Space Odyssey", by Stanley Kubrick and Arthur C. Clarke. With it, they made an incredible attempt at trying to predict the future.


Remember this film was made in 1968, 50 years ago. We haven't even gotten to the moon 50 years ago. Again, this film made a good, accurate attempt at predicting the future.

Here, we see someone interacting with a computer, using natural language, artificially intelligent computer, and they are playing a game of chess together.


Now I can imagine how this must have seem to audience in 1968. OK, human beings conversing with computers using natural language. That seems reasonable. Computers beating human beings at chess. That seems inplausible.

And of course, it turns out beating human beings at chess was the easy part. Making computers understand natural languages, that's still a tough challenge.

Even in this film, when it got so many right about the future, it still has some interesting aspect of prediction, it didn't quite get right.

So in this future, when someone wants to make a phone call, a video call, you go to a phone somewhere attached to a wall.


They never predicted we would be walking around with a phone in our pockets. We could make a video call with a phone in our pockets.

I didn't say this to point fingers at films like "2001", and say, "Oh, they got it wrong with mobile phones or they didn't predict mobile phones".

It's more to say, "They couldn't predict mobile phones." Mobile phones were one of those things that's almost unpredictable.

Give you another example. The film, "Blade Runner", 1982, directed by Ridley Scott. In this future, we have flying cars, we have off-world colonies, we have genetically engineered replicates.


Yet again, when the main character wants to make a phone call, he goes to a phone attached to a wall. The idea of mobile telephones making video calls wasn't predicted, wasn't predictable.


Of course, this has some ???? effect. So when we see the main character passing the time, he wasn't passing the time with his mobile phone. He was passing the time in this future reading a newspaper. This is the future with flying cars, off-world colonies, genetically engineered replicates.


When we look at the headline of the newspaper, we see some very futuristic headlines, farming the oceans, the moon, and the Antarctica.

We also have a very interesting headline here: "World-Wide Computer Linkup **Planned**". It doesn't exist, but it is planned.

So this future, flying cars are predicted, space travel, off-world colonies, all predicted. But the idea of a world-wide computer network, that's still on the way. That's still far future.

And so, we have this ???, not only do we walking around with mobile phones in our pockets, that are effectively super computers, but we also have a world-wide computer network.

So our present is a future that is almost inconceivable to predict. Certainly, a lot of time, our present feels like a science fiction of the future. Right?

Every day, we see news headlines saying new advances in technology, and it certainly feels like, like the future.


We got self-driving cars, drones, A.I., AR, VR, the block chain, right? All of these things are very futuristic.

But if these were science fiction, I have to wonder what science fiction story am I in.

Am I in a utopia (烏托邦), or dystopia (反烏托邦)? Is it a dream, or a nightmare?
And what is the difference between the two?


Perhaps the only difference between them, utopia or dystopia, is one with perception. It is how we feel about these technologies; it is how we make use of these technologies.

When I am trying to analyze my own feelings about futuristic technologies, see what I feel about some of these technologies. I find my feelings falling into two categories: either I am really excited about some technologies, or I am very apprehensive (憂慮) about others, or even fearful about some technologies.


I've been asking myself, WHY?
Why am I apprehensive; yet, sometimes, excited?

So to answer this question, why do I feel this way about technology? There is one possible answer, comes right from [Douglas Adams](https://en.wikipedia.org/wiki/Douglas_Adams).

> Anything that is in the world when you are born is normal and ordinary and is just the natural part of the way the world works.
>
>Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
>
>Anything invented after you're thirty-five is against the natural order of things.
>
> [name=Douglas Adams, author][color=#90b7f7]

So maybe that's it. Maybe I am just old. That's why sometimes I feel very apprehensive about technology.

But that can't be it because I still sometimes get excited about other technologies.

I am not just talking about, you know, flying cars or self-driving cars, drones, AR's, A.I., all these stuff.

I am talking about the technologies we use to build on the web.

I feel a lot apprehension about the shear amount of technologies that seems to coming at us all the time. I feel overwhelmed. It feels like too much.

I've been making websites a long time, 20 years now. Yet, I feel apprehensive about the current state of technology on the web.

My friend, Frank Chimero, he's also been making websites for over 20 years. He wrote something very interesting recently. He said, I wonder if I had 20 years of experience making websites, or is it really 5 years of experience repeated 4 times? [^FrankChimeroQuote]

Because it feels like every 5 years we have to learn so many new things, ???? threw out the window and figure out how to make websites again.

Now I think I would be absolutely fine, even excited if the way we got from where we are now to where we are going felt like this.


The new technologies are emerging, and I am fine. I am learning them as I go. There is a nice, steady upgrade path from the present to the future.

But a lot of time, it doesn't feel like this. It feels more like this.


All of a sudden, there's so much stuff to learn, so many new technologies. This is where I got the feeling of apprehension, or even fear.

But I don't fear change. I fear the rapid rate of change. That's a crucial difference.

It's not about the change. It's about the rate of change.

If we are going to talk about the rate of change. There is an interesting idea I want to bring up.

It is an idea from a book about architecture. The book is called, "[How Buldings Learn](http://www.books.com.tw/products/F010482073)", by [Stewart Brand](https://en.wikipedia.org/wiki/Stewart_Brand).

In this book, Stewart Brand talked about the work by a British Architect named [Frank Duffy](https://en.wikipedia.org/wiki/Frank_Duffy_(architect)). And Frank Duffy talked about the idea of [Shearing layers](https://en.wikipedia.org/wiki/Shearing_layers).


He said, a building ??? conceived, is several layers of longevity (壽命). So the site that you put your buildings on top of. We are talking about geological timescales, thousands of years, maybe.

The structure of a building, maybe that stays the same for centuries. But then as you get to the surface of the infrastructure, you might want to change that every few decades.

And the walls, the doors, those can change every few years. Until you finally get to the stuff inside the room, the furniture, you can change that on a daily basis.

So these rate of change are getting faster as you move further inside the building.

Now, what I find interesting about shearing layers, is not just each layer has different rate of change, but also each layer depends on the layer below.

You can't have a structure until you have a site of your building. You can't put infrastructure, the surface in place until you have outer walls. You can't have furniture in the room until you have walls and doors of that room.

So Stewart Brand took this idea of shearing layers from architecture. This idea of different rate of change, and he applied to, well, everything.

He came up with this idea of "[Pace Layers](http://longnow.org/seminars/02015/jan/27/pace-layers-thinking/)". It's really a system of thinking that everything, any kind of system, works at different rate of change. And here, he applied it to the human race, the different rates of change in the human race.


At the lowest layer, you got the physiological (生理) nature of human beings that take tens of thousands of years, or even longer to change.

So there's very little physiological difference between a caveman and an astronaut.

Above that you got culture, these are centuries and centuries of accumulated knowledge of musing.

Governance, you don't want that to change too quickly; it can be very disruptive.

Infrastructure, you want that to change a little bit faster so you can keep pace with the change of life.

You start to get to commerce, much more faster paced. You don't think very long term when it comes to commerce. Most businesses don't last longer than 10 years.

And then finally, you got fashion. Art. These are the stuff that's supposed to move quickly. It would be a very boring world if fashion stays the same for long period of time.

And by fashion, I also mean things like pop music, art, the whole point of this is to move quickly, to try lots of new stuff, to say, what about this, what about this, try lots of new things quickly and discard stuff.

Sometimes the good idea is to move down the layers so it begins as fashion and ends up as culture.

So talk about pace layers, and the difference between these are rate of change.

> Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous.
>
> Fast and small instructs slow and big by accrued innovation and by occasional revolution. Slow and big controls small and fast by constraint and constancy. 
>
>Fast gets all our attention, slow has all the power.
>
> [name=Stewart Brand, author][color=#90b7f7]

> In a durable society, each level is allowed to operate at its own pace, safely sustained by the slower levels below and kept invigorated by the livelier levels above.
>
> [name=Stewart Brand, author][color=#90b7f7]

And with this, with this way of thinking, I begin to understand more about my feelings about different technologies.

Why am I sometimes excited and sometimes apprehensive?


I think the apprehension comes from this idea of something moving maybe in the wrong pace layer, maybe the rate of change feels like it should be slower or faster.

This idea of things at right rate of change.

So when I look at what kind of things am I excited about versus what kind of things am I apprehensive about.

I start to categorize the technologies.

For example, I am much more excited about the materials of building on the web than about the tools we use to build on the web.


When I talk about materials, I mean the building block of the web: HTML, CSS, and JavaScript.

I still get excited when new features are added to HTML, CSS or JavaScript.

But then there's tools we use, and there's lots of them. I just don't get as excited about these tools. And sometimes like I said, I feel apprehensive because there are just so many of them.


Now these particular tools here, we are talking about things like version control, preprocessors, transpilers. Eh, all these kinds of tools that you use on your computers, but the outputs are going to be HTML, CSS, and JavaScript.

So when it comes to these kinds of tools. I don't have much of an opinion. I am not excited about them, not really apprehensive about them either. I just don't care about them as much.

The point is, you can use whatever you want. You can use some of these tools. You can use none of these tools. You can use all of these tools. And it really doesn't matter to me because the end result is going to be HTML, CSS, and JavaScript.

These tools sit on your computer. They are there to help you work faster, work better. So choose the tools that work for you. It doesn't make any difference to me.

But there's another category of tools that I don't think can be evaluated the same way.


These are also tools for building on the web. But the difference here is that these tools are built with the material.

A CSS framework is built in CSS. A JavaScript library is built in JavaScript. And now, I don't think it make sense to simply say, "use whatever you want", because the user is going to pay the price here.


If you use a CSS framework, the user has to download the framework so that you, as the developer, get the benefit.

If you use a JavaScript library in the client (the browser), the user has to download the library so that you, the developer, get the benefit.

And I don't think that's the right balance.

And another reason I don't get excited about frameworks and libraries is again, I've been making websites for a long time, and I've seen frameworks just come and go. This costs of me new JavaScript frameworks.

There probably are new JavaScript framework releases since I started beginning this talk. Always new frameworks.

Overtime I learnt not to get too attached to these kinds of frameworks and libraries.

Whereas the materials, these are good, long-term investment. When something lands in the browser, it just stays there. So I like to treat these tools as cattle, not pets.

These move at a faster pace than these layers. And there's those two. That's the whole point. You couldn't ??? like fashion. Try this, and try that. See what works. And what works well ends up moving into the materials.

And fundamentally, I don't get too excited about these tools because I feel they benefit the developer maybe more than they benefit the user.

And when I get excited about technologies, it's usually because the technology directly benefits end users.

And the technologies that I am not excited about, very often they are technologies that benefits the developers.

I am not saying they are bad technologies; they are probably very good technologies. I personally just don't get that excited about them.

My friend, Charlie Owen, once said on the twitter.


So this idea of pace layers, of things moving at different rates of change, is something that I think we can apply to the technologies of the web.


At the very lowest layer we got the Internet. TCP/IP, the protocols for packet switching on the Internet. It has been the same for decades now. That feels very simple, very steady.

On top of that, we have HTTP, Hyper Text Transfer Protocol, that has changed overtime. Now we have HTTP/2. That took a long time. And that feels correct that it took a long time. These are layers we don't want swapped out too quickly.

And we have URLs, the addresses on the web. I wish the URLs were at the lowest layer, and they never change. Unfortunately in realities, they do. But, we should work hard to keep them as constant as possible.

And the technologies we are building, HTML, it doesn't change that often. The last big change was HTML5 back in 2010. That feels OK.

CSS, we get new stuff more often. Most recently with CSS grid, flexbox, other layout tools. But it still feels like the pace of change is enough to keep track of.

And there's JavaScript. And I don't mean just the language, but the frameworks, the ecosystem, the tools you are on JavaScript. And that feels a little overwhelmed. And that feels constantly new stuff.

God, when I see it, that's part of these pace layers that makes more sense. I begin to get more comfortable with the fast pace of change of JavaScript ecosystems because it supposed to be fast changed.

We are supposed to try things out in JavaScript; see what works; throw things away; keep the stuff that works well.

For example, the early use of JavaScript was things like image rollovers, or form validation. And now, we don't even need to use JavaScript for that. Because those things have moved down the layers into CSS and HTML.

> Fast learns, slow remembers.
> Fast and small instructs slow and big.
> Fast gets all our attention, but slow has all the power.
>
> [name=Stewart Brand, author] [color=#90b7f7]

I found when I build on the web. I like to build in this way. To begin with the simplest of technologies, start designing my URLs, URL-first design.

Then I think about the HTML, the structure, the presentation, then the behaviors with JavaScript.

And I think this makes sense. I think this is a sensible way to build the web. But as a testament (見證) to the power of the web, you don't have to build it in this layered way.

If you want, you can build it like this. And a lot of people do build like this.


We are on the Internet. It's on the web. But then everything is done in JavaScript. The URL routing, done in JavaScript. The DOM, generated in JavaScript. CSS, in JavaScript.

This is the architecture, for example, of a Single Page App (SPA).

And like I said, it's a testament of the flexibility of the web. It gives you a lot of choice. You can choose to build it in a layered way, or you can jump straight to the top stack.

Now the reason why I don't like building in this way is it results from my experience is either it doesn't work at all or it works great.


And I much rather build something that offers the layers in between. And it goes through something that doesn't work at all, something that just about works, works fine, works well, and working great.


This makes sense on the web, I think. Because this model, we just go from it doesn't work at all to works great, and nothing in between.


It makes complete sense for other beings. For example, if you are building for native, this is how you build. If you build an iOS App, and I have an iOS device, it works great. But if you build an iOS App, and I have an Android device, it doesn't work at all. You can't install an iOS App on an Android device.

It was the same when we used to use Flash. If you build using Flash, and I have a Flash plugin, it works great. If I didn't have a plugin, it doesn't work at all.

So this way of building does make a lot of sense for other field of software. But to do this on the web, it feels like a missed opportunity. Because on the web, we can give people an experience tailored to their capabilities in this layered way.


We cannot not build in this layered way. And I wonder why that is. I wonder if it has to do with the tools. Maybe it begins by designing something very precisely in Photoshop or Sketch.


And we try to recreate that pixel for pixel in the browser. And there is this idea that there is one version. There is one perfect, works great version.

But as to reality, something can go from very low fidelity (保真度) to very high fidelity by the layering of technologies.


So I would suggest, instead of building like this. You go from assuming something on the Internet, assuming JavaScript is available, to reduce the number of assumptions.


Add them in over time. Begin with the assumption that we are on the Internet. Think about URLs, and the HTML, then the CSS, then the JavaScript.


To build in layers. These are the layers of the web.

> I like designing in layers. I love looking at the design of a page, a pattern, whatever, and thinking about how it’ll change if, say, fonts aren’t available, or JavaScript doesn’t work, or if someone doesn’t see the design as you and I might, and is having the page read aloud to them.
>
> [name=Ethan Marcotte, web designer][color=#90b7f7]

I agree with that. Because in this way, you are reducing the number of assumptions. That way you don't have to think in terms of something that either didn't work at all or working great.


Instead, see the truth, which is there are a lot of grey area. It is a continuum. Things move from not working to working great.


Now, a lot of people say, that's fine for simple stuff, but as soon as you get to more complicated things, you have to build in assumptions. You have to build in monolithic, binary way of thinking.


But I don't think we can divide everything on the web into simple things and complicated things.


In fact, you get to the complicated things by building simple things. Again, it is a layered approach.


To get from simple to complex, it's layers. Always layers.


We like to talk about simple websites and complex web apps.


But again, I don't think we can divide the entire web into two binary categories. It's continuous.


There are layers from websites to web apps. And this term, web app, doesn't have a meaning anyway. It doesn't have a definition. It's different from this term, progressive web app, that you might have heard about.


This does have a definition. At least in my opinion, it does.

A progressive web app is something that consists of three technologies.

It is served over HTTPS, so it is secure.

It has a web app manifest. It is a JSON file with metadata. The kind of metadata we use to put in the head of ???.

Finally, there is a file called service worker. It is a very interesting technology. It's JavaScript that doesn't get treated like other JavaScript files. It's kind of like a Cookie because it gets installed on the user's computer. But It's more powerful than a Cookie because it can execute instructions. And it's like a proxy because it sits between a user's browser and the server. And it means you can do things like caching, and avoid the network altogether.

What I find interesting about these three pieces of technology that form progressive web app is that they are also layers.


You can begin with your existing websites, switching it over to HTTPS. Add that web app manifest. And finally the most important step, add the service worker.

So any website can become a progressive web app through this process of adding layers.

I am not going into the code of how service workers work. I've put all that into a book. Maybe you can get that from abookapart.com.


But I do think it's interesting to see how service workers, kind of change the way I think about building on the web.

Like I said, for 20 years, this is how I thought about building on the web. Layers and layers and layers. And each layer depends on the layer below.

I can't put an URL up unless I am on the web. I can't have CSS unless I have URL. And yet when you introduce service workers, suddenly, I have to consider this possibility.

I have to consider the idea that the user could be getting my URLs could be getting HTMLs could be getting CSS could be getting JavaScript, and the Internet has gone way. There is no Internet connection. They are offline and still these technologies work. That took me some time to get my head around.

It's fundamentally different way of thinking.

Now how do you use this kind of technologies. Again, it's kind of like layered approach. You can do very simple things or more complex.


So for example, this is a website I built 10 years ago, called [huffduffer](https://huffduffer.com). It's about build your own podcast of found sounds.


And if you lose the Internet connection when you are on Huffduffer, you got this custom offline page. Okay, that's the most basic thing you can do with service workers.

Instead of browser showing the default offline message, now it's branded like my website. It's kind of like having a branded 404 page. But really, it doesn't change the user experience too much. But it can make things more delightful.


Trivago, a travel website, is a progressive web app.


And if you are offline when you are trying to use the web app, it gives you a nice game to play. But again, this is cute but it's like a browser addition, like a cute 404 page.


This is a more extreme example. I put a book online. It's called "Resilient Web Design". And it's available on resilientwebdesign.com. The website is the book. And this is how it looks when you are online.


And this is how it looks when you are offline.


Because as soon as you visit this URL, the whole book is effectively installed onto your browser. So from then on, it never makes a network request; it always goes to the cached version.

Now this is an extreme offline-first example, where the network itself is like an unnecessary layer after load. And this works because the content is never going to change. It's a book. It's unchanged.

Most websites have contents that change. That's why they are on the web.

So for example, on my own website, adatio.com, if you browse around, you got to read the latest content.


But if you lose your Internet connection, you got a custom offline page. But what I've also been doing is when you are browsing around, I've been caching every page you've visited. So the custom offline page would say, "Sorry, you're offline but here are these pages you already visited so you can read them again."

So that is good, but of course I only ever show the users something they've already seen. And I've making assumptions on behalf of the user that they might be interested in these contents.


And the next step would be to allow the users themselves to say what they want to save offline. That's what I do on this website, archive.dconstruct.org.

dConstruct is a conference that we ran for 10 years. And we have the audio from every talk given in 10 years of conference.


As you browse around the website, looking at these talks, you see this option, not just of saving the page offline, but to save the audio offline. So you can choose what to save offline.


And then later when you are offline, as well as a custom offline page, you now get to see "here is what you decided to save offline".

So when you are on an aeroplane, you can listen to that audio.


So service workers, kind of itself a gateway to more layers and layers of experience that you can add on top.


At the simplest level, you can choose to use service worker for caching your CSS, your JavaScript, your icons. That is the stuff you would do anyway with the browser cache.

Then you can add a custom offline page. Like I said, it is like having your custom 404 page, ???? a brand name.

The ??? of having a progressive web app is to give the user the opportunity to add it to their home screen, where it can launch just like a regular app, where we retrieve it in the browser just like a regular app.

And service workers also have the opportunity for push notifications on the web. Something that previously only was ??? native. Now you can make people's life a misery on the web too with push notifications.

Background sync, a really powerful technology, where you can allow people to interact with app offline, and when the Internet connection is regained, sync up with the web serer, even when the browser is closed. It can all happen in the background.

All of these are possible if service workers are available. But of course, you don't even know if service worker is available. You don't know any of these technologies are supported. And some of them aren't supported very well at all just yet. And that's okay.


The fact that these technologies aren't supported everywhere is absolutely fine as long as you are building in a layered way. As long as you don't assume any of these technologies are ubiquitous, you are gonna be okay.

Don't build in these assumptions. Instead, treat everything as a layer.

That's how we should think about browser support of these things. That's not something we hope to rely on, but they are something we can layer on top of our existing websites.

That's how we should think about browser features. Reminds me of how we should think about the future.


> The future is already here. It's just not evenly distributed.
> [name=William Gibson, a science fiction author][color=#90b7f7]

Browser features are already here. They are just not evenly distributed.

So back to the future, and predicting the future.

Over the next 2 days, like I said, you are gonna see a lot of exciting technologies of the future of the web. Maybe now you can use this lense to evaluate these technologies and decide what pace layers are these technologies fall into. What the lifecycle would be? Are they fast moving? Will they disappear in a year or two? And that's okay. That's the whole point. They supposed to be fast moving, and they supposed to disappear.

And there's longer lasting depictions of the future.

And I want to finish by quoting a talk about the future from a computer programmer named [Ida Rhodes](https://en.wikipedia.org/wiki/Ida_Rhodes). She worked on [UNIVAC I](https://en.wikipedia.org/wiki/UNIVAC_I), the very first computer.


She would herself been called a computer. The word, "computer", used to refer to the people who do the programming rather than machines.

She gave an address to the Electronic Computer Symposium in 1952. 1952! Computers barely existed. And yet, she described a future that was spot on. She described a future that is filled with Internet of Things. And she addressed a roomfull of programmers in a talk called "[The Human Computer's Dream of the Future](http://www.computerhistory.org/atchm/wp-content/uploads/2018/01/ida-thodes-1952.pdf)".

And I would like to close by repeating her words to you.

> Most present day inventions, it seems to me, do not differ much from the way humanity has been picturing them in imagination for countless generations. The submarine and aeroplane must have been foreseen by many of our species from the time they first observed the ways of the fish and the bird. All tele-instruments are probably what men always hoped they might be; the destructive power of our hydrogen bombs is no more terrifying than the Biblical prediction of their impact. But I doubt whether even the most fertile imagination possessed by a mathematician a short century ago could have foreseen the wondrous features of our high-speed electronic computer with the magic appearances and disappearances of numbers in its storage registers; with the gratifying compliance of its control in dispatching our commands, with the incredible speed of execution in its arithmetic unit. Such reflections lead us to conclude that the future developments in this field will be stupendous (驚人), and I envy all the engineers present here who have the opportunity of taking an active part in them.
> [name=Ida Rhodes, 1952][color=#90b7f7]

Thank you. 謝謝。

---

Reference:

* [The Way of the Web - Jeremy Keith](https://hookedoncode.com/2018/04/the-way-of-the-web-jeremy-keith/)
* [dConstruct Audio Archive](https://archive.dconstruct.org)
* [Can I use… Support tables for HTML5, CSS3, etc](https://caniuse.com/#search=background%20sync%20api)
* [Packaging Websites](http://bit.ly/webpackaging)

[^FrankChimeroQuote]: https://frankchimero.com/writing/everything-easy-is-hard-again/

###### tags: `MW18`