Jeremy Keith's Blog, page 15

Speedier tunes

I wrote a little while back about improving performance on The Session by reducing runtime JavaScript in favour of caching on the server. This is on the pages for tunes, where the SVGs for the sheetmusic are now inlined instead of being generated on the fly.

It worked. But I also wrote:

A page like that with lots of sheetmusic and plenty of comments is going to have a hefty page weight and a large DOM size. I���ve still got a fair bit of main-thread work happening, but now the bulk of it is style and layout, whereas previously I had the JavaScript overhead on top of that.

Take a tune like Out On The Ocean. It has 27 settings. That���s a lot of SVG markup that needs to be parsed, styled and rendered, even if it���s inline.

Then I remembered a very handy CSS property called content-visibility:

It enables the user agent to skip an element’s rendering work (including layout and painting) until it is needed ��� which makes the initial page load much faster.

Sounds great! But there are two gotchas.

The first gotcha is that if a browser doesn���t paint the element, it doesn���t know how much space the element should take up. So you need to provide dimensions. At the very least you need to provide a height value. Otherwise when the element comes into view and gets rendered, it pushes down on the content below it. You���d see a sudden jump in the scrollbar position.

The solution is to provide a value for contain-intrinsic-size. If your content is dynamic���from, say, a CMS���then you���re out of luck. You don���t know how long the content is.

Luckily, in my case, I could take a stab at it. I know how many lines of sheetmusic there are for each tune setting. Each line takes up roughly the same amount of space. If I multiply that amount of space by the number of lines then I���ve got a pretty good approximation of the height of the sheetmusic. I apply this with the contain-intrinsic-block-size property.

So each piece of sheetmusic has an inline style attribute with declarations like this:

content-visibility: auto;contain-intrinsic-block-size: 380px;

It works a treat. I did a before-and-after check with pagespeed insights on the page for Out On The Ocean. The ���style and layout��� part of the main thread work went down considerably. Total blocking time went from more than 600 milliseconds to less than 400 milliseconds.

Not a bad result for a little bit of CSS!

I said there was a second gotcha. That���s browser support.

Right now content-visibility is only supported in Chrome and Edge. But that���s okay. This is a progressive enhancement. Adding this CSS has no detrimental effect on the browsers that don���t understand it (and when they do ship support for it, it���ll just start working). I���ve said it before and I���ll say it again: the forgiving error-parsing in HTML and CSS is a killer feature of the web. Browsers just ignore what they don���t understand. That���s what makes progressive enhancement like this possible.

And actually, there���s something you can do for all browsers. Even browsers that don���t support content-visibility still understand containment. So they���ll understand contain-intrinsic-size. Pair that with a contain declaration like this to tell the browser that this chunk of content isn���t going to reflow or get repainted:

contain: layout paint;

Here���s what MDN says about contain:

The contain CSS property indicates that an element and its contents are, as much as possible, independent from the rest of the document tree. Containment enables isolating a subsection of the DOM, providing performance benefits by limiting calculations of layout, style, paint, size, or any combination to a DOM subtree rather than the entire page.

So if you���ve got a chunk of static content, you might as well apply contain to it.

Again, not bad for a little bit of CSS!

Rotten Apple

The European Union���s Digital Markets Act is being enforced and Apple aren���t happy about it.

Most of the discussion around this topic has centred on the requirement for Apple to provision alternative app stores. I don���t really care about that because I don���t really care about native apps. With one exception: I care about web browsers.

That���s the other part of the DMA that���s being enforced: Apple finally have to allow alternative browsing engines. Hallelujah!

Instead of graciously acknowledging that this is what���s best for users, Apple are throwing a tantrum.

First of all, they���re going to ringfence any compliance to users in the European Union. Expect some very interesting edge cases to emerge in a world where people don���t spent their entire lives in one country.

Secondly, Apple keep insisting that this will be very, very bad for security. You can read Apple���s announcement on being forced to comply but as you do you so, I���d like you to remember one thing: every nightmare scenario they describe for the security of users in the EU is exactly what currently happens on Macs everywhere in the world.

This includes risks from installing software from unknown developers that are not subject to the Apple Developer Program requirements, installing software that compromises system integrity with malware or other malicious code, the distribution of pirated software, exposure to illicit, objectionable, and harmful content due to lower content and moderation standards, and increased risks of scams, fraud, and abuse.

Users of macOS everywhere are currently exposed to all the risks that will supposedly overwhelm iOS users in the European Union. Weirdly, the sky hasn���t fallen.

