Jeremy Keith's Blog, page 38

Coaching on the Clearleft podcast

Season three of the Clearleft podcast is here!

The first episode is a nice gentle one to ease into things. It���s about coaching …and training …and mentorship. Basically I wanted to find out what the differences are between those three things.

But I must confess, there���s a commercial reason why this episode is coming out now. There���s a somewhat salesy promotion of an upcoming coaching programme with Julia Whitney. This is definitely the most overt marketing I���ve done on the Clearleft podcast, but if you listen to the episode, I think you���ll agree that it fits well with the theme.

Fear not, future episodes will not feature this level of cross-promotion. Far from it. You can expect some very revealing podcast episodes that pull no punches in getting under the skin of design at Clearleft.

The stars of this episode are my colleagues Rebecca and Chris, who were an absolute joy to interview.

Have a listen and hear for yourself.

Season three of the Clearleft podcast

If you���re not already subscribed to the Clearleft podcast, you should probably remedy that. The third season is about to drop any day now.

Once again, the season will comprise six episodes released on a weekly schedule.

That���s a cadence I more or less picked at random, but I think it���s working out well. Six episodes are enough for the podcast to sustain your interest without overstaying its welcome. And by taking nice long breaks between seasons, you���re never going to end up with that podcast problem of having a backlog of episodes that you never seem to get around to listening to.

That said, if you did fancy going through the backlog, there���s a mere twelve episodes for you to catch up on. Six from season one and six from season two. None of the episodes are overly long. Again, I don���t want this podcast to overstay its welcome. I respect your time. A typical episode is somewhere between 20 and 25 minutes of multiple viewpoints and voices.

You can subscribe to the RSS feed or use whichever service you prefer to get your podcasts from: Apple, Google, Spotify, Stitcher, Deezer, TuneIn, Castro, Pocket Casts, Player FM, or my own personal choice, Overcast.

Or you could just huffduff whichever episodes sound most appealing to you. But honestly, and I may be biased here, they���re all pretty darn great so I recommend subscribing.

If you subscribe now, then the episodes from season three will magically appear in your podcast software of choice. Again, I know I���m biased, but this is going to be an excellent season featuring some very smart folks sharing their stories.

Just to be clear, in case you haven���t listened to the Clearleft podcast before, this isn���t your usual podcast format. Yes, I interview people but I don���t release one interview per episode. Instead, each episode zeroes in one topic, and features different opinions from different people. It���s tight and snappy with no filler. That involves a lot of production and editing work, but I think it���s worth it for the end result.

Can you tell that I���m excited?

Airport time

I went and spoke at an actual real live conference. As expected, it felt good ���and weird. All at the same time.

It felt strange to be inside a building with other humans sharing an experience. At times it felt uncomfortable. The speaker���s dinner the night before the conference was lovely ���and anxiety-inducing. Not just because it was my first time socialising in ages, but also just because it was indoors. I���ve been avoid indoor dining.

But the travel to Z��rich all went smoothly. The airport wasn���t too busy. And on the airplane, everyone was dutifully masked up.

There���s definitely more paperwork and logistics involved in travelling overseas now. Jessica and I had to fill in our passenger locator forms for Switzerland and the UK. We also needed to pre-book a Covid test for two days after we got back. And we had to get a Covid test while we were in Switzerland so that we could show a negative result on returning to England. It doesn���t matter if you���re double-vaccinated; these tests are mandatory, which is totally fair.

Fortunately the conference organisers took care of booking those tests, which was great. On the first day of the conference I ducked out during the first break to go to the clinic next door and have a swab shoved up my nose. Ten minutes later I was handed a test result���negative!���complete with an official-looking stamp on it.

Two days later, after the conference was over, we had time to explore Z��rich before heading to the airport to catch our evening flight. We had a very relaxing day which included a lovely boat trip out on the lake.

It was when we got to the airport that the relaxation ended.

We showed up at the airport in loads of time. I subscribe to the Craig Mod school of travel anyway, but given The Situation, I wanted to make sure we accounted for any extra time needed.

We went through security just fine and waited around for our gate to come up on the screen of gates and flights. Once we had a gate, we made our way there. We had to go through passport control but that didn���t take too long.

At the gate, there was a queue so���being residents of England���we immediately got in line. The airline was checking everyone���s paperwork.

