Jeremy Keith - Building - View Source 2019


Thank you, all, very much for still being here. It has been a long day. Your time is precious and I appreciate it. I appreciate you've stuck with it for the day. Also, thank you to someone who isn't in the room, Amanda, thank you very, very much for the live captioning that you've been doing. Thank you to Mozilla and White Coat Captioning for doing that.

A bit of housekeeping, just I'm contractually obligated by the Public Speakers Guild, as the last speaker of the day, to say I'm the only thing standing between you and going for a beer. I feel like, in this situation, because it's been two days of intense talks, I want to point out that you are the only thing standing between me and going for a beer.

So, I would like to talk to you, which is kind of weird, when you think about it. On two levels, I'm here to talk to you, like some clerical error on the part of Mozilla that's ended up with me here. I'm going to talk to you. I'm literally going to stand here on the stage, move my jawbone and pass air through my throat for, like, half an hour or so, right? And you're just going to sit there and take it. It's kind of a weird activity, what we're doing here, me talking.

But of course, the reason why it works is because I will be using language as I do it and hopefully we've all got the same codebase, English in this case. Language is amazing. I mean, language is one of the things that kind of makes us human. It was one of the great leap forwards in human civilization. Through language and moving my jaw and waggling this fleshy piece of meat, I can tell you something that happened and you are able to revisit the past. Or, I can imagine something in the future and relay that to you and you are able to travel to the future through language. So, language is a kind of time travel.

On a more basic level, it's a form of communication, which is also amazing. I can have an idea inside my brain and I move my jaw up and down, vibrate the air between us and transfer that idea from my brain into your brain. So then, language is like a virus. Right. It's almost involuntary. I can say, don't think of an elephant. You thought of an elephant, right? That's the auditory equivalent of the chicken game. You've played the chicken game and lost. That phrase "don't think of an elephant," that's from a book. He has written books on language and he wrote this one back in 1980, The Metaphors We Live By. This conceptual metaphor, which is what we're used to. You talk about one thing in terms of another thing and it's really useful when you're talking about something intangible. Time is a classic example. We can talk about time like it's a physical object. Time moving through space, time flies, time drags. Saving time, wasting time. Time is intangible, but talking about time with a metaphor like that helps us conceptualize it.

But what George was interested in was cognitive metaphors. Political language, in particular, the framing we use in language could maybe affect the way we approach thinking about things. He says, if you're going to have a debate about tax relief, you've framed taxation as something you need relief from. I think we are guilty of this, too. We talk all the time about what you can do now in the browser. The browser. Singular. Not browsers. Maybe this frames our thinking. So, I'm fascinated with the language and the metaphor we use to talk about the web and ourselves, the language and the metaphors to talk about ourselves.

The web's a relatively new medium. We tend to borrow from the medium that came before. This isn't new. This is something that Scott McCloud talked about. He is talking about how every medium borrows from the one before. He points out that many early movies were like film stage plays and television was taking radio and adding pictures it.

Now, this resonated with me because it reminded me of something I'd seen written somewhere else, it was something published in A List Apart. Who has read it? Good. Good. He makes the exact same point in this article, every medium borrows from the time before. Terrific article. By the way, I highly recommend you read it, even though it's 19 years old. It is more relevant now. John says this, when a new medium borrows from an existing one, some of what it borrows make sense, but much of the borrowing is thoughtless ritual. And over time, the new medium develops its own conventions, throwing off the existing conventions that don't make sense. So on the web, the medium that come before, if you were a designer, was print. It's not the web. Designers kind of wanted to recapture that control they were used to in print, on the web.

That's where we got Creating Killer Websites. This was 1996. Does anyone remember this? Awe, my fellow gray haired friends. This was the guy who came up with Tables for Layout and all the stuff Tejas was talking about earlier. This is kind of what John was pushing back on that maybe control shouldn't be what we're after on the web. Here's what John said: The web is a new medium, although it has emerged from the print medium. Yet, it is too often shaped by that from which it sprint. Killer Websites are those which tame the wildness of the web, constraining pages as if they were made of paper. Desktop publishing for the web. But he does acknowledge that, yes, we have a lot to learn from this history of not just print, but pre print, layout, illuminated manuscripts. This is the next leap forward, after language, is writing. Now we can communicate ideas and you don't even need to be in the same physical space, we don't have to vibrate the air between us anymore. I can make marks on wood and I can put an idea into your head. Kind of amazing.

So, with this kind of debate, I guess, between John talking about the flow and the flexibility of the web, the wildness and then David talking about constraining things into control on the other, they seem to be two very opposing viewpoints, and they are. But they also have an agreement. Because what they're agreeing on is the language they're using as they talk about the web because both of them are talking about making websites. That, in itself, is a metaphor. I know it's very unfashionable these days. We're making web app experiences. Websites, how very dare you. We're making websites.

