Mastodon furthermore implements the whole server-server ActivityPub standard, which can be used for some actions, like following someone, just fine. This is a very well described standard.
Mastodon doesn't implement ActivityPub server-client standard, instead it has the aforementioned selfbrewn "rest" API. Which, IMO is a shame, and has caused all clients (mobile, web, etc) to rely on this nonstandard API.
Edit: the point being:there are several ways to get content from Mastodon, depending on usecase and needs. You really don't need to scrape or parse or load the JS cliënt.
To be fair to Mastodon, the main developer did give a reason for this.
> The ActivityPub Client-to-Server spec assumes a thin server and thick client. By which I mean, the client, like an e-mail app, has to download and manage most data from the server. From my understanding that's the only way to make anything like search or username autocomplete or even a notifications tab to work with the C2S at all. In my experience, app developers are generally not excited to do that kind of legwork, and we're entering the kind of P2P territory which comes with its own challenges like the ease of hopping from one device to another, or the fact that to have the same functionality in iOS, Android, and Web, you would need to recreate the heavy-lifting fundamental boilerplate in each separately. For that reason, I am not particularly interested in the C2S part of ActivityPub.
https://www.reddit.com/r/Mastodon/comments/zqfr4h/comment/j1...
For reference, here's the JSON endpoint for the same account as listed in the article: https://mastodon.online/api/v1/accounts/109298336948075673/s...
Firefox has a nice UI for browsing JSON, but Chrome will just give you a text dump. Ironically, Firefox also used to have a nice UI for browsing RSS feeds but they removed it awhile ago.
[1] https://addons.mozilla.org/en-US/firefox/addon/rsspreview/
Your comment could just as well have said SGML or XML instead of JSON which would make the distinction more obvious.
If you send an HTTP request with an header of 'Accept: application/activity+json' you get proper machine-readable data out.
Given the context I assumed the regular unspecified internal type of JSON commonly used to back SPAs
Both are vastly inferior and tedious ways requiring me to type a new URL. It is not controverserial to say the primary purpose of a web browser is to display HTML. Most URLs resolve to HTML pages. It's been this way for 30 years. Only in the last 10 has this radical new application view of the web been creating walled gardens on top of the old document model web. And that's mostly for commercial/profit-motive reasons so it's sad to see non-profit motive software cargo culting SPA only dev.
It also means post v3 mastadon is inherently incompatible with indieweb standards like webmention since there is no page to check for URLs.
IIRC, (some) browsers used to have a feature that allowed you to browse a web page that had XML content, such as http://a.com/b.xml .
You could expand and collapse nodes. Or maybe I remember it as being for XML, but it was actually for RSS. After all, RSS is an XML format or application - is that the right term?
See the Example section at:
https://en.m.wikipedia.org/wiki/RSS
Haven't checked lately if browsers still do.
I'm fine with things like pagination and submitting forms being broken without Javascript, but at least make it possible to view a linked thread.
I've been running a Lemmy server or my own for a bit and I have to say, Mastodon just seems so incredibly wasteful. Lemmy's UI may be quite barebones in comparison but the server component runs a lot more efficiently while also providing actual HTML when you ask for content.
I'm tired too.
I have no problem turning on JS for a web app. I understand Google Maps just couldn't really work how it's expected to without JS. Same for web email clients, or games, or office suits.
But if your "app" is just a progressively-enhanced list of posts (e.g., a blog), there is no justification for forced JS usage. Sorry Mastodon.
Running JS is a privilege for those with the computing power (or battery capacity) to spare, and turns the browser into the biggest risk vector on whatever machine that browser is installed on.