📝 This Week in Web Design and Development

View this newsletter on the web.

🔗 Links from around the web

  • Here’s a great post from Bastian Allgeier all about simplicity in web development. He writes about how things are getting more complicated and it might not be helpful for us all in the long run:

You want to build a JS file? Please update Webpack first. Oh, that new version of Webpack is no longer compatible with your Node version. Oh, your new Node version is no longer compatible with that other dependency. Oh, now you have 233 detected security issues in all your node_modules but you can’t fix them because that would break something completely unrelated.

This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.

  • Scott Jehl explains that 5G is on the horizon and how it could cause problems for users. The idea is that when we get power, we use it… and then some. Since 5G will arrive in affluent areas first, we’ll widen the gap between high and low end connections even wider than it are today.
  • caniuse.com is perhaps the greatest website ever made but the brand new caniemail.com must come just shy at second place (just look at that nice mobile experience). It helps figure out which features email clients support.
  • How do you change the colors of product images using CSS blend modes and SVG? Kyle Wetton answers that question by showing us how to build a feature that changes the color of someone’s t-shirt without needing a brand new photograph to do it! Pretty nifty trick, this one.
  • A while back, Monica Lent wrote about what she learned as a junior developer and has some super interesting thoughts on technical debt, what being a senior developer means, and the skills that a programmer should acquire that go beyond coding. And at the other end of the spectrum… What does tech leadership really mean?

📝 From the blog

How to Contribute to an Open Source Project

Sarah Drasner offers this primer on contributing to open source projects for those who may be new to it. I particularly like this bit:

As a maintainer, it’s frustrating when someone put in a lot of work and submits a giant honking PR that does 10 different things. It’s really tough to review, and inevitably, they’re doing six things you want, and four things you don’t. Not only that, it’s usually spread out over multiple files which is difficult to untangle. I’ve definitely closed PRs with some high-quality code I would like just because it would take forever for to review and manage it.

In my opinion, you have about 1,000% more chance of getting your PR merged and your time spent honored if you split things over multiple, smaller PRs.

This advice reminds me of what I learned a while back on the topic of starting a front-end refactor, too. Keeping focused is the hardest part about contributing to any project but it will be sure to pay off over time.

📝 This Week in Web Design and Development

View this newsletter on the web.

🔗 Links around the web

🔥 Hot take of the week

[Robin]: This week I’m in Portland, Oregon for XOXO (an arts festival for kindred web folk) and I mention this because I got to chatting with a designer about publishing on the web. They mentioned that they’re sort of overwhelmed with getting started; the writing isn’t the hard part, they mentioned, instead it was the editing, the publishing! Hitting that big green button and making those thoughts public.

To help with this feeling, Chris wrote about how to get started with technical writing and I think one of the most important notes he makes is this one:

Write at the moment of learning. The moment you learn something is the best time to write. It’s fresh in your mind and you can remember what it was like before you understood it. You also understand what it takes to go from not knowing to knowing it. That’s the journey you need to take people on.

Not to brag (I am currently bragging) but this is how I went about writing the series of posts all about CSS Modules. As I was hacking things together and trying to figure out this weird and technical thing that made zero sense to me I would make notes in a journal as I went. Eventually, by fleshing out those notes I could then retrace my thoughts when it came to implementing CSS Modules on a recent project. It was sort of magic!

However, I think it took a rather long time to gain the confidence to publish on the web—and a lot of that confidence came from owning my own little website where I could publish whatever nonsense was rattling around my noggin.

I’m reminded of this because Jamie Tanna wrote a great piece recently called Why I Have a Website and You Should Too, where he writes:

Having a website and/or blog is not about being a web developer, nor about being a celebrity of sorts, but is about being a citizen of the Web. This may sound a bit grand, but that’s the point — the World Wide Web is this amazing thing that was literally built for everyone. We need to make sure that we are all using it to its best, and owning a piece of it to show big companies that it’s ours, not theirs!

Lots of folks have written along similar lines in the past, and what I like here is how Jamie describes why owning your own site is useful for letting others find you and giving you a space to experiment with weird ideas.

If you’re a developer it could be a list of all your favorite demos from CodePen! If you’re a big reader it could be a list of your favorite books! Or if you’re a hiker, your favorite walks around the countryside! And so this is just a reminder that personal websites are not just for designers and engineers and it’s okay to avoid making a Medium-style blog.

But I think the best thing about having our own websites is to experiment with web technology, sure, but more importantly: to help give us all that jolt of confidence we need to keep publishing, to keep learning and growing. We should ignore any potential audience and think about only how we can make ourselves smarter and more informed on a subject.

That’s why I reckon we should all have a little home for ourselves on the web.

📝 From the Blog

Should a website work without JavaScript?