That idea of a site is something you go to, a building site, a construction site. I mean, that was literally how we thought of it in the early days, right? Our pages were under construction  I'll give you the full, nostalgic affect. We used to say, oh, this is under construction. Let's face it, it's always under construction, we just stopped putting these animated GIF s on these websites. Here's one that I hear a lot, we're talking about what we do and how we borrow from another medium. We talk about our work, though we are architects. Right?

Everyone wants to be an architect. You talk to architects about the industry, it's terrible. It's a dumpster fire. It's all about competitions and prizes and unbelievable spec work. You're like, no. But still, everyone wants to be like an architect. I blame Hollywood. It's become shorthand, you want likable person, oh, they're an architect. The villain is never an architect in the movie. And there is a lot we can learn from architecture. I know many UX designers who consider this book to be the best work they've read. It's 101 Things I Learned in Architecture School. A lot of the ideas and messages are absolutely transferrable to other mediums. There's another book on software, Pattern Language by Christopher Alexander. This is a classic book. By "classic book," I mean a book everyone's heard of and nobody's read. 1977. And it influenced people, Ward, who invented the Wiki, the gang of 4, the design patterns, directly influenced by Christopher because he's talking about breaking things down into modular, reusable components. This absolutely resonates.

What's funny, actually, is there was a book by Molly where she specifically looks at the influence of product designers, architects and she points out that Christopher had a huge influence in the digital world and almost no architecture. Architects don't like him, they think he's preachy. I ran an event all about components and patterns and design systems. I did it for a couple years. It was great. We got Jina Anne. By the end of the day, I was saying, we really should have had a drinking game, if someone mentioned a pattern language by Christopher, you take a drink.

Here's the full drinking game I came up with, any time someone says Christopher Alexander, take a drink. Any time someone says Lego, take a drink. Any time someone points out naming is hard, take a drink. Any time anyone says "bootstrap," puke it back up.

There's another book, How Buildings Learn, classic book, 1994. In this book, Stewart looks at the work of Frank Duffy. He had this idea of buildings not being structured in space, but layers of structure in time and talked about sheering layers. A building properly conceived is several layers of longevity. So, he mapped out these layers, these sheering layers. You think about the site that a building sits on, you're talking about geological time scale and the structure you hope will last for centuries, the walls, the plumbing, it gets shorter when you talk about the furniture you can change on a daily basis. This is sheering layers.

So, he's interested in the time scales here. I spotted something else about sheering layers, each layer depends on the layer before. You can't have the structure until you have the site. You can't move stuff around in the room until you've made the walls and the doors. This idea of each layer in the sheering layers, depending on the layer before, it reminded me about the work of Steven Johnson. He keeps going back to this idea of the adjacent possible. Certain things need to exist before you can create something. It's why you don't get the microwave oven invented in Europe. The world wide web, you have to have computers, internet. You can keep going further. You build Facebook, Google, they depends on the web, which depends on the internet, which depends on computers. These layers of stuff that's built up.

They depends on the layers below, the adjacent possible and sheering layers. Stewart Brand revisits this in a later book, The Clock of the Long Now. Anybody heard of the Long Now Foundation? Any members? All right. For once, there's a member. Great! Dedicated to long term thinking. All their years begin with five digits. And they're building a clock that will tell time for 10,000 years, which is fascinating. I recommend looking at the design principles. So, in this book, time and responsibility, the ideas behind the world's slowest computer, Stewart abstracts from architecture and applies it to everything. That sheering layers are everywhere and he calls this "pace layers." This idea of different layers of time scales. He gives an example by taking us, the human race, and looking at the pace layers of the human race. The sort of slow, bottom end, the DNA, that doesn't change. Culture builds up over centuries, with language, with countries and all this kind of stuff.

Governance, they tend to stick around for quite awhile, but they can change. Infrastructure needs to move faster than that. Commerce, very fast moving and fashion moves really quickly. So, he maps these pace layers on to this diagram. Right. Where you got the fast moving stuff at the top and the slow moving stuff at the bottom. He's talking about pop music, where everything is supposed to change quickly. And it's good that it moves fast. It would be dull if fashion moved slowly. You want it to.

