[Robin]: My favorite website at the moment is Volume, “a publishing platform for high-quality illustrated books.” It’s a place where you can kickstart book-related projects but what gets made at the end are these enormous and beautiful bits of graphic design.

Just take a look at how relatively simple the layout is:

As you scroll through each project there are these big pull quotes and although I don’t often like them, I think they work extremely well here because of how gosh darn pretty they are:

With nothing more than a splash of color, some big type, and a few well-placed images, the Volume website becomes so much more interesting than it might otherwise be. The nifty thing about this is that these are tools we all have out our fingertips.

Speaking of typography, I also stumbled upon this piece for the New York Times by Jason Farago all about art and power. As you scroll through the piece the painting will zoom in so that Jason can describe that part in more detail:

The Space Jam website has been a time capsule. You’d head to spacejam.com suddenly be teleported back to 1996; a time before CSS, a time when using <table> elements to make grids and layouts on a page was cool, a time before DevTools and Firebug showed us what the heck we were even building.

The Space Jam website is special because it’s a piece of web design history. It shows us how far we’ve come.

But if you head to the site today, it now shows a completely redesigned website for the new movie starring LeBron James. You can still access the old site by clicking a logo in the top right which is neat but there’s something a tiny bit sad to me that the old website is no longer attached to this URL anymore.

While I was lamenting that URL changing and being lost to the sands of time, Max Böck had other concerns. He wrote this great piece about performance and compared the original 1996 website with this new version. After running both sites through WebPageTest, Max comes to this conclusion:

[…] after 25 years of technological progress, after bringing 4.7 billion people in the world online, after we just landed a fifth robot on Mars, visiting the Space Jam website is now 1.3 seconds faster. That seems…underwhelming.

[…] Although connection speeds and devices keep getting better and better, the web is actually getting slower. We see the increasing bandwidth as an invitation to use more and more stuff in our websites. More images, more videos, more JavaScript.

So if the old Space Jam website shows us how far we’ve come, then the replacement shows us how far we still have to go.

And despite all the tools we have now — not to mention the conferences, books, and websites that are dedicated to the subject — we’ve sort of stagnated. Why after all these years are we stuck with painfully slow websites? Why haven’t things improved much at all and, in many cases, actually gotten a whole lot worse?

There’s probably a lot of reasons, but I think it’s ultimately a cultural problem. Many folks, and not all of them are developers, tend to believe performance is a nice-to-have, an additional feature we can get to later instead of it being baked into our work day-to-day.

Kealan Parr wrote about bad web performance and how to improve it the other day. He argued that a slow website isn’t just an annoying experience for users but a huge detriment to a business as well. Or, to put it another way, bad performance is bad for business:

[…] Firefox made their webpages load 2.2 seconds faster on average and it drove 60 million more Firefox downloads per year. Speed is also something Google considers when ranking your website placement on mobile. Having a slow site might leave you on page 452 of search results, regardless of any other metric.

How do we make fast websites though? Kealan explains:

Here’s the thing: performance is more than a one-off task. It’s inherently tied to everything we build and develop. So, while it’s tempting to solve everything in one fell swoop, the best approach to improving performance might be an iterative one. Determine if there’s any low-hanging fruit, and figure out what might be bigger or long-term efforts. In other words, incremental improvements are a great way to score performance wins. Again, every millisecond counts.

Incremental wins, I like that. But before we dive in and try and make our websites fast, we need to understand why things are slow in the first place. That’s why I enjoyed this other performance-related blog post by Jake Archibald where he looks into who has the fastest F1 racing website in 2021.

What’s great about this post is that all the recommendations that Jake suggests are tiny improvements that would shave off whole seconds from each website. And, thankfully, these are all small enough that they don’t require restructuring your whole organization.

Also, there’s so many great bits of advice that can be applied to the websites that we’re all building right now, like this one:

[…] it’s important to avoid hosting render-blocking content on other servers.

That’s always a good reminder and it’s why I now tend to avoid hosting images, fonts, and CSS on other people’s servers.

[Robin]: Someone emailed me the other day out of the blue and noticed an odd pattern: apparently whenever I write about just about anything design systems related or about front-end development, the conversation always comes back to my frustrations with Bootstrap. I’m constantly refactoring it, removing it, tidying it up.

So: why’s that?

Well, I think Bootstrap is an example of a remarkably good tool that’s often misused. And the reason why is because when folks start building an app they often think of CSS as something that’s annoying, something that shouldn’t be built from scratch so they turn to a library like Bootstrap. They don’t want to have to build a carousel or a button or an anything for the millionth time, they just want to copy and paste HTML and CSS together to make it work.

The problem with this is that if left untended, Bootstrap can become an example of radioactive code.

The last three projects I’ve worked on all started with Bootstrap to provide the foundations for things — they’d start by loading Bootstrap via a CDN in the head of the document:

