It would be best to also change the text then, not just the link. The text could read "Install the app and play now" when the link is changed to point to the play store.

I would much prefer to run single threaded in the browser than be cajoled into installing another fucking app.

I would rather offer the browser-based version to everyone, but it is an objectively worse experience because of the state of the Go compiler. You can still visit the broswer-based version if you want to, it's just a link swap on the page done in JavaScript.

Out of curiosity, what do you think I should do? Keep in mind, not everyone feels the same about being "cajoled" into installing an open source application. But virtually everyone won't appreciate the UI hangs.

Maybe you could offer both links, with a note that says what you just said?

(I don't think you're forcing free open backgammon down people's throats, but there's an existing fatigue due to less scrupulous publishers detecting mobile browsers and pushing people away from otherwise functional websites.)

Why would a backgammon game need multiple threads?

I agree than the basic functionality should require so little work that multiple threads should be useless. Some features like bots or game analysis could benefit from multiple threads, and should at the very least run outside the main UI thread. However these are only nice-to-have, and I'd be happy with a web-client that either doesn't support these at all, or only uses a single worker thread. And I see no reason to support this on desktop, while redirecting to an app on mobile.

Moving those features a webworker so the UI stays responsive should be easy, however I'm not sure how synchronizing multiple webworkers to take advantage of multiple cores compares to synchronizing multiple threads in a native app.

So the UI can respond while the CPU is calculating. Assuming the AI is using some sort of alpha-beta search the CPU also will scale embarrassingly well across multiple threads.