Interestingly, the good stuff, the fast layers will make its way down into the lower layers. Like, a really good pop song, may become part of culture. So the way that Stewart says is fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instruct slow and big by a crude innovation, by occasional revolution. Slow and big control small and fast by constraint and constancy. He says fast gets our attention, but slow has all the power. This idea of pace layers, I'm hopefully going to be transferring from my brain into yours. I see pace layers. Like when a typography points out bad stuff to you. Thanks, you've ruined my life to you. That's what it's like for pace layers for me. It's a joke at work. Time to pace layers, how long before somebody points out this is like pace layers.

Remember the first time someone points out the arrow in the FedEx logo? You've seen the arrow? What about this logo? Who sees the bear? You see the bear? Okay. You won't be able to unsee that. Right. That's the virus I put in your head.

Or, consider the duck. A perfectly normal duck until you're on the internet and someone points out all ducks are actually wearing dog masks. All ducks are actually wearing dog masks. And now, when I show you the same picture of the same duck

You cannot unsee that. And that's what it's like with pace layers for me. It's like, I see them everywhere. So I thought, can I apply pace layers to the web, to where we work? And I've given it a stab and I think it kind of works. So at the bottom layer, the slow moving layer, you've got the internet, TCP/IP, it hasn't changed since 1974. We'd have to rip everything out and write everything from scratch. HTTP, protocols for emails and hypertext. We have HTTP2 now. It feels like it shouldn't move too quickly. We put URLs on the web. Now, I would love it if URLs were down here at the bottom, here, and URLs never change. URLs absolutely change, disappear, they rot. We can fight against the rot and I think we should. What to you put at that URL? The obvious answer is hypertext with HTML. HTML has changed. When HTML was first created, borrowed all these tags from SGML, it was 25 26 tags  elements, as we'd say today. And now there's 100. The pace hasn't been too quick. I feel like I've been able to keep up.

CSS, there's more and more newer stuff coming in CSS, which is great, we have grid and Flexbox and all this other stuff. I feel like, this is good. I can keep on top of this. You know, follow the right blogs. Keep track of the right people. Then there's the JavaScript language. Like, the libraries, the tools we use for JavaScript. This is like, I give up. That was so last week, we've switched over to last week. I can't believe you're still using that tool. Show of hands if anyone else feels like this with the pace of change with JavaScript. Keep your hands up and take a look around. You're not alone. This apparently is the new normal.

What's interesting, remember, fast learns, slow remembers. So, it's kind of the point of JavaScript to go, what about this? What about that? The good stuff makes its way down. When I was first making things with JavaScript, the common uses were things like image rollovers, you mouse over something, the image changes. Or form validation. Is that actually an email address? Was that required field filled in? I used JavaScript to do that. Today, I would use CSS. I would use HTML, input type equals email required to do form validation. Fast learns, slow remembers. Those things filter down.

We needed a solution for responsive images, we figured it out in JavaScript and then the moves down into HTML. Mapping these things out helps me with feeling overwhelmed by the pace of change in JavaScript because I realized, it's supposed to be that way. It's meant to be trying new stuff and changing things quickly. If I want to go somewhere that's slower moving, I can spend my time in one of those layers.

Something else I noticed, huh, this order of things, this layered structure, that's kind of how I build websites, too, right? I assume the presence of the internet. You know, okay, URL design, there's a place to start. I think that's a great place to start designing something and then thinking about the structure of your content with HTML before thinking about the presentation and then adding JavaScript on top of that for the behavior and the really powerful stuff, right? This really maps to how I like to build, in layers.

However, it is a testament to the flexibility of the web that you don't have to build this way. If you want to, you don't have to use all the layers. You can, if you wish build like this. You can assume the presence of the internet and everything on top of that, do it all in Javascript, URLs, routine, do it in JavaScript. CSS, in JS, please. Everything on top of that. This is literally the architecture of single page apps, right? You can use this architecture, rather than using the layered architecture. Now personally, I don't like this architecture, it doesn't sit right with me. I'll tell you why, you've kind of turned this into a single point of failure, where if you got JavaScript, everything is great. If you don't, you've got nothing. It works great or it doesn't work. Something happens in the network, you get absolutely nothing.

This binary way of thinking between something doesn't work at all or it works great makes total sense in other mediums. If you're building a native app for a phone, you're building an iOS app and I have a device, great. I get 100% of what you've designed and built. If you're building an app and I have an Android device, I get 0% of what you've designed and built. So that mind set makes total sense in a lot of software situations, but not on the web. On the web, it is possible for us to build like this, where we can build in layers.

When something goes from not working at all, to just about working, to working really well to working great. You might design something and maybe because of the device I'm using or my browser or my network, I don't get 100% of what you designed or built, but I won't get 0%. Maybe I get 80%, maybe I get 90%. I feel like that's better than the binary situation. What's really nice about this approach of building on the web is it maps so well to the technologies we use for building on the web, a layered approach. I'm not the only one who thinks this way.

