Live data from Hacker News

FastHTML – Modern web applications in pure Python

fastht.ml

111–120 of 229 posts

Re: FastHTML – Modern web applications in pure Python

#111

Whoah, this comment section is surreal. People really aren't bothered by the propensity for runtime errors in python? How slow it is? That it has no good features for managing complexity in large codebasea? The fact that abstractions like these pretty much always break, or at some point you want to do something more outside of the box, and you have to put in a monumental effort? I'm working on a Django+graphQL app an…

There has been funding in recent years to fix the quirks and improve performance. The Faster CPython project has had good outcomes towards achieving these goals.

Python 3.13 will have a JIT, and true threads. It'll likely take a couple more releases for these features to be stable and utilized throughout the stdlib and the wider ecosystem. In a few years, performance and quirks will likely not be an issue.

Re: FastHTML – Modern web applications in pure Python

#112
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 placeholder needed :-)

Re: FastHTML – Modern web applications in pure Python

#114

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

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

Re: FastHTML – Modern web applications in pure Python

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

> Cdn caches etc. we all know this.

No matter what language you use, you use CDNs and caches.

Re: FastHTML – Modern web applications in pure Python

#116
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…

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 foundations. This isn't one of them -- it's a direct simple mapping.

Re: FastHTML – Modern web applications in pure Python

#118
post #95

Whoah, this comment section is surreal. People really aren't bothered by the propensity for runtime errors in python? How slow it is? That it has no good features for managing complexity in large codebasea? The fact that abstractions like these pretty much always break, or at some point you want to do something more outside of the box, and you have to put in a monumental effort? I'm working on a Django+graphQL app an…

Slow is if you need to download MBs worth of JS frameworks. I love that this is usable without JS if you want to. Also the abstractions around HTML seem to be very thin so I don't really get your pint there. GraphQL seems to be a performance killer too, so maybe just use simple, boring SQL?

Downloading that all that stuff is a one time thing if you are developing. And most js dependencies are actually developer tools. The runtime dependencies of a webapp tend to be pretty minimal actually. Also, python has lots of dependencies typically.

I actually prefer Kotlin for a lot stuff people use those languages for. Similar amount of stuff to download but just a lot better tools (e.g. refactoring) and less leaky abstractions. I've used all of it of course. I just know what I prefer at this point. I was doing some python last week. It's alright but also quite a messy ecosystem.

As for Graphql, I just completed a project of ripping that out. Using it was a mistake. People like it for the wrong reasons; mostly because they are afraid of joining tables with SQL and spending some time thinking about what the optimal table structure is to minimize the amount of expensive joins needed. So they end up using stuff that does that poorly by combining the results of multiple micro-services after it comes out of the database. Which has all the predictable downsides in terms of performance. People use ORMs for the same reason. ORMs are popular for the same reason. It's not the tools but the people wielding them shying away from thinking about doing more optimal things with their databases. This stuff can work fine if you know what you are doing of course. But lots of people simply don't.

Re: FastHTML – Modern web applications in pure Python

#119
post #64

Very cool! After trying different approaches to render HTML from Python objects (including lxml, xml, etc.) I ended up liking htpy[0] the most, and the apps I built look similar to the examples in the FastHTML docs. I'll definitely try it. One pattern I use is putting all the functions that generate HTML inside their own class. That way, I can more easily create and reuse components like: class Views: ... def comp1(s…

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!

Re: FastHTML – Modern web applications in pure Python

#120
post #107

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

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.

Post reply on HN