[throwaway89988]

Hi Jeremy, congratulations for the launch and the website looks very nice indeed.

I am honestly mostly interested in your reason, to mix HTML/CSS generation into the Python code. Disclaimer, I am very biased towards separation of concern and like my backend just returning JSON/XML/whatever data and a templating system. Of course this increases the ramp-up time to learn a framework, but then it is IMHO very powerful, flexible and fast.

Could you perhaps elaborate on your choice for FastHTML and what tradeoffs you see?

[jph00]

I'm a big fan of Locality of Behavior (LoB): https://htmx.org/essays/locality-of-behaviour/ . I don't think this need be incompatible with SoC. But even if you did think so, I believe that it's better to have everything in one language as much as possible, with the simplest possible specification of marshalling over network boundaries. My view is that hypermedia is a better way to do both of these things.

(I think HTML templating is a historical accident for what it's worth, and I hope it dies.)

[anon373839]

> (I think HTML templating is a historical accident for what it's worth, and I hope it dies.)

HTML templating does have one very nice benefit though: there’s a seamless path between designing and iterating on a static HTML template (which renders in the browser) and then sprinkling in the dynamic bits on top of that.

If you start with fairly complex markup in the initial design, I’m imagining it could be tedious to rewrite the whole thing in Python. Or is there some tooling that can help with this?

[vaylian]

> (I think HTML templating is a historical accident for what it's worth, and I hope it dies.)

It might be worth writing a blog post about that. It sounds like you have some more interesting things to say about the topic.

[throwaway89988]

Thank you very much for insights and elaboration!

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. ;-)

[pydanny]

My impression having done Django for over 15 years is that FastHTML allows for separation of concerns, albeit not within templates. Rather, most of the "presentation layer" is executed during the return statement. A common pattern in people building non-tiny FastHTML projects is to break out presentation into a components layer and business logic into a business layer.

Often we see "components.py" for presentation and "content|logic|models.py" broken out for business logic. You can see this pattern done in my as-yet-DNS-switched blog here: https://github.com/pydanny/daniel-blog-fasthtml

Of course, it's still early in the project, it's going to be interesting to see what patterns emerge over time. :-)