Skip to content

Releases: volfpeter/htmy

v0.4.2

15 Jan 09:46
dc9a2a4
Compare
Choose a tag to compare

What's Changed

  • Formatter: skip properties whose value is None by @volfpeter in #31

Full Changelog: v0.4.1...v0.4.2

v0.4.1

02 Jan 18:16
1b6b2cf
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: v0.4.0...v0.4.1

v0.4.0

28 Dec 12:24
e6605f5
Compare
Choose a tag to compare

What's Changed

  • New default renderer with 2-6x better performance by @volfpeter in #25

Full Changelog: v0.3.6...v0.4.0

Additional notes from #25

  • htmy.HTMY should be considered deprecated and replaced by htmy.Renderer.
  • htmy.Renderer is a completely new renderer implementation with 2-6x performance compared to the renderer in version 0.3.6, largely depending of course on the use-case.
  • htmy.renderer is now a package that offers the default Renderer of the lib, and also a BaselineRenderer (the original renderer of the lib). The reason for keeping the latter is its simplicity and easy to prove correctness. It can be used for debugging, testing, benchmarking other implementations.

Regarding performance, the improvement you can expect strongly depends on the composition and depth of your component tree. The 2-6x improvement (compared to 0.3.6) can be expected for component trees that have a mixture of sync components, async components, and ErrorBoundarys. Some general recommendations:

  • Sync components can be resolved faster, so (as recommended in the docs) if a component doesn't need to be async, don't make it async.
  • Less nesting improves performance. If a component is mostly "boilerplate" (some HTML layout with dynamic content in a couple of places), then you could consider using Snippet instead with a text_processor to fill in the dynamic parts.
  • ErrorBoundary components can be relatively expensive, use them only where they are necessary.

With the tips above, you can potentially expect even better performance. This will still be considerably slower than Jinja for example, but there is no free lunch. For really performance critical parts, you could still create a wrapper component that uses a different rendering engine internally and return its result as a SafeStr.

v0.3.6

02 Dec 11:24
0322a39
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.5...v0.3.6

v0.3.5

29 Nov 19:43
b28abdc
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.4...v0.3.5

v0.3.4

21 Nov 21:33
701030a
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.3...v0.3.4

v0.3.3

19 Nov 09:24
65f47f8
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.2...v0.3.3

v0.3.2

17 Nov 14:02
a4b3f9a
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.1...v0.3.2

v0.3.1

13 Nov 16:25
df5eea8
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.3.0...v0.3.1

v0.3.0

11 Nov 20:46
88cccdf
Compare
Choose a tag to compare

What's Changed

  • Markdown example doc improvement by @volfpeter in #6
  • Added the i18n module and I18n utility for async, JSON based internationalization by @volfpeter in #9

Full Changelog: v0.2.0...v0.3.0