separate panel into django back vs front

kiara commented

2025-02-18 14:06:02 +01:00

Owner

we have been trying htmx:

we have been trying [htmx](https://htmx.org/): - [django integration](https://django-htmx.readthedocs.io/) - [extensions](https://htmx.org/extensions/) - [client-side templates](https://github.com/bigskysoftware/htmx-extensions/blob/main/src/client-side-templates/README.md) - [auth](https://harabat.github.io/django-htmx/08_authentication_i_login_logout_signup/) - [login required](https://stackoverflow.com/questions/71002060/how-to-handle-redirect-for-login-required-in-htmx-partial-view)

kiara added the

component: fediversity panel

label

2025-02-18 14:06:02 +01:00

kiara referenced this issue

2025-02-19 13:27:18 +01:00

Receive a notification when deployment finishes #75

kiara commented

2025-02-24 13:23:42 +01:00

Author

Owner

~~one challenge on this seems porting over our django form.as_p~~

edit: as per @fricklerhandwerk this would not actually change under htmx

~~one challenge on this seems porting over our django `form.as_p`~~ edit: as per @fricklerhandwerk this would not actually change under htmx

kiara changed title from ~~separate panel into django back vs SPA front~~ to separate panel into django back vs front

2025-02-24 16:05:09 +01:00

kiara commented

2025-03-11 12:59:24 +01:00

Author

Owner

from discussion on matrix:

@kiara:

on another note, our current form.as_p seems non-trivial to port to an SPA setup

@fricklerhandwerk:

I may be misunderstanding some detail within this context, but tbh I don’t see where an SPA comes into play. (Also, unsolicited opinion, I think SPAs are a total 2010s fad and a wrong turn in software development that fortunately already almost died a deserved death) Django allows clean mapping to CRUD operations via standard HTTP requests, and htmx allows smoothing down the transitions and automating user interactions such as submitting forms. Combined with a healthy dose of CRDT(-oriented thinking, at the very least) this is very powerful and maintainable

@kiara:

i wanted to better understand your anti-SPA take. was this because of the single-page aspect's superfluous upfront loading times, or are you opposing the separation of traditional back-ends into front-ends loaded as static assets (for caching and CDN purposes) vs API-based back-ends in general?

@fricklerhandwerk:

The reason I have strong opinions about web stuff is primarily resource use and (closely related) accessibility. Breaking the HTTP model of interaction means tacking lots and lots of stuff on top of the browser, which is slow and makes and already complex system even more complex but now also ad hoc.
If someone badly wants a desktop or mobile application, it’s 2025 and we have Nix and Haskell with tons of bindings, and it’s not impossible or out of reach any more to build and deploy cross-platform GUIs. There are no excuses any more, and since LLMs lack of experience with this or that tech is also none
Otherwise, a RESTful HTTP state machine augmented with dynamic elements via htmx to me currently seems to be in a sweet spot of adequate level of abstraction (the problem is mostly implementation-sided; as we discussed the patterns for e.g. event sourcing aren’t well established in the developer community and tooling), native performance, and standardisation (this stuff is very well-understood)

@kiara:

hm. yes, backends can use haskell, but i'm not sure i find alleviating client compute a convincing argument against SPAs. front-ends can be written in anything that compiles to wasm anyway, whereas SPAs had had techniques like server-side rendering to alleviate clients since forever. to be fair, i guess there has been stuff like isomorphic web apps, so that might sorta blur the lines again.
i guess what i'm getting at tho is like, manually doing the django stuff for what would otherwise just be json schema forms (#195) is... feeling painful right now already.

from discussion on matrix: @kiara: > on another note, our current `form.as_p` seems non-trivial to port to an SPA setup @fricklerhandwerk: > I may be misunderstanding some detail within this context, but tbh I don’t see where an SPA comes into play. (Also, unsolicited opinion, I think SPAs are a total 2010s fad and a wrong turn in software development that fortunately already almost died a deserved death) Django allows clean mapping to CRUD operations via standard HTTP requests, and htmx allows smoothing down the transitions and automating user interactions such as submitting forms. Combined with a healthy dose of CRDT(-oriented thinking, at the very least) this is very powerful and maintainable @kiara: > i wanted to better understand your anti-SPA take. was this because of the single-page aspect's superfluous upfront loading times, or are you opposing the separation of traditional back-ends into front-ends loaded as static assets (for caching and CDN purposes) vs API-based back-ends in general? @fricklerhandwerk: > The reason I have strong opinions about web stuff is primarily resource use and (closely related) accessibility. Breaking the HTTP model of interaction means tacking lots and lots of stuff on top of the browser, which is slow and makes and already complex system even more complex but now also ad hoc. > If someone badly wants a desktop or mobile application, it’s 2025 and we have Nix and Haskell with tons of bindings, and it’s not impossible or out of reach any more to build and deploy cross-platform GUIs. There are no excuses any more, and since LLMs lack of experience with this or that tech is also none > Otherwise, a RESTful HTTP state machine augmented with dynamic elements via htmx to me currently seems to be in a sweet spot of adequate level of abstraction (the problem is mostly implementation-sided; as we discussed the patterns for e.g. event sourcing aren’t well established in the developer community and tooling), native performance, and standardisation (this stuff is very well-understood) @kiara: > hm. yes, backends can use haskell, but i'm not sure i find alleviating client compute a convincing argument against SPAs. front-ends can be written in anything that compiles to wasm anyway, whereas SPAs had had techniques like server-side rendering to alleviate clients since forever. to be fair, i guess there has been stuff like isomorphic web apps, so that might sorta blur the lines again. i guess what i'm getting at tho is like, manually doing the django stuff for what would otherwise just be json schema forms (#195) is... feeling painful right now already.

kiara added a new dependency

2025-03-19 07:09:41 +01:00

#244 account workspaces

kiara added a new dependency

2025-03-19 07:10:27 +01:00

#255 installable app

kiara referenced this issue

2025-04-07 21:39:49 +02:00

decouple mono-repo #303

kiara removed a dependency

2025-04-08 17:24:28 +02:00

#255 installable app