This may mark the beginning of Gov.uk’s decline. The top-listed priorities are the very antithesis of starting with user needs. Instead from now on it’s going to be about growth, shiny new technology, having a native app, and literally pivoting to video.
It’ll be interesting to see if they try to maintain their existing design principles while simultaneously abandoning them.
I not only worry that “cli-fi” might not be an effective form of environmental expression – I have come to believe that the genre might be actively dangerous, stunting our cultural ability to imagine a future worth living in or fighting for.
It’s a popular myth that a Bitcoin’s value is based on nothing, just pulled out of thin air by math. But that’s not true—Bitcoin is a way to commoditize energy consumption without accidentally producing anything useful. Other energy-intensive industries tend to convert energy into useful materials like aluminum or cement. Bitcoin converts electricity into waste heat and records its destruction in the form of numbers, which can then be traded for other numbers but not used to make anything people need or converted back into energy.
Solarpunk and synthetic biology as a two-pronged approach to the future:
Neither synbio nor Solarpunk has all the right answers, but when they are joined in a symbiotic relationship, they become greater than the sum of their parts. If people could express what they needed, and if scientists could champion those desires — then Solarpunk becomes a will and synbio becomes a way.
Interesting to see an article on web performance on the BBC. Perhaps we should be emphasising green over speed?
Behind the scenes, animation and interaction effects were added using HTML and CSS, two fundamental web languages. That meant there was no need to download large JavaScript files often used to do this on other sites.
As a society we need to treat AI resources as finite and precious, to be utilised only when necessary, and as effectively as possible. We need frugal AI.
It sounds like Remix takes a sensible approach to progressive enhancement.
The speed with which Twitter recedes in your mind will shock you. Like a demon from a folktale, the kind that only gains power when you invite it into your home, the platform melts like mist when that invitation is rescinded.
A terrific piece by Maggie Appleton that starts with a comparison of graphical user interfaces and command line tools—which reminds me of the trade-offs between seamless and seamful design—and then moves into a proposed paradigm for declarative design tools:
Small, scoped areas within a graphical interface that allow users to read and write simple programmes
This observation feels spot-on to me:
The shift that I noticed, totally anecdotally, is literary writers are starting to write more dystopian climate futures and science fiction writers are starting to write about climate solutions.
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 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.
I really like the format of this bit of journo-fiction. An interview from the future looking back at the turning point of today.
It probably helps that I’m into nuclearpunk just as much as solarpunk, so I approve this message.
Atomkraft? Ja, bitte!
But is it always the case that faster websites are greener websites? We reluctantly have to consider another facet: if making a website for a car manufacturer faster leads to an increase in the number of cars sold, can we really say that our website is greener?
This is very timely for me, given that Clearleft is currently engaged on a project that’s making me decidedly queasy for this exact reason—the success metrics of the project would be net negative for the world.
Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:
Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.
Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:
The more I think about it, the more I cannot believe webviews with unfettered JavaScript access to third-party websites ever became a legitimate, accepted technology. It’s bad for users, and it’s bad for websites.
By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
Verdict: 👎
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
A fascinating and inspiring meditation on aerodynamics.
The best climate fiction can do more than spur us to action to save the world we have — it can help us conceptualize the worlds, both beautiful and dire, that may lie ahead. These stories can be maps to the future, tools for understanding the complex systems that intertwine with the changing climates to come.
192 more stories of progress from 2021.
Some welcome perspective on healthcare, conservation, human rights, and energy.