What’s Changed and Where’s it Going?

A presentation at An Event Apart Washington DC in July 2019 in Washington, DC, USA by Dave Rupert

Slide 1

Slide 1

What's changed and where's it going

A Talk By Dave Rupert @davatron5000

Slide 2

Slide 2

Responsive Web Design 102: A refresher course

This talk is a refresher course on Responsive Design. I feel like we’re at a point where RWD is nearly 10 years into Responsive Design and it’s a good time to reflect on all we’ve learned and also evaluate how it’s all going. A lot of my work in the last year or so has been rehabbing existing sites and I’ve learned a few things I’d like to share here today.

Slide 3

Slide 3

2010

Let’s start by teleporting back to 2010… where it all started.

Slide 4

Slide 4

Responsive Web Design

In 2010 Ethan Marcotte wrote a blog post that became a book called Responsive Web Design. During this time a lot of us were duplicating our effort by creating both a desktop site and an m-dot site that worked on these new-fangled iPhones.

In his blog post Ethan propsoed a new technique where you can use a combination of three things to create a site that works on both desktops and phones:

  1. Flexible Grid
  2. Fluid Media
  3. Media Queries

I was mad at Ethan for this. It was pretty disruptive to our pixel perfect workflows that we had essentially mastered. But the more we played with it, the more we realized the potential.

Slide 5

Slide 5

RWD is a Technique

But in 2010/2011, RWD is still very much a web design technique.

Slide 6

Slide 6

But it didn't stop there...

Slowly but surely, more and more concerns were piled on and the breadth of things you needed to understand to make a Responsive Website grew and grew.

  • Mobile First
  • Sass
  • Web Typography
  • Responsible Responsive Design
  • Touch
  • Patterns & Principles
  • Making Money with RWD
  • And going responsive at an organization level…

Karen rightly pointed out that RWD is starting to impact our businesses. Through her and Ethan’s

Slide 7

Slide 7

RWD is a Philosophy

It’s at this point, RWD pivots from a technique, to a philosophy.

Slide 8

Slide 8

But it didn't stop there...

In order to make a website, we now have to have some proficiency in…

  • Git
  • SVG, a new image format based on Math
  • JavaScript, o lord, JavaScript
  • The Command Line
  • Animation
  • How to put a webfont on the webpage
  • We need to be reminded about Accessibility
  • CSS Grid, the most important advancement in CSS since CSS itself!
  • Websites can work offline now
  • We can use webfonts, but we need to understand how to set type
  • Image performance, a whole book on how to put an image on a webpage
  • Progressive Web Apps, websites now interact with the operating system
  • And of course the “non-canon” books about Design Systems… who knows if these will take off.

Slide 9

Slide 9

Looking at the Data

If we look at some data we can see this explosion of concerns…

Slide 10

Slide 10

2014

Let’s go back to 2014 and I picked 2014 for two reasons…

  1. It’s 5 years ago, a mid-point in the last decade of responsive design
  2. I feel like this is 2012-2014 era is when a lot of sites started adopting Responsive Design and we were building momentum towards Google Search’s 2016 recommendation for RWD.

A lot of the website I’m being called in to help on are from this era and perhaps you have one too.

Slide 11

Slide 11

Total Kilobytes

According to HTTP Archive, the average Mobile site has more than tripled in size since in the last 5 years from ~560kb to ~1.7MB. Don’t look at the Desktop stats, we’re only looking at mobile because that’s the only thing that matters.

JavaScript! JavaScript! The problem is JavaScript… well…

Slide 12

Slide 12

JavaScript Bytes

Not necessarily… but it’s still quite a lot.

JavaScript we’re sending to Mobile has more than doubled over the last 5 years. We’re now sending ~360kb of JS. And it’s important to note, this is just the transfer size, the actual JavaScript size is considerably more than this.

What about CSS?

Slide 13

Slide 13

CSS Bytes

CSS has actually tripled in size over the last 3 years from 18kb to 56kb.

This is really curious to me because I don’t exactly think we have 3x the style problems compared to 5 years ago. If anything, with browser standardization we’ve removed the need for *most CSS prefixes.

