In Search of Lost Time, by Tom Vanderbilt
Temporal standards bodies.
Tags: eme
723
Wednesday, March 22nd, 2023
Monday, March 20th, 2023
Adoption. — Ethan Marcotte
Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.
Tuesday, March 14th, 2023
When JavaScript Fails
So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?
Because before, when you clicked on a link, the browser would go white for a moment.
JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum.
Tuesday, February 21st, 2023
Vibe Driven Development
This describes how I iterate on The Session:
It comes down to this annoying, upsetting, stupid fact: the only way to build a great product is to use it every day, to stare at it, to hold it in your hands to feel its lumps. The data and customers will lie to you but the product never will.
This whole post reminded of the episode of the Clearleft podcast on measuring design.
The problem underlying all this is that when it comes to building a product, all data is garbage, a lie, or measuring the wrong thing. Folks will be obsessed with clicks and charts and NPS scores—the NFTs of product management—and in this sea of noise they believe they can see the product clearly. There are courses and books and talks all about measuring happiness and growth—surveys! surveys! surveys!—with everyone in the field believing that they’ve built a science when they’ve really built a cult.
Friday, February 10th, 2023
Explore the In Our Time archive | Braggoscope
Matt made this lovely website for spelunking and hyperlinking through the thousand episodes of Radio 4’s excellent In Our Time programme.
He’s also written a little bit about how he made it using some AI (artificial insemination) for the categorisation code.
Tuesday, January 17th, 2023
Henry From Online | How To Make a Website
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
Wednesday, December 21st, 2022
The Performance Inequality Gap, 2023 - Infrequently Noted
It is not an exaggeration to say that modern frontend is so enamoured by post-scarcity fairy tales that it is mortgaging the web’s future for another round of night drinking at the JavaScript party.
Strong—and true—words from Alex.
This isn’t working for users or for businesses that hire developers hopped up Facebook’s latest JavaScript hopium. A correction is due.
I concur.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
Friday, November 18th, 2022
Remix and the Alternate Timeline of Web Development - Jim Nielsen’s Blog
It sounds like Remix takes a sensible approach to progressive enhancement.
Thursday, November 17th, 2022
Theory-building and why employee churn is lethal to software companies – Baldur Bjarnason
This extract from Baldur’s new book is particularly timely in light of the twipocalypse.
Thursday, October 20th, 2022
Why We’re Breaking Up with CSS-in-JS | Brad Frost
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
Thursday, October 13th, 2022
Two JavaScripts
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.
I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.
The Web’s Next Transition | Epic Web Dev by Kent C. Dodds
The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.
Progressively enhance for a more resilient web :: jjenzz
I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.
A really good explanation of progressive enhancement as an approach to building anything on the web:
Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.
Tuesday, October 11th, 2022
Bunny Fonts | Explore Faster & GDPR friendly Fonts
A drop-in replacement for Google Fonts without the tracking …but really, you should be self-hosting your font files.
Knowing
There’s a repeated catchphrase used throughout Christopher Nolan’s film Tenet: ignorance is our ammunition.
There are certainly situations where knowledge is regrettable. The somewhat-silly thought experiment of Roko’s basilisk is one example. Once you have knowledge of it, you can’t un-know it, and so you become complicit.
Or, to use another example, I think it was Jason who told me that if you want to make someone’s life miserable, just teach them about typography. Then they’ll see all the terrible kerning out there in the world and they won’t be able to un-see it.
I sometimes wish I could un-learn all I’ve learned about cryptobollocks (I realise that the term “cryptocurrency” is the more widely-used phrase, but it’s so inaccurate I’d rather use a clearer term).
I sometimes wish I could go back to having the same understanding of cryptobollocks as most people: some weird new-fangled technology thing that has something to do with “the blockchain.”
But I delved too deep. I wanted to figure out why seemingly-smart people were getting breathlessly excited about something that sounds fairly ludicrous. Yet the more I learned, the more ludicrous it became. Bitcoin and its ilk are even worse than the occassional headlines and horror stories would have you believe.
The reason I have such a visceral reaction to crypto projects isn’t just that they’re irresponsibly designed and usually don’t achieve what they promise. It’s also that the thing they promise sounds like a fucking nightmare.
Or, as Simon responded to someone wondering why there was so much crypto hate:
We hate it because we understand it.
I have yet to encounter a crypto project that isn’t a Ponzi scheme. I don’t mean like a Ponzi scheme. I mean they’re literally Ponzi schemes: zero-sum racing to the bottom built entirely on the greater fool theory. The only difference between traditional Ponzi schemes and those built on crypto is that crypto isn’t regulated. Yet.
I recently read The Glass Hotel by Emily St. John Mandel, a novel with the collapse of a Ponzi scheme at its heart. In the aftermath of the scheme’s collapse, there are inevitable questions like “How could you not know?” The narrator answers that question:
It’s possible to both know and not know something.
I’ve been thinking about that a lot.
Wednesday, September 21st, 2022
Will Serving Real HTML Content Make A Website Faster? Let’s Experiment! - WebPageTest Blog
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
Sunday, September 11th, 2022
Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
Tuesday, August 23rd, 2022
Work ethics
If you’re travelling around Ireland, you may come across some odd pieces of 19th century architecture—walls, bridges, buildings and roads that serve no purpose. They date back to The Great Hunger of the 1840s. These “famine follies” were the result of a public works scheme.
The thinking went something like this: people are starving so we should feed them but we can’t just give people food for nothing so let’s make people do pointless work in exchange for feeding them (kind of like an early iteration of proof of work for cryptobollocks on blockchains …except with a blockchain, you don’t even get a wall or a road, just ridiculous amounts of wasted energy).
This kind of thinking seems reprehensible from today’s perspective. But I still see its echo in the work ethic espoused by otherwise smart people.
Here’s the thing: there’s good work and there’s working hard. What matters is doing good work. Often, to do good work you need to work hard. And so people naturally conflate the two, thinking that what matters is working hard. But whether you work hard or not isn’t actually what’s important. What’s important is that you do good work.
If you can do good work without working hard, that’s not a bad thing. In fact, it’s great—you’ve managed to do good work and do it efficiently! But often this very efficiency is treated as laziness.
Sensible managers are rightly appalled by so-called productivity tracking because it measures exactly the wrong thing. Those instruments of workplace surveillance measure inputs, not outputs (and even measuring outputs is misguided when what really matters are outcomes).
They can attempt to measure how hard someone is working, but they don’t even attempt to measure whether someone is producing good work. If anything, they actively discourage good work; there’s plenty of evidence to show that more hours equates to less quality.
I used to think that must be some validity to the belief that hard work has intrinsic value. It was a position that was espoused so often by those around me that it seemed a truism.
But after a few decades of experience, I see no evidence for hard work as an intrinsically valuable activity, much less a useful measurement. If anything, I’ve seen the real harm that can be caused by tying your self-worth to how much you’re working. That way lies burnout.
We no longer make people build famine walls or famine roads. But I wonder how many of us are constructing little monuments in our inboxes and calendars, filling those spaces with work to be done in an attempt to chase the rewards we’ve been told will result from hard graft.
I’d rather spend my time pursuing the opposite: the least work for the most people.
Monday, August 15th, 2022
Baldur Bjarnason -
This is kind of brilliant:
Maybe what’s needed for websites and web apps is a kind of Prepper Web Dev?
Sunday, July 31st, 2022
Equality vs. Equity :: Aaron Gustafson
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.