Hacker News new | past | comments | ask | show | jobs | submit login

Sorry, but I hate server-side "helper" functions that generate HTML. For one thing it's never the same as what eventually gets shown on the page. 99.9% of the time you're missing attributes when needs to be hacked around. Debugging is a nightmare. Refactoring is hell. And css programmers have no clue what to do with this.

Maybe I'm missing something here. Why not a templating engine?




In this case, it's a 1:1 mapping to what's on the page, so your concern doesn't apply here. Debugging and refactoring is far easier with Python functions than templates, and CSS programmers just use CSS the usual way.

To answer your question, I'll quote from https://about.fasht.ml:

Templates were originally created for web development in the 1990s, back when web design required complex browser-specific HTML. By using templates, designers were able to work in a familiar language, and programmers could “fill in the blanks” with the data they needed. Today this is not needed, since we can create simple semantic HTML, and use CSS to style it.

Templates have a number of disadvantages, for instance:

- They require a separate language to write the templates, which is an additional learning curve

- Template languages are generally less concise and powerful than Python

- Refactoring a template into sub-components is harder than refactoring Python code

- Templates generally require separate files

- Templates generally do not support the Python debugger.

By using Python as the HTML-generation language, we can avoid these disadvantages. More importantly, we can create a rich ecosystem of tools and frameworks available as pip-installable Python modules, which can be used to build web applications.


> - They require a separate language to write the templates, which is an additional learning curve

Sure, but that's an advantage, not the learning curve obviously. You can't use FastHTML without knowing HTML anyway, at least not from the examples. In fact it's a really complicated way to do HTML. Jinja2 or Django templates are closer to HTML and much easier to reason about.

> - Templates generally require separate files

Again, that's an advantage. Someone who are not familiar with Python could easily update the HTML, and someone who knows Python most likely also know at least some basic HTML.

I don't like this, at all, but I'm also not required to use it.


What do you have trouble reasoning about regarding FastHTML python compared to Jinja2 or Django templates?

To me, it seems like a direct translation, and that's what makes it easy to reason about. I'm curious about what situations you find more intuitive to use Jinja2 over Python.

For example, in FastHTML:

P() -> <p></p>

Div(P()) -> <div><p></p></div>

The lack of a big transformation layer and things being 1:1 is what makes me think it's just as easy to reason about, but it comes with the advantage of a more powerful Python over a templating language.

I agree that this wouldn't be a great solution if you want people who don't know Python to make HTML edits.


> You can't use FastHTML without knowing HTML anyway

We are not talking about the learning curve for HTML but of Django or Jinja or Mustache or whatever templating engines and their special syntax for loops, conditionals, etc.


I disagree. But ... I am somebody who listens and am able to change my mind. I'll experiment with this.


> Maybe I'm missing something here.

I think you are missing how htmx (https://htmx.org/) is intended to be used. You still have your regular HTML page and by interacting with that HTML, you trigger server-side functions that return HTML. That HTML is used to update only a small part of your page. htmx works with HTML fragments while HTML templates work with entire pages.


> Why not a templating engine?

They are awkward to use, usually have a foreign syntax of its own and scale poor with dynamic languages (in terms of ability, not speed). But I also think this solution here is not that good either. It's ok for small stuff or purely tag-based output, but if you have many parameters, it becomes ugly really fast.

We've used those HTML-generators 20 years ago, and they were not really popular. I still use this still for bland XML today. But I can't see this scaling well for a complex website. Maybe there are some more features I've not seen in the documentation, but otherwise I think they should step up some more gears for this. But on the other side, I guess you are not forced to use the helper-functions. At the end they are probably just strings shoved around, so you can use whatever template-engine or string-generator you prefer.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: