Hacker News Reader

Comment by throwaway89988 | Hacker News Reader

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?

View on HN

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

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

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

He's already written a bit here, starting in the second paragraph under "Why": https://about.fastht.ml/components

> (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?

FastHTML has a NotStr(X) component that renders X as HTML.

I just copied a big HTML Tailwind component to a NotStr() and it worked fine.

I then split it in two, before and after, so I could make the dynamic bit from natural FastHTML components and it worked fine returning Div(before, dynamic_parts, after).

Plan to convert most of my smaller websites to FastHTML in the next few days before it's much more enjoyable for me.

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

Reply on news.ycombinator.com