4 ms·
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-o
by 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 agoI 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!