search

isso-comments / isso

a Disqus alternative
https://isso-comments.de
MIT License
5k stars 439 forks source link

Wishlist: Javascript-free client, Python API #331

Open hydrargyrum opened 6 years ago

hydrargyrum commented 6 years ago

Would it be possible to have a Javascript-free client, for example with an iframe? If not, why?

ducdetronquito commented 6 years ago

Very interested too ! @jelmer , any idea on this feature request ?

posativ commented 6 years ago

I think a server-generated page for each thread with a commenting option would be a great addition. Let's say you have a static blog and don't want JS, then you can generate a link to the Isso-generated HTML for this particular thread.

fluffy-critter commented 4 years ago

Relatedly it'd be nice to have an externally-usable/documented Python API so that I can just embed Isso directly into my Python/Flask-based website generator.

ix5 commented 2 years ago

This is a nice idea and would probably also make a lot of people happy who swear by their static blog engines.

I can see two issues though:

First, a duplication of functionality. If both the server and the client are supposed to render HTML, we'd end up re-implementing the whole client part in python (possibly using jinja2 templates or what-have-you). Or, we'd render as much as possible on the server, keeping the client light but requiring a lot of round trips. Also not ideal.

Second, how do you re-"hydrate" static content from the client side, i.e. make it interactive again? Should the client become HTML Form-based only?

That's quite a lot of open questions and I don't see anyone working on this.

fluffy-critter commented 2 years ago

I think having all of the rendering happen server-side and having the API be "give me HTML for this post" vs. "give me HTML for this thread" would be a good starting point.

Also where does the client data ever get rehydrated aside from the 'edit post' button? That can be part of the edit API. And isn't the Markdown converted to HTML server-side, anyway?

I don't really see what a fully-Javascript client-side is bringing to the table in the first place aside from asynchronously rendering the comment thread, and nothing about that actually depends on the rendering being Javascript in the first place.

jelmer commented 2 years ago

The JavaScript rendering means you can embed in a static site. Unless you're going to embed e.g. the post counts in iframes I don't think server side rendering gives us the same functionality.

It would also be harder (/impossible) to e.g. do the preview rendering without navigating to a different page.

fluffy-critter commented 2 years ago

There's no reason the rendering has to happen in Javascript, though, the whole thread rendering can be done in the server-side API and send it back as the response payload. Which is my understanding of what was happening with the Markdown already.

I'm also not saying that the API would be made Python-embedding only, just that things could be refactored to allow Python apps to embed the comment rendering directly while other things (static or otherwise) continue to use the Javascript API.

My suggestion is just to move more of the rendering to the server side so that it could also be provided as a python API, not to remove the javascript API.

fluffy-critter commented 2 years ago

Oh and just to be clear, retrieval of the preview render would still happen in Javascript, in this scenario. I'm just talking about the rendering of the thread as a whole.

It might also help simplify the configuration of things, because then the thread rendering configuration on the server doesn't have a chance to mismatch the client, like then client doesn't have to be configured whether or not to render upvotes/downvotes and so on.

jelmer commented 2 years ago

Yeah, I have no problems with supporting a Python API as well (though there are maintenance costs of supporting both). I was just responding to the suggestion of only providing a Python API.

fluffy-critter commented 2 years ago

I don't think anyone was suggesting that. If that's how you interpreted what I was saying, it wasn't my intention and I apologize for my lack of clarity.