When we got to the front of the line, we showed all our documents. Passport? Check. Boarding pass? Check. Passenger locator form? Check. Negative Covid result? Che ���wait a minute, said the member of staff, this is in German. According to gov.uk, the test result needs to be in English, French, or Spanish.

I looked at the result. Apart from the heading at the top, all of the actual information was international: names, dates, and the test result itself said ���neg.���

Not good enough.

My heart sank. ���Call or email the clinic where you got the result. Get them to send you an English or French version��� said the airline representative. Okay. We went off to the side and started doing that.

At this point there was still a good 40 or 50 minutes ���till the flight took off. We could sort this out.

I phoned the clinic. It was late Saturday afternoon and the clinic was closed. Shit!

Jessica and I went back to the gate agent we were dealing with and began pleading our case (in German ���maybe that would help). She was very sympathetic but her hands were tied. Then she proposed a long shot. There was a Covid-testing centre in the airport. She would call them and tell them we were coming. But at this point it was 35 minutes until the flight left. We���d really have to leg it.

She scribbled down vague directions for where we had to go, and we immediately pelted off.

At this point I feel I should confess. I did not exhibit grace under pressure. I was, to put it mildy, freaking out.

Perhaps because I was the one selfishly indulging in panic, Jessica kept her head. She reminded me that we weren���t travelling to a conference���there wasn���t anywhere we had to be. Worst case scenario, we���d have to spend an extra night in Z��rich and get a different flight tomorrow. She was right. I needed to hear that.

I was still freaking out though. We were running around like headless chickens trying to find where we needed to go. The instructions had left out the crucial bit of information that we actually needed to exit through passport control (temporarily re-entering Swiss territory) in order to get to the testing centre. Until we figured that out, we were just running hither and tither in a panic while the clock continued to count down.

It was a nightmare. I don���t mean that figuratively. I mean, I���m pretty sure I���ve had this exact nightmare. I���m in a building with a layout I don���t know and I need to get somewhere urgently but I don���t know how to get there.

Even the reason for this panicked situation felt like it had a dream logic to it. You know when you wake up from a bad dream and you examine the dream in retrospect and you realise it doesn���t actually make any sense? Well, that���s how this felt. You���ve got a negative test result but it needs it to be in one of these three languages ���I mean, that sounds like the kind of nonsensical reasoning that should dissolve upon awakening.

Time was slipping away. Our flight leaves in twenty minutes.

Finally we realise that we need to go back through passport control. On the other side we run around some more until we spot the location that matches the vague description we���ve been given. There���s a sign! Covid testing centre!

We burst in through the doors. The gate agent had called ahead so we were expected. The young doctor on duty was cool as a cucumber. He must have to deal with this situation all day long. He calmly got us both to start filling in the appropriate online forms to pay for the tests, but instead of waiting for us to finish doing that, he started the testing straight away. Smart!

This felt like another nightmare I���ve had. I don���t mean having a swab shoved up my nose until it tickles my brain���that was probably the least uncomfortable part of this whole ordeal. I mean I need to fill out this web form accurately. On a touch screen device. And do it as quickly as possible!

Well, we did it. Filled in the forms, got the swabs. But now it was less than fifteen minutes until our flight time and we knew we still had to get back through passport control where there were lines of people.

���You���ll have the test results by email in ten minutes,��� said the doctor. ���Go!���

We sprinted out of there and went straight for the passport lines. Swallowing my pride, I went to the people at the end of a line. ���Our flight leaves in ten minutes! Can we please cut in front!?���

���No.���

Right, next line. ���Our flight leaves in������

���Yes, yes! Go!���

���Thank you! Thank you so much!���

We repeated this craven begging until we got to the front of the line and gave our passports to the same guy who had orginally stamped them first time we came through. He was unfazed.

Then we ran back to the gate. Almost everyone had boarded by this point, but the gate was still open. Maybe we could actually make it!

But we still needed our test results. We both stood at the gate with our phones in hand, the email app open, frantically pulling to refresh.

The minutes were ticking by. At this point the flight departure time had arrived, but the gate agent said there was a slight delay. They could wait one or two minutes more.

Pull, refresh. Pull, refresh.

���I���ve got mine!��� shouted Jessica. Half a minute later, mine showed up.

We showed the gate agent the results. She stamped whatever needed to be stamped and we were through.

I couldn���t believe it! Just 15 minutes ago I had been thinking we might as well give up���there was absolutely no way we were going to make it.

But here we were boarding the plane.

