Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastHTML – Modern web applications in pure Python

fastht.ml

Post reply on HN
Print view View original

151–160 of 229 posts

Re: FastHTML – Modern web applications in pure Python

#151

Post by polyrand »

pelme wrote: post #119
jph00 wrote: post #64

Earlier quoted context omitted.

Yes htpy is nice! Other interesting examples of functional HTML include Elm-html (Elm), hiccl (Common Lisp), hiccup (Clojure), Falco.Markup (F#), Lucid (Haskell), and dream-html (OCaml). FastHTML's system, called "FastTag" (FT) is a bit of a mashup of all of them plus some extra bits. I seriously considered just using htpy actually -- but in the end decided I preferred something a little different. I've wondered abou…

Thanks for making FastHTML, it is great to see more Python tooling that embraces Python for generating HTML. What made you build FastTag instead of going with htpy? I am the author of htpy and any feedback would be very welcome!

For what it's worth. One thing I really like about `htpy` is that the element attributes go before the child elements. I find this easier to write and read. Other things I like:

Having child elements as a list (i.e: the __getitem__ override) makes it convenient to build elements based on simple conditions + list comprehensions. This can be done with other frameworks, but it seems more natural to me when using `htpy`.

I also like that you can just `print()` elements and get the final HTML without having to pass it through a different function. This is not something specific about FastHTML, but rather something I've found I also had to do when using `lxml` or similar tools (I wrote about my experiments here[0])

[0]: https://ricardoanderegg.com/posts/python-build-html-componen...

Re: FastHTML – Modern web applications in pure Python

#152

Post by pietz »

This looks cool and I will check it out but I'm also quite happy with my tech stack.

I started to couple my FastAPI backend with native Jinja2 templates and noticed that I hate Jinja2 with passion (no disrespect). I tried HTPY which seemed great but this Python abstraction of HTML just felt weird and I found myself converting HTML to HTPY all the time. I even created a GPT for it. Then I found JinjaX and noticed that this hits the nail on the head for me. It's a Jinja2 preprocessor that allows the usage of components instead of the weird extends and macro syntax.

I'm happy to look at FastHTML but I'm not sure what type of benefit I can expect.

Re: FastHTML – Modern web applications in pure Python

#153

Post by magnio »

kissgyorgy wrote: post #52

Frameworks like this are really next-gen, but I wish people would think in terms of the bigger Python ecosystem and not just their own framework. This is about the fifth web framework which are not compatible with each other: Streamlit, ReactPy, FastHTML, Dash, Shiny, etc.. I created a truly reusable Python component framework which is just a a string generation library and can be used for ANY existing Python web fra…

Thank you for saying this. Having to dabble with streamlit at work, I am very disappointed in those kind of solutions, where the moment you venture off the happy path, you are on your own. Any kind of integration or extension needs you to be aware of streamlit's internals. For example, there is no built-in way to open a folder picker AFAIK.

Re: FastHTML – Modern web applications in pure Python

#154

Post by giancarlostoro »

One thing I'm dying to see is a Python template engine that builds to WASM. This is the killer feature of C# for me right now. Blazor removes any need for me to ever touch React or JavaScript ever again. I think if done as a stand alone template engine, then every web framework could benefit from it, including this one.

I just might have to research.

Re: FastHTML – Modern web applications in pure Python

#155

Post by pelme »

harel wrote: post #130
mixmastamyk wrote: post #31

Earlier quoted context omitted.

1. These folks on such a project will otherwise need to deal with templates with Python in them. Inside out or outside in, there’s some complexity. Linted, formatted, optionally typed Python is likely going to be more maintainable than html templates in the long run and is one of the easier langs to pick up. css/js can be linked separately. I don’t see any limitations that would prevent one from using a template on a…

I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in m…

In our company, where htpy was born, we are building a highly interactive application with htpy combined with Alpine.js+htmx. We have a couple of thousands lines of htpy code in production right now. We stick all HTML generation code into components/x.py or components.py files to keep it separate from other code. It is easy to grasp the structure. We use type hints so it is clear what data different components expect. "Goto defintion" just works so it is easy to navigate the code.

I agree about that HTML looks better with tags and it takes a bit of getting used to the python syntax. If something like JSX was possible in Python with all the tooling working, that would be great.

Re: FastHTML – Modern web applications in pure Python

#156

Post by pelme »

jph00 wrote: post #131
pelme wrote: post #119

Earlier quoted context omitted.

Thanks for making FastHTML, it is great to see more Python tooling that embraces Python for generating HTML. What made you build FastTag instead of going with htpy? I am the author of htpy and any feedback would be very welcome!

I wrote a few things with each of FT and htpy, and looked at the resulting code -- I felt like the htpy approach was slightly less neat personally. htpy has the benefit that '.' and '#' can have special meanings, but the downside of needing to use both __getitem__ and __call__. I didn't feel like that was a tradeoff I wanted to make. I actually originally wrote FT for a different purpose (XML for language model input…

Thanks, that makes sense! :)

Re: FastHTML – Modern web applications in pure Python

#157

Post by idf00 »

harel wrote: post #130
mixmastamyk wrote: post #31

Earlier quoted context omitted.

1. These folks on such a project will otherwise need to deal with templates with Python in them. Inside out or outside in, there’s some complexity. Linted, formatted, optionally typed Python is likely going to be more maintainable than html templates in the long run and is one of the easier langs to pick up. css/js can be linked separately. I don’t see any limitations that would prevent one from using a template on a…

I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in m…

> Once you grow beyond the "website" with simple interaction your front end becomes it's own universe

I think this has been a major failing/pain point of web-dev that this MUST be the case. However, I think fastHTML for me is going to fix that. Naturally there is no approach that is ideal in every case, but for a ton of them fastHTML I think works. I've built several things with fastHTML and am very optimistic.

As far as the visual identification, I think python is just as clear to see visual blocks as HTML, but comes with many additional refactoring options (that you can choose when it makes sense to use for your use-case).

Try playing with https://h2x.answer.ai/ and putting in some HTML code and see how it looks in python. Maybe you'll disagree, but I find it quite refreshing.

Re: FastHTML – Modern web applications in pure Python

#158

Post by crabbone »

pokipoke wrote: post #117

I haven't seen such bad Python code (fasthtml repo) for a long time. It feels like its written in 2008 using Python2

I started grasping for air once I saw hand-parsing data coming from configuration file written by the same authors!

Then I realized that part of the Python code in the repo is generated from notebooks...

I'm not a Web programmer, so just took a peak out of curiosity. I'm just a little bit happier now that I'm not a Web programmer.

Re: FastHTML – Modern web applications in pure Python

#159

Post by idf00 »

curioussavage wrote: post #83
jph00 wrote: post #67

Earlier quoted context omitted.

Fast enough for YouTube, Instagram, and Dropbox. If you need to scale up bigger than that then maybe reach for something else I guess. Today's HN launch of FastHTML's home page was running on a $5/month hobbyist account at Railway.app, where it averaged 1% utilization of 1 VCPU. (The trick, as always, is to optimise the inner loops in your app as needed; often that just means using pre-existing fast libs for that bit…

YouTube instagram and Dropbox definitely don’t scale thanks to python. They scale thanks to the massive infrastructure they built around some python code. Cdn caches etc. we all know this. And they could probably save money by migrating to a more performant and safe language. But they have money firehoses and household brand recognition so they don’t care.

> YouTube instagram and Dropbox definitely don’t scale thanks to python

But python doesn't prevent them from scaling either ;)

Post reply on HN