We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
I did not know about box-decoration-break—sounds like a game-changer for text effects that wrap onto multiple lines.
I’ve noticed a trend in recent years—a trend that I’ve admittedly been part of myself—where performance-minded developers will rebuild a site and then post a screenshot of their Lighthouse score on social media to show off how fast it is.
Mea culpa! I should post my CrUX reports too.
But I’m going to respectfully decline Phil’s advice to use any of the RUM analytics providers he recommends that require me to put another script element on my site. One third-party script is one third-party script too many.
This is a great tutorial—I just love the interactive parts that really help make things click.
I hadn’t come across this before—run Lighthouse tests on your pages from six different locations around the world at once.
This website is hosted across a network of solar powered servers and is sent to you from wherever there is the most sunshine.
This is a truly wonderful web page! It’s an explanation from first principles of how cameras and lenses work.
At its most basic, it uses words which you can read in any browser. It also uses images so if your browser supports images, you get that enhancement. And it uses interactive JavaScript widgets so that you get that layer of richness if your browser supports the technology.
Then you realise that every post ever published on this personal site is equally in-depth and uses the same content-first progressive enhancement approach.
A fascinating look at the history of calendrical warfare.
From the very beginning, standardized global time zones were used as a means of demonstrating power. (They all revolve around the British empire’s GMT, after all.) A particularly striking example of this happened in Ireland. In 1880, when the United Kingdom of Great Britain and Ireland declared GMT the official time zone for all of Great Britain, Ireland was given its own time zone. Dublin Mean Time was twenty-five minutes behind GMT, in accordance with the island’s solar time. But in the aftermath of the 1916 Easter Rising, London’s House of Commons abolished the uniquely Irish time zone, folding Ireland into GMT, where it remains to this day.
This is an excellent new tool for showing exactly what kind of tracking a site is doing:
Who is peeking over your shoulder while you work, watch videos, learn, explore, and shop on the internet? Enter the address of any website, and Blacklight will scan it and reveal the specific user-tracking technologies on the site—and who’s getting your data. You may be surprised at what you learn.
Best of all, you can inspect the raw data and analyse the methodology.
There are some accompanying explainers:
I added a dark mode to my website a while back. It was a fun thing to do during Indie Web Camp Amsterdam last year.
I tied the colour scheme to the operating system level. If you choose a dark mode in your OS, my website will adjust automatically thanks to the prefers-color-scheme: dark media query.
But I’ve seen notes from a few friends, not about my site specifically, but about how they like having an explicit toggle for dark mode (as well as the media query). Whenever I read those remarks, I’d think “I’m really not sure I’ve got time to deal with adding that kind of toggle to my site.”
But then I realised, “Jeremy, you absolute muffin! You’ve had a theme switcher on your website for almost two decades now!”
Doh! I had forgotten about that theme switcher. It dates back to the early days of CSS. I wanted my site to be a demonstration of how you could apply different styles to the same underlying markup (this was before the CSS Zen Garden came along). Those themes are very dated now, but if you like you can view my site with a Zeldman theme or a sci-fi theme.
To offer a dark-mode theme for my site, all I had to do was take the default stylesheet, pull out the custom properties from the prefers-color-scheme: dark media query, and done. It took less than five minutes.
So if you want to view my site in dark mode, it’s one of the options in the “Customise” dropdown on every page of the website.
More of the whimsical web!
A collection of truly personal sites.
This site is meant to showcase how a more personal web could look like, and hopefully give you some inspiration to make your own corner of the web a bit weirder.
Of course Cassie’s site is included!
I’m not the only one swapping out Sass with CSS for colour functions:
Because of the declarative nature of CSS, you’re never going to get something as terse as what you could get in Sass. So sure, you’re typing more characters. But you know what you’re not doing? Wrangling build plugins and updating dependencies to get Sass to build. What you write gets shipped directly to the browser and works as-is, now and for eternity. It’s hard to say that about your Sass code.
I wrote recently about moving away from Sass to using native CSS features. I had this to say on the topic of mixins in Sass:
These can be very useful, but now there’s a lot that you can do just in CSS with
calc(). The built-indarken()andlighten()mixins are handy though when it comes to colours.
I know we will be getting these in the future but we’re not there yet with CSS.
Anyway, I had all this in the back of my mind when I was reading Lea’s excellent feature in this month’s Increment: A user’s guide to CSS variables. She’s written about a really clever technique of combining custom properites with hsl() colour values for creating colour palettes. (See also: Una’s post on dynamic colour theming with pure CSS.)
As so often happens when I’m reading something written by Lea—or seeing her give a talk—light bulbs started popping over my head (my usual response to Lea’s knowledge bombs is either “I didn’t know you could do that!” or “I never thought of doing that!”).
I immediately set about implementing this technique over on The Session. The trick here is to use separate custom properties for the hue, saturation, and lightness parts of hsl() colour values. Then, when you want to lighten or darken the colour—say, on hover—you can update the lightness part.
I’ve made a Codepen to show what I’m doing.
Let’s say I’m styling a button element. I make custom propertes for hsl() values:
button {
--button-colour-hue: 19;
--button-colour-saturation: 82%;
--button-colour-lightness: 38%;
background-color: hsl(
var(--button-colour-hue),
var(--button-colour-saturation),
var(--button-colour-lightness)
);
}
For my buttons, I want the borders to be slightly darker than the background colour. When I was using Sass, I used the darken() function to this. Now I use calc(). Here’s how I make the borders 10% darker:
border-color: hsl(
var(--button-colour-hue),
var(--button-colour-saturation),
calc(var(--button-colour-lightness) - 10%)
);
That calc() function is substracting a percentage from a percentage: 38% minus 10% in this case. The borders will have a lightness of 28%.
I make the bottom border even darker and the top border lighter to give a feeling of depth.
On The Session there’s a “cancel” button style that’s deep red.
Here’s how I set its colour:
.cancel {
--button-colour-hue: 0;
--button-colour-saturation: 100%;
--button-colour-lightness: 40%;
}
That’s it. The existing button declarations take care of assigning the right shades for the border colours.
Here’s another example. Site admins see buttons for some actions only available to them. I want those buttons to have their own colour:
.admin {
--button-colour-hue: 45;
--button-colour-saturation: 100%;
--button-colour-lightness: 40%;
}
You get the idea. It doesn’t matter how many differently-coloured buttons I create, the effect of darkening or lightening their borders is all taken care of.
So it turns out that the lighten() and darken() functions from Sass are available to us in CSS by using a combination of custom properties, hsl(), and calc().
I’m also using this combination to lighten or darken background and border colours on :hover. You can poke around the Codepen if you want to see that in action.
I love seeing the combinatorial power of these different bits of CSS coming together. It really is a remarkably powerful programming language.
This micro libarary does DOM diffing in native JavaScript:
Reef is an anti-framework.
It does a lot less than the big guys like React and Vue. It doesn’t have a Virtual DOM. It doesn’t require you to learn a custom templating syntax. It doesn’t provide a bunch of custom methods.
Reef does just one thing: render UI.
I worry that more and more nowadays, people jump to JavaScript frameworks because that is what they know or have been taught, even though they are entirely inappropriate for a wide array of things and can often produce poor results.
Last week I wrote about the great work that Matthew did and now he’s written up his process:
The important thing is to have a resilient base layer of HTML and CSS, and then to enhance that with JavaScript.
It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.
No more lighting or audio technicians. No more studio audiences. Heck, no more studios.
There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching Mary Beard present Front Row Late from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.
All of this is one big belaboured metaphor for websites.
In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an emergency website kit:
The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.
Eric emphasises the importance of performance in his post Get Static:
I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
Tom Loosemore offers this advice to teams building new coronavirus services:
- Get a 4 year-old Android phone, and use it as your test/demo device.
- https://design-system.service.gov.uk is your friend.
- Full React isn’t your friend if it makes your service slow & inaccessible
Remember: This is for everyone.
Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as Matthew attests:
coronavirus.data.gov.uk is a static site, fetching and displaying remote data. It is also a 100% client-side JavaScript React site.
http://dracos.co.uk/made/coronavirus.data.gov.uk/ is 238K vs 770K (basics) on load. I’ve removed about 550K of JavaScript. It seems to work the same.
One sign that your website isn’t meeting the needs of all your users is when Matthew Somerville gets sufficiently grumpy about it to do a proper version himself.
It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His accessible Odeon project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: traintimes.org.uk—it’s a terrificly performant progressive web app.
It’s thankless work though. It flies in the face of everything considered “modern” web development. (If you want to know the cost of “modern” framework-driven JavaScript-first web development, Tim has the numbers.) But Matthew is kind of a hero to me. I wish more developers would follow his example.
Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.
Hope springs eternal.
Update: Matthew has written about his process in Looking at coronavirus.data.gov.uk.
I use Firefox. You should too. It’s fast, secure, and more privacy-focused than the leading browser from the big G.
When it comes to web development, the CSS developer tooling in Firefox is second-to-none. But when it comes to JavaScript and network-related debugging (like service workers), Chrome’s tools are currently better than Firefox’s (for now). For example, Chrome has a tab in its developer tools that lets you run Lighthouse on the currently open tab.
Yesterday, I got the Calibre newsletter, which always has handy performance-related links from Karolina. She pointed to a Lighthouse extension for Firefox. “Excellent!”, I thought, and I immediately installed it. But I had some qualms about installing a plug-in from Google into a browser from Mozilla, particularly as the plug-in page says:
This is not a Recommended Extension. Make sure you trust it before installing
Well, I gave it a go. It turns out that all it actually does is redirect to the online version of Lighthouse. “Hang on”, I thought. “This could just be a bookmarklet!”
So I immediately uninstalled the browser extension and made this bookmarklet:
Drag that up to your desktop browser’s bookmarks toolbar. Press it whenever you’re on a site that you want to test.
This is a pretty close approximation Bob Shaw’s slow glass.
The monitor shows what’s behind it, with 6 months delay.
Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.