We got to our seats and strapped in. We were both quite sweaty and probably looked infectious ���but we also had fresh proof that neither of had the ���rona.

We just sat there smiling, looking at each other, and shaking our heads. I just couldn���t believe we had actually made it.

The captain made an announcement. They were having a little technical difficulty with the plane���s system���no doubt the cause of the slight delay, luckily for us. They were going to reboot the system in the time-honoured fashion of turning it off and again.

The lights briefly went out and then came back on as the captain executed this manouvre.

Meanwhile Jessica and I were coming down from our adrenaline rush. Our breathing was beginning to finally slow down.

The captain���s voice came on again. That attempt at fixing the glitch hadn���t worked. So to play it safe, we were going to switch planes. The new plane would take off in an hour and a half from a different gate.

As the other passengers tutted and muttered noises of disapproval, Jessica and I just laughed. A delay? No problem!

But oh, the Alanis Morissette levels of irony! After all that stress at the mercy of the ticking clock, it turned out that time was in plentiful supply after all.

Everything after that proceeded without incident. We got on the replacement plane. We flew back to England. We breezed across the border and made our way home.

It felt good to be home.

Travel

I���m speaking at a conference this week. But unlike all the conference talks I���ve done for the past year and a half, this one won���t be online. I���m going to Z��rich.

I have to admit, when I was first contacted about speaking at a real, honest-to-goodness in-person event, I assumed that things would be in a better state by the end of August 2021. The delta variant has somewhat scuppered the predicted trajectory of The Situation.

Still, this isn���t quite like going to speak at an event in 2020. I���m double-vaccinated for one thing. And although this event will be held indoors, the numbers are going to be halved and every attendee will need to show proof of vaccination along with their conference ticket. That helps to put my mind at ease.

But as the event draws nearer, I must admit to feeling uneasy. There���ll be airports and airplanes. I���m not looking forward to dealing with those. But I am looking forward to seeing some lovely people on the other end.

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That���s because a lot of people have been venting their frustrations with Safari recently:

Jorge Arango wrote Back to the Bad Old Days of the��Web,Dave Rupert wrote One-offs and low-expectations with Safari,Perry Sun wrote For developers, Apple���s Safari is crap and outdated, andTim Perry wrote Safari isn’t protecting the web, it’s killing it.

I think it���s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that���s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It���s also not helpful to make claims like ���Safari is the new Internet Explorer!��� Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you���ll just to have to listen to the podcast episode.

If you���d rather read the transcript, tough luck. That���s a real shame because, like I said, it���s an excellent and measured assessment. I���d love to add it to the links section of my site, but I can���t do that in good conscience while it���s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn���t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I���d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it���she���s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

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, andJim 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 keycode property. Here���s a better alternative.

But with the more recently change, the communication was more like:

Hey, you really shouldn���t use confirm(), prompt(), or alert(). So go fuck yourself.

Resigning from the AMP advisory committee

Inspired by Terence Eden���s example, I applied for membership of the AMP advisory committee last year. To my surprise, my application was successful.

I���ve spent the time since then participating in good faith, but I can���t do that any longer. Here���s what I wrote in my resignation email:

Hi all,

As mentioned at the end of the last call, I���m stepping down from the AMP advisory committee.

I can���t in good faith continue to advise on the AMP project for the OpenJS Foundation when it has become clear to me that AMP remains a Google product, with only a subset of pieces that could even be considered open source.

If I were to remain on the advisory committee, my feelings of resentment about this situation would inevitably affect my behaviour. So it���s best for everyone if I step away now instead of descending into outright sabotage. It���s not you, it���s me.

I���d like to thank the OpenJS Foundation for allowing me to participate. It���s been an honour to watch Tobie and Jory in action.

I wish everyone well and I hope that the advisory committee can successfully guide the AMP project towards a happy place where it can live out its final days in peace.

I don���t have a replacement candidate to nominate but I���ll ask around amongst other independent sceptical folks to see if there���s any interest.

All the best,

Jeremy

I wrote about the fundamental problem with Google AMP when I joined the advisory committee:

This is an interesting time for AMP ���whatever AMP is.

See, that���s been a problem with Google AMP from the start. There are multiple defintions of what AMP is.

There���s the collection of web components. If that were all AMP is, it would be a very straightforward project, similar to other collections of web components (like Polymer). But then there���s the concept of validation. The validation comes from a set of rules, defined by Google. And there���s the AMP cache, or more accurately, Google hosting.

