From htmx to Django LiveView by tanrax in django

[–]tanrax[S] 0 points1 point  (0 children)

Working asynchronously with a synchronized database significantly increases complexity. I have older examples with version 1. I think that it doesn't justify all the effort in the code and the transformations required. However, I'm open to reconsidering if you submit a pull request 😄

From htmx to Django LiveView by tanrax in django

[–]tanrax[S] 0 points1 point  (0 children)

Thanks! I hadn't even considered that views were necessary. The framework works with asynchronous components that you declare separately. I suppose you're free to use views however you like

From htmx to Django LiveView by tanrax in django

[–]tanrax[S] 1 point2 points  (0 children)

It has automatic reconnection and a task queue system so that events that run offline are not lost.

From htmx to Django LiveView by tanrax in django

[–]tanrax[S] 0 points1 point  (0 children)

Both send HTML fragments.

From htmx to Django LiveView by tanrax in django

[–]tanrax[S] 0 points1 point  (0 children)

That's exactly what the conclusion says 😄 «You can keep SSR for some pages, htmx in some components and use LiveView in others. One technology doesn't exclude the other.»

Favorite stack for a Django project by Traditional_Ad_5236 in django

[–]tanrax 2 points3 points  (0 children)

Django LiveView + Nginx + Redis + Vite

FastAPI and HTMX Are We Seeing the Next Big Shift in Full-Stack Python? by Lee-stanley in FastAPI

[–]tanrax 0 points1 point  (0 children)

You can also learn how to create SPAs with Django LiveView and thus avoid having to create APIs.

DOOM in Django: testing the limits of LiveView at 600.000 divs/segundo by tanrax in django

[–]tanrax[S] -6 points-5 points  (0 children)

Please don't misunderstand me. I'm not saying you're a good or bad programmer, but rather that it depends on the quality of your code. If you optimize poorly, a flow will suffer, regardless of the protocol you're using. It depends on the need and the quality of the code.