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:
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.
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.
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.
Ben shares the secret of SEO. Spoiler: the villain turns out to be Too Much JavaScript. Again.
Time to Interactive (TTI) is the most impactful metric to your performance score.
Therefore, to receive a high PageSpeed score, you will need a speedy TTI measurement.
At a high level, there are two significant factors that hugely influence TTI:
- The amount of JavaScript delivered to the page
- The run time of JavaScript tasks on the main thread
Lighthouses of the world, mapped.
What if accessibility were a ranking signal for Google search results?
Here’s a thought: what if Google put its thumb on the scale again, only this time for accessibility? What if it treated the Lighthouse accessibility score as a first-class ranking metric?
Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.
That said, I think Chris makes a good poin here:
My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.