Only one piece of that trinity���the collection of web components���is eligible for the label of being open source, and even that���s a stretch considering that most of the contributions come from full-time Google employees. The other two parts are firmly under Google���s control.

I was hoping it was a marketing problem. We spent a lot of time on the advisory committee trying to figure out ways of making it clearer what AMP actually is. But it was a losing battle. The phrase ���the AMP project��� is used to cover up the deeply interwingled nature of its constituent parts. Bits of it are open source, but most of it is proprietary. The OpenJS Foundation doesn���t seem like a good home for a mostly-proprietary project.

Whenever a representative from Google showed up at an advisory committee meeting, it was clear that they viewed AMP as a Google product. I never got the impression that they planned to hand over control of the project to the OpenJS Foundation. Instead, they wanted to hear what people thought of their project. I���m not comfortable doing that kind of unpaid labour for a large profitable organisation.

Even worse, Google representatives reminded us that AMP was being used as a foundational technology for other Google products: stories, email, ads, and even some weird payment thing in native Android apps. That���s extremely worrying.

While I was serving on the AMP advisory committee, a coalition of attorneys general filed a suit against Google for anti-competitive conduct:

Google designed AMP so that users loading AMP pages would make direct communication with Google servers, rather than publishers��� servers. This enabled Google���s access to publishers��� inside and non-public user data.

We were immediately told that we could not discuss an ongoing court case in the AMP advisory committee. That���s fair enough. But will it go both ways? Or will lawyers acting on Google���s behalf be allowed to point to the AMP advisory committee and say, ���But AMP is an open source project! Look, it even resides under the banner of the OpenJS Foundation.���

If there���s even a chance of the AMP advisory committee being used as a Potempkin village, I want no part of it.

But even as I���m noping out of any involvement with Google AMP, my parting words have to be about how impressed I am with the OpenJS Foundation. Jory and Tobie have been nothing less than magnificent in their diplomacy, cat-herding, schedule-wrangling, timekeeping, and other organisational superpowers that I���m crap at.

I sincerely hope that Google isn���t taking advantage of the OpenJS Foundation���s kind-hearted trust.

Browsers

I mentioned recently that there might be quite a difference in tone between my links and my journal here on my website:

���Sfunny, when I look back at older journal entries they���re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I���ve bookmarked the vibe is much more enthusiastic, like I���m excitedly pointing at something and saying ���Check this out!��� I feel like sentiment analyses of those two sections of my site would yield two different results.

My journal entries have been even more specifically negative of late. I���ve been bitchin��� and moanin��� about web browsers. But at least I���m an equal-opportunities bitcher and moaner.

Mozilla, I complained about your Facebook Container extension for Firefox.Apple, I complained about the ridiculous way Safari���s update cycle is tied to operating system.Google, I complained about the way a breaking change was rolled out in Chrome (and the implications for future breaking changes).Microsoft, you got off lightly. But please consider any of my criticisms of Chrome to apply to Edge too, seeing as they���re basically the same now.

I wish my journal weren���t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.

So my message to you is this: if there���s something about a web browser that you���re not happy with (or, indeed, if there���s something you���re really happy with), take the time to write it down and publish it.

Publish it on your website. You could post your gripes on Twitter but whinging on Jack���s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.

I know it���s a clich�� to say that browser makers want to hear from developers���and I���m often cynical about it myself���but they really do want to know what we think. Share your thoughts. I���ll probably end up linking to what you write.

Foundations

There was quite a kerfuffle recently about a feature being removed from Google Chrome. To be honest, the details don���t really matter for the point I want to make, but for the record, this was about removing alert and confirm dialogs from cross-origin iframes (and eventually everywhere else too).

It���s always tricky to remove a long-established feature from web browsers, but in this case there were significant security and performance reasons. The problem was how the change was communicated. It kind of wasn���t. So the first that people found out about it about was when things suddenly stopped working (like CodePen embeds).

The Chrome team responded quickly and the change has now been pushed back to next year. Hopefully there will be significant communication before that to let site owners know about the upcoming breakage.

So all���s well that ends well and we���ve all learned a valuable lesson about the importance of communication.

Or have we?

While this was going on, Emily Stark tweeted a more general point about breakage on the web:

Breaking changes happen often on the web, and as a developer it’s good practice to test against early release channels of major browsers to learn about any compatibility issues upfront.

