Pretty cool idea that leans into Lemmy’s ability to provide a rich and federated blogging platform. Essentially, with this tool, it seems, a lemmy post along with its comments can become static content on a static web page of your choice.
cross-posted from: https://aussie.zone/post/1244281
This is a great way to include comments and discussion on a static site. Take a look at the demo.
This is pretty cool. Perfect idea for a small standalone Lemmy instance.
Or even just a personal community which you use as a blog. It’s even suggested in the documentation. The key being that you can make any community “moderators only”, meaning that only moderators can post, while anyone can still comment and vote. Which is just like a blog, except if it’s convenient, you can run it out of any instance that someone else is running. And then, with a tool like this, load it up to your own personal web page, and have a public blog that’s automatically federated!
Of course, running it out of your own instance would give you more control, though as the moderator of your own personal community you have a good deal of control already.
This is actually really cool! It’s work like this that helps expand the technology!
a lemmy post along with its comments can become static content on a static web page of your choice
This isn’t quite right. The “static web page” (the pre-rendered page) doesn’t include the Lemmy post or comments. When your browser renders the static page, the browser will then pull down the lemmy comments.
It needs a good UX for participating, maybe add lemmy buttons like upvote/downvote and reply and when they are clicked redirect to lemmy?
I didn’t make this, I only cross posted it. Also it’s very much in alpha.
That’s not really possible because there’s no way to know which instance to direct someone to. No point directing them to an instance where they don’t have an account.
Also I don’t think showing buttons like upvote which just redirect to another page is a good UX at all.
That’s not really possible because there’s no way to know which instance to direct someone to. No point directing them to an instance where they don’t have an account.
At least they will know it is on lemmy , then they can figure out how to use it. And that’s a general problem of the fediverse, there are extensions that redirect you to your home instance for that.
Also I don’t think showing buttons like upvote which just redirect to another page is a good UX at all.
I think it is at least better then the current state, where you have a tiny button that testing with heat maps will probably show is almost invisible, maybe adding text “go to lemmy to participate in the discussion” is also a decent option.
Could this help with SEO? I don’t think I’ve seen a lemmy instance show up in a search yet.
The short answer is no. It doesn’t create a static page from lemmy comments. It loads dynamic lemmy comments into static pages.
If they include links back to the original lemmy instance, it should help a bit. At least in the past the ranking algorithm liked seeing lots of links from other sites.
I’m going to need to brush up on my SEO skills. That’s really the last thing I’m looking for.
Sadly no, it won’t help in that way either (although that wasn’t the intent).
The lifecycle of a webpage in a browser is something like:
- download page - includes text content, and links to other resources like format, logic (javascript), and images
- start downloading other resources
- render text, and other resources as they arrive
- start manipulating page with javascript, which in this case includes a final step
- download lemmy post and render that, including the post, comments, and a link to the original post.
When google and others crawl the web looking for data to include in search they generally only index content from step 1, so it would only see the parameters passed to LBS (shown as “declaration” in the demo), and would not see anything rendered by LBS.
This is the “static” nature of static sites. The page downloaded by the browser is not built on request, rather it’s only built periodically by the author - usually whenever they have an update or another post. I haven’t posted anything on my blog in months so the pages wouldn’t have been re-built during that time. There are benefits to this strategy in that it’s very secure, very robust, very fast, and very easy to host, but the disadvantage is that any dynamic or “up to date content” (like comments from lemmy) need to be prepared by the client and thus can not be included in step one above and indexed in search.
There is a best of both worlds approach (SSR) where you could render all the comments when a page is originally built, and then update it when the client later renders the page. This means there’s at least something for search indexers to see even if it’s not up to date. The problem here is that there’s a plethora of different engines which people use to build pages and I can’t make a plugin for all or even a few of them.
With all that in mind, this is fantastic feedback, and why I posted this pre-alpha demo. Lots of commenters have said the same thing. I can re-factor to at least make SSR easier.
I’ll have to play with it. I haven’t looked through the code, but I’m pretty sure the default Lemmy UI isn’t SEO-friendly as well (though kbin probably is), so it would be cool to have a tool that provides it.
But maybe it doesn’t make sense for it to be your tool. I think it would be cool to have a lemmy feature where it’ll serve a cached, static page if it detects a bot is crawling it or the client doesn’t support JavaScript, and serve the regular site otherwise. Maybe your tool is the right option, or maybe someone should build a different one. IDK.
You’re right, this tool isn’t designed to address this problem and is ill-suited.
Lemmy should definitely render a static page and then “hydrate” that with JavaScript in the client. This is a common problem with modern js apps. SSR (server side rendering) is the solution but it can be very complex. You really need to build the whole app with SSR in mind, it’s not really something to bolt on as an additional feature at the end.
I think we could get away with sniffing the user agent and serving up static content instead if it looks like a bot.
I’m a full stack dev by day, but everything I’ve worked on has been a web app that doesn’t need SEO, so I’m not exactly sure how that works in practice. But presumably we could generate and cache a basic webpage periodically for each post for use by bots and perhaps for accessibility (e.g. very basic HTML that’s just good enough to use with links or something). It would have the same content as the main page, but none of the JS or CSS.
It shouldn’t be too hard to render with a templating library.
I don’t think so (as it’s about hosting lemmy content statically outside of lemmy.
