Checked in at Dimsum & Duck. Dim sum! — with Jessica
Tags: war
872
Friday, September 24th, 2021
Thursday, September 23rd, 2021
Checked in at Sadler’s Wells. Opening night of Akram Khan’s Creature! — with Jessica
Thursday, September 9th, 2021
Meet the Self-Hosters, Taking Back the Internet One Server at a Time
Taking the indie web to the next level—self-hosting on your own hardware.
Tired of Big Tech monopolies, a community of hobbyists is taking their digital lives off the cloud and onto DIY hardware that they control.
Tuesday, September 7th, 2021
The Single-Page-App Morality Play – Baldur Bjarnason
I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.
Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.
Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.
Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.
A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.
Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.
It’s always humans.
Tuesday, August 31st, 2021
Why are hyperlinks blue?
A wonderful bit of spelunking into the annals of software interfaces by Elise Blanchard.
Monday, August 30th, 2021
Representation and what happened to women in Tech
Men specialized in hardware while software development was seen as an exciting alternative to secretarial work. In 1967, Cosmopolitan published an article titled The Computer Girls, encouraging young women to pursue careers in computer science. So the curve went up, and continued to do so up until 1984. That’s when personal computers appeared.
Marketing matters:
When Apple released the Macintosh 128K and the Commodore 64 was introduced to the market, they were presented as toys. And, as toys were gendered, they were targeted at boys. We can look at advertisements from that time and quickly find a pattern: fathers and sons, young men, even one where a man is being undressed by two women with the motto Two bytes are better than one. It’s more evident with the ads for computer games; if women appear, they do so sexualized and half-naked. Not that appealing for young girls, one could imagine.
Software Crisis 2.0 – Baldur Bjarnason
Baldur Bjarnason writes an immense treatise on the current sad state of software, grounded in the historical perspective of the past sad state of software.
Friday, August 27th, 2021
Checked in at Caffé & Bar Belpaese. Pre-dinner drink on the square — with Jessica
Thursday, August 26th, 2021
Checked in at ViCafé Münsterplatz. Coffee on the square — with Jessica
Wednesday, August 25th, 2021
Checked in at Terminal 2 - The Queen’s Terminal. Back in an airport after 18 months — with Jessica
Monday, August 23rd, 2021
Checked in at The Crown and Shuttle. Beer in the beer garden — with Jessica
Sunday, August 22nd, 2021
Checked in at Allen Gardens. Playing with Cider — with Jessica
Checked in at Ottolenghi. Shakshuka — with Jessica
Checked in at Christ Church Gardens. Playing with Cider — with Jessica
Friday, August 20th, 2021
canistilluse.com - Jim Nielsen’s Blog
…you would be forgiven if you saw an API where a feature went from green (supported) to red (unsupported) and you thought: is the browser being deprecated?
That’s the idea behind my new shiny domain: canistilluse.com. I made the site as satire after reading Jeremy Keith’s insightful piece where he notes:
the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.
It’s weirdly gratifying to see a hastily-written sarcastic quip tuned into something real.
Monday, August 16th, 2021
Upgrade paths
After I jotted down some quick thoughts last week on the disastrous way that Google Chrome rolled out a breaking change, others have posted more measured and incisive takes:
- Chris Ferdinandi wrote Google vs. the web,
- Rich Harris wrote Stay alert,
- Chris Coyier wrote Choice Words about the Upcoming Deprecation of JavaScript Dialogs, and
- Jim Nielsen wrote I Want To Confirm a Prompt That We Stay Alert
In fairness to Google, the Chrome team is receiving the brunt of the criticism because they were the first movers. Mozilla and Apple are on baord with making the same breaking change, but Google is taking the lead on this.
As I said in my piece, my issue was less to do with whether confirm(), prompt(), and alert() should be deprecated but more to do with how it was done, and the woeful lack of communication.
Thinking about it some more, I realised that what bothered me was the lack of an upgrade path. Considering that dialog is nowhere near ready for use, it seems awfully cart-before-horse-putting to first remove a feature and then figure out a replacement.
I was chatting to Amber recently and realised that there was a very different example of a feature being deprecated in web browsers…
We were talking about the KeyboardEvent.keycode property. Did you get the memo that it’s deprecated?
But fear not! You can use the KeyboardEvent.code property instead. It’s much nicer to use too. You don’t need to look up a table of numbers to figure out how to refer to a specific key on the keyboard—you use its actual value instead.
So the way that change was communicated was:
Hey, you really shouldn’t use the
keycodeproperty. Here’s a better alternative.
But with the more recently change, the communication was more like:
Hey, you really shouldn’t use
confirm(),prompt(), oralert(). So go fuck yourself.
Saturday, August 14th, 2021
Checked in at Howl at the Moon. Session! — with Jessica
Friday, August 13th, 2021
Checked in at Dumpling Shack. Shengjianbao — with Jessica
Checked in at Beigel Bake. Beigel time! — with Jessica
Tuesday, August 10th, 2021
Stay alert - DEV Community 👩💻👨💻
It’s not just a story about unloved APIs, it’s a story about power, standards design, and who owns the platform — and it makes me afraid for the future of the web.
A thoughtful, considered post by Rich Harris on the whole ballyhoo with alert and its ilk:
For all its flaws, the web is generally agreed to be a stable platform, where investments made today will stand the test of time. A world in which websites are treated as inherently transient objects, where APIs we commonly rely on today could be cast aside as unwanted baggage by tomorrow’s spec wranglers, is a world in which the web has already lost.