Yikes! To me, this appears wrong on almost every level.

First of all, breaking changes don���t happen often on the web. They are���and should be���rare. If that were to change, the web would suffer massively in terms of predictability.

Secondly, 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.

I wasn���t the only one surprised by this message.

Simon says:

No, no, no, no! One of the best things about developing for the web is that, as a rule, browsers don’t break old code. Expecting every website and application to have an active team of developers maintaining it at all times is not how the web should work!

Edward Faulkner:

Most organizations and individuals do not have the resources to properly test and debug their website against Chrome canary every six weeks. Anybody who published a spec-compliant website should be able to trust that it will keep working.

Evan You:

This statement seriously undermines my trust in Google as steward for the web platform. When did we go from “never break the web” to “yes we will break the web often and you should be prepared for it”?!

It���s worth pointing out that the original tweet was not an official Google announcement. As Emily says right there on her Twitter account:

Opinions are my own.

Still, I was shaken to see such a cavalier attitude towards breaking changes on the World Wide Web. I know that removing dangerous old features is inevitable, but it should also be exceptional. It should not be taken lightly, and it should certainly not be expected to be an everyday part of web development.

It���s almost miraculous that I can visit the first web page ever published in a modern web browser and it still works. Let���s not become desensitised to how magical that is. I know it���s hard work to push the web forward, constantly add new features, while also maintaining backward compatibility, but it sure is worth it! We have collectively banked three decades worth of trust in the web as a stable place to build a home. Let���s not blow it.

If you published a website ten or twenty years ago, and you didn���t use any proprietary technology but only stuck to web standards, you should rightly expect that site to still work today …and still work ten and twenty years from now.

There was something else that bothered me about that tweet and it���s not something that I saw mentioned in the responses. There was an unspoken assumption that the web is built by professional web developers. That gave me a cold chill.

The web has made great strides in providing more and more powerful features that can be wielded in learnable, declarative, forgiving languages like HTML and CSS. With a bit of learning, anyone can make web pages complete with form validation, lazily-loaded responsive images, and beautiful grids that kick in on larger screens. The barrier to entry for all of those features has lowered over time���they used to require JavaScript or complex hacks. And with free(!) services like Netlify, you could literally drag a folder of web pages from your computer into a browser window and boom!, you���ve published to the entire world.

But the common narrative in the web development community���and amongst browser makers too apparently���is that web development has become more complex; so complex, in fact, that only an elite priesthood are capable of making websites today.

Absolute bollocks.

You can choose to make it really complicated. Convince yourself that ���the modern web��� is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.

This is for everyone. Not just for everyone to consume, but for everyone to make.

Updating Safari

Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS���moving it from a fixed top position to a floaty bottom position right over the content you���re trying to interact with.

Courage.

It remains to be seen whether this change will actually ship. That���s why it���s in beta���to gather all the web���s hot takes first.

But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.

Compared to other browsers, Safari lags far behind when it comes to shipping features. I���m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap���albeit an invisible one���between Safari and other browsers.

Jorge Arango has noticed this gap:

I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.

That���s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple���s Safari is crap and outdated:

Don���t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

Alas, that post also indulges in speculation about Apple���s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave���s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari���s ���quirks.���

Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don���t agree with everything in it. I think that Apple���and Mozilla���s���objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it���s not enough to just object; you���ve got to offer an alternative vision too.

That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:

Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.

But perhaps most damning of all is how Safari deals with bugs.

A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won���t ship until …who knows?

This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn���t work out too well for them in the subsequent court case).

I don���t get it. I���m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I���m sure I���ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.

And yet, of all the applications that need a speedy update cycle���a user agent for the World Wide Web���Apple���s version is needlessly delayed by the release cycle of the entire operating system.

I don���t want to speculate on why this might be. I don���t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google���s cardinal sin is avoiding anything ���Not Invented Here���, Apple���s downfall is ���We���ve always done it this way.���

Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.

Safari is not an evergreen browser.

That���s frustrating when it comes to new features. It���s unforgivable when it comes to bugs.

At least on Apple���s desktop computers, users have the choice to switch to a different browser. But on Apple���s mobile devices, users have no choice but to use Safari���s rendering engine, bugs and all.

As I wrote when I had to deal with one of Safari���s bugs:

I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that���s a hell-freezing-over prospect, I wish that Safari updates weren���t tied to operating system updates.