I’d love to dig into this more. I wonder if CSS frameworks play into this or if we’ve all just got lazy.

Slide 14

Slide 14

Image Bytes

Now images make up the brunt of the website bloat. I have mixed feelings about this…

On one hand, we most certainly are sending down bloated images to the client. I’d bet you $100 I can unoptimized image on your homepage.

On the other hand, the Mobile landscape has changed. With 2x and 3x phones we have to send down larger imagery. And in the era of Instagram and Snapchat it’s really important that your brand maintains a level of visual fidelity.

So in someways, I want to externalize this blame say “not my fault” but also acknowledging there’s things I can control.

Slide 15

Slide 15

Quick Note on Kilobytes

  • Gzipped vs Unzipped
    • Gzipped: Reflects the speed at which resources will arrive
    • Unzipped: Reflects the amount of work on the CPU and maintenance costs
  • All bytes are not equal
    • JS bytes that must be downloaded, parsed, and executed and cause a style recalculation on the client are more expensive than CSS bytes
    • Image bytes are memory intensive and more expensive to resize on device.

Slide 16

Slide 16

But...

But Aren’t mobile Phones and mobile connection speeds getting faster? Won’t this problem go away?

Slide 17

Slide 17

Yes but No, Actually.

Slide 18

Slide 18

DOMContentLoaded

This chart is great because the dataset for DOMContentLoaded for Mobile and Desktop was actually joined together, but in ~2016 they started collecting different metrics for mobile and desktop. And you can see how mobile, even though devices and connection speeds are getting faster, this even where HTML says it’s ready has slowly creeped upwards.

Slide 19

Slide 19

onLoad

The chart of onLoad, the point where the browser has everything it thinks it needs for the page, fills in some of the details. We see the average mobile site has gotten ~6s slower, while the average desktop site has gotten ~1.5s faster.

Despite advancements in technology, mobile sites are getting slower. And this is due to all the HTML/CSS/JS/Fonts/etc that we’re sending to the device.

Slide 20

Slide 20

The DoubleClick Study

Why does this matter?

Accordion to DoubleClick’s study on the impact of mobile latency we know that 53% of users abandon a site if it takes more than 3s to load. 50% of people expect a page to load in 2s…

Slide 21

Slide 21

Charting that out

The average site takes 18.4s to load…

But the money zone is at 3s…

This is an incredible gap to close.

Slide 22

Slide 22

Looking at some Examples

I thought it’d be good to look at some examples. These are all sites I’ve worked on in the last year or and while I’ll talk mainly about one site in particular, the stories here are mostly the same and

Slide 23

Slide 23

Khoros

Khoros was a 6 month project, but 3 weeks into the project our client (spredfast.com at the time) announced a merger with (lithium.com). A couple weeks later we got a new creative director. A couple weeks later after the dust from the merger had settled we had a different CMO than the one that hired us. And a month after that it was decided there would be a NEW comapny established. But we still had an early March deadline. And the big catch was the branding (fonts, colors, logo, etc) for this new company wouldn’t be ready until early February. We had one month to build out and deliver a website coordinating with their in-house designers and content people. We all got a few grey hairs in the process, but using the power of a design system, we were able to meet the deadline.

Austin Chamber

We recently launched the Austin Chamber of Commerce’s new website. We worked with them on establishing a new look and feel for this organization that plays a big role in attracting business to Austin. In about 3 months we handed off a design system to a development team who integrated that in nearly 3 months and we had a website. They even started building pages using the components without even asking us, which honestly was the entire goal of delivering a design system.

PapaJohns

We helped a small pizza company from Kentucky update a few areas of their site. Addressing the elephant in the room, Papa Johns is a company that has undergone quite a few changes in the last couple years. Apparently Shaq is on the board now and visits the office!? One thing I’ve learned over the last couple years is that a lot of times the headlines in the news are very different than your experience and the diverse team of people you work with.

Papa Johns makes an interesting case study because this is a site that was handed off by Happy Cog (a talented agency and friends of my shop Paravel), but over the years the site - just like many sites I see - just grew and grew and grew.

How big you ask? Well…

Slide 24

Slide 24

1 MB 1 MB + CSS JS

