What? Mastodon (main fork) update now requires javascript to load anything at all on permalinks outside the "app"/interface side? UGHHHHHH.
We're really tired of every website everywhere using javascript to load content - this web-appifying of everything. It's an absolutely baffling disregard for HTML. Don't see any reason at all for it to need to do this.
@Bot @Taylor The problem with javascript is, you have to execute code from potentially unknown sources.
I remember the time, when a web browser was a quite light-weight application. Today web browsers are the most complicated piece of software on most computer systems. Such complicated software is very prone to bugs. Sometimes bugs can be exploited to compromise the system, the software is running on.
@ayron @Taylor Yeah.... Honestly though that can be mitigated. Reason being? I've heard that if you don't use ANY PREMADE packages, and write EVERY. BIT. IF. IT
YOURSELF. You don't really have to worry about unknown code sources, since you are the only code source. Problem is though now you have to deal with spaghetti
@Bot The mitigations must be applied client side. There are several browser addons, you can run the web browser as another user or run it in a container or virtual machine and put the browser window into Xnest or Xephyr. These measures enhance the security but lower the comfort and also break several websites.
I feel like they are speedrunning "copy twitter"
@saphire @Taylor That's funny and all... But what is their justification honestly? Everyone here is complaining, but there must be a reason. Did they give any in any sort of documentation? They should have, if not try asking the devs. Honestly the reason might be simply that it's easier to maintain (in theory)? I have no fucking clue, I did web development for a class and was told to use Javascript stuff. And I don't use the web stuff, I use Tusky
Javascript is good when you need interactivity and need it done snappy and easily integrated without having to refresh your tab three hundred times for every post, reply, like, etc...
In this case it's.. a bit questionable as to why it was added when they already had a server side generation of this all done? Shrug...
@saphire @Bot Yeah. You don't need JS to render text posts. That's unnecessary. I block js by default, as do many people I know. If a page doesn't load *anything* without it, sometimes I won't even bother. (I often just give up with Pleroma pages.)
If you want dynamic content? That's what server-side languages are for. JS is not for that. It shouldn't be being used for that.
...fediverse posts are actually HTML (a subset of it), but get it mostly
And... uh. I do see valid uses of JS, please do not cut down all and any use of it for "dynamic content". Initial content should preferably be served from the server when possible, but it's not always the easiest solution, etc
God I hate this absolutism on the topic between "ALL THE JS" vs "NO JS, BURN IT ALL" x.x
@saphire @Taylor Looked into it. Goddamit I think I know why they did it now. Hey, was this place using Node.js before this new thing? If it was, then I think they are doing this simply because, it's easier to have folks enable Javascript cleint side then deal with moving the thing to a new base. Source:
From what I am aware of, they basically decided to condense the effort on UI to be the same for logged in users (which is a fully JS based web app basically, which is fine, as you get shuffled around within it seamlessly), and the web preview
EXCEPT IT DOES NOT WORK AS GOOD AS WITH TWITTER BECAUSE TWITTER AGGRESSIVELY CACHED ALL THE DAMN JS AND SO CLICKING POST IN THE WILD WILL NOT BE TOO LONG TO LOAD
UNLIKE MASTODON THAT IS HUNDREDS OF DIFFERENT SERVERS
Sorry for the caps
@Taylor I am honestly confused. I just have no idea what any of this means really, especially since loading in content with Javascript from a server is what I learned to do. Heard the reason is it's more dynamic apparently