[feat] Static HTML as a user setting #368

Open
opened 2022-12-13 00:17:40 +00:00 by videotoblin · 5 comments

The idea

Hey all.

I think it'd be great if Static HTML generation was a user setting, rather than a server one. Static HTML generation is a great tool for creating less overhead on the user-side, but having it enabled for every user on the server just seems like a bad idea, given that it breaks some things.

The reasoning

  • Not everyone needs Static HTML. Some people do.
  • Almost the same server-side overhead anyways.
  • Compatibility with potato browsers on potato hardware.
  • This probably should have been a user setting all along.

Have you searched for this feature request?

  • I have double-checked and have not found this feature request mentioned anywhere.
  • This feature is related to the Akkoma backend specifically, and not pleroma-fe.
### The idea Hey all. I think it'd be great if Static HTML generation was a user setting, rather than a server one. Static HTML generation is a great tool for creating less overhead on the user-side, but having it enabled for every user on the server just seems like a bad idea, given that it breaks some things. ### The reasoning * Not everyone needs Static HTML. Some people do. * Almost the same server-side overhead anyways. * Compatibility with potato browsers on potato hardware. * This probably should have been a user setting all along. ### Have you searched for this feature request? - [x] I have double-checked and have not found this feature request mentioned anywhere. - [x] This feature is related to the Akkoma backend specifically, and not pleroma-fe.
videotoblin added the
feature request
label 2022-12-13 00:17:40 +00:00

given that it breaks some things.

It would be helpful if you report said things that break due to static-fe.

> given that it breaks some things. It would be helpful if you report said things that break due to static-fe.
Contributor
  • Compatibility with potato browsers on potato hardware.

that's just an argument in favor of static-fe, not of your feature request

  • This probably should have been a user setting all along.

could you please elaborate? this isn't really a reasoning

> - Compatibility with potato browsers on potato hardware. that's just an argument in favor of static-fe, not of your feature request > - This probably should have been a user setting all along. could you please elaborate? this isn't really a reasoning
Author

given that it breaks some things.

It would be helpful if you report said things that break due to static-fe.

Remote following is the only one I can think of off the top of my head right now.

  • Compatibility with potato browsers on potato hardware.

that's just an argument in favor of static-fe, not of your feature request

  • This probably should have been a user setting all along.

could you please elaborate? this isn't really a reasoning

  1. I think it's an argument in favor of making it a user option because not everyone has potato hardware and would like the extra fancy features of Pleroma FE.
  2. See 1.
> > given that it breaks some things. > > It would be helpful if you report said things that break due to static-fe. Remote following is the only one I can think of off the top of my head right now. > > - Compatibility with potato browsers on potato hardware. > > that's just an argument in favor of static-fe, not of your feature request > > > - This probably should have been a user setting all along. > > could you please elaborate? this isn't really a reasoning 1. I think it's an argument in favor of making it a user option because not everyone has potato hardware and would like the extra fancy features of Pleroma FE. 2. See 1.

honestly, making static-fe interactive would be one heck of an undertaking

it's currently read-only and just there to provide a cacheable response for external people

making it interactive would require some huge auth changes, considering everything works on oauth

honestly, making static-fe interactive would be one _heck_ of an undertaking it's currently read-only and just there to provide a cacheable response for external people making it interactive would require some huge auth changes, considering everything works on oauth
Contributor

Isn't this really just a question for having multiple front-ends? So some people can use the static-fe while others can choose to use a more JS-based fe? If so, this is already possible. Some instances already do that with bloat-fe for example (which you can e.g. host on a subdomain). See also https://docs.akkoma.dev/stable/clients/.

Isn't this really just a question for having multiple front-ends? So some people can use the static-fe while others can choose to use a more JS-based fe? If so, this is already possible. Some instances already do that with [bloat-fe](https://git.freesoftwareextremist.com/bloat/about/) for example (which you can e.g. host on a subdomain). See also <https://docs.akkoma.dev/stable/clients/>.
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#368
No description provided.