Live data from Hacker News

FastHTML – Modern web applications in pure Python

fastht.ml

211–220 of 229 posts

Re: FastHTML – Modern web applications in pure Python

#211

I’ve been trying out fasthtml as a more scalable prototyping tool for a side project. I’ve really enjoyed using it! I tried gradio first, but 1. didn’t like the look, and 2. You can’t really go off the beaten path. So far I’ve really enjoyed working with fast HTML and htmx. Honestly my biggest complaint on working with “Python-only” dev has been the CSS. I wanted to give the app an easy, but unique/customized look. M…

Pico CSS¹ essentially works like that, so you can hard-override any of its exposed variables² to suit your needs.

I discovered it through FastHTML (it was the CSS Jeremy and Johno Whitaker used in their first-ever demo³ early June), and find the 'dx' simple, stupid, in a great way.

----

¹ https://picocss.com/

² https://picocss.com/docs/css-variables#all-css-variables

³ https://youtu.be/ptRaku0zyeA

Re: FastHTML – Modern web applications in pure Python

#212
post #156
post #131

Earlier quoted context omitted.

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

FastHTML is very interesting and reading this thread has led me to discover htpy as well which I am shocked I have never seen before! The htpy website and docs are also great. So now I am a bit of a dilemma over which one to use.

I actually hate working in HTML with all those closing tags etc so I nearly always set up a build/make process to edit my templates in PUG format. When I paste my PUG->html output into https://h2x.answer.ai/, or run html2htpy over them, I get python code that basically looks the same as those PUG templates. What a realization that is! So I may as well create and edit them in python rather than PUG and exploit the power of my beloved python dev environment and tools (as nicely stated in that "Throw out your templates" essay https://github.com/tavisrudd/throw_out_your_templates reference from the htpy docs). Thanks very much Jeremy and Andreas for this fantastic insight :)

Re: FastHTML – Modern web applications in pure Python

#213

What would be cool++ (and potentially very impactful) is if somebody builds a python/htmx native "wordpress" on top of this. The Python ecosystem offers django/wagtail and some other CMS like options but imho they have not (yet?) taped into the vast potential of the Python ecosystem once the algorithmic / data science part is natively integrated with cms type web apps. The .ml domain extension may be exactly the plac…

About .ml

The first demo Jeremy put out was called "Build Applications For LLMs in Python",¹ as part of the "Mastering LLMs" conference by Hamel Husain and Dan Becker.² (You can see a few PoC demos by the end of that video when Johno takes over, it looks a lot like what Gradio or Streamlit can do).

So I think your .ml angle is definitely part of the original ethos of FastHTML (which isn't surprising coming from the founder of fast.ai & answer.ai, among other things).

The FastHTML team explicitly recommends would-be contributors to consider making reusable components, the likes of Gradio's, to facilitate all the things notably relating to AI workflows.

----

About WordPress & CMS

That part is admittedly much larger in scope. I'd expect it to rise in correlation with the success of FastHTML itself in the Python web ecosystem writ large (beyond data / AI) but no sooner—unless someone makes a killer case for a FastHTML-based Python CMS that becomes a driver of popularity, but that's admittedly a much taller and wider order than 'simply' becoming the go-to #1 Python/ML prototype-to-market-at-scale one-stop shop. I mean, just that is huge, and yet nowhere near WordPress.

But tbh, I really like your idea, and I think it may eventually prove true, having used FastHTML first-hand for a few weeks now (and web dev being far from my turf). The fact is can ship with FastHTML, fast & well-behaved web apps, more than I ever could. If I ever get the time I'll play a bit to see what a legacy-free FastHTML CMS could look like. But no matter how good the engine, the plugin ecosystem is what makes WP, and no single dev or company can replicate that alone. It's an alchemy with the times, there are windows. Not sure one is open now.

----

¹ https://youtu.be/ptRaku0zyeA

² https://hamel.dev/blog/posts/course/

Re: FastHTML – Modern web applications in pure Python

#214
post #46

Earlier quoted context omitted.

I'm not seeing that. What browser/device are you using? The interactivity on the home page is just using Tailwind. I don't see why it would be slow for you (other than that the site is quite visually complex, so it naturally requires some baseline level of performance on your device).

Funny that you say "Visually complex" and "requires some baseline level of performance" when this same machine handles 3D games that are a thousand orders of magnitude more complex than your HTML displaying text and a few colours. What am I expecting though, that's the state of the web these days. Keep on creating more of the same rather than trying to fix this brainrot foundation you're building on.

You completely ignored and/or failed to answer their question.

Re: FastHTML – Modern web applications in pure Python

#215
post #116

Earlier quoted context omitted.

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…

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…

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.

Re: FastHTML – Modern web applications in pure Python

#216
post #152

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…

htpy recently got a html2htpy command which can convert HTML to htpy code: https://htpy.dev/html2htpy/

Re: FastHTML – Modern web applications in pure Python

#217
post #24

First, I welcome any project that enriches a software ecosystem, and this project no doubt does just that. However, I have two points which will deter me from using this (or any python->html/js framework) in a commercial production project: 1. It silos front end development in Python world. It might be great if your entire team are and always will be Python devs, but what happens when you want dedicated from end deve…

That's always the problem with these things. You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries), and I can probably count on no fingers the number of decent designers I've met who knew python. So as soon as you want to grow your team you'll end up with a split. Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it wo…

> decent designers I've met who knew python

i don't know many designers who can program at all? is it really needed?

Re: FastHTML – Modern web applications in pure Python

#219
post #107

Earlier quoted context omitted.

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 HT…

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

Re: FastHTML – Modern web applications in pure Python

#220
post #215
post #116

Earlier quoted context omitted.

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…

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 thin…

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!

Post reply on HN