Howdy everyone! Here’s some of the most interesting things we spotted this week. Let’s go!
What’s the cost of using a JavaScript framework?
That’s the question that Tim Kadlec answers in this very in-depth post where he grabs data from the HTTP Archive and compares different frameworks against one another, testing how much they all impact performance.
I don’t want to dig into the stats specifically because I don’t think that’s the most interesting part of this post. Instead, it’s this part:
In an ideal world, I believe a framework should go beyond developer experience value and provide concrete value for the people using our sites. Performance is just one part of that—accessibility and security both come to mind as well—but it’s an essential part.
So in an ideal world, a framework makes it easier to perform well by either providing a better starting point or providing constraints and characteristics that make it hard to build something that doesn’t perform well.
Tim digs into the performance of these frameworks after the bytes have been sent down the wire because there’s a performance cost whenever all that JavaScript has to be run, too. And I think it’s worth mentioning that this post from Tim isn’t just dunking on frameworks — it’s pushing us all to try harder rather than simply accepting the status quo when making websites.
Hopefully this is some pressure for the JavaScript frameworks to do better, as while it isn’t their fault exactly, it’s telling when even the top 10% best-performing are pointedly worse than not using a framework. It’s the same situation as accessibility and frameworks. No need to point fingers, but the frameworks are in the best position to make a difference.
Improving your VS Code Workflow
There’s a handful of nifty improvements here and my favorite one has to be how Chris saved his VS Code workspaces to his dock and then made custom icons for them so it looks like this:
Now, whenever he clicks one of these links it boots up VS Code with the right workspace and with the correct terminal commands running. Pretty neat!
There’s an input attribute for a one-time code
So says our very own Geoff Graham where, in this post, he shows us how to autocomplete input fields with the two factor authentication codes that happen to look like this:
This is done by using the following markup:
<input type="number" autocomplete="one-time-code" />That’s pretty neat and is bound to save folks a whole bunch of time typing in these annoying but extremely useful codes.
Alex Holachek did a deeper look into all this recently. There is a lot of autocomplete values and it’s likely most of us aren’t taking advantage of all of them (not to mention inputmode).
Here’s a tab I can’t close because it’s too pretty
It’s the type specimen for Klim Type’s the Heldane Collection. Just, wow! Klim’s designs are always charming and eye-popping and. just. look.
The neat thing about this type specimen is that it also acts as an essay about the design of the typeface itself. Gah. I love this thing so very much.
CSS Separator Generator
That’s a weird bunch of words to put together but it describes this website perfectly: you can use this CSS generator to quickly generate backgrounds if you want to make the bit between sections of your website more interesting:
Should come in pretty handy soon for me.
If the diagonal separator is the one that catches your eye here, here’s a much deeper look into that one.
SVG, Favicons, and all the fun things we can do with them
SVG favicons have some degree of support across the board now, and Eric Bailey walks us through it all. Chrome and Firefox will take a straight up .svg file instead of .ico, and Safari has that special “pinned” “mask” thing.
The cool things is that this unlocks some tricky like re-styling the SVG in dark mode or when high contrast is activated:
There’s a ton of other good things to keep in mind in this post, so it’s definitely worth reading for the most up-to-date info on the subject.
Dark mode ?? variable fonts
We published a neat trick for improving legibility in dark mode: slightly changing the text weight with a variable font. It’s just a tiny bit of code that might something like this:
body {
font-weight: 400;
}
@media (prefers-color-scheme: dark) {
body {
font-weight: 350;
}
}But that has a big impact on the reading experience as you can see from this example:
Speaking of fonts, here’s a look at accessible font sizing
Andrés Galante looks at all the things we need to take into consideration when designing accesible text on the web. Is the type too light or too dark? Or too small or too big? Is the color of the text good for reading long blocks of text?
My extra hot tip here would be to think about the distance between the screen and the reader. That’s often hard to do when we’re developing on a laptop or bigger screens, so it’s best to test as many devices as we get our mitts on.
Sponsor
CodePen PRO
Unlock the full power of CodePen by upgrading to a PRO account. You’ll be able to save private Pens, upload assets, work with others in real-time with Collab Mode, and more! And, hey, it’s a heckuva great deal starting at just $8.
Let’s leave you with this one: BlurHash
Are you familiar with the “blur up” technique? The idea is that we’re lazy loading images, but rather than showing nothing before the image loads, you show a blurred version of the image you’re about to load. The blurred version being much, much smaller and less of a performance concern. This library makes the blurry images from only about 20 characters pre-saved and renders them to a <canvas>.
