I am not too very happy that we need at least CSS/HTML/Javascript (ok, HTMX...) for web applications and would love to have a simpler tech stack.
For me, the biggest concern is CSS/HTML/JavaScript do not go away and it seems to me, when I choose FastHTML I still need a descent understanding of these AND need to understand how FastHTML transforms Python code on top of it. Templates show me mostly what I will get once they are rendered, which means less mental work for me.
Templating w/o embedded logic like Mustache are acceptable for me and I found good use cases for them. Once templating systems become obviously Turing Complete I see a problem. ;-)
FastTags (FT) are a 1:1 mapping to HTML. It takes ~5 mins to learn. There's no transformation other than that the function name is the tag, the positional args are children, and the kwargs are attributes. (Oh and we have to rename `for` and `class` since they're reserved words.)
I understand your reticence, because there have been a great many similar-looking projects over the years that create abstractions over the foundations. This isn't one of them -- it's a direct simple mapping.
Inspired somewhat by the comments in this post, I yesterday just dove into rewriting all the Golang templates for my project in Gomponents, a golang HTML builder that seems at least superficially similar to the model you're using here.
So far, there are ways in which it's definitely nicer to build things with an actual programming language, to have proper function signatures and types, to be able to easily break things down into composable bits.
But it also certainly seems to me at least to obscure the overall HTML code structure, compared to what I had in the templates. Maybe that will change somewhat as I get used to "reading" the new system, but the very fact that it's now much easier to compose things means that the overall structure won't be in one place any more. Just one of the trade-offs of a system like this.
IMO it's not a "structure in one place" vs "more composable so more spread out"
In HTML, you are much more likely to have things in one place because you don't have great options otherwise.
In Python, you can choose to keep things in one place and not compose them, or you can choose to refactor to compose them if that makes them better for your particular use.
It is, however, definitely true that with the extra option, you have the option to refactor it so much it's less readable. How much to refactor and split things apart, decentralize, DRY vs how much to keep things in a structured place can be a hard thing to figure out!
I am not too very happy that we need at least CSS/HTML/Javascript (ok, HTMX...) for web applications and would love to have a simpler tech stack.
For me, the biggest concern is CSS/HTML/JavaScript do not go away and it seems to me, when I choose FastHTML I still need a descent understanding of these AND need to understand how FastHTML transforms Python code on top of it. Templates show me mostly what I will get once they are rendered, which means less mental work for me.
Templating w/o embedded logic like Mustache are acceptable for me and I found good use cases for them. Once templating systems become obviously Turing Complete I see a problem. ;-)