It���s the same with web browsers. I just got a new Mac. It came with one browser pre-installed: Safari. It���s a good browser. But I also have the option of installing another browser, like Firefox (which I���ve done). A lot of people just use Safari. That���s good. That���s choice. Everyone wins.

Now Apple need to provide parity on iOS, at least for users in the EU. Again, Apple are decribing this coming scenario as an absolute security nightmare. But again, the conditions they���re describing are what already exist on macOS.

All Apple is being asked to do is offer than the same level of choice on mobile that everyone already enjoys on their computers. Rather than comply reasonably, Apple have found a way to throw their toys of the pram.

As of the next update to iOS, users in the EU will no longer have homescreen apps. Those web apps will now launch in a browser window. Presumably they���ll also lose the ability to send push notifications: being a homescreen app was a prerequisite for that functionality.

This is a huge regression that only serves to harm and confuse users.

I have a website about traditional Irish music. Guess where a significant amount of the audience is based? That���s right: Ireland. In the European Union.

There is no native app for The Session, but you can install it on your phone nonetheless. Lots of people have done that. After a while they forget that they didn���t install it from an app store: it behaves just like any other app on their homescreen.

That���s all about to change. I���m going to get a lot of emails from confused users wondering why their app is broken, now opening in a regular browser window. And I won���t be able to do anything about it, other than to tell them to take it up with Apple.

Presumably Apple is hoping that users will direct their anger at the EU commission instead. They���re doing their best to claim that they���re being forced to make this change. That���s completely untrue. A lie:

This is emphatically not required by the EU���s Digital Markets Act (DMA). It���s a circumvention of both the spirit and the letter of the Act, and if the EU allows it, then the DMA will have failed in its aim to allow fair and effective browser and web app competition.

Throughout all their communications on this topic, Apple are sticking to their abuser logic:

Look what you made me do!

This is going to hurt me more than it hurts you.

Apple���s petulant policy of malicious compliance is extremely maddening. What they���re about to do to users in the EU is just nasty.

This is a very dark time for the web.

I feel bad for the Safari team. They���ve been working really hard recently to make Safari a very competitive browser with great standards support with a quicker release cycle than we���ve seen before. Then it all gets completely torpedoed at the level of the operating system.

I really hope that Apple won���t get away with their plan to burn down web apps on iOS in the EU. But hope isn���t enough. We need to tell the EU commission how much damage this will do.

If you���ve ever built a web app, then your users will suffer. Remember, it���s a world wide web, including the European Union.

Create a PDF with the following information:

Your company���s name.Your name.That your company operates or services the EU.How many users your service has in the EU��(approximately).The level of impact this will have on your business.The problems this will cause your business.Whether or not the submission is confidential.

The submission can be as short or long as you want. Send it to contactus@open-web-advocacy.org, ideally before Monday, February 19th.

I know that���s a lot to ask of you on your weekend, but this really matters for the future of the web.

At the very least, I encourage to get involved with the great work being done by the Open Web Advocacy group. They���re also on Discord.

Please don���t let Apple bully an entire continent of users.

Federation syndication

I���m quite sure this is of no interest to anyone but me, but I finally managed to fix a longstanding weird issue with my website.

I realise that me telling you about a bug specific to my website is like me telling you about a dream I had last night���fascinating for me; incredibly dull for you.

For some reason, my site was being brought to its knees anytime I syndicated a note to Mastodon. I rolled up my sleeves to try to figure out what the problem could be. I was fairly certain the problem was with my code���I���m not much of a back-end programmer.

My tech stack is classic LAMP: Linux, Apache, MySQL and PHP. When I post a note, it gets saved to my database. Then I make a curl request to the Mastodon API to syndicate the post over there. That���s when my CPU starts climbing and my server gets all ���bad gateway!��� on me.

After spending far too long pulling apart my PHP and curl code, I had to come to the conclusion that I was doing nothing wrong there.

I started watching which processes were making the server fall over. It was MySQL. That seemed odd, because I���m not doing anything too crazy with my database reads.

Then I realised that the problem wasn���t any particular query. The problem was volume. But it only happened when I posted a note to Mastodon.

That���s when I had a lightbulb moment about how the fediverse works.

When I post a note to Mastodon, it includes a link back to the original note to my site. At this point Mastodon does its federation magic and starts spreading the post to all the instances subscribed to my account. And every single one of them follows the link back to the note on my site ���all at the same time.

This isn���t a problem when I syndicate my blog posts, because I���ve got a caching mechanism in place for those. I didn���t think I���d need any caching for little ol��� notes. I was wrong.