After listening to an episode of the JS Party podcast, Chris jotted down his thoughts about this question. One interesting point that caught my attention is this one:

Service workers are JavaScript. Web workers are JavaScript. Some of the fancy resilience and performance features of the web are powered by the same technology that causes the grief we debate about.

This is… true! And unexpected! I think generally it’s easy to paint everything with a broad brush and say that JavaScript is bad because performance or accessibility. However if you dig deeper into things with a more nuanced understanding of the situation it’s pretty clear that it’s not the technology at fault, but the way in we use it.

Chris continues:

There is an in-between moment with progressive enhancement. If a feature is functional without JavaScript, that means it’s likely you are deferring the loading of that JavaScript for the performance benefit. But it does eventually need to be downloaded and executed. What happens during that time? There is a performance and UX cost there. Best case, it’s negligible. Worst case, you break the feature during this in-between time.

This reminds me of Jeremy Keith’s book on the subject of resilience in web design which is worth reading. The point Jeremy makes throughout the book is that JavaScript is a vital tool but it’s very easy to build websites (or apps or whatever we’re calling them this week) that can blow up in the slightest gust of wind.

My hot take: I don’t think we can really talk about websites working without JavaScript because the question is too broad. Instead we should focus on the specifics of each feature that we’re building. Does this website with nothing but images, links, and paragraphs need JavaScript? Ehhhhh, probably not? Sometimes? Maybe?

It’s annoying and complicated and far from simple. Yay for nuanced arguments though!

📝 This Week in Web Design and Development

View this newsletter on the web.

[Robin]: There’s a part of any front-end codebase that’s like the core of a reactor—all the features in an application are dependent on this tiny amount of code; fragments and snippets that are the load-bearing posters of your codebase. That sounds obvious but in practice, it’s hard to see what’s load-bearing and what’s trash. Maybe the trash is load-bearing!

(That’s when you have some real design systems issues.)

The reason why I mention this is that one problem we’ve had in our front-end is one I haven’t heard anyone else mention before: for a long time it was almost impossible to write good front-end code in our codebase. Our components were so strange and peculiar, so dependent on custom CSS or page-level styles that you couldn’t possibly do the right thing when you were building a feature.

All too slowly I realized that if we didn’t fix these core parts of the front-end then everything our engineers built in the future would be nothing but hacks on top of even more peculiar hacks.

One example I discovered recently was with our tables. At Gusto, we have two codebases; our component library (which consists of our reusable React components and core styles) and our primary web application (which consumes the component library).

I stumbled upon code like this in our primary web app:

table.big-table { tr.big-table-row td.cell { background-color: #eee; } }

That’s…not great! But why is this so odd? Why would a very capable and smart engineer hack together code like this? Well, after investigating the core of our codebase, and looking at the very bottom of the stack of styles that make up our component library we had a ton of code that was way too specific.

And so the only way to get around that is to make these nasty specificity hacks in the primary web app.

In our component library we might have styles like this:

table.table > th.table > td { }

Code like this isn’t terrible but it’s effect on the system truly can be catastrophic. And as I mentioned earlier I often imagine that the core of a codebase should be seen as a nuclear reactor—a machine that can leak toxic code into other parts of the codebase if we’re not paying attention. And it’s radioactive code like the stuff above that poisons everything built on top of it and ensures that it’s quite impossible to write high quality front-end code.

If you want to change one small thing and it requires what feels like a hack, like the specificity issue above, then your reactor is leaking toxic code and you need to fix it before more issues build up over time.

And so we need to be constantly reminding ourselves of the core of our codebase: are we building hacks on top of hacks or are we extending the core and building something that will last on top of it?

So we must always remember that if folks have to fight the very core of a codebase then this is a signal that the reactor is on fire. Because smart people will do extraordinarily dumb things when they don’t have the tools and support that they need. And so to help them we must always remember the core, we must always be finding ways in which to make it simpler and less error-prone.

And then we need to go fix it.

📝 From the Blog

Styling Links with Real Underlines

Ollie Williams brings up a lot of interesting points in this post, especially where he argues that:

In graphic design, underlines are generally seen as unsophisticated. There are nicer ways to draw emphasis, to establish hierarchy, and to demarcate titles. […] But the web is different. Hyperlinks are the defining feature of the internet; and from the internet’s inception, they have been underlined. It’s a universally understood convention. The meaning is crystal clear — an underline means a link.

Underlines are a particularly webbish design convention and it’s pretty odd that native apps rarely appear to use them. I guess it’s because websites generally have so much more longform text.

Either way, it’s pretty neat that the text-decoration-skip-ink CSS property has now been added to our tool-belt to control how underlines are styled—but!—the neatest thing is that the default underlines are now much prettier.

The default value of text-decoration-skip-ink is auto (left) and a value of none (right). So! In my opinion this is the coolest thing.