They were sending down 1MB of CSS and 1MB of JS. Now this gzips down to around 256kb and 300kb. But. This is a lot of code.

How much code?

Slide 25

Slide 25

37,000+ Lines of CSS

Approximately 37,000 lines of CSS. This is a maintenance burden. Every time you write a line of CSS, you have 37,000 potential collisions. This is a lot and makes it difficult to work in and it appears that most people would just copy and paste whole sections and give it more specificity to work around this issue.

Slide 26

Slide 26

Managing CSS

So… let’s talk about managing CSS.

Slide 27

Slide 27

Step 1: Interface Inventory

This section of my talk is going to sound really familiar, it’s a classic design system story.

Slide 28

Slide 28

Buttons

We found ~32 different buttons on the site. The bulk of that was ~20 different green buttons with slightly different spacing, border-radii, sizes, and icons.

Slide 29

Slide 29

Product Cards

Digging in we found ~14 different product cards on the site which is somewhat unexpected for a company that more or less sells one product.

There’s more examples here of course, but hopefully we’re getting a sense of the explosion of variants that happened one small decision at a time over the life of the product.

Slide 30

Slide 30

Step 2: Measure

I find it really helpful at the start of a project to measure what you’re up against.

Slide 31

Slide 31

CSS Stats

CSS Stats is a great tool that can help give you a 10,000ft view of your CSS file. You can see the 1,012kb (I wasn’t lying 😉). 10k selectors, 16k declarations, 711 font sizes, 75 background colors, and 41 unique colors for a site that really only has 3 colors red, white, and green. And black for text.

Slide 32

Slide 32

Lighthouse

Lighthouse is built into Chrome/Edge/Opera/Brave so you have no excuse not to use it and run it on your site right now.

It gives you a rating on your Performance, your Accessibility, UX Best Practices, and SEO.

But I have some rules about how to use this tool. When you start it up you get asked to choose your Speed and we -in this room- choose Mobile with Applied 4G with 4X Slowdown. In this house we’re mobile first and don’t trust in vanity metrics.

These measurements are from a remote pre-production environment and won’t really reflect all the third-party scripts and CDN etc that might impact the site. Always know the limitations of your data.

Slide 33

Slide 33

Step 3: Patternize

The next step is doing the work.

Slide 34

Slide 34

Color

We reduced and improved the contrast of the colors to meet WCAG 2 AA recommendations and got the number down to ~16 colors and maybe 8 of those are greytones.

Slide 35

Slide 35

Buttons

32 buttons became about 12. The majority is this matrix of 9 colors: 3 colors × 3 sizes. Using color and size we can prescribe consistent meaning though the site.

Slide 36

Slide 36

Product Cards

We ended up with ~5 different product cards each with similar, cohesive style but different define usecases.

  • Product Card
  • Banner Card
  • Feature
  • Special Offer Card
  • Hero Offer Card

Slide 37

Slide 37

Step 4: Measure Change

Now that we’re finished, let’s measure the site and see how we’ve done…

Slide 38

Slide 38

28 Major Components 67 Total Variants 105 Pages Covered

Pages play a crucial role in how we build design systems. Pages

Slide 39

Slide 39

source-map-explorer

One other tool I use is source-map-explorer which takes your Sass and JavaScript sourcemaps and breaks them out into a treemap. This a good way to see files grouped together. On our “AFTER” side, the top half is our components and the bottom half are our utilities…

(Disclaimer: Animations is coming in verrrry large. There’s no way we have 28kb of animations. I think this is a problem with third party CSS getting lumped in)

I have some interesting data from this. Looking at my components, knowing I have 28 major components and 56kb of component CSS, I know that components average about 2kb of CSS. So if someone wants a new component, that’s going to add ~2kb of CSS to the total unzipped size. Variants? About 800 bytes each.

This is cool data to have and this visualization allows you to audit your CSS, combat the bloat, and you can identify large bits of CSS that you can potentially whittle down.

Slide 40

Slide 40

CSS Stats: Before and After

Let’s check CSS Stats for the before and after…

Slide 41

Slide 41

