this post was submitted on 01 Aug 2023
50 points (100.0% liked)
Lemmy
496 readers
1 users here now
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TL;DR: the code/servers could be changed to use SSR, but that's more expensive to run.
Lemmy is written more as a web app than as a traditional webpage. This means that the website sends a partial page plus the code+resources needed to finish building the page and the browser builds ("renders") the final page.
This has advantages in that the server can send less data over time, cache more of that data, and overall has to do less work, plus also makes the site feel more snappy for the user, because their browser only needs to download the data that's changed (instead of a whole new page).
The disadvantage is that the browser needs to be more powerful, and older/simpler browsers (like IE6, some text-only browsers and some web spiders) won't apply the extra work to finish the page off.
The normal solution is called "server-side rendering" (SSR) where the server renders the full page, sends that over, then also sends over the code+data needed to run things more dynamically ("hydrating" the static site into an app-like experience). This means the server has to do a lot of work, but is often the best of both worlds; search engines see the proper page (good for SEO) but users get to have a nice experience (once that longer initial load is complete, anyway).
There’s two archive-friendly solutions Lemmy could take to solve this tho:
I'd rather see the second option - having a JavaScript-free solution is definitely more resilient than trying to detect and whitelist every archive service. As long as it works for wget/curl then it works for almost everyone.
This would be best