A simple solution would be not to include the link back to the original note. But I like the reminder that what you see on Mastodon is just a copy. So now I���ve got the same caching mechanism for my notes as I do for my journal (and I did my links while I was at it). Everything is hunky-dory. I can syndicate to Mastodon with impunity.

See? I told you it would only be of interest to me. Although I guess there���s a lesson here. Something something caching.

Speak up

Harry popped ���round to the Clearleft studio yesterday. It���s always nice when a Clearleft alum comes to visit.

It wasn���t just a social call though. Harry wanted to run through the ideas he���s got for his UX London talk.

Wait. I buried the lede. Let me start again.

Harry Brignull is speaking at this year���s UX London!

Yes, the person who literally wrote the book on deceptive design patterns will be on the line-up. And judging from what I heard yesterday, it���s going to be a brilliant talk.

It was fascinating listening to Harry talk about the times he���s been brought in to investigate companies accused of deliberately employing deceptive design tactics. It involves a lot of research and detective work, trawling through internal communications hoping to find a smoking gun like a memo from the boss or an objection from a beleaguered designer.

I thought about this again today reading Nic Chan���s post, Have we forgotten how to build ethical things for the web?. It resonates with what Harry will be talking about at UX London. What can an individual ethical designer do when they���re embedded in a company that doesn���t prioritise user safety?

It’s like a walking into a jets pray of bullshit, so much so that even those with good intentions get easily overwhelmed.

Though I try, my efforts rarely bear fruit, even with the most well-meaning of clients. And look, I get it, no on wants to be the tall poppy. It’s hard enough to squeeze money from the internet-stone these days. Why take a stance on a tiny issue when your users don’t even care? Your competitors certainly don’t. I usually end up quietly acquiescing to whatever bad are made, praying no future discerning user will notice and think badly of me.

It’s pretty clear to me that we can’t rely on individual people to make a difference here.

Still, I take some encouragement from Harry���s detective work. If the very least that an ethical designer (or developer) does is to speak up, on the record, then that can end up counting for a lot when the enshittification hits the fan.

If you see something, say something. Actually, don���t just say it. Write it down. In official communication channels, like email.

I remember when Clearleft crossed an ethical line (for me) by working on a cryptobollocks project, I didn���t just voice my objections, I wrote them down in a memo. It wasn���t fun being the tall poppy, the squeeky wheel, the wet blanket. But I think it would���ve been worse (for me) if I did nothing.

A week in Turin

Jessica and I spent last week working remotely. We always work remotely in the sense of not being in an office, but I mean we were remote from home too.

We���ve done this twice before. Once in Ortigia, Sicily and once in C��ceres, Spain. This time we were in Turin.

We had one day at the start of the trip to explore the city and do touristy things, checking out museums and such. After that we hunkered down in a very lovely and cosy AirBnB working each day.

I found it very productive. Maybe it���s a similar effect to going to a coffee shop to write���something about the change of scene encourages more of a flow state. The apartment was nice and quiet too so it wasn���t a problem when I needed to be on a call.

Best of all was what awaited at the end of each working day. We were staying in the Quadrilatero neighbourhood, famed for its aperitivo scene. Heck, there was a wonderful Vermouth bar literally across the street.

And after an aperitivo? Time to sample some Piedmontese cuisine. Bagna c��uda! Vitello tonnato Agnolotti! Panna cotta! We had some wonderful meals at restaurants like Consorzio, L���Acino, and Pautasso (a neighbourhood spot we went to on our last night that had the most perfectly convivial atmosphere you could imagine).

They say a change is as good as a rest. I certainly enjoyed this change of scene.

There���s something about going somewhere for a working week that feels very different to going somewhere primarily as a tourist. You get a different flavour of a place.

The schedule for Patterns Day

It is now exactly five weeks until Patterns Day���just another 35 sleeps!

Everthing is in place for a perfect day of deep dives into design systems. There’ll be eight snappy 30 minute talks���bam, bam, bam!

Here’s the schedule I’ve got planned for the day:

9:00Registration.9:45Jeremy introduces the day.10:00Jina delivers the opening keynote.10:30D��bora talks about the outcomes, lessons and challenges from using design tokens.11:00Break.11:30Yolijn talks about the relay method for design system governance.12:00Geri talks about her journey navigating accessibility in design systems.12:30Lunch.14:00Richard talks about responsive typography in design systems.14:30Samantha talks about getting buy-in for a design system.15:00Break.15:30Mary talks about transitioning from a single to a multi-brand design system.16:00Vitaly delivers the closing keynote.16:30Jeremy wraps up the day.16:45Have a drink and a geek pub quiz at the Hare And Hounds pub.

I assume you’ve got your ticket already, but if not use the discount code JOINJEREMY to get 10% off the ticket price.

