And you can add the /embed suffix to any mastodon post url, to get a javascript-free version.
But I understand its not the same as maintaining a JS-free version of their web UI. To be fair, with the little budget and little workforce they have, this was likely not high on the priority list.
The latter can be especially important to observe because sometimes people are just full of it and it's all just a bunch of vibes, where people agree something is wrong, but they can't settle on a coherent idea. In those cases that phenomenon is often the most important thing to understand. I would go so far as to say vibes based psuedo-consensus is one of the most common things manufactured by internet mobs.
Have you tried https://brutaldon.org?
Or perhaps you're the type of person that'd be willing to self host https://codeberg.org/grunfink/snac2 or https://humungus.tedunangst.com/r/honk?
A good designed web app works just with plain html and minimal ressource use and than adds on top of that the get even better with css and js niceties. This used to be called progressive enhancement, if the client supports a feature, make your website better for these clients. It's just better and well rounded design with the added bonus of supporting clients with less capabilities.
https://github.com/jwilk/zygolophodon
I'm working on adding a WebExtension that would let you use it in the browser.
Doesn't that just move the JS from the browser into the extension? What's the benefit?
The benefit is that you don't need to enable arbitrary code execution in your browser. A variety of benefits flow from that; static pages, almost no advertising, fewer working paywalls, smaller attack surface etc.
I'm not sure I agree that it's a static page if there's a web extension running JS involved in the page render. I guess it's a grey area.
> almost no advertising, fewer working paywalls
We're talking about Mastodon, right? I thought it would not have those.
> smaller attack surface
This one I'll give you, but what kind of attacks would you expect from a Mastodon instance?
If all of this is a big enough issue to make you disable JS in the browser, wouldn't it be reasonable to whitelist Mastodon instances that you use?
> static pages
As in it won't change after you load the page.
> almost no advertising, fewer working paywalls
Indeed, haven't seen these with mastodon instances, but you never know when that will start happening.
> smaller attack surface
The instance could have been hacked, or you could have angered the admin, or you could have angered some other user who knows of a vulnerability they could leverage to send you custom JS.
The JavaScript sent by Mastodon is obfuscated, so it isn't reasonable to expect to be able to audit it and mark it as safe. You could YOLO and allowlist an JS from trusted instances of course, but that opens you up to the scenarios above.
That's not what static means in the context of web development. It means that the html is delivered from the server in a static form and doesn't need to be changed in any way to be displayed.
> The JavaScript sent by Mastodon is obfuscated, so it isn't reasonable to expect to be able to audit it and mark it as safe
This is what file hashes are for. But agreed, you do need to trust the upstream file provider. I had assumed that a federated system like Mastodon had considered this already and had a way of confirming js hashes to ensure against rogue nodes. Is that not the case? If so it seems like an oversight.
But anyways, thanks for replying to me. I asked because, as a web developer, I'm always curious about why people disable JS. I have yet to be convinced of any valid reasons for most people to do it, but I can understand that some people have stronger security concerns. For those people though, it always feels like it would make more sense to spin up a VM and browse inside there with all the unsafe JS, rather than enduring a daily struggle through a litany of websites that don't work properly.
File hashes only indicate the file and or hash weren't modified in transit, you can't know which party created the hash, and whether to trust that party, since they aren't authenticated from developer to browser, only from the server to the browser. Even if there were end-to-end authentication and there were a web of trust that could be used for authenticating developer keys, you can't trust code without auditing it, and you can't audit JS on most sites, because it is almost always minified/obfuscated or huge.
I expect it is unlikely Mastodon would care about JS hashes, because they are delivered by the instances rather than a CDN, and each instance can run a different version of the code, and each instance can modify the code as they please.
As above, many/most sites work fine, or much better without JS. The ones that don't can be dealt with using external tools like yt-dlp gallery-dl zygolophodon etc.
Mastodon had a minimal HTML-only interface before, you could read posts and replies of each profile.
They removed it some time ago, now you just see a blank page if you don't have JS, and I think it's a huge mistake; it was a clear albeit small advantage over mainstream social networks.