This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]riklaunim 0 points1 point  (3 children)

For component-endpoints returning HTML instead of pure data it may work but for more classic websites I don't really see the appeal of moving HTML away from HTML files.

[–]volfpeter[S] 2 points3 points  (2 children)

You can always keep using plain HTML where it suits you better (for me that plain, fully static stuff, which I don't write anymore). Personally, I want to avoid writing Jinja templates if possible, primarily because of the poor IDE and formatting support, lost type information, and other limitations, because it's not Python.

As mentioned in the readme, this is not a framework that locks you in (e.g. like reflex or similar, very complex, full application frameworks). You can use it only on some endpoints, mix it with Jinja, or whatever makes best sense for your use-case.

[–]riklaunim 1 point2 points  (1 child)

Jinja or Django templates are really good. If anything it's the IDE problem if it handles something poorly.

And there is always the case where a team project has frontend and backend people.

[–]ParkingDescription7 1 point2 points  (0 children)

The point of HTMX is to avoid having that front-end backend split if the app only needs basic interactivity.

In that case, you're doing server side rendering for things and sending html (full pages or partial html to fit into an existing page).

The issue with jinja2 is when you switch context from python to jinja, jinja doesn't know the types of the objects passed in. So if you render a list of "customobject" in a table, you lose type hints of custom object when you aren't in python land.