We reduced our CSS 91% to 100kb. This gzips down to ~14kb and we know it can build ~105 pages on the website.

  • 91% less selectors.
  • 83% less font-size declarations
  • 63% less background-colors (this still seems high)
  • 69% less colors.. and truth be told, while preparing this talk, I saw 3 or 4 repeated colors here and got this down to 10 unique colors.

Slide 42

Slide 42

Lighthouse: Before and After

Let’s check Lighthouse…

Slide 43

Slide 43

Not green across the board, but getting closer. You’ll see the number of green checkmarks goes up to up to 3 and we lost 2 red checkmarks.

Slide 44

Slide 44

Back to the Money Zone

Looking back at the money zone, our CPU Idle time, that’s more or less the onLoad meaning the CPU has a chance to take a breath…

Slide 45

Slide 45

Moved up to 6s. We’re getting closer.

Slide 46

Slide 46

Opportunities

What’s nice about Lighthouse it gives you recommendations for how you can improve your site and shows the estimated impact it might have on your site…

Slide 47

Slide 47

Doing those tasks has the potential to move us into that money zone.

Slide 48

Slide 48

Managing JS

Slide 49

Slide 49

npm

Over the last 5 years the JavaScript community has (more or less) settled on using npm to install dependencies, called “packages”, from the Internet.

This replaces manually going to a website, downloading a zip file, and then extracting that to your project inside a poorly organized directory structure.

Slide 50

Slide 50

package.json

Using npm to install these packages gives us a package.json which is a file that lists our dependencies. This is what we want. If you hop into a project, you can look at this file and get an idea of what technologies this site relies on. And if npm disappears tomorrow and is replaced by something else, we’ll have this list of packages that our needs to function.

And if these dependencies have dependencies, npm will fetch those files too. Very often, this can get out of control end up with thousands of dependencies… but hey.. at least it’s all organized.

Slide 51

Slide 51

ES Modules

JavaScript has also gained a native module importing syntax which improves the authoring experience of JavaScript.

You can import packages as objects and then write your JavaScript and then export pieces of your JavaScript that other files can import and use.

Imports and Exports. It makes decent sense.

Slide 52

Slide 52

But we didn’t have that…

Slide 53

Slide 53

We had a 1MB jQuery “App”

Slide 54

Slide 54

Auditing in Notion

I took a couple days to manually audit all the JavaScript in an app called Notion. I have all 67 files in here, found a little snippet as an identifier I could search the code base with, I found the number of occurrences of each, documented their dependencies and page weight. It was quite illuminating.

Slide 55

Slide 55

You might not need...

Looking at the codebase I found a few Responsive Design Solutions™ that you might not need anymore…

matchMedia polyfill - All browsers have this, even IE respond.js - A media query polyfill for IE6-8 Picturefill - Technically you need this for IE11.. but, there are workarounds HTML5shiv - Came with the famous HTML5 Boilerplate FastClick - Removed the 300ms tap delay in Webkit.. but this has been fixed LoadCSS - A script to compliment Critical CSS techniques, found out last week you don’t need it Modernizr - More or less replaced by @supports Webfontloader.js - Replaced by font-display: swap Require.js - A script to require scripts, don’t need it jQuery?!?? - Lots of jQuery’s good parts have been replaced by native browser tech and CSS animations.

TOTAL: 133.59 kb unzipped 49.25 kb gzipped

Slide 56

Slide 56

But looking at our site… removing jQuery is maybe a little more difficult. Take this freight.js tool, a way to declare button behavior in HTML that’s more or less a wrapper around $.ajax()

Slide 57

Slide 57

391 Occurences

391 occurrences 
@ 1hr per fix 
@ 1hr per QA
---------------------------
19.55 Weeks of Human Effort

And we still end up with a difficult to maintain jQuery app.

Auditing our JavaScript now gives us the ability to have a more informed discussion about what to do next.

Slide 58

Slide 58

Perhaps a framework makes more sense?

JavaScript Frameworks were built to solve these kinds of problems with a lot more structure. So we’ve started on a path that leverages Angular to add more structure to our JavaScript system.

Slide 59

Slide 59

That which is not managed, grows

Alls this to say, CSS gets a bad wrap for being “append only”, but as you can clearly see JS can grow and grow and grow. The

