Two serious problems with web apps such as Lemmy clients:

① The JavaScript conflict of interest —

The app is dynamically pushed from the server for every execution. The code is controlled by the webmaster, and therefore the app is designed to primarily serve the webserver. The interests of the user running it have a lower priority. The app was designed in a way that is oblivious to the fact that users have multiple accounts on different nodes, for example. The app conceals moderator and admin actions from the user, because that is what’s in the webmaster’s best interest, not the user’s.

The UNIX principle of having many small tools working together enables dev teams to focus on bring high quality to a small piece of code. The sum of many high-quality small tools is a high-quality tool in the end. The Lemmy devs could not possibly gather the resources to re-invent emacs in JavaScript. JS forces us to give up the important option of selecting good quality components for a toolchain.

② Unrealistic expectation of a working uplink —

As we can see from !isitdown@infosec.pub, the Lemmy nodes that are the least repressive and most respectful of our digital rights are up and down. They run on a shoestring budget. Client apps that are dependent on the server having 99.99% availability are themselves fragile and flimsy; helpless and useless when the server goes offline.

In the 1990s, we had newsreaders that would fetch usenet posts and store them locally, similar to email. We could read and take actions offline, then sync up whenever there was a connection. A notable motivator was the fact that many users had dial-up modems that shared a voice landline. There are still people with no Internet, who get their connection occasionally from a public library. They have been left behind.

Little consideration is given to how it’s a shitty quality client that becomes helpless and dysfunctional when the uplink is severed even for a few minutes. As I write this post, the infosec.pub server could fall offline spontaneously. Then what? The submission form stays open. It will let me type as long as I want without telling me that my manual human labor is being wasted. I will get a nasty surprise when clicking the submission button – a nonsense error pop-up “Type Error”.

A good quality app does not need the server to be online. It would launch a good editor like emacs or vi. When composing a post or comment is finished, it would store the message locally no matter what because it’s wise to have your own copy and so there is no data loss when the server glitches out. The app would have a separate activity to post the message if (and only if) there is an uplink and the Lemmy server is reachable.

Users should not be slaves to the servers’ uptime schedules

③ Anubis / proof of work enshitification —

This is really the same point as ② but in the context of anti-bot tech. Some Lemmy nodes are highly bot-hostile. They let you take just one or two actions, then scrap your session. Usually while typing. Then you must reload the site in another tab (so you don’t lose what you typed), in order to satisfy the proof of work demand over and over throughout your session. A good client would only have to go through that once, then it would submit all your actions quickly together and bounce.