<head> <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta3/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-eOJMYsd53ii+scO/bJGFsiCZc+5NDVN2yr8+0RDqr0Ql0h+rP48ckxlpbzKgwra6" crossorigin="anonymous"> </head>

This is bad for a whole bunch of performance reasons so eventually folks would start using it as a dependency in node. They would npm install bootstrap and badda bing badda boom, you now have all the CSS you’ll ever need.

The problem here is that Bootstrap contains so much stuff that you don’t need 95% of it. You’ll need the reset, the normalize styles but the dozens and dozens of component styles you won’t need or ever use. They’ll just get in the way and slow you down.

But not only are you asking users to download data but it will make for a worse developer experience, too. That’s because folks on most teams will start to componentize their front-end code and instead of refactoring Bootstrap they’ll often choose to make a new component and then override the Bootstrap styles. This will happen until things get so messy that even though you might have a nifty <Button> React component, there might be eight different style sheets impacting that component from god knows where.

When a team starts using Bootstrap in this way it gets incredibly difficult to see the damage and point it back to this single point of failure. You’ll just start finding that it’s harder to write good front-end code. You’ll find tons of hacks lying around in your codebase and you’ll furrow your brow before continuing writing more code somewhere else.

Now, I don’t blame Bootstrap for this — I blame how Bootstrap is used.

The way we should use it is by taking only the pieces we need, specifically, the component styles. We shouldn’t npm install this stuff either. I think we need to vendor it.

What does “vendoring” code mean? Well, the other day I stumbled upon this term in a blog post by Tom MacWright:

Vendoring, in the programming sense, means “copying the source code of another project into your project.” It’s in contrast to the practice of using dependencies, which would be adding another project’s name to your package.json file and having npm or yarn download and link it up for you.

This is exactly how I think we should be using CSS framework-esque projects like Tachyons and Bootstrap: just go and copy/paste only the parts of that code that you need.

Whenever I join a team this is almost always the first thing I do when it comes to design systems. I vendor Bootstrap, copying and pasting and deleting only the stuff we need and moving all those global styles into React components so that they can be read and understood easily in the future.

Vendoring code in this way might sound gross but it’ll be easier to make changes in the future, easier to read, and oddly enough easier to update if that specific library changes, too.

First up this week, Tatiana Mac wrote about taking a no-motion-first approach to animations where she argues that animations can be neat and fun and great but for some folks animations are horrible and can cause them actual discomfort or even pain.

In light of this, Tatiana argues that we should make our websites work without motion first:

Animations help to breathe life into interactive experiences. Animations, especially when overused and abused, can make people very ill. Through this article, I hope to provide you an approach and guidance to discussing how you/your company use animation thoughtfully and responsibly.

This approach doesn’t require us to completely change the way we work, only the way we think. And so Tatiana recommends that when we need to add animation we ought to use this fancy media query called prefers-reduced-motion:

@media (prefers-reduced-motion: no-preference) { /* animation styles go here */ }

What this will do is check to see if the user has disabled animations in their operating system and if they haven’t, it’ll then apply those animation styles within. That certainly sounds simple enough to me.

I also really liked this bit of the article where Tatiana describes what’s critical versus what’s valuable in interface design on the web:

When I collaborate with a designer/animator on an animation, I first ask, “Is this animation critical to understanding the content?”

More often than not, the answer is “no.” (It might take some finessing of the conversation, so remember to emphasise that being critical isn’t the same thing as being important or nice or aesthetic.) When conceived well, animations should be an enhancement to an explanation.

I love this because it’s progressive enhancement through and through. What’s truly critical in an interface? Are fonts? Are images? Are those border radiuses and that fancy scroll-jacking animation that flips across the screen? We have to let our ego take a raincheck for a bit and admit that, well, nope—when it comes to web design all of those things are accessories, additions to the critical functions of the site.

This reminds me of a story I heard about Nintendo and how they made Mario 64. Throughout the entire development process the team had a single question they would ask themselves whenever they added a new feature or mechanic: “Is this fun?” It was their only metric for success and helped guide them through the development process of a truly brilliant game.

Perhaps when it comes to web design we should be asking ourselves a similar question. And maybe our question depends on the company/the problem/the context of whatever we’re trying to build.

But I think a good starting point is to ask ourselves: “Is this critical?” Because when it comes to web design what’s truly critical is HTML and that’s about it. Everything else is a nice to have but words and links and forms are perhaps the only truly critical parts of an interface—and that’s the beautiful thing about progressive enhancement.

[Robin]: hsl() is my new favorite design tool. Okay, so it’s not entirely new — hsl() has been around for a while — but I’ve caught myself using this new color format lately and, from now on, I’ll be avoiding writing CSS like this:

.element { color: #b91313; }

.element { color: hsla(0, 81%, 40%, 1); }

.element { background: hsl(0 81% 40%); background: hsl(0 81% 40% / 1); }