See you there!

Switching costs

Cory has published the transcript of his talk at the Transmediale festival in Berlin. It���s all about enshittification, and what we can collectively do to reverse it.

He succinctly describes the process of enshittification like this:

First, platforms are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.

More importantly, he describes the checks and balances that keep enshittification from happening, all of which have been dismantled over time: competition, regulation, self-help, and workers.

One of the factors that allows enshittification to proceed is a high switching cost:

Switching costs are everything you have to give up when you leave a product or service. In Facebook���s case, it was all the friends there that you followed and who followed you. In theory, you could have all just left for somewhere else; in practice, you were hamstrung by the collective action problem.

It���s hard to get lots of people to do the same thing at the same time.

We���ve seen this play out over at Twitter, where people I used to respect are still posting there as if it hasn���t become a cesspool of far-right racist misogyny reflecting its new owner���s values. But for a significant amount of people���including myself and anyone with a modicum of decency���the switching cost wasn���t enough to stop us getting the hell out of there. Echoing Robin���s observation, Cory says:

���the difference between ���I hate this service but I can���t bring myself to quit it,��� and ���Jesus Christ, why did I wait so long to quit? Get me the hell out of here!��� is razor thin.

If users can���t leave because everyone else is staying, when when everyone starts to leave, there���s no reason not to go, too.

That���s terminal enshittification, the phase when a platform becomes a pile of shit. This phase is usually accompanied by panic, which tech bros euphemistically call ���pivoting.���

Anyway, I bring this up because I recently read something else about switching costs, but in a very different context. Jake Lazaroff was talking about JavaScript frameworks:

I want to talk about one specific weakness of JavaScript frameworks: interoperability, or the lack thereof. Almost without exception, each framework can only render components written for that framework specifically.

As a result, the JavaScript community tends to fragment itself along framework lines. Switching frameworks has a high cost, especially when moving to a less popular one; it means leaving most of the third-party ecosystem behind.

That switching cost stunts framework innovation by heavily favoring incumbents with large ecosystems.

Sounds a lot like what Cory was describing with incumbents like Google, Facebook, Twitter, and Amazon.

And let���s not kid ourselves, when we���re talking about incumbent client-side JavaScript frameworks, we might mention Vue or some other contender, but really we���re talking about React.

React has massive switching costs. For over a decade now, companies have been hiring developers based on one criterion: do they know React?

���An expert in CSS you say? No thanks.���

���Proficient in vanilla JavaScript? Don���t call us, we���ll call you.���

Heck, if I were advising someone who was looking for a job in front-end development (as opposed to actually being good at front-end development; two different things), I���d tell them to learn React.

Just as everyone ended up on Facebook because everyone was on Facebook, everyone ended up using React because everyone was using React.

You can probably see where I���m going with this: the inevitable enshittification of React.

Just to be clear, I���m not talking about React getting shittier in terms of what it does. It���s always been a shitty technology for end users:

React is legacy tech from 2013 when browsers didn���t have template strings or a BFCache.

No, I���m talking about the enshittification of the developer experience ���the developer experience being the thing that React supposedly has going for it, though as Simon points out, the developer experience has always been pretty crap:

Whether on purpose or not, React took advantage of this situation by continuously delivering or promising to deliver changes to the library, with a brand new API being released every 12 to 18 months. Those new APIs and the breaking changes they introduce are the new shiny objects you can���t help but chase. You spend multiple cycles learning the new API and upgrading your application. It sure feels like you are doing something, but in reality, you are only treading water.

Well, it seems like the enshittification of the React ecosystem is well underway. Cassidy is kind of annoyed at React. Tom is increasingly miffed about the state of React releases, and Matteo asks React, where are you going?

Personally, I would love it if more people were complaining about the dreadful user experience inflicted by client-side React. Instead the complaints are universally about the developer experience.

I guess doing the right thing for the wrong reasons is fine. It���s just a little dispiriting.

I sometimes feel like I���m living that old joke, where I���m the one in the restaurant saying ���the food here is terrible!��� and most of my peers are saying ���I know! And such small portions!���

This week

It���s been another busy week of evening activities that ended up covering a range of musical styles.

Monday

On Monday night I went to the session at The Fiddler���s Elbow. It���s on every fortnight. The musicians are always great but the crowd can be more variable. Sometimes it���s too rowdy for comfort. But this week was perfect, probably because not many people are going out in late (dry) January.

The session, led by fiddler Ben Paley was exceptionally enjoyable. Nice and laid back, with a good groove.

Tuesday

