[Editor’s Note from Chris]: The world is in a bad way, team. If reading about web tech doesn’t feel right to you right now, smash that delete button (or unsubscribe through the link at the bottom). We’ll always be around if you care to come back, and all these issues are archived.
I’d encourage you to use whatever strengths you have to better the world. Find organizations that are most important to your community and help. Maybe with money. Maybe with your web skills. Maybe with your voice. Maybe with your time.
💪 💜
Increment: a wonderful magazine all about software development
The other day a rather lovely magazine arrived in the mail called Increment, published by the folks at Stripe, and I can’t wait to get my teeth sunk into it. Also, Chris happened to write a post in this issue all about the growing responsibilities of front-end developers:
Being a frontend developer requires an ever-larger grab bag of skills. It’s the natural outcome of the web getting bigger. As more people use the web, as the internet economy expands, and as browsers gain more capabilities and grow more complex, our expectations of what’s possible on the web grow with them.
I think Chris asks a ton of interesting questions in this post and expands upon his thoughts in The Great Divide. This time around I feel a hint of optimism here: yes, things are getting more complex, Chris suggests, but also there’s so many exciting things that us front-end developers can now improve and fix and, best of all, build.
The nifty thing about this magazine is that all of the issues are also available for the web too, so you can read all about Lea Verou’s guide to CSS variables or Safia Abdalla’s thoughts on composable, modular frontends, or Ramsey Nasser’s frontend stack for video games.
Google has new performance metrics called…
…Core Web Vitals! And they seem like an interesting collection of data points that help us best understand what the performance problem with our websites might be and how we might go about fixing the issue. Here’s what those metrics are though (and I can imagine us seeing numbers with these abbreviations a lot from here on out):
- LCP: Largest Contentful Paint
- FID: First Input Delay
- CLS: Cumulative Layout Shift
To see how your site stacks up against these metrics today you can use the Chrome extension that happens to look something like the screenshot above. From the blog post introducing these new fangled things though, it sounds like these metrics will start to be added to PageSpeed Insights and Lighthouse as well as Chrome DevTools pretty soon. Hopefully this gives us a better way to communicate as developers about this stuff, too.
A first look at aspect-ratio
That’s the name of a new CSS property and Chris hops into the new hot thing by walking us through how aspect-ratio works with a bunch of scenarios. First up, throw it on an element like this:
.el {
aspect-ratio: 16 / 9;
}Considering an element like this will have a width of auto by default, the height here will be calculated from that. But! This is what makes this property interesting, as Chris makes note:
If the element has either a height or width, the other is calculated from the aspect ratio.
Jamstack Conf 2020
It’s pretty remarkable how quickly the videos for this year’s conference were published. The talks cover a wide spectrum of topics, each of them interesting in their own right, and discuss a ton of things that have been made possible with the Jamstack, such as the COVID Tracking Project.
The talks also come with the news from Netlify of their latest feature, Build Plugins. This allows us developers to do a bunch of nifty things when a Netlify build gets triggered. For instance, you could check for broken links, or misspelled words, or inline your critical CSS.
I think what’s exciting about this announcement for me is that I can see tools such as Grunt and Gulp and even Webpack to some degree becoming less necessary over time with an extended list of plugins. And this decreases the complexity of build tools because yikes I cannot imagine how much time I’ve spent wondering why this one weird Gulp thing keeps happening.
I can’t wait to see where this stuff goes.
Responsive web design turns 10!
Ethan Marcotte has made a few notes about the anniversary of coining the term which makes for a fascinating read:
Around that time, my partner Elizabeth visited the High Line in New York City shortly after it opened. When she got back, she told me about these wheeled lounge chairs she saw in one section, and how people would move them apart for a bit of solitude, or push a few chairs together to sit closer to friends. We got to excitedly chatting about them. I thought there was something really compelling about that image: a space that could be controlled, reshaped, and redesigned by the people who moved through it.
I remember spending that evening reading more about those chairs and, from there, about more dynamic forms of architecture. I read about concepts for walls built with tensile materials and embedded sensors, and how those walls could bend and flex as people drew near to them. I read about glass walls that could become opaque at the flip of a switch, or when movement was detected. I even bought a rather wonderful book on the subject, Interactive Architecture, which described these new spaces as “a conversation” between physical objects or spaces, and the people who interacted with them.
After a few days of research, I found some articles that alternated between two different terms for the same concept. They’d call it interactive architecture, sure, but then they’d refer to it with a different name: responsive architecture.
Just a few days later Ethan followed up with another piece but this time about the challenges that a lot of folks are currently experiencing with responsive design, especially when it comes to naming breakpoints such as “mobile,” “tablet” or “desktop”:
…focusing on two or three key layouts often means that the “in-between” states don’t get as much attention from digital teams. (Filament Group’s Todd Parker calls these the “awkward teenage haircuts” of a responsive layout, and I love that term.) And as devices and viewports continue to evolve, our users will likely start seeing those previously-ignored breakpoints.
This reminds me of something I jotted down not so long ago when it comes to Thinking in Behaviors, Not Screen Sizes which might be worth a read as well.
Thoughts on browser engine diversity
There’s been a lot of talk about browser engine diversity recently—especially since Microsoft discontinued Internet Explorer—and most of that talk certainly hasn’t been positive. Many folks have decried the lack of diversity and the sad state of affairs that one bad actor might have an enormous influence of the shape of the web. And this, in turn, makes everything worse for us as users of the web first and foremost.
But Brian Kardell has a bunch of interesting thoughts here which I hadn’t considered but now seem awfully obvious in hindsight—most browsers evolved and didn’t start from scratch:
Web engines today are so astonishingly complex (measured in tens of millions of lines of code) that we only get new ones through evolution. For the most part, this has been true for a long time. Even Netscape was a “take 2” from many of the same minds from Mosaic. Mozilla was created from a rework of Netscape. Even IE was born by licensing the Mosaic code. WebKit was born by forking KHTML. In other words: The critical investment required to create a full-blown compliant browser from nothing would be mind-boggling if everything were stopped today – and it never stops.
New colors, new web, new me!
Ollie Williams explores the expanding gamut of color on the web and the Display P3 colorspace that you might’ve heard a few things about lately. Effectively this lets us use colors that were never possible before, as Panic did recently with the website of their new code editor, Nova.
Sponsor
Deployment Previews for All
Frontend staging environments on-demand. Shorten feedback loops, increase code quality and push stable releases.
Get started today with a 2-week free trial →
Sponsor
Netlify Build Plugins are Here!
Netlify made some noise at the Jamstack Conf 2020 when they introduced Build Plugins. They’re these little helpers that do big things when your site is building — from accessibility and 404 checkers to image optimizations and cache busting. Seriously, there’s already a whole bunch of plugins available!
And, hey, you can build and contribute your own build plugins. In fact, Sarah wrote up how to do it and it’s a great place to start.
[Chris]: I enjoyed this little website: Guitar Practice Loops.
That’s an <audio> element that plays those guitar chords over and over. If you’re also a guitar player, the idea with the chart is that those notes are within the scale that traditionally works best with those chords, so you can practice noodling around and playing lead. I spent a bit of an afternoon playing banjo along with it!
The (very anonymous) creator emailed me about it and mentioned that while they are into a variety of newer/fancier tech, this thing is “just” a WordPress website, as WordPress made it delightfully simple to toss up a site like this. Could you build this with just about anything? Sure. But, like them, I probably would have leaned on WordPress too. WordPress would make publishing new entries really easy (log in, upload audio, upload graphic, publish). It gives you an easy way to publish pages that aren’t part of the flow (about, contact). You get the pagination out of the box.
Maybe you have your own go-to tech that makes you feel really productive really quickly?