Slide 60

Slide 60

Rolling Out A Design System

I want to talk about rolling out a Design System real quick…

Slide 61

Slide 61

A Design System is a group of people with different abilities coming together to stitch together some patterns.

I’ve seen this process go many ways.

Slide 62

Slide 62

I’ve seen a group of people come together…

Slide 63

Slide 63

Upload some patterns to the cloud…

Slide 64

Slide 64

And rejoice.

Slide 65

Slide 65

I’ve also seen a team of people get ready to ship a Design System…

Slide 66

Slide 66

And get pulled over to fight some fire…

And when they’re about to get back to shipping the Design System…

Slide 67

Slide 67

They get pulled over to someone’s big idea.

And after they’ve lost a few people on the way and are about to push that Design System out…

Slide 68

Slide 68

New people show up and ask “Why not use Bootstrap?”

Slide 69

Slide 69

And then you’re back to the beginning, having the same conversations.

And what I have to say about this is the Patterns, the assembling the puzzle pieces of a Design System, that’s not the difficult part. It’s the people part.

Slide 70

Slide 70

Conway's Law

Computer Scientist Melvin COnway once said in the 60s

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway

Or as I like to put it…

Slide 71

Slide 71

Rupert's Law

Your website is a manifestation of your organization’s problems. – Dave Rupert

Why are two pages on the website different? That’s because of 2 different departments. Why does one page look good and one look weird? One team values design, the other doesn’t. Why does one page have too much animation? Design has too much unchecked power. Why is the site inaccessible? The org doesn’t care.

In fact, I’d go so far to the success of a Design System hinges on a person who is over Product, Engineering, and Design being bought in on the benefits of a design system.

Slide 72

Slide 72

2019

Let’s fast-forward to this year.

Slide 73

Slide 73

Frameworks

JavaScript frameworks have exploded and are impossible to ignore in 2019.

  • Angular, from Google
  • React, from Facebook
  • Vue, the indie choice

Slide 74

Slide 74

HTML5 Components

Let’s look at the structure of a traditional HTML5 app…

This is the classic separation of concerns.

Slide 75

Slide 75

Angular Components

Angular has made the decision through their tooling to enforce a pattern called “co-location”. You HTML/CSS/JavaScript and Tests are split up at the Component level.

Slide 76

Slide 76

React Components

React components actually prescribes very little, but one thing React components do is render out HTML using a slightly modified syntax called JSX.

In general, the community at large has settled on a similar structure where everything about your component is managed (or pulled into) a single JS file. From this you get patterns like CSS-in-JS. Technically, this is demoing CSS Modules, but there are a lot of options here. And then relies on Webpack or whatever tool to split up and dissect this code.

Slide 77

Slide 77

Vue Components

Vue Components are awesome. The sort of take things a step further and say “We’ll do HTML, CSS, and JavaScript in one file, but we’re going to add some structure.

I like this separation of concerns quite a bit. It’s still all handed off, sliced and diced by Webpack but it’s a pretty great authoring experience.

Regardless of your preference, I think it’s interesting to see this iteration on the “Separation of Concerns” and how different frameworks approach the “componentization” trend.

Slide 78

Slide 78

Buzzwords...

  • JAM Stack is Javascript, APIs, Markup. You make a static site of some kind and use JavaScript to connect to APIs. Most of the application power is on the front-end but can still be static pages powered by jQuery. Could be a JS Framework. Very broad term.
  • GraphQL is the ability to build your own database queries from the front-end. It’s a bit hard to wrap your head around but gives developers power to create data queries on their own without having to bother a backend developer every time.

Slide 79

Slide 79

The Power of Serverless

Once templating and data querying move to the client, well now we have to re-evaluate our relationship with the server. A “Serverless” server is a server that spins up on demand. It doesn’t run endlessly and fall over every two days. You hit the serverless API, the server starts up, and then shuts down when it’s all over.

Slide 80

Slide 80

Mobile has hit the tipping point

One thing in 2019 we can’t ignore is that mobile has hit the tipping point.

Slide 81

Slide 81

Mobile use still increasing

According to Mary Meeker’s Internet Trends report we can see that mobile use is continuing to increase and laptop/desktop use is starting to taper off.

