5 ms·

I've been working on a Django + Vite + HTMX + Alpine project for the past year or so Using django-htmx and django-vite libs (the latter forked to add Jinja sup

I've been working on a Django + Vite + HTMX + Alpine project for the past year or so Using django-htmx and django-vite libs (the latter forked to add Jinja support) Been pretty happy with it The main wart I find is the lack of type-safe templating in Python, feels primitive and clunky compared to what you have with TSX in a React project Been using Jinja macros as 'components' which... works. The syntax is kinda ugly to read though, and haven't found any really great linter.

andy800 2y ago
Kotlin is an awesome back-end language with strong typing, tons of libraries and multiple HTTP frameworks (http4k, ktor, vert.x, many more) and templating options (jte is terrific, and fully typed). Guessing it's too late to switch now but worth checking out.
mixmastamyk 2y ago
> lack of type-safe templating in Python Try htpy. It moves templating into python where it can be linted/typed: https://htpy.dev/ https://htpy.dev/
- anentropic 2y ago
  Yeah this is probably the way to go in future... The only thing putting me off currently is https://htpy.dev/faq/#how-does-htpy-performance-compare-to-django-or-jinja-templates https://htpy.dev/faq/#how-does-htpy-performance-compare-to-d... It would be awesome if Python community can get something with these ergonomics that also has performance of Jinja
  - mixmastamyk 2y ago
    I played with the benchmark and the extra delay was not significant, maybe 20ms for a substantial page? I profiled the code and did not find it doing anything particularly wrong. However it uses generators to build the page lazily from fragments at runtime, whereas jinja gets a boost from “compiling” them somehow. I believe one could prerender the static parts of the page and get most of the speed of jinja, but the improvement still won’t be noticeable unless the project is very performance sensitive.
  - pelme 2y ago
    (I am the maintainer of htpy). We use htpy for a big project with a lot of complex components/pages. We have yet to see htpy being a problem for performance reasons. For us, the performance problems always seem to be in our database queries or how we process our data. Also, to be clear, a lot of big sites use the Django template system which htpy seems to typically beat on performance. There are faster ways to generate HTML but htpy is not really slow either! So to us, htpy performance has never been an issue which is why we have not been optimizing it further. If anyone is interested in re-implementing parts of htpy in cython/rust/something or improve the performance in other ways, that should be quite doable. The core htpy element/attribute implementation is a few hundred lines of code. It is heavily tested with 1000+ lines of tests. It could be a quite fun project, contributions are welcome!
jakobgm 2y ago
I can also highly recommend JinjaX [0] as a way to introduce a much more ergonomic component syntax in Jinja2 templates. We have been using it for almost 2 years and have only recently started to write new templates in htpy as a way to attain greater type safety. [0] https://jinjax.scaletti.dev/ https://jinjax.scaletti.dev/
- anentropic 2y ago
  I looked closely at it for this project... in some ways very appealing! However to me it seemed like it would mostly improve the ergonomics of using components, whereas the ugliest template code I had was in the component definitions themselves and I think it wouldn't help much there. Also, for my specific case we were deploying to AWS Lambda and I wanted to pre-compile all the Jinja templates. But JinjaX instantiates its own jinja env so our pre-compilation step (from top-level Django jinja env) couldn't reach the JinjaX defs. Probably there is a way to hack that into working.

andy800 2y ago

Kotlin is an awesome back-end language with strong typing, tons of libraries and multiple HTTP frameworks (http4k, ktor, vert.x, many more) and templating options (jte is terrific, and fully typed). Guessing it's too late to switch now but worth checking out.

mixmastamyk 2y ago

> lack of type-safe templating in Python Try htpy. It moves templating into python where it can be linted/typed: https://htpy.dev/ https://htpy.dev/

anentropic 2y ago
Yeah this is probably the way to go in future... The only thing putting me off currently is https://htpy.dev/faq/#how-does-htpy-performance-compare-to-django-or-jinja-templates https://htpy.dev/faq/#how-does-htpy-performance-compare-to-d... It would be awesome if Python community can get something with these ergonomics that also has performance of Jinja
- mixmastamyk 2y ago
  I played with the benchmark and the extra delay was not significant, maybe 20ms for a substantial page? I profiled the code and did not find it doing anything particularly wrong. However it uses generators to build the page lazily from fragments at runtime, whereas jinja gets a boost from “compiling” them somehow. I believe one could prerender the static parts of the page and get most of the speed of jinja, but the improvement still won’t be noticeable unless the project is very performance sensitive.
- pelme 2y ago
  (I am the maintainer of htpy). We use htpy for a big project with a lot of complex components/pages. We have yet to see htpy being a problem for performance reasons. For us, the performance problems always seem to be in our database queries or how we process our data. Also, to be clear, a lot of big sites use the Django template system which htpy seems to typically beat on performance. There are faster ways to generate HTML but htpy is not really slow either! So to us, htpy performance has never been an issue which is why we have not been optimizing it further. If anyone is interested in re-implementing parts of htpy in cython/rust/something or improve the performance in other ways, that should be quite doable. The core htpy element/attribute implementation is a few hundred lines of code. It is heavily tested with 1000+ lines of tests. It could be a quite fun project, contributions are welcome!

jakobgm 2y ago

I can also highly recommend JinjaX [0] as a way to introduce a much more ergonomic component syntax in Jinja2 templates. We have been using it for almost 2 years and have only recently started to write new templates in htpy as a way to attain greater type safety. [0] https://jinjax.scaletti.dev/ https://jinjax.scaletti.dev/

anentropic 2y ago
I looked closely at it for this project... in some ways very appealing! However to me it seemed like it would mostly improve the ergonomics of using components, whereas the ugliest template code I had was in the component definitions themselves and I think it wouldn't help much there. Also, for my specific case we were deploying to AWS Lambda and I wanted to pre-compile all the Jinja templates. But JinjaX instantiates its own jinja env so our pre-compilation step (from top-level Django jinja env) couldn't reach the JinjaX defs. Probably there is a way to hack that into working.