Jeremy Keith's Blog

Safari, Chrome, and Edge all allow you to install websites as though they���re apps.

On mobile Safari, this is done with the ���Add to home screen��� option that���s buried deep in the ���share��� menu, making it all but useless.

On the desktop, this is ���Add to dock��� in Safari, or ���Install��� in Chrome or Edge.

Firefox doesn���t offer this functionality, which as a shame. Firefox is my browser of choice but they decided a while back to completely abandon progressive web apps (though they might reverse that decision soon).

Anyway, being able to install websites as apps is fantastic! I���ve got a number of these ���apps��� in my dock: Mastodon, Bluesky, Instagram, The Session, Google Calendar, Google Meet. They all behave just like native apps. I can���t even tell which browser I used to initially install them.

If you���d like to prompt users to install your website as an app, there���s not much you can do other than show them how to do it. But that might be about to change���

I���ve been eagerly watching the proposal for a Web Install API. This would allow authors to put a button on a page that, when clicked, would trigger the installation process (the user would still need to confirm this, of course).

Right now it���s a JavaScript API called navigator.install, but there���s talk of having a declarative version too. Personally, I think this would be an ideal job for an invoker command. Making a whole new install element seems ludicrously over-engineered to me when button invoketarget="share" is right there.

Microsoft recently announced that they���d be testing the JavaScript API in an origin trial. I immediately signed up The Session for the trial. Then I updated the site to output the appropriate HTTP header.

You still need to mess around in the browser configs to test this locally. Go to edge://flags or chrome://flags/ and search for ���Web App Installation API���, enable it and restart.

I���m now using this API on the homepage of The Session. Unsurprisingly, I���ve wrapped up the functionality into an HTML web component that I call button-install.

Here���s the code. You use it like this:

Install the app

Use whatever text you like inside the button.

I wasn���t sure whether to keep the button element in the regular DOM or generate it in the Shadow DOM of the custom element. Seeing as the button requires JavaScript to do anything, the Shadow DOM option would make sense. As Tess put it, Shadow DOM is for hiding your shame���the bits of your interface that depend on JavaScript.

In the end I decided to stick with a regular button element within the custom element, but I take steps to remove it when it���s not necessary.

There���s a potential issue in having an element that could self-destruct if the browser doesn���t cut the mustard. There might be a flash of seeing the button before it gets removed. That could even cause a nasty layout shift.

So far I haven���t seen this problem myself but I should probably use something like Scott���s CSS in reverse: fade in the button with a little delay (during which time the button might end up getting removed anyway).

My connectedCallback method starts by finding the button nested in the custom element:

class ButtonInstall extends HTMLElement { connectedCallback () { this.button = this.querySelector('button'); ��� }customElements.define('button-install', ButtonInstall);

If the navigator.install method doesn���t exist, remove the button.

if (!navigator.install) { this.button.remove(); return;}

If the current display-mode is standalone, then the site has already been installed, so remove the button.

if (window.matchMedia('(display-mode: standalone)').matches) { this.button.remove(); return;}

As an extra measure, I could also use the display-mode media query in CSS to hide the button:

@media (display-mode: standalone) { button-install button { display: none; }}

If the button has survived these tests, I can wire it up to the navigator.install method:

this.button.addEventListener('click', async (ev) => { await navigator.install();});

That���s all I���m doing for now. I���m not doing any try/catch stuff to handle all the permutations of what might happen next. I just hand it over to the browser from there.

Feel free to use this code if you want. Adjust the code as needed. If your manifest file says display: fullscreen you���ll need to change the test in the JavaScript accordingly.

Oh, and make sure your site already has a manifest file that has an id field in it. That���s required for navigator.install to work.

Here���s the schedule for Web Day Out���what a fantastic collection of talks!

Web Day Out10:00 ��� 10:30I can���t believe it���s not JavaScriptJemima Abu10:30 ��� 11:00A pragmatic guide to browser supportRachel Andrew11:30 ��� 12:00Progressive web apps from the trenchesAleth Gueguen12:00 ��� 12:30Build for the web, build on the web, build with the webHarry Roberts14:00 ��� 14:30Breaking with habitsManuel Matuzovi��14:30 ��� 15:00What���s new in web typography?Richard Rutter15:30 ��� 16:00Customisable and the friends we made along the wayJake Archibald16:00 ��� 16:30The browser is the playgroundLola Odelola

Seeing all of those talk titles in a row is getting me very, very excited for this day!

I hope that you���re excited too, and I hope you���ve got your ticket already.

If you need to convince your boss to send you (and your team) to Web Day Out I���ve put together some reasons to attend along with an email template that you can use as a starting point.

Also, if your company is sending a group of people anyway, consider sponsoring Web Day Out. You get a bunch of conference tickets as part of the sponsorship deal.

Hope to see you in Brighton on Thursday, 12 March 2026!

This isn���t a rhetorical question. I genuinely want to know why developers choose to build websites using React.

There are many possible reasons. Alas, none of them relate directly to user experience, other than a trickle-down justification: happy productive developers will make better websites. Citation needed.

It���s also worth mentioning that some people don���t choose to use React, but its use is mandated by their workplace (like some other more recent technologies I could mention). By my definition, this makes React enterprise software in this situation. My definition of enterprise software is any software that you use but that you yourself didn���t choose.

Inertia

By far the most common reason for choosing React today is inertia. If it���s what you���re comfortable with, you���d need a really compelling reason not to use it. That���s generally the reason behind usage mandates too. If we ���standardise��� on React, then it���ll make hiring more straightforward (though the reality isn���t quite so simple, as the React ecosystem has mutated and bifurcated over time).

And you know what? Inertia is a perfectly valid reason to choose a technology. If time is of the essence, and you know it���s going to take you time to learn a new technology, it makes sense to stick with what you know, even if it���s out of date. This isn���t just true of React, it���s true of any tech stack.

This would all be absolutely fine if React weren���t a framework that gets executed in browsers. Any client-side framework is a tax on the end user. They have to download, parse, and execute the framework in order for you to benefit.

But maybe React doesn���t need to run in the browser at all. That���s the promise of server-side rendering.

The front end

There used to be a fairly clear distinction between front-end development and back-end development. The front end consisted of HTML, CSS, and client-side JavaScript. The back end was anything you wanted as long as it could spit out those bits of the front end: PHP, Ruby, Python, or even just a plain web server with static files.

Then it became possible to write JavaScript on the back end. Great! Now you didn���t need to context-switch when you were scripting for the client or the server. But this blessing also turned out to be a bit of a curse.

When you���re writing code for the back end, some things matter more than others. File size, for example, isn���t really a concern. Your code can get really long and it probably won���t slow down the execution. And if it does, you can always buy your way out of the problem by getting a more powerful server.

On the front end, your code should have different priorities. File size matters, especially with JavaScript. The code won���t be executed on your server. It���s executed on all sorts of devices on all sorts of networks running all sorts of browsers. If things get slow, you can���t buy your way out of the problem because you can���t buy every single one of your users a new device and a new network plan.

Now that JavaScript can run on the server as well as the client, it���s tempting to just treat the code the same. It���s the same language after all. But the context really matters. Some JavaScript that���s perfectly fine to run on the server can be a resource hog on the client.

And this is where it gets interesting with React. Because most of the things people like about React still apply on the back end.

React developers

When React first appeared, it was touted as front-end tool. State management and a near-magical virtual DOM were the main selling points.

Over time, that���s changed. The claimed speed benefits of the virtual DOM turned out to be just plain false. That just left state management.

But by that time, the selling points had changed. The component-based architecture turned out to be really popular. Developers liked JSX. A lot. Once you got used to it, it was a neat way to encapsulate little bits of functionality into building blocks that can be combined in all sorts of ways.

For the longest time, I didn���t realise this had happened. I was still thinking of React as being a framework like jQuery. But React is a framework like Rails or Django. As a developer, it���s where you do all your work. Heck, it���s pretty much your identity.

But whereas Rails or Django run on the back end, React runs on the front end ���except when it doesn���t.

JavaScript can run on the server, which means React can run on the server. It���s entirely possible to have your React cake and eat it. You can write all of your code in React without serving up a single line of React to your users.

That���s true in theory. The devil is in the tooling.

Priorities

Next.js allows you to write in React and do server-side rendering. But it really, really wants to output React to the client as well.

By default, you get the dreaded hydration pattern���do all the computing on the server in JavaScript (yay!), serve up HTML straight away (yay! yay!) ���and then serve up all the same JavaScript that���s on the server anyway (ya���wait, what?).

It���s possible to get Next.js to skip that last step, but it���s not easy. You���ll be battling it every step of the way.

Astro takes a very different approach. It will do everything it can to keep the client-side JavaScript to a minimum. Developers get to keep their beloved JSX authoring environment without penalising users.

Alas, the collective inertia of the ���modern��� development community is bound up in the React/Next/Vercel ecosystem. That���s a shame, because Astro shows us that it doesn���t have to be this way.

Switching away from using React on the front end doesn���t mean you have to switch away from using React on the back end.

Why use React?

The titular question I asked is too broad and na��ve. There are plenty of reasons to use React, just as there are plenty of reasons to use Wordpress, Eleventy, or any other technology that works on the back end. If it���s what you like or what you���re comfortable with, that���s reason enough.

All I really care about is the front end. I���m not going to pass judgment on anyone���s choice of server-side framework, as long as it doesn���t impact what you can do in the client. Like Harry says:

���if you���re going to use one, I shouldn���t be able to smell it.

Here���s the question I should be asking:

Why use React in the browser?

Because if the reason you���re using React is cultural���the whole team works in JSX, it makes hiring easier���then there���s probably no need to make your users download React.

If you���re making a single-page app, then ���well, the first thing you should do is ask yourself if it really needs to be a single-page app. They should be the exception, not the default. But if you���re determined to make a single-page app, then I can see why state management becomes very important.

In that situation, try shipping Preact instead of React. As a developer, you���ll almost certainly notice no difference, but your users will appreciate the refreshing lack of bloat.

Mostly though, I���d encourage you to investigate what you can do with vanilla JavaScript in the browser. I totally get why you���d want to hold on to React as an authoring environment, but don���t let your framework limit what you can do on the front end. If you use React on the client, you���re not doing your users any favours.

You can continue to write in React. You can continue to use JSX. You can continue to hire React developers. But keep it on your machine. For your users, make the most of what web browsers can do.

Once you keep React on the server, then a whole world of possibilities opens up on the client. Web browsers have become incredibly powerful in what they offer you. Don���t let React-on-the-client hold you back.

And if you want to know more about what web browsers are capable of today, come to Web Day Out in Brighton on Thursday, 12th March 2026.

As part of their on-stage banter, The Dubliners used to quip that ���All the books that are banned in Ireland should be published in Irish, to encourage more people to learn their native tongue.���

There was no shortage of banned books back in the day. I���m reading one of them now. The Country Girls by Edna O���Brien.

About halfway through the book, I read this passage:

The parcels for the Halloween party were coming every day. I couldn���t ask my father for one because a man is not able to do these things, so I wrote to him for money instead and a day girl brought me a barmbrack, apples, and monkey-nuts.

Emphasis mine, because that little list sounded so familiar to me.

Back in 2011, I wrote a candygram for Jason. It was called Monkey nuts, barmbrack and apples.

It���s not exactly Edna O���Brien, but looking back at it fifteen years on, I think it turned out okay.

The line-up for Web Day Out is now complete! The final speaker to be added to the line-up is the one and only Manuel Matuzovi��.

You may know Manuel from his superb Web Accessibility Cookbook (full disclosure: I had the honour of writing the foreword to that book). Or perhaps you���re familiar with the crimes against markup that he documents at HTMHell. But at Web Day Out, he���s going to be talking about CSS.

The past few years have seen a veritable explosion in CSS capabilities. It���s one thing to hear about all the new stuff in CSS, but how do you actually start using it?

You may need to unlearn what you have previously learned. That���s what Manuel���s talk will be covering:

Manuel built a new project from scratch with modern CSS and questioned every line of code he wrote.

In this talk, he presents what he has learned and encourages you to review your best practices.

You can see why I���m so excited about this���it���s perfect for the agenda of Web Day Out:

Do you feel like you���re missing out on some of the latest advances in HTML, CSS, and JavaScript APIs? Web Day Out is your chance to get up to speed on what matters.

There���ll be eight brilliant speakers for your entertainment:

Jemima AbuRachel AndrewJake ArchibaldAleth GueguenManuel Matuzovi��Lola OdelolaHarry RobertsRichard Rutter

You won���t want to miss this, so get your ticket now for the ludicrously reasonable price of just ��225+VAT!

See you in Brighton on 12 March 2026!

I find Brian Eno to be a fascinating chap. His music isn���t my cup of tea, but I really enjoy hearing his thoughts on art, creativity, and culture.

I���ve always loved this short piece he wrote about singing with other people. I���ve passed that link onto multiple people who have found a deep joy in singing with a choir:

Singing aloud leaves you with a sense of levity and contentedness. And then there are what I would call “civilizational benefits.” When you sing with a group of people, you learn how to subsume yourself into a group consciousness because a capella singing is all about the immersion of the self into the community. That’s one of the great feelings ��� to stop being me for a little while and to become us. That way lies empathy, the great social virtue.

Then there���s the whole Long Now thing, a phrase that originated with him:

I noticed that this very local attitude to space in New York paralleled a similarly limited attitude to time. Everything was exciting, fast, current, and temporary. Enormous buildings came and went, careers rose and crashed in weeks. You rarely got the feeling that anyone had the time to think two years ahead, let alone ten or a hundred. Everyone seemed to be passing through. It was undeniably lively, but the downside was that it seemed selfish, irresponsible and randomly dangerous. I came to think of this as “The Short Now”, and this suggested the possibility of its opposite - “The Long Now”.

I was listening to my Huffduffer feed recently, where I had saved yet another interview with Brian Eno. Sure enough, there was plenty of interesting food for thought, but the bit that stood out to me was relevant to, of all things, prototyping:

I have an architect friend called Rem Koolhaas. He���s a Dutch architect, and he uses this phrase, ���the premature sheen.��� In his architectural practice, when they first got computers and computers were first good enough to do proper renderings of things, he said everything looked amazing at first.

You could construct a building in half an hour on the computer, and you���d have this amazing-looking thing, but, he said, ���It didn���t help us make good buildings. It helped us make things that looked like they might be good buildings.���

I went to visit him one day when they were working on a big new complex for some place in Texas, and they were using matchboxes and pens and packets of tissues. It was completely analog, and there was no sense at all that this had any relationship to what the final product would be, in terms of how it looked.

It meant that what you were thinking about was: How does it work? What do we want it to be like to be in that place? You started asking the important questions again, not: What kind of facing should we have on the building or what color should the stone be?

I keep thinking about that insight: ���It didn���t help us make good buildings. It helped us make things that looked like they might be good buildings.���

Substitute the word ���buildings��� for whatever output is supposedly being revolutionised by generative models today. Websites. Articles. Public policy.

If you���re building software, it���s generally a good idea to avoid the Not-Invented-Here syndrome. This is when you insist on writing absolutely everything from scratch even if it would make more sense to use a third-party provider.

Need your app to take payments? Don���t try to become your own payment provider���use an existing provider instead.

Need your app to send email? Don���t try to code all that up yourself���just use an existing service.

This same thinking seems to apply to JavaScript libraries too. If you don���t use a library or framework, you���ll just end up writing your own library or framework instead, right?

Except that���s not the way that JavaScript frameworks work. At least not any more.

There was a time when JavaScript libraries really did abstract away browser differences that you probably didn���t want to deal with yourself. In the early days of jQuery���before querySelector existed���trying to work with the DOM could be a real pain. Libraries like jQuery helped avoid that pain.

Maybe it was even true in the early days of Angular and React. If you were trying to handle navigations yourself, it probably made sense to use a framework.

But that���s not the case any more, and hasn���t been for quite a while.

These days, client-side JavaScript frameworks don���t abstract away the underlying platform, they instead try to be an alternative. In fact, if you attempt to use web platform features, your JavaScript framework will often get in the way. You have to wait until your framework of choice supports a feature like view transitions before you get to use it.

This is nuts. Developers are choosing to use tools that actively get in the way of the web platform.

I think that most developers have the mental model of JavaScript frameworks completely backwards. They believe that the framework saves them time and effort (just like a payment provider or an email service). Instead these frameworks are simply limiting the possibility space of what you can do in web browsers today.

When you use a JavaScript framework, that isn���t the end of your work, it���s just the beginning. You still have to write your own code that makes use of that framework. Except now your code is restricted to only what the framework can do.

And yet most developers still believe that using a JavaScript framework somehow enables them to do more.

Jim Nielsen has a great framing on this. JavaScript libraries aren���t like payment providers or email services. Rather, it���s the features built into web browsers today that are like these third-party providers. When you use these features, you���re benefiting from all the work that the browser makers have put into making them as efficient as possible:

Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing new their offerings.

So if you leverage what they offer you, that gives you an advantage because you don���t have to build it yourself.

Want to do nifty page transitions? Don���t use a library. Use view transitions.

Want to animate parts of the page as the user scrolls? Don���t use a library. Use scroll-driven animations.

Want to make something happen when the user clicks? Don���t use a library. For the love of all that is holy, just use a button.

If you agree that using a button makes more sense than using a div, then I encourage you to apply the same thinking to everything else your app needs to do.

Take advantage of all the wonderful things you can do in web browsers today. If instead you decide to use a JavaScript framework, you���re basically inventing from scratch.

Except now all of your users pay the price because they���re the ones who have to download the JavaScript framework when they use your app.

UX London will be back in 2026. It���s on June 2nd, 3rd, and 4th:

Each day features a morning packed with inspiring talks followed by an afternoon of practical hands-on workshops. It���s the perfect blend!

As with last year, each day will be themed:

2 June 2026: discovery day3 June 2026: design day4 June 2026: delivery day

You can come for a single day, but for best value, you should come for all three days.

I���m starting to put the line-up together now���hoping to match the excellence of last year���s event���and I���ll start announcing speakers early in the new year.

But if you trust me, then I highly recommend getting a super-early bird ticket now. They���ll only be available for another couple of weeks. You get a significant discount if you buy now.

Oh, and while I���m in the process of putting the line-up together, you should know that you can submit a talk or workshop proposal:

We always pay ALL our speakers for their time as well as covering the cost of accommodation and economy travel.

Don���t be shy! Pitch early, pitch often.

(That said, I wouldn���t recommend pitching a talk that focuses on ���AI���. It���s not just that the bubble will probably have burst by the time UX London rolls around, it���s also that UX London doesn���t tend to focus on tools, whether they���re graphic design tools like Figma or generative tools like whatever people are using to turbo-charge their output of slop. If you���ve got a case study you want to talk about that happened to use some ���AI��� tool, great! But don���t make that the focus of the talk. Tell me about the problem and the solution.)

England is criss-crossed by routes that were originally laid down by the Romans. When it came time to construct modern roads, it often made sense to use these existing routes rather than trying to designate entirely new ones. So some of the roads in England are like an early kind of desire path.

Desire paths are something of a clich�� in the UX world. They���re the perfect metaphor for user-centred design; instead of trying to make people take a pre-defined route, let them take the route that���s easiest for them and then codify that route.

This idea was enshrined into the very design principles of HTML as ���pave the cowpaths���:

When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.

Ireland never had any Roman roads. But it���s always had plenty of cowpaths.

The Irish word for cow is b��.

The Irish word for road is b��thar, which literally means ���cowpath���.

The cowpaths were paved in both the landscape and the language.

Almost two months ago, I put out the call for speaker suggestions for Web Day Out. I got some good responses���thank you to everyone who took the time to get in touch.

The response that really piqued my interest was from Aleth Gueguen. She proposed a talk on progressive web apps, backed up with plenty of experience. The more I thought about it, the more I realised how perfect it would be for Web Day Out.

So I���m very pleased to announce that Aleth will be speaking at Web Day Out about progressive web apps from the trenches:

Find out about the most important capabilities in progressive web apps and how to put them to work.

I���m really excited about this line-up! This is going to be a day out that you won���t want to miss. Get your ticket for a mere ��225+VAT if you haven���t already!

See you in Brighton on 12 March, 2026!