dream-html VS litestar

FOR some time now, I have been maintaining an OCaml library called dream-html. This library is primarily intended to render correctly-constructed HTML, SVG, and MathML. Recently, I added the ability to render well-formed XML markup, which has slightly different rules than HTML. For example, in HTML if you want to write an empty div tag, you do:

htmx is a JavaScript library which interprets a set of HTML attributes and JavaScript events. It doesn't have anything to do with static typing. However, it's fairly easy to add a statically-typed layer on top of it eg https://github.com/yawaramin/dream-html

There is some truth to this. Imho the next level of htmx is unlocked when you componentize everything like a React app...but with nested routes corresponding to nested components like a Remix app...and using an HTML generation DSL embedded directly in your language, so HTML becomes a first-class citizen of your language's constructs, rather than a templated afterthought. I have a demo of this: https://github.com/yawaramin/dream-html/tree/todoapp/app

Nowadays I highly recommend HTML embedding libraries directly in the programming language. E.g. ScalaTags https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html

Yes, you give up the ability of designers and frontend-only people to easily work with the HTML templates. But in exchange you get quite a lot.

I found your article very informative and it matches up quite a bit with my own thinking about HTML generation. In fact it looks like we independently arrived at pretty much the same conclusions. A lot of the issues you raise are the impetus behind the way I designed my HTML-generation DSL: https://github.com/yawaramin/dream-html

I am developing an HTML generation library on top of Dream, to have great support in the language including htmx support: https://yawaramin.github.io/dream-html/dream-html/Dream_html/index.html

Look at this code which prints out an HTML tag: https://github.com/yawaramin/dream-html/blob/main/lib/dream_...

Initially you might think generating HTML tags from data structures in code should be a simple matter. But there are complexities--some tags are defined as having no child tags, others do. Some tags are purely character data (unstructured text), not structured data. Some are just comments. We need a way to compose multiple tags together into a single 'virtual' tag for flexible HTML generation. All these conditions can be pretty hard to keep track of--unless your compiler does exhaustiveness checking. Then the compiler will tell you if you missed any cases.

In the example above I didn't make any manual effort to cover all the cases, I simple listed out the cases I wanted to handle in order. The compiler made sure that I didn't miss any.

How does this compare to Litestar?

https://litestar.dev

Not really tried the Claude 3.5, later tried o1-preview on github models and recently Qwen2.5 32B for a prompt to generate a litestar[0] app to manage a wysiwyg content using grapesjs[1] and use pelican[2] to generate static site. It generated very bad code and invented many libraries in import which didn't exist. Cluade was one of the worst code generator, later tried sieve of atkin to generate primes to N and then use miller-rabin test to test each generated prime both using all the cpu core available. Claude completely failed and could never get a correct code without some or the other errors especially using multiprocess, o1-preview got it right in first attempt, Qwen 2.5 32B got it right in 3'rd error fix. In general for some very simple code Claude is correct but when using something new it completely fails, o1-preview performs much better. Give a try to generate some manim community edition visualization using Claude, it generates something not working correct or with errors, o1-preview much better job.

In most of my test o1-preview performed way better than Claude and Qwen was not that bad either.

[0] https://github.com/litestar-org/litestar

[1] https://grapesjs.com/

[3] https://getpelican.com/

If I was starting from scratch with Python web API development today, I would probably look more closely at LiteStar, which seems to me to be a better architected and with a better project governance structure.

I wonder what happened after. It looks like the commenter/creator moved on:

https://github.com/litestar-org/litestar/commits?author=Gold...

What would you like to see here? Could you perhaps open an issue at https://github.com/litestar-org/litestar so we can track and implement this?

If you are just needing a client what you need should be available OOTB, unless you want more hands off.

Here is also a good article for example: https://dev.to/pbaletkeman/secure-python-litestar-site-with-...

I thought Litestar was the recommendation these days over FastAPI. Is it not?

https://litestar.dev/

Litestar - Litestar has been picking up quite a lot of steam in the past year since the lead maintainer of their largest OS competitor (fastapi) seems to be unable to prioritize listening to community feedback / concerns people have over the project. You literally can't mention fastapi on this site without people bringing up litestar.

A redirect to https://litestar.dev/