Ethan Marcotte says, I like designing in layers. I like looking at the design of a page, a pattern, whatever and think about how it will change if fonts aren't available or JavaScript doesn't work or if anyone doesn't see the design like you and I might and is having the page read aloud to them. It's anticipating the unexpected. We all know Ethan from writing a list called Responsive Web Design. And Ethan begins his article by quoting John's article, by building on top of it, another layer, if you will.

And this term that Ethan comes up with, responsive web design, it was borrowed directly from architecture. In architecture, there's a school of thought called responsive design, responding to the people within them. Architecture, actually a pretty rich seam for metaphors and language to describe our work. There's another area of work that we've borrowed, we've taken from, so that will do very nicely. That's when we describe ourselves as engineers, software engineers. Now, I will admit, I have a soft spot for the term "software engineering," not because of the words itself, not the metaphor, but where it comes from. Hamilton, she coined this term "software engineer." She wrote the code for the Apollo command, that was woven into the computers for the greatest endeavor. I think of software, hardware and human beings working together to get human beings on to the moon, absolutely amazing.

By the way, I should point something out about this particular picture. You're familiar with the selfie, a self portrait photography popular with the youth. This is an "everyone elsie." The only person not in the picture is Michael is not in this picture. It is an everyone elsie. So, engineering, software engineering, if you're sending people to the moon, yeah, that does feel like engineering. There's chemical engineering, mechanical engineering, industrial engineering. Strangely, what unites these various disciplines to follow this engineering umbrella, I think it's the fact that you got what you're working with is the materials that you're working with and the tools that you use to work with those materials.

I think the materials of the web are HTML, CSS and JavaScript. That's what the end users are going to get. Now, what tools you use to design and build on the web, there's graphic design tools, Photoshop. You open up a Photoshop document, you put in a width and a height and you're thinking back in the killer website constrained way. These are obvious tools to build with. There are less obvious tools when working on a web project. We have to communicate whether it's email or Slack or calendars or meetings. These are productivity tools. But when you think about it, it's an oxymoron because that's what a tool is, all tools are productivity tools. That's what tools do.

I think we should acknowledge, these are also tools that are necessary to build something. Let's dive deep into specifically, what about when we're developing? There's a whole bunch of tools we can use. Version control and task runners, build tools, pipelines, pre processes, post processors. I've lumped all of these together because what they share in common, they sit on your computer and they're productivity tools. They're there to help you work faster. The end user doesn't see any of that. You can say, oh, yeah, because we work faster, there's a benefit to the end user, not directly. So when it comes to these things, because they sit on your computer, use whatever you want. Use whatever makes sense to you or your team. Like, that should be the defining factor.

I will admit, again, like with the JavaScript ecosystem, I'm a bit overwhelmed with the pace of change. You're still using that particular task runner? We changed last week to this new one. It feels like maybe some  I understand, you're working at scale and you need these complicated tools. Does it always have to be that way? Does it always have to be so complicated? What it reminds me of, that startup, Juicero? It was a really expensive machine and you'd buy the expensive machine and put the expensive packets of juice into the machine and you got juice. It did what it was supposed to do, it made juice. You could just squeeze the packet by hand. I'm just saying, you can just squeeze the packet by hand. I'm being disingenuous. So, this is where the metaphor breaks down. I'm going to leave that.

As well as the materials and the tools. When you're choosing those kind of tools, your task runners, use whatever works for you. There's a whole class of tools where that isn't true, the tools that are written themselves. If you're using CSS, you're making the user download the framework so you, the developer, get the benefit. If you use a JavaScript framework, you're making the user download it. If you use it on the server side, it's sitting on your computer. Just pointing that out. The tools that are built into materials and delivered to the end user, you cannot say, hey, whatever works best for you. You must consider the needs of the users, over the needs of the engineers.

At the very least, there's a balance to be had there and I would rather wait the balance in terms of users than engineers.

Hey, I like developer experience as much as the next developer, but user needs, they've got to come first.

Now, when you're choosing tools, there's a lot of questions you can ask about, is this an appropriate tool? Is this going to help me? And one thing to ask is, well, how well does it work? That's the obvious question. Something to ask especially if it's going to be for the end user, not how well does it work, but how well does it fail? What happens when things don't go perfectly? And now we're back to that situation of the single point of failure, right? If you're building in that binary where it's the internet or binary, it works great or doesn't work at all.