Slide 82

Slide 82

And interestingly mobile device time has overtaken TV. This is a big moment.

The traffic I’m seeing on client sites is overwhelmingly mobile right now. And if I truly start thinking Mobile First, it changes a lot of my perspectives. Even weird things like font-size should never go over 20px. Not really. But in a mobile world, larger type sizes become less useful.

Slide 83

Slide 83

The Expectation Gap

The expectation gap is large. So there’s a lot of work to do.

And worth mentioning, all those JS Frameworks I talked about… they’re not mobile first. They were designed and shipped in the desktop era. We have a long way to go.

Slide 84

Slide 84

2024

Let’s look into our potential future a bit…

Slide 85

Slide 85

Web Components

Web Components have a sordid past, but it’s worth talking about because Web Components are also trying to solve the same problem as JS Frameworks: the story of JavaScript Components.

The potential here is that Web Components would be able to be a native solution, requiring less JS to performantly construct mobile-first component-based front-end experiences.

Slide 86

Slide 86

Create and HTML Import

The original version of Web Components had a feature called “HTML Imports”. You author components in an HTML <template> element then use a <script> tag to define a Custom Element.

Slide 87

Slide 87

Import that HTML Import into HTML

And then you use HTML <link rel="import"> to import that HTML file so you can use that custom HTML element. It’s HTML all the way down.

It worked pretty well. Polymer and AMP were built on this.

Slide 88

Slide 88

Firefox kills HTML Imports

But Firefox draws a line in the sand and says they have no interest in implementing HTML Imports.

Their argument in 2014 was that they wanted to see how ES Modules would shake out and that might inform our decisions here.

Slide 89

Slide 89

Web Components: Part II

ES Modules has now landed in most modern browsers so the most common way to author Web Components now is using JS.

Slide 90

Slide 90

All-in-JS Web Components

This is using LitElement, a small wrapper around native Web Components to make them a bit more easier to author.

You can see this style of component now looks a lot similar to a React Component.

Slide 91

Slide 91

Import Module Script in HTML

Then in your HTML, you import a JS module file to use your new custom HTML element.

Slide 92

Slide 92

Web Components are kinda “meh” right now, but…

Rich Harris recently wrote about why he doesn’t use Web Components and it highlights a lot of the nuanced problems in building component systems and frameworks with them.

In a lot of ways, Web Components were designed at a low-level for framework authors to build frameworks on… but framework authors aren’t building on it. Seems like Web Components has failed it’s core mission.

Slide 93

Slide 93

Systems Using Web Components

That’s not to say you can’t use Web Components right now. Lightning Web Components from Salesforce uses them. And projects like A-Frame, Ionic,

Slide 94

Slide 94

HTML Template Instantiation Spec

http://w3c.github.io/webcomponents/proposals/Template-Instantiation.html

Slide 95

Slide 95

Unity Component Spec

https://github.com/TheLarkInn/unity-component-specification

Slide 96

Slide 96

Web Components have the potential to be great.

Slide 97

Slide 97

Web Assembly

Slide 98

Slide 98

Squoosh

Squoosh is an image compression app from a few Google Dev Rels.

Slide 99

Slide 99

LiquidFun

LiquidFun by Lorenzo Cadamuro is amazing. This would be nearly impossible with JavaScript. One thing that JavaScript is bad at is math. And liquid physics uses a lot of math. That’s being handled by the Web Assembly component handing the rending off to WebGL. This is very cool and very fast.

Slide 100

Slide 100

https://perceptiontoolkit.dev/

Slide 101

Slide 101

Web Assembly will make websites more powerful.

Slide 102

Slide 102

CSS Houdini

Slide 103

Slide 103

https://css-houdini.rocks/rough-boxes

Slide 104

Slide 104

https://css-houdini.rocks/irregular-grid

Slide 105

Slide 105

https://css-houdini.rocks/masonry

Slide 106

Slide 106

Houdini will make websites unique again.

Slide 107

Slide 107

So before I go…

Slide 108

Slide 108

Mobile First: Once More with Feeling

Slide 109

Slide 109

Thank you very much

Dave Rupert @davatron5000