On Tuesday night I stayed in and watched a film. Killers Of The Flower Moon. Two thumbs up from me.

Wednesday

On Wednesday evening it was the regular session at The Jolly Brewer. Jolly good it was too.

Thursday

On Thursday night I was back in The Jolly Brewer. My friend Rob roped me into doing a Burns Night thing. ���It���s not a session, but it���s not a gig��� was how he described it. I wasn���t sure what to expect.

We had been brushing up on our Scottish tunes, but we were mostly faking it. In the end it didn���t matter. I don���t think there was a single Scottish person there. But there was a good crowd enjoying their tatties and neeps with suitably-addressed haggis while we played our tunes in the background.

Some more musicians showed up: a fiddler and two banjo players. ���Isn���t there old-time music here tonight?��� they asked. We told them that no, it was Burns Night, but why not play some old-time tunes anyway?

So I passed the night jamming along to lots of tunes I didn���t know. I hope I wasn���t too offputting for them. It was good fun.

Friday

Finally on Friday evening it was my turn to leave my mandolin at home and listen to some music instead. The brilliant DakhaBrakha were playing out at Sussex Uni in the Attenborough Centre.

Imagine if Tom Waits and Cocteau Twins came from Eastern Europe and joined forces. Well, DakhaBrakha are even better than that.

I think I first heard them years ago on YouTube when I came across a video of them playing at KEXP. The first song caught my attention, then proceeded to mercilessly hold my attention captive until I was completely at their mercy���the way it builds and builds is just astonishing! I���ve been a fan ever since.

The gig was brilliant. I was absolutely blown away. I highly recommend seeing them if you can. Not only will you hear some brilliant music, you���ll be supporting Ukraine.

���������� ��������������!

Patterns Day and more

Patterns Day is exactly six weeks away���squee!

If you haven���t got your ticket yet, get one now. (And just between you and me, use the discount code JOINJEREMY to get a 10% discount.)

I���ve been talking to the speakers and getting very excited about what they���re going to be covering. It���s shaping up to be the perfect mix of practical case studies and big-picture thinking. You can expect talks on design system governance, accessibility, design tokens, typography, and more.

I���m hoping to have a schedule for the day ready by next week. It���s fun trying to craft the flow of the day. It���s like putting together a set list for a concert. Or maybe I���m just overthinking it and it really doesn���t matter because all the talks are going to be great anyway.

There are sponsors for Patterns Day now too. Thanks to Supernova and Etch you���re going to have bountiful supplies of coffee, tea and pastries throughout the day. Then, when the conference talks are done, we���ll head across the road to the Hare And Hounds for one of Luke Murphy���s famous geek pub quizes, with a bar tab generously provided by Zero Height.

Now, the venue for Patterns Day is beautiful but it doesn���t have enough space to provide everyone with lunch, so you���re going to have an hour and a half to explore some of Brighton���s trendy lunchtime spots. I���ve put together a list of lunch options for you, ordered by proximity to the Duke of York���s. These are all places I can personally vouch for.

Then, after the conference day, and after the pub quiz, there���s Vitaly���s workshop the next day. I will most definitely be there feeding on Vitaly���s knowledge. Get a ticket if you want to join me.

But wait! That���s not all! Even after the conference, and the pub quiz, and the workshop, the nerdy fun continues on the weekend. There���s going to be an Indie Web Camp here in Brighton on the Saturday and Sunday after Patterns Day.

If you���ve been to an Indie Web Camp before, you know how inspiring and fun it is. If you haven���t been to one yet, you should definitely come along. It���s free! If you���ve got your own website, or if you���re even just thinking about having your own website, it���s a great opportunity to meet with like-minded people.

So that���s going to be four days of non-stop good stuff here in Brighton. I���m looking forward to seeing you then!

Linking

One of the first ever personal websites���long before the word ���blog��� was a mischievous gleam in Peter���s eye���was Justin Hall���s links.net. Linking was right there in the domain name.

I really enjoy sharing links on my website. It feels good to point to something and say, ���Hey, check this out!���

Other people are doing it too.

I really enjoy Neil���s links (RSS), always wrapped up with a quote of the day.Scott Boms���s Through Lines (RSS) are always packed with good stuff, along with new typeface releases.Jim Nielsen���s notes (RSS) are as valuable as his blog, which is to say, very.Then there���s Clive Thompson���s Linkfest (RSS)���it���s right there in the name.

Then there are some relatively new additions to the linking gang:

Hidde���s links (RSS),Andy���s links (RSS), andSophie���s links (RSS) batched into a weekly release.

There are more out there for you to discover and add to your feed reader of choice. Good link hunting!