This layered approach to building fails really well. Something does go wrong. You know, one of these whole layers or within the layer, you use some CSS that isn't supported in every browser. It's fine. Use HTML that isn't 100% supported, that's fine. These technologies fail well, which brings us to something interesting. JavaScript's the more powerful technology, it doesn't fail as much as HTML. This is kind of good example of a principle, a law of nature that was underlying the creation of the web itself. The principle of least power. Which states that you should choose the least powerful language suitable for a given purpose. That seems a bit weird on the surface. Why would I choose the least powerful language? It will probably last longer, less prone to failure. Derek puts it this way: In the front end stack, HTML, CSS, JavaScript and Aria, if you can solve it simpler, you should. Yes, you want to build a clickable button, you could do that with JavaScript or just use a button. The lazy solution is a better one, that's a classic example of the principle of least power.

I think this matters on the web when it runs into another law of nature and that is Murphy's Law. Anything that can possibly go wrong, will go wrong. Edward, aerospace, no one ever died on his watch. Right? I think we're a bit quick to say, everything will be done. Edge cases. Can you imagine if other industries do that. Car manufacture companies, they strap dummies in the cars and crash them. They're considering these situations, trying to make things safer, they will fair well. Can you imagine if they went, hey, we've been looking at the data and we're going to stop crashing these cars. They are being driven by humans and on roads and not being smashed into walls at high speed. Yes, of course, that's the happy path. That's the situation we hope for. You hope for the best and you prepare for the worst and we are not preparing for the worst edge case.

Like cars, designed to perform in extreme heat or on icy roads websites should be built to face the reality of the web's inherent variability. Reality, the web's inherent variability. Exactly what John was talking about 19 years ago. Whenever there's a discussion about engineering, bridges come up. I'm going to talk about a particular bridge. This is the Quebec Bridge, construction started in 1904, after there was an architecture competition. Theodore Cooper was in charge and lengthened the bridge from 490 meters to 550 meters. Mostly because he wanted it to be longer than the bridge. The longest bridge in the world. But he didn't calculate the already high stresses being put on the steel. He wasn't based in Quebec, he was based in New York. When the idea was put forward that other people could double check his numbers, he really didn't like that. There would be no code reviews on this project.

So, construction's happening, it's 1907. An August 6, an engineer noticed there's bending starting to happen. He sees it again on the 27th of August. It's gotten worse. They're informing Cooper and Cooper does send a telegram and says, place no more load on Quebec Bridge. They didn't know how to interpret it and they kept working. It was right before the end of work, like, the whistle was just about to blow when the bridge collapsed and 75 of the 86 workers died. Something interesting started happening in Canada, years later, it's 1925, Canadian engineering schools started holding a private ceremony. This was the ritual of the calling of the engineer. You'd speak in obligation. And you'd be given an iron ring. A symbol, a metaphor of pride, yes, but also, humility. You'd wear it on the little finger of your working hand so it would brush against the paper or the keyboard and be there as a constant reminder of responsibility. And that's why I take issue with us just deciding to call ourselves "engineers."

You haven't earned it. So, what do we do? What do we call ourselves architects? Engineers? Developer's not bad. I think maybe we got it right back in the geo cities days when we just talked about building things. We're building, just like brick laying. Collaborating together to make things. I mean, is that so bad? That we work together and we build. Maybe it's not engineering. Maybe it's not architecture. But Christopher Alexander did say, most of the wonderful places of the world were not made by architects, but by the people. Maybe? I don't mind thinking of myself as a bricklayer. Not when we've got such amazing bricks to work with. It's a metaphor again, but think about the web. Hypertext. The link. What an amazing brick. The link is. I can make a page at a URL and I can link to another URL. And some other URL over there and that combination of links has never existed before in the history of the web? That's an amazing thing. That's kind of magical.

I think we forget the magic. I honestly think it is the next step in our civilization. We've gone from language and writing and the printing press to the world wide web and hypertext, it's the next layer on top of all those layers. And, that we can choose to build amazing things.

I'll finish with this story. A traveler comes across three workman, building something. The first worker, what are you doing there? He says, I'm, you know, stacking stones. Okay. Bricks. He says to the second worker, what are you doing? I'm making a wall. They're all doing the same thing, but they give different answers. I'm making a wall, stacking bricks. He says to the third builder, what are you doing? I'm making a cathedral. Maybe it's less about how we describe ourselves and much more about what we build together. We are bricklayers.

And over the last two days, you've heard from some really amazing brick layers, people who are building websites and web apps, building browsers, building businesses, building communities, building the web. What an honor and a privilege to be involved. After two days, my mind is full. I feel like we need to stop now so I'm going to stop moving my jaw up and down and flapping the fleshy piece of meat in my mouth and simply say, thank you.

Discover the best of web development

Sign up for the Mozilla Developer Newsletter