5 ms·

I'm not very optimistic about the technical direction of Mastodon. Mastodon had a minimal HTML-only interface before, you could read posts and replies of each

I'm not very optimistic about the technical direction of Mastodon. 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.

dgrin91 2y ago
The hilarious dichotomy of HN - this post says UX is going wrong because of JS requirements and HTML only was better, while the one below (currently this: https://news.ycombinator.com/item?id=42682927 https://news.ycombinator.com/item?id=42682927) says UX is getting better.
- andreamonaco 2y ago
  Yeah I noticed that hahaha
- scyzoryk_xyz 2y ago
  I know right, almost like an internet forum or something
  - glenstein 2y ago
    It's a legitimate point - the criticism carries more weight if its part of a unified collective consensus (e.g. the Unity fees debacle) than if it's a bunch of all-over-the-map criticisms that all contradict each other (Gamergate). Seems straightforward enough to me. 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.
    - scyzoryk_xyz 2y ago
      I don’t see how this argues for or against the point about JS in Mastodon, but yeah, I too would go so far as to say that vibes, pseudo-consensus and internet mobs manufacturing things might have something to do with it.
      - glenstein 2y ago
        That's because we branched off into a different topic about what can or can't be derived from the wisdom of mobs. It doesn't argue for JS any more or less than your own comment did which I was replying to.
- jknoepfler 2y ago
  I mean, yeah. I read opinions I sharply disagree with all the time on this forum. If I didn't I probably wouldn't post here. ( Because contradicting opinions enrich my own, not because "someone's wrong on the internet again").
jeromegv 2y ago
You can still get every user access through RSS 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.
- andreamonaco 2y ago
  I understand! It's just that I was used to read some people's feed with JS disabled, a kind of plain-HTML blog, and that stopped working suddenly, so I was a bit shocked. But it's not a tragedy.
- masfuerte 2y ago
  The /embed thing stopped working recently.
- deleted 2y ago
  [deleted]
mikae1 2y ago
I actually love the official web client. So much that I never open Tusky (or Elk). Have you tried https://brutaldon.org https://brutaldon.org? Or perhaps you're the type of person that'd be willing to self host https://codeberg.org/grunfink/snac2 https://codeberg.org/grunfink/snac2 or https://humungus.tedunangst.com/r/honk https://humungus.tedunangst.com/r/honk?
- andreamonaco 2y ago
  I didn't say anything bad about the web JS interface, I said that having also a minimal HTML-only option was good. Anyway I will try that site, thanks!
progval 2y ago
And even with JS enabled, it now needs more network round-trips, which is noticeably slower, even with a very low-latency connection to the server. For example, loading https://mastodon.social/@Gargron/ https://mastodon.social/@Gargron/ takes 1.2s to display the posts (or 3.3s when logged in), with a warm cache and 5ms ping to mastodon.social.
INTPenis 2y ago
I also loved the HTML interface, I hate having to temporarily enable JS on a bunch of weird domains just to read threads. But I also hosted a node for many years and realize how heavy it is to render stuff server side. So the decision is clearly to make it less resource hungry for selfhosters.
mvdtnz 2y ago
A truly overwhelming majority of users browse with JS enabled. Designing or even considering those who don't is (in the most literal way possible) a waste of time.
- iknowstuff 2y ago
  Yea to be concerned about a product’s direction on account of not pandering to the 0.0001% of users is hilarious
- Grumbledour 2y ago
  No, because this is about more than just supporting non-js use cases, it is about the type of design from the ground up and how you structure your application. JS is very welcome on these kind of interfaces, but also really unnecessary for what it actually does. It just adds bells and whistles. Or it should "add", if designed correctly. As another comment pointed out, now it takes more network round trips and uses more ressources. And now it does not work without JS anymore. 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.
prmoustache 2y ago
Note that you don't have to use the UI of your chosen instance. You can use whatever client you like, be it a web, desktop gui, mobile gui, tui or cli.
pabs3 2y ago
Here is a client you can use to avoid turning on JS: https://github.com/jwilk/zygolophodon https://github.com/jwilk/zygolophodon I'm working on adding a WebExtension that would let you use it in the browser.
- esperent 2y ago
  > 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?
  - pabs3 2y ago
    There is just a small JS shim from the extension to the Python code, but yes. 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.
    - esperent 2y ago
      > static pages 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?
      - pabs3 2y ago
        I was mostly speaking to the general advantages of not enabling JS. > 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.

dgrin91 2y ago

The hilarious dichotomy of HN - this post says UX is going wrong because of JS requirements and HTML only was better, while the one below (currently this: https://news.ycombinator.com/item?id=42682927 https://news.ycombinator.com/item?id=42682927) says UX is getting better.

andreamonaco 2y ago
Yeah I noticed that hahaha
scyzoryk_xyz 2y ago
I know right, almost like an internet forum or something
- glenstein 2y ago
  It's a legitimate point - the criticism carries more weight if its part of a unified collective consensus (e.g. the Unity fees debacle) than if it's a bunch of all-over-the-map criticisms that all contradict each other (Gamergate). Seems straightforward enough to me. 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.
  - scyzoryk_xyz 2y ago
    I don’t see how this argues for or against the point about JS in Mastodon, but yeah, I too would go so far as to say that vibes, pseudo-consensus and internet mobs manufacturing things might have something to do with it.
    - glenstein 2y ago
      That's because we branched off into a different topic about what can or can't be derived from the wisdom of mobs. It doesn't argue for JS any more or less than your own comment did which I was replying to.
jknoepfler 2y ago
I mean, yeah. I read opinions I sharply disagree with all the time on this forum. If I didn't I probably wouldn't post here. ( Because contradicting opinions enrich my own, not because "someone's wrong on the internet again").

jeromegv 2y ago

You can still get every user access through RSS 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.

andreamonaco 2y ago
I understand! It's just that I was used to read some people's feed with JS disabled, a kind of plain-HTML blog, and that stopped working suddenly, so I was a bit shocked. But it's not a tragedy.
masfuerte 2y ago
The /embed thing stopped working recently.
deleted 2y ago
[deleted]

mikae1 2y ago

I actually love the official web client. So much that I never open Tusky (or Elk). Have you tried https://brutaldon.org https://brutaldon.org? Or perhaps you're the type of person that'd be willing to self host https://codeberg.org/grunfink/snac2 https://codeberg.org/grunfink/snac2 or https://humungus.tedunangst.com/r/honk https://humungus.tedunangst.com/r/honk?

andreamonaco 2y ago
I didn't say anything bad about the web JS interface, I said that having also a minimal HTML-only option was good. Anyway I will try that site, thanks!

progval 2y ago

And even with JS enabled, it now needs more network round-trips, which is noticeably slower, even with a very low-latency connection to the server. For example, loading https://mastodon.social/@Gargron/ https://mastodon.social/@Gargron/ takes 1.2s to display the posts (or 3.3s when logged in), with a warm cache and 5ms ping to mastodon.social.

INTPenis 2y ago

I also loved the HTML interface, I hate having to temporarily enable JS on a bunch of weird domains just to read threads. But I also hosted a node for many years and realize how heavy it is to render stuff server side. So the decision is clearly to make it less resource hungry for selfhosters.

mvdtnz 2y ago

A truly overwhelming majority of users browse with JS enabled. Designing or even considering those who don't is (in the most literal way possible) a waste of time.

iknowstuff 2y ago
Yea to be concerned about a product’s direction on account of not pandering to the 0.0001% of users is hilarious
Grumbledour 2y ago
No, because this is about more than just supporting non-js use cases, it is about the type of design from the ground up and how you structure your application. JS is very welcome on these kind of interfaces, but also really unnecessary for what it actually does. It just adds bells and whistles. Or it should "add", if designed correctly. As another comment pointed out, now it takes more network round trips and uses more ressources. And now it does not work without JS anymore. 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.

prmoustache 2y ago

Note that you don't have to use the UI of your chosen instance. You can use whatever client you like, be it a web, desktop gui, mobile gui, tui or cli.

pabs3 2y ago

Here is a client you can use to avoid turning on JS: https://github.com/jwilk/zygolophodon https://github.com/jwilk/zygolophodon I'm working on adding a WebExtension that would let you use it in the browser.

esperent 2y ago
> 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?
- pabs3 2y ago
  There is just a small JS shim from the extension to the Python code, but yes. 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.
  - esperent 2y ago
    > static pages 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?
    - pabs3 2y ago
      I was mostly speaking to the general advantages of not enabling JS. > 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.