FastHTML – Modern web applications in pure Python(fastht.ml)
fastht.ml
FastHTML – Modern web applications in pure Python
https://fastht.ml/
228 comments
[deleted]
I've been using this while it was in development and it's a pleasure to work with. Highlights for me:
- Incremental complexity - starts super simple and I can add stuff as I need it. I don't like frameworks where step 1 already leaves you with lots of files and a bunch of things you need to know.
- Easy escape hatches. I like some of the simpler demo/dashboard things but inevitably hit a ceiling that suddenly requires a lot of hacking to get past. Since FastHTML is a lot more transparent it's very easy to go right in and do something with JS or mess with the request or make something custom. So you're not stuck with only the widgets a framework gives you or anything like that.
- Incremental complexity - starts super simple and I can add stuff as I need it. I don't like frameworks where step 1 already leaves you with lots of files and a bunch of things you need to know.
- Easy escape hatches. I like some of the simpler demo/dashboard things but inevitably hit a ceiling that suddenly requires a lot of hacking to get past. Since FastHTML is a lot more transparent it's very easy to go right in and do something with JS or mess with the request or make something custom. So you're not stuck with only the widgets a framework gives you or anything like that.
Nice work! I think the Python community definitely needs something like this. The thought never occurred to me to use HTMX w/Python for both server rendered HTML and dynamic behavior in the browser.
I have a few questions for you.
1. Why do you recommend conda or pip and not uv? Is this because the plug and play deployment platforms are configured to use pip?
2. Do you plan to make this “batteries included” like Django? E.g. it looks like currently you have to manage database schema and migrations outside of FastHTML.
3. Perhaps not in scope for this, but it seems to me making LLM API requests in the FastHTML backend could cause some scaling problems since these i/o operations can take a really long time and tie up the same threads required to render web pages. Any thoughts on that?
EDIT: Added third question.
I have a few questions for you.
1. Why do you recommend conda or pip and not uv? Is this because the plug and play deployment platforms are configured to use pip?
2. Do you plan to make this “batteries included” like Django? E.g. it looks like currently you have to manage database schema and migrations outside of FastHTML.
3. Perhaps not in scope for this, but it seems to me making LLM API requests in the FastHTML backend could cause some scaling problems since these i/o operations can take a really long time and tie up the same threads required to render web pages. Any thoughts on that?
EDIT: Added third question.
1. I don't think we mention conda afaict? We suggest pip since it's already available and works fine, and most people are familiar with it. uv works fine too, but we always like to show how to do things the way with the fewest steps and that the most people will already know about.
2. We plan to include batteries in situations where it results in something better than just using some pre-existing project. So for DBs for instance we created Fastlite (a thin wrapper around sqlite-utils) since that particular API works best with FastHTML projects. You can use `transform` for simple migrations BTW. For more complex ones, we're planning to add support for sqlalchemy/alembic and other systems
3. We recommend using async for LLM API requests (which is supported by FastHTML, thanks to ASGI/Uvicorn/Starlette), although you can also use threads. uvicorn supports running multiple workers too. So there's lots of scaling options
2. We plan to include batteries in situations where it results in something better than just using some pre-existing project. So for DBs for instance we created Fastlite (a thin wrapper around sqlite-utils) since that particular API works best with FastHTML projects. You can use `transform` for simple migrations BTW. For more complex ones, we're planning to add support for sqlalchemy/alembic and other systems
3. We recommend using async for LLM API requests (which is supported by FastHTML, thanks to ASGI/Uvicorn/Starlette), although you can also use threads. uvicorn supports running multiple workers too. So there's lots of scaling options
1. The conda recommendation is in the JS App Walkthrough documentation page:
> A Python package manager: we recommend conda or pip
2. Makes sense! Something like sqlalchemy/alembic would be cool for PostgreSQL support.
3. Ah, this is interesting. Will read up on the different ASGI implementations. I had just assumed that having LLM workloads, async or not, on your main web server would be a problem (memory and/or i/o), but maybe not. To do date I’ve been moving LLM i/o workloads to background jobs on different machines with Celery, but it’s a bit more work and also makes streaming impossible. I recently did a Qwik + Celery stack for heavy LLM use, but have wanted a pure Python solution.
Thank you!
> A Python package manager: we recommend conda or pip
2. Makes sense! Something like sqlalchemy/alembic would be cool for PostgreSQL support.
3. Ah, this is interesting. Will read up on the different ASGI implementations. I had just assumed that having LLM workloads, async or not, on your main web server would be a problem (memory and/or i/o), but maybe not. To do date I’ve been moving LLM i/o workloads to background jobs on different machines with Celery, but it’s a bit more work and also makes streaming impossible. I recently did a Qwik + Celery stack for heavy LLM use, but have wanted a pure Python solution.
Thank you!
I possibly misunderstand your q3 -- if so apologies.
You shouldn't generally run your AI model directly on your web server, but instead run it on a dedicated server. Or just use an inference service like Together, Fireworks, Lepton, etc (or use OpenAI/Anthropic etc). Then use async on the web server to talk to it.
Thanks for pointing our the JS app walkthru mention - I'll update that to remove conda; we don't have have FastHTML up as a conda lib yet! I also updated it to clarify we're not actually recommending any particular package manager.
You shouldn't generally run your AI model directly on your web server, but instead run it on a dedicated server. Or just use an inference service like Together, Fireworks, Lepton, etc (or use OpenAI/Anthropic etc). Then use async on the web server to talk to it.
Thanks for pointing our the JS app walkthru mention - I'll update that to remove conda; we don't have have FastHTML up as a conda lib yet! I also updated it to clarify we're not actually recommending any particular package manager.
I've added fasthtml (and its dependencies) to conda-forge, so it's available in conda/mamba now.
[deleted]
The asyncio runtime should suspend while waiting for a LLM API response, not block
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?
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?
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.)
(I think HTML templating is a historical accident for what it's worth, and I hope it dies.)
> (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?
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.
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.
> (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.
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
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. ;-)
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.
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.
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!
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!
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. :-)
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. :-)
I wasn’t expecting to see Jeremy when I opened the link. I’m a long time fan of his work and have been recently playing with Claudette. Claudette is written using a Jupyter notebook in a literate programming style. Seeing Jeremy deconstruct problems and build solutions from first principles is always amazing. I have experience with multiple JS frameworks and I am excited to try fasthtml. Thank you Jeremy for all your contributions.
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. Most CSS libraries expect to be part of a JS based build pipeline for any type of customization. bootstrap still requires scss customizations, tailwind is its own thing of configuration, pre-processors and tree shaking. Really wish there was a robust css library that relied on css-variables to customize. There are a few but they’re relatively anemic. Anyone know of any good options out there that would be a good fit, or did tailwind just eat everything up?
This might sound kinda retro/boring, but I've been really enjoying Bootstrap v5 -- it's come a long way! https://about.fastht.ml/ is written with it. I've started creating a FastHTML wrapper for bootstrap here:
https://github.com/AnswerDotAI/fh-bootstrap
https://github.com/AnswerDotAI/fh-bootstrap
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
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
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:
[0]: https://htpy.dev/
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(self):
return Div(self.header(), P("too"))
[0]: https://htpy.dev/
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 about a class-based approach like that -- interesting to hear it's worked for you. I should try it! I'm using a purely functional approach for re-use, as you see in this example of the code for about.fastht.ml:
https://github.com/AnswerDotAI/fh-about/blob/main/overview.p...
I've wondered about a class-based approach like that -- interesting to hear it's worked for you. I should try it! I'm using a purely functional approach for re-use, as you see in this example of the code for about.fastht.ml:
https://github.com/AnswerDotAI/fh-about/blob/main/overview.p...
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!
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...
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...
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) so id and class attributes weren't of any interest at all at that time!
Also, I was able to implement FT using just 2 lines of code -- it felt like a very natural data structure that was a good fit with Python.
Having said all that, I think htpy is really nifty and elegant. :D
Also, I was able to implement FT using just 2 lines of code -- it felt like a very natural data structure that was a good fit with Python.
Having said all that, I think htpy is really nifty and elegant. :D
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 :)
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 :)
I was talking with my cofounder today about how we'd likely need to become a multilingual platform once we eventually take on more than backend applications and I'm glad to see projects like this. They give me hope that we won't have to make that jump.
I'm really excited to give this a try seeing as this should just run on our cloud with minimal to no changes given the premise.
I know of one or two other projects like this in the ecosystem, but this approach seems the most promising so far.
Also I'm not sure when Jeremy finds time to sleep given all the other exciting work from Answer.AI. and his various courses :P
I recently implemented deepspeed + qlora in a finetuning library and that was also entirely based on the fsdp implementation him and his various associates wrote.
So he really is just making great contributions all over the place.
I'm really excited to give this a try seeing as this should just run on our cloud with minimal to no changes given the premise.
I know of one or two other projects like this in the ecosystem, but this approach seems the most promising so far.
Also I'm not sure when Jeremy finds time to sleep given all the other exciting work from Answer.AI. and his various courses :P
I recently implemented deepspeed + qlora in a finetuning library and that was also entirely based on the fsdp implementation him and his various associates wrote.
So he really is just making great contributions all over the place.
I am a python developer who has been envious of modern application dev frameworks
& typescript, but never had the time to invest in another stack. This is so exciting. I suspect this might be catalyst that empowers more people to ship stuff
Take a look at streamlit as well. It’s got a few weird sharp edges but is really easy to pick up
I like streamlit but found it if gets beyond a certain size it gets very hard to manage.
Also, because FastHTML is powered by starlette, it handles async really well. That means web sockets have been a trivial implementation.
Also, because FastHTML is powered by starlette, it handles async really well. That means web sockets have been a trivial implementation.
One check I always like to do with a new Python-based framework is this - does it support the creation of a dynamic number of components at runtime, AND each having their own component state? Most frameworks I've tried support one or the other, but not both. Is there an example that demonstrates something like this in FastHTML - user provides a number n at runtime, n cards are generated, each card has its own text field which can be modified by the user without affecting the other cards' text fields.
Yes lots! The "idiomatic" todo app is a nice simple example:
https://github.com/AnswerDotAI/fasthtml/blob/main/examples/a...
While the design of it violates the separation of concern principle (keep data and code separate), I have to say this is most impressive, thanks for writing and sharing it.
I have always been reluctant to accept any boilerplate code (esp. such that one cannot fully understand) in my codebase, and this does not have ANY! All the sample code looks absolutely beautiful, so I will give this a try for my next Web app projects.
I have always been reluctant to accept any boilerplate code (esp. such that one cannot fully understand) in my codebase, and this does not have ANY! All the sample code looks absolutely beautiful, so I will give this a try for my next Web app projects.
Can you explain how this doesn't keep data and code separate? Not sure what you mean.
This looks really cool. I have experience with shiny apps in R, and Python has a shiny package too now. FastHTML looks a lot like Python shiny without routes. I think both of these frameworks are great for people with no web dev experience. It would be great if there is some discussion of htmx and why it is used in the tutorials section of FastHTML docs.
Shiny and FastHTML are both built on top of Starlette, so both use the same routing implementation. FastHTML by default uses a `RouteX` subclass that adds quite a bit of functionality to Starlette routes (mainly around automatically passing in the needed parameters for a handler).
There's quite a bit of background of why HTMX is used, particularly these two sections of about.fastht.ml:
- https://about.fastht.ml/foundation#sec2
- https://about.fastht.ml/tech#sec2
There's quite a bit of background of why HTMX is used, particularly these two sections of about.fastht.ml:
- https://about.fastht.ml/foundation#sec2
- https://about.fastht.ml/tech#sec2
I'm personally always confused with those batteries-included frameworks like Django, FastAPI and similar. Sure, they might be easier for a beginner to quickly whip up a simple Web site/app, but in my experience as your requirements grow they quickly start getting in your way.
Starting with more flexible initial components (e.g. Starlette) and adding batteries (SQLAlchemy, Jinja2, HTMX...) as needed allows for a sensible evolutionary approach and prevents painting yourself into a corner with early decisions.
Starting with more flexible initial components (e.g. Starlette) and adding batteries (SQLAlchemy, Jinja2, HTMX...) as needed allows for a sensible evolutionary approach and prevents painting yourself into a corner with early decisions.
Django is like a marriage. You have to commit fully to get the most out of it. You have to work through the (perceived) suboptimal parts to find a compromise that such that the whole system does not fall down.
And with enough time you come to realize there are certain things that are out of scope for the current codebase. Just as there are things that are out of scope for the current marriage.
hahaha - I dont know...I should stop here. This metaphor is stretching thin
And with enough time you come to realize there are certain things that are out of scope for the current codebase. Just as there are things that are out of scope for the current marriage.
hahaha - I dont know...I should stop here. This metaphor is stretching thin
Is FastAPI really "batteries included"? I would say that it's orders of magnitude lighter than Django
So I don't disagree with your general premise, but FastAPI isn't in the same ballpark or even universe with Django. Yes, it's heavier than Starlette, but it's an extremely light framework, and was really intended to be a successor to microframeworks like Flask.
Hey, just looking this quickly, the ideal case are for python developers that don't use Flask or Django? I'm a web developer for just 10 years, and I like seeing HTMX being applied, but I don't see why I should consider adopt it.
Maybe I'm not the ideal user, but would like to know from you who do you think this is for.
Maybe I'm not the ideal user, but would like to know from you who do you think this is for.
Flask or Django users should be able to get started pretty quickly with FastHTML, and users of the preview that have switched over tell us that they're finding it easier and faster to create what they want in FastHTML.
Having said that, the people that will get the most out of it and folks that haven't got much prior web dev experience -- e.g. people who have just done some streamlit/gradio/etc apps, or maybe Python programmers that haven't written web apps at all. I mention this briefly on https://about.fastht.ml in the section "A new generation of coders":
> "Coding is the key to turning the ideas in your head into products and services that can help people. AI has recently made it easier to get started with coding, which means there are more people than ever before who can create useful stuff. But this new generation of coders do not generally have the same background as full-time software engineers. They may have been trained in a different field, or they may have learned to code on their own. We hope that FastHTML will make it easier for this new generation of coders to turn their ideas into reality. To create maintainable and scalable solutions."
Having said that, the people that will get the most out of it and folks that haven't got much prior web dev experience -- e.g. people who have just done some streamlit/gradio/etc apps, or maybe Python programmers that haven't written web apps at all. I mention this briefly on https://about.fastht.ml in the section "A new generation of coders":
> "Coding is the key to turning the ideas in your head into products and services that can help people. AI has recently made it easier to get started with coding, which means there are more people than ever before who can create useful stuff. But this new generation of coders do not generally have the same background as full-time software engineers. They may have been trained in a different field, or they may have learned to code on their own. We hope that FastHTML will make it easier for this new generation of coders to turn their ideas into reality. To create maintainable and scalable solutions."
I'm a hobby programmer and would never use the existing web ecosystem to write anything -- seems unnecessarily complicated. If I have a task to do I'll get it done in C/C++ or preferably Python. I do see the benefit of using the browser for cross platform UI under Python over say Tcl/Tk though, would this project be of help to someone like me that wants to keep it simple and just get something done for their own personal use?
Yes it should be a great fit. If you give it a try, and have any issues, we have a Discord community that can help: https://discord.gg/qcXvcxMhdP
This looks really nice. I'm just wondering how it would combine with Pyscript, which I've been watching for a good while now. As a primarily Python user wanting to do some web dev, I'd rather not touch JS/TS at all, beyond importing 3p packages.
I doubt you'd need pyscript with this. Pyscript uses WASM in the browser, whereas FastHTML uses Python on the server directly -- the FastHTML approach avoids the need for your phone/laptop to download an entire python implementation just to use a web page!
Oh my goodness. I like to keep things boring where possible and swore I would never stray from Django + HTMX + Django Ninja, but I am exceedingly tempted to use this in an upcoming project. Lovely architectural choices - bravo!
It's a bit of a tangent, but do you have any go-to resources for learning how to use Django-ninja with HTMX? I haven't really put a lot of time into it, but HTMX seemed difficult to use with JSON APIs on first attempt.
I'm only really familiar with Django and DRF, but if love to switch at some point.
I'm only really familiar with Django and DRF, but if love to switch at some point.
Htmx isn’t designed to work with JSON APIs at all. It needs HTML back from the server. You can detect when a request comes from htmx with a header it adds though so that allows you to return a different response if you want.
FastHTML is an impressive and innovative idea. It seems like a web development tool similar to Streamlit, but with more precise control.
FastHTML's concept led me to consider a feature that allows direct deployment of PyQt code as web services, even without HTML knowledge, like "PyQtWeb."
PyQtWeb > FastHTML > [Streamlit, Gradio]
FastHTML's concept led me to consider a feature that allows direct deployment of PyQt code as web services, even without HTML knowledge, like "PyQtWeb."
PyQtWeb > FastHTML > [Streamlit, Gradio]
Thank you! I'm another engineer who uses python (and C, Matlab and a few others) and whenever I want a web app I end up with some Rube Goldberg style contraption. Looking forward to trying your software.
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 developers? What happens when you need to deviate out of what the framework gives you in a front-end context? What happens when you need to eject from "python" into a dedicated front end environment? All your front end code is now written in Python. Worst, you now might even have JavaScript code embedded inside Python code. I keep hearing "CoffeeScript" in the back of my mind...
2. Any python project using FastAPI (which is fantastic), flask, etc. and is growing in scope, will ultimately build Django. For example, FastAPI (which is great), has SqlModel (which is awesome) which makes SqlAlchemy less sucky and more like Django. Start to factor in all the other batteries we got used to getting with Django, and it starts adding up. If the project is smallish in scope and well defined to know it will stay such, sure it's a valid and excellent choice. The same applies here - unless batteries are included, or this is (as suggested in a comment) available as a Django app, you'll end up building Django.
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 developers? What happens when you need to deviate out of what the framework gives you in a front-end context? What happens when you need to eject from "python" into a dedicated front end environment? All your front end code is now written in Python. Worst, you now might even have JavaScript code embedded inside Python code. I keep hearing "CoffeeScript" in the back of my mind...
2. Any python project using FastAPI (which is fantastic), flask, etc. and is growing in scope, will ultimately build Django. For example, FastAPI (which is great), has SqlModel (which is awesome) which makes SqlAlchemy less sucky and more like Django. Start to factor in all the other batteries we got used to getting with Django, and it starts adding up. If the project is smallish in scope and well defined to know it will stay such, sure it's a valid and excellent choice. The same applies here - unless batteries are included, or this is (as suggested in a comment) available as a Django app, you'll end up building Django.
Regarding (1), I think you might be misunderstanding how FastHTML works. If you want to write JS code in FastHTML, then you can just do that. But you can focus entirely on using it for the bits it works well for.
For instance, I wrote a little app (https://word2md.answer.ai/ ) which lets you copy/paste from MS word, and converts it to Markdown. I found that there's some nice existing JS code for cleaning up MS Word markup, so I used that on the client side, and used server-side python code for converting that to markdown. Here's the Python code, which is just plain python in a regular python file:
https://github.com/AnswerDotAI/word2md/blob/main/main.py
And here the JS code, which is just plain JS in a regular JS file:
https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.j...
Regarding (2), I've heard the same basic argument nearly every time I've tried to create anything new, and I've heard it apply to lots of other people's projects too. Yes, if there's an existing product that's pretty good already, then it's likely the new thing won't be as good in every way. I don't think that's a reason to not try to make something better, however. I like Django a lot, have used it since its very early days, and I'm friends with one of the founders of it -- it's an amazing project. But it's not perfect, and hopefully it's OK if some people want to try different things too.
For instance, I wrote a little app (https://word2md.answer.ai/ ) which lets you copy/paste from MS word, and converts it to Markdown. I found that there's some nice existing JS code for cleaning up MS Word markup, so I used that on the client side, and used server-side python code for converting that to markdown. Here's the Python code, which is just plain python in a regular python file:
https://github.com/AnswerDotAI/word2md/blob/main/main.py
And here the JS code, which is just plain JS in a regular JS file:
https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.j...
Regarding (2), I've heard the same basic argument nearly every time I've tried to create anything new, and I've heard it apply to lots of other people's projects too. Yes, if there's an existing product that's pretty good already, then it's likely the new thing won't be as good in every way. I don't think that's a reason to not try to make something better, however. I like Django a lot, have used it since its very early days, and I'm friends with one of the founders of it -- it's an amazing project. But it's not perfect, and hopefully it's OK if some people want to try different things too.
Regarding 2, I completely agree. A good existing project is no argument against new projects in the same space. It was more an observation (and very current experience of me reworking a fastapi project to Django+ninja because it simply grew in scope enough to merit it).
Regarding 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.
Regarding 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.
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 new page.
I recently looked into these kind of html builder libs, pioneered by dominate. “htpy” was the only one where I was impressed with the source code.
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 new page.
I recently looked into these kind of html builder libs, pioneered by dominate. “htpy” was the only one where I was impressed with the source code.
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 my opinion. The tag syntax makes it clear to visually identify blocks and layout elements. You lose this when you describe the layout in Python.
As an aside, HTML is formatted in a very visual way in my opinion. The tag syntax makes it clear to visually identify blocks and layout elements. You lose this when you describe the layout in Python.
> 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.
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.
I guess it's a personal preference. I tried it, and it looked a mess in my eyes.
Take a strong tag:
Take a strong tag:
Div(
"If you click '",
Strong('Accept all'),
"', we and",
A('our partners', href='/v2/partners', target='_blank'),
...
[deleted]
This is html building not js. It’s not any more verbose, in fact slightly less because no need for closing tags. Main difference is parens instead of angle brackets. Now you can use tools.
I do prefer lower case callables but that’s a minor nitpick, and “htpy” and other libs can do that.
I do prefer lower case callables but that’s a minor nitpick, and “htpy” and other libs can do that.
Yes, it is HTML, and it loses all the benefits of HTML, by adding complexity of code and loss of structure. I'm uncomfortable with HTML and JS obfuscated by Python like that. I'm not using the word "verbose" as a character count comparison, but as an overall feel of weight when I see such code. It just takes me back to Java Swing, or ExtJS in the JavaScript world. It's not bad if it's the only way to describe an interface or layout. But there are better ways - HTML.
Please don't get my comments as criticism of the project itself, I think it's lovely and has a lot of merit. I've had to deal with the aftermath of these kind of things before, which makes me very aware of where it usually ends up at: Devs in language X don't like Html/JavaScript/Y/Z, so they wrap it with language X until X is all there is. Then one day, the business realises they have a codebase nobody other than it's original creators can or want to deal with, and any change becomes a behemoth of a project. It always starts with the best of intentions.
Please don't get my comments as criticism of the project itself, I think it's lovely and has a lot of merit. I've had to deal with the aftermath of these kind of things before, which makes me very aware of where it usually ends up at: Devs in language X don't like Html/JavaScript/Y/Z, so they wrap it with language X until X is all there is. Then one day, the business realises they have a codebase nobody other than it's original creators can or want to deal with, and any change becomes a behemoth of a project. It always starts with the best of intentions.
The complexity and structure are near equivalent. S-expressions are an html precursor.
Python is one of the most popular languages and easy to read. People are more resilient than given credit.
I tend to agree with your closing comment about over abstraction in general, however you may have forgotten that a Jinja/html template is an abomination of conflicting concepts.
I’m more worried about the rest of this framework to be honest. :-D
Python is one of the most popular languages and easy to read. People are more resilient than given credit.
I tend to agree with your closing comment about over abstraction in general, however you may have forgotten that a Jinja/html template is an abomination of conflicting concepts.
I’m more worried about the rest of this framework to be honest. :-D
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.
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.
If you’re using backend templates it’s already coupled. The css as well. It’s a myth that separate langs in separate files == decoupled. I didn’t realize myself until recently—just got so used to it.
The main way around that is the SPA/API architecture, but that comes with huge complexity drawbacks as well.
Nothing special about html, at least as a Python string builder you can factor it and use tools. It can also be put into separate files. So many upsides and little to no downside besides initial surprise.
The main way around that is the SPA/API architecture, but that comes with huge complexity drawbacks as well.
Nothing special about html, at least as a Python string builder you can factor it and use tools. It can also be put into separate files. So many upsides and little to no downside besides initial surprise.
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 works after coming back from your day job that uses a more mainstream framework.
Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it works after coming back from your day job that uses a more mainstream framework.
> You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries
You can definitely do this with FastHTML: https://h2x.answer.ai/
You can definitely do this with FastHTML: https://h2x.answer.ai/
> decent designers I've met who knew python
i don't know many designers who can program at all? is it really needed?
i don't know many designers who can program at all? is it really needed?
[deleted]
Hey fastHTML team, congratulations on first public release of fastHTML.
I just want to point out fastHTML, fastAI and fastAPI can bering together to form a python stack for training, deploying ml application python native fashion. The stack will known as faststack
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.
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.
It doesn't look like they use a formatter or linter. I hope I'm wrong but I feel like that and their use of nbdev are really going to hurt adoption. :(
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 :-)
The .ml domain extension may be exactly the placeholder needed :-)
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/
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/
I have been looking for something like this for a while and am very excited to see this project.
I am currently settled on [ludic](https://getludic.dev) which is very similar to my eyes and has been discussed here [1]. The developer is responsive and the repo has a comparable number of stars to FastHTML on github.
Ludic's big feature is type-guided-components[2] that allow compile time checking of the compatibility of components forming a structure---and autocomplete while writing. So for example the component `WithSideBar` from the catalog[3] needs to contain a `SideBar` component and a list oof other child components. It seems elegantly put together too.
Looking forward to trying out FastHTML.
[1] https://news.ycombinator.com/item?id=39776199 [2] https://getludic.dev/docs/components [3] https://getludic.dev/catalog/layouts#sidebar
I am currently settled on [ludic](https://getludic.dev) which is very similar to my eyes and has been discussed here [1]. The developer is responsive and the repo has a comparable number of stars to FastHTML on github.
Ludic's big feature is type-guided-components[2] that allow compile time checking of the compatibility of components forming a structure---and autocomplete while writing. So for example the component `WithSideBar` from the catalog[3] needs to contain a `SideBar` component and a list oof other child components. It seems elegantly put together too.
Looking forward to trying out FastHTML.
[1] https://news.ycombinator.com/item?id=39776199 [2] https://getludic.dev/docs/components [3] https://getludic.dev/catalog/layouts#sidebar
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.
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.
htpy recently got a html2htpy command which can convert HTML to htpy code: https://htpy.dev/html2htpy/
Look very nice, I love simplicity. Wondering how it would scale in real life - game of pi example feels slow.
Is it possible to mix it with gradio? E.g. Make most of layout and UI in fastHTML but reuse some complex high level components from gradio?
Is it possible to mix it with gradio? E.g. Make most of layout and UI in fastHTML but reuse some complex high level components from gradio?
The home page was running on a $5/month hobby account at launch today and reached 1% use of 1 VCPU -- so speed seems pretty good to me! Having said that, not all the example apps are well optimised, since we're aiming largely to teach the basics.
I'd love to see gradio-style components written in FastHTML -- I actually raised this idea with the founder of gradio today. It would be a great combo IMO.
I'd love to see gradio-style components written in FastHTML -- I actually raised this idea with the founder of gradio today. It would be a great combo IMO.
What is the advantage over e.g. https://streamlit.io/ ?
Streamlit is for small, interactive, data-driven applets. FastHTML is for building entire websites with direct control over the HTML output.
[deleted]
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.
I just might have to research.
Might not be exactly what you're talking about, but Shiny for Python compiles to WASM, so that you can deploy stand-alone
https://shiny.posit.co/py/docs/shinylive.html
https://shiny.posit.co/py/docs/shinylive.html
I'm specifically talking about say jinja2 rendering to WASM and doing any sort of application logic client side like Blazor does. Blazor can also do server-side logic. It's essentially a SPA framework on serious steroids with minimal mental overhead of having to go to JavaScript and back.
"What's the FastAPI of frontend?" - A tweet I wrote 2022
I'll give this a go for my next project!
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?
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.
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.
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.
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.
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.
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.
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.
Python isn't really known for its speed. The syntax seems like a nightmare. Very magic syntax like Ruby on Rails. I feel bad for the person that will need to maintain this in 5 years when its grown to large.
Did you try Reflex.dev? Any opinions on it?
Reflex converts the Python code into a react frontend and fastapi backend. It's an abstraction that hides much of the underlying foundation, which is a very differently philosophy to FastHTML -- which endeavors to make the underlying foundation directly available.
Personally I wanted to create something that made the foundations of the web more directly available to Python programmers, rather than hiding it behind multiple layers of abstraction. Reflex is very impressive though, and I expect for some types of app it might be a better choice; probably worth trying out both!
Personally I wanted to create something that made the foundations of the web more directly available to Python programmers, rather than hiding it behind multiple layers of abstraction. Reflex is very impressive though, and I expect for some types of app it might be a better choice; probably worth trying out both!
Python is fast compared to something? Maybe fast enough to generate HTML.
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, but sometimes you may need to reach for cython/PyO3/etc. Often you'll find you don't need anything extra. FastHTML's own home page doesn't need anything extra.)
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, but sometimes you may need to reach for cython/PyO3/etc. Often you'll find you don't need anything extra. FastHTML's own home page doesn't need anything extra.)
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 ;)
But python doesn't prevent them from scaling either ;)
> Cdn caches etc. we all know this.
No matter what language you use, you use CDNs and caches.
No matter what language you use, you use CDNs and caches.
They could partly run Python, in which case it would be a better example of FastHTML scaling in this way. Some CDNs have Python edge functons: https://developers.cloudflare.com/workers/languages/python/ https://aws.amazon.com/developer/application-security-perfor...
With Vercel and Netlify it's just TypeScript/JavaScript: https://vercel.com/docs/functions/edge-middleware https://docs.netlify.com/edge-functions/overview/
With Vercel and Netlify it's just TypeScript/JavaScript: https://vercel.com/docs/functions/edge-middleware https://docs.netlify.com/edge-functions/overview/
Python is glue, used to call and integrate other faster languages. Most of what is done with Python is calling fast C and C++ code.
Back in ancient times, a software project I was working in, failed, precisely because of Python performance with the Zope framework, it was too slow to render a webpage that required more than a few interesting calculations.
Today the language is almost the same, but computers have a thousand times more memory, and the CPUs are similarly faster.
The exact same project would have been successful today, just like neural networks are cornerstones of modern computing, because of the advances in hardware.
Back in ancient times, a software project I was working in, failed, precisely because of Python performance with the Zope framework, it was too slow to render a webpage that required more than a few interesting calculations.
Today the language is almost the same, but computers have a thousand times more memory, and the CPUs are similarly faster.
The exact same project would have been successful today, just like neural networks are cornerstones of modern computing, because of the advances in hardware.
I never expected this quick jab to trigger such reactions.
Yes, it’s glue. True for Ruby, PHP, Perl as well.
I just think it’s disingenuous to associate the word “fast” with anything implemented with it, granted that C is 70 times faster than it. I mean, me saying it’s slow compared to C is less hyperbolic than saying it’s fast.
And I think Python is perfectly adequate for plenty of use cases, so is PHP, so is Ruby. I like to be mean to JavaScript, but even that is fine for web dev.
Yes, it’s glue. True for Ruby, PHP, Perl as well.
I just think it’s disingenuous to associate the word “fast” with anything implemented with it, granted that C is 70 times faster than it. I mean, me saying it’s slow compared to C is less hyperbolic than saying it’s fast.
And I think Python is perfectly adequate for plenty of use cases, so is PHP, so is Ruby. I like to be mean to JavaScript, but even that is fine for web dev.
Not just fast, but webscale. Also fast to develop.
https://youtu.be/b2F-DItXtZs?si=r6vGxl22gXkXO1Y7
https://youtu.be/b2F-DItXtZs?si=r6vGxl22gXkXO1Y7
ROI is more important than silly benchmarks.
https://www.tiobe.com/tiobe-index/
But, we can play the benchmark game, if that tops your morning cereal.
Competes with Go. Blows most popular TS frameworks out of the water.
https://www.techempower.com/benchmarks/#section=data-r22&hw=...
For you: https://gprivate.com/6chku
https://www.tiobe.com/tiobe-index/
But, we can play the benchmark game, if that tops your morning cereal.
Competes with Go. Blows most popular TS frameworks out of the water.
https://www.techempower.com/benchmarks/#section=data-r22&hw=...
For you: https://gprivate.com/6chku
That benchmark makes Go look good, and JS very good. The upper part of the table belongs to Go, and the very top is JS.
The bottom of the benchmark table are all slow Python implementations xD
The bottom of the benchmark table are all slow Python implementations xD
fast enough for a million users on a $4 budget.
When you get to 1% of the world population, you can switch to rust/go
When you get to 1% of the world population, you can switch to rust/go
I'm looking at the very first example, and I'm a little confused.
The function `home()` displays a list of messages, but they aren't passed into `home()`. Instead, `messages` is basically a global variable, and some other functions can append messages to it. Then I went looking at some more examples, and I see this pattern repeated. Is this how you're supposed to build webapps with this package? How does it isolate the list of messages for different users?
Which example? I see global vars in a couple of the demos. The game state for the Game of Life makes sense, since it is intended to be shared. The `messages` list in the Chatbot demo is definitely NOT how you'd build a multi-user application, that's mainly showing the styling aspect.
In general, you'd have an actual database and make it so users can only see their own data! See https://github.com/AnswerDotAI/fasthtml/blob/main/examples/a... which adds a filter to queries and DDL statements to ensure that the user can only see/edit their own todos.
In general, you'd have an actual database and make it so users can only see their own data! See https://github.com/AnswerDotAI/fasthtml/blob/main/examples/a... which adds a filter to queries and DDL statements to ensure that the user can only see/edit their own todos.
Not a very good "ad" as your page is quite slow and skips many frames, especially when scrolling past "The fastest way to create a real web application."
"Fast"
"Fast"
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).
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.
Hi Jeremy, congratulations for the launch.
How does this compare to Dash?
I've used Dash for many applications, so I'm wondering what are the advantages of FastHTML?
How does this compare to Dash?
I've used Dash for many applications, so I'm wondering what are the advantages of FastHTML?
I looked through the examples and man is the code ever unreadable to me. If you're using HTMX why not just use Flask or Django and use much easier to read templating engines?
I always found trying to read function calls as markup to get unwieldy. Realistically people are most likely going to either be using Python with traditional templating engines or Python as an API with a JS framework on top.
Good luck to this project, perhaps it isn't for me.
I always found trying to read function calls as markup to get unwieldy. Realistically people are most likely going to either be using Python with traditional templating engines or Python as an API with a JS framework on top.
Good luck to this project, perhaps it isn't for me.
It's you!
Just wanted to say, nice job, love how much work has gone in to this and especially the site/docs to help people get going.
Just wanted to say, nice job, love how much work has gone in to this and especially the site/docs to help people get going.
Thank you for building this :-)
Can you address the longevity question? Do you think you and/or other highly motivated/enthusiastic folks could be maintaining this project for the long-term?
Or should we only be building projects on top of this framework with a 2-3 year time-frame?
Can you address the longevity question? Do you think you and/or other highly motivated/enthusiastic folks could be maintaining this project for the long-term?
Or should we only be building projects on top of this framework with a 2-3 year time-frame?
Jeremy, this is awesome. I hope this catches on
I have used and liked FastHTML although I was going in a different direction (not very modern and no javascript) https://github.com/drummonds/lofigui. It works well.
Looks neat! It seems at least superficially similar to https://github.com/getludic/ludic which I quite like too.
I love everything about this. I have been using HTMX heavily for a side project and glad to see it used in this project. Is fast.ai hiring? I would love to make contributions to their mission.
[deleted]
[deleted]
This looks very interesting.
Is it possible to inject custom JS wherever I want in the app? Also, is the generate html/css/javascript readable as the application scale up?
Is it possible to inject custom JS wherever I want in the app? Also, is the generate html/css/javascript readable as the application scale up?
I'm so going to use this for my next project
GitHub link to project: https://github.com/AnswerDotAI/fasthtml
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 and I'm basically considering buying a farm at this point. Python is really not the right language.
I'm working on a Django+graphQL app and I'm basically considering buying a farm at this point. Python is really not the right language.
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.
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.
You're the one starting about JS... I never said I liked JS either
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.
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.
Threads that slow down single thread performance by 50-100%. The "faster CPython" figures are just marketing as well.
Whenever I run some benchmark myself, I do not see any improvements over Python 3.7 and the horrible numbers for the threaded build.
Whenever I run some benchmark myself, I do not see any improvements over Python 3.7 and the horrible numbers for the threaded build.
I'm wondering whats the state of GraalPy - seems it support many of pip extensions.
https://github.com/oracle/graalpython
Yes, I think people are polite and give the new framework a chance. Anything that is not Django is of course appreciated.
I do not understand why Dropbox and Instagram are cited as references. People also cited Google 10 years ago, but Google has now fired the Python team.
Dropbox moved large parts to Golang, and Instagram code does not seem to be something to aspire for. Perhaps Instagram manages to prop up a horrible stack by throwing hundreds of developers at the problem. Not every company, especially startups, can afford that.
If the new free threading becomes the default, I would not expose Python directly to the web. Already before that CPython has show a lackadaisical attitude towards threading correctness and convoluted abstractions that are barely auditable.
I do not understand why Dropbox and Instagram are cited as references. People also cited Google 10 years ago, but Google has now fired the Python team.
Dropbox moved large parts to Golang, and Instagram code does not seem to be something to aspire for. Perhaps Instagram manages to prop up a horrible stack by throwing hundreds of developers at the problem. Not every company, especially startups, can afford that.
If the new free threading becomes the default, I would not expose Python directly to the web. Already before that CPython has show a lackadaisical attitude towards threading correctness and convoluted abstractions that are barely auditable.
I’ve seen good Python projects and bad Python projects. Not all errors are caught at compile time and performance may or may not matter in non-cpu bound workloads. There’s no “right” language. Python can shine in the right context (including web applications).
Can you expand on the features you need for managing complexity in large code bases?
We’ve built a few APIs which serve millions of users without any problems and with very low latency with FastAPI, and so far we’re very happy with the choice.
We’ve built a few APIs which serve millions of users without any problems and with very low latency with FastAPI, and so far we’re very happy with the choice.
Static typing (that is actually sound, strict, and enforced by default) with support for interfaces. Just generally a language that doesn't incentivizes using strings and dictionaries for everything. A language that has actual separation and implementation hiding, rather than the convention of using underscores and praying that no one touches it.
Static analysis is pretty much impossible for large python codebases. IntelliJ does not understand a single shit about the codebase I'm working on and I find myself having to ctrl+f instead of being able to shift click, etc. There is simply such a thing as "too dynamic".
Python was designed for quick scripts and pseudocode mockup prototypes. There's a bunch of bullshit strapped onto it nowadays but there's no escaping the roots of the design of python. It's not a good fit for large software or software nor software that needs to be reliable. Sure, with _enough effort and discipline_ you can bla bla bla. I'm not interested in that. I'm interested in working smarter, not harder.
Static analysis is pretty much impossible for large python codebases. IntelliJ does not understand a single shit about the codebase I'm working on and I find myself having to ctrl+f instead of being able to shift click, etc. There is simply such a thing as "too dynamic".
Python was designed for quick scripts and pseudocode mockup prototypes. There's a bunch of bullshit strapped onto it nowadays but there's no escaping the roots of the design of python. It's not a good fit for large software or software nor software that needs to be reliable. Sure, with _enough effort and discipline_ you can bla bla bla. I'm not interested in that. I'm interested in working smarter, not harder.
Pydantic, dataclasses and mypy help a lot, I don't get what you mean by incentivizing strings and dictionaries for everything, that definitely doesn't sound like good modern Python. The go-to-definition functionality is available in any modern editor, it sounds like yours isn’t set up properly.
Yeah I also don't get it. Python is great and I really like it, but it never feels like a good choice for an app that runs 24/7 for years to come. So many wasted CPU cycles.
The only two langauges that have better error handling are golang and rust.
but not having to context switch from python to another language is worth it for 95% of applications.
but not having to context switch from python to another language is worth it for 95% of applications.
Honestly, Jeremy and the Fast.ai team really deserve some kind of award/medal of honour/general sainthood at this point.
Came here to post this but HN hivemind beat me to it. Can't stress this enough. This Coupled with generative AI for code generation will make the barrier to entry sure low. Time to migrate my bootstrapped Flask/JINJA2 templates website(www.voxtodo.com) to this shiny new.
Will there be a FastHTML.NET, using C# and F# instead of Python?
Weirdly topical. Currently investigating Django as a backend for product redevelopment. I'd like to avoid a fully separate frontend app, because frankly it's overkill. I was thinking of HTMX, Alpine, and cobbling together some component-esque template organization. I'll check this out!
This looks like a lot of fun, but I wouldn't probably have any need for it. I currently find an AI prompt in the code editor, along with AI code completion, a fantastic way to rapidly code. Mixing Latte template files with a minimal framework like Flight PHP, and HTMX makes me just as productive. I guess python devs would be more appreciative though.
Yikes. I'm going to follow this one cause it's right up my alley, but I'm worried I will absolutely hate the process if some standards don't change, e.g. having to have multiple functions called "get()" for them to be a GET request is going to drive mypy/flake8 mad.
You can just use `@app.get` and name your function whatever you like, just like FastAPI, if you prefer.
Although I don't see why flake8 should care - multi-dispatch is built into the python stdlib so having multiple functions with the same name is not weird or new.
Although I don't see why flake8 should care - multi-dispatch is built into the python stdlib so having multiple functions with the same name is not weird or new.
Thanks for the info. In general, being compliant with established conventions (even if you don't personally like them) can lower the barrier of entry for some people who may superficially reject your library based on esthetic concerns.
If you'd like to dig deeper, the reference is:
If you'd like to dig deeper, the reference is:
F811 redefinition of unused 'get' from line xx
error: Name "get" already defined on line xx [no-redef]
But you would have these 'get' functions in different modules though, so how would it be a 'redefinition'?
Python to Python
HTML to HTML
JS to JS
CSS to CSS
That's it, no more complexity
That's it, no more complexity
I think this is a very useful framework to write about on Wikipedia on how not to use HTML in your python code. There's a canonical reason on why we shouldn't.
Readability, reusability ... the list goes on.
Readability, reusability ... the list goes on.
I'm not sure I understand your perspective, we've been using HTML + template library for a while with great success as an industry, across multiple languages.
From what I understand is this adds JS bindings.
From what I understand is this adds JS bindings.
How does this compare to streamlit?
does this integrate with django?
This seems like the path to widest adoption. Focus on building an “HTMX component” library and just use Django, and not recreating a less battle tested Django.
Like, just using htpy [1] with Django and some minor component abstraction seems like it might already be a feature complete version of this.
[1] https://htpy.dev/
Like, just using htpy [1] with Django and some minor component abstraction seems like it might already be a feature complete version of this.
[1] https://htpy.dev/
Both of the co-authors of the popular book series "Two Scoops of Django" are now FastHTML users and contributors, and they tell me that they're able to reduce the complexity of their Django software by quite a lot by rewriting in FastHTML.
Django is fantastic and I'm a big fan, but it's gotten over-complicated in recent years IMO and isn't explicitly designed to work well with HTMX or ASGI. Using it with htpy and htmx is a totally reasonable option for folks that already know Django well, but it's not going to be quite the same thing as using FastHTML.
Django is fantastic and I'm a big fan, but it's gotten over-complicated in recent years IMO and isn't explicitly designed to work well with HTMX or ASGI. Using it with htpy and htmx is a totally reasonable option for folks that already know Django well, but it's not going to be quite the same thing as using FastHTML.
Have you written about the drawbacks of Django anywhere? I can’t decide where I land on this kind of stuff.
On the one hand, Django’s not “fully async”, etc.
On the other hand, someone built Instagram with it, and it hit the right balance of structure and flexibility that they could modify it’s pluggable parts to meet their needs, and eventually it’s perhaps nothing but the Django request/response cycle with everything else custom built. But to me that’s a wildly positive success story. Working as intended.
And you know, the trope of “you don’t have any users”, funny because it’s (usually) true. Like async/etc doesn’t matter when you need to serve 1 request per minute.
On the one hand, Django’s not “fully async”, etc.
On the other hand, someone built Instagram with it, and it hit the right balance of structure and flexibility that they could modify it’s pluggable parts to meet their needs, and eventually it’s perhaps nothing but the Django request/response cycle with everything else custom built. But to me that’s a wildly positive success story. Working as intended.
And you know, the trope of “you don’t have any users”, funny because it’s (usually) true. Like async/etc doesn’t matter when you need to serve 1 request per minute.
will it compatible with pypy now or in future to speed it up ?
Cool domain, fastHT.ML
Fantastic design!
This is so cool
This is the future, right after React.
IS It work in termux?
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 framework and even more: HTML, XML, RSS, SVG generation, even robots.txt generation as a silly example. I use it with Django and HTMX but it doesn't have an opinion about anything how should you use it. If you pass a Component to Django HttpResponse instead of a string or template, it just works.
I guess I should just write some documentation and release it before the 6th one of these appears :) so we ALL can collaborate with the same API on a bunch of Component sets like Twitter Bootstrap or Material components!
https://github.com/kissgyorgy/compone
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 framework and even more: HTML, XML, RSS, SVG generation, even robots.txt generation as a silly example. I use it with Django and HTMX but it doesn't have an opinion about anything how should you use it. If you pass a Component to Django HttpResponse instead of a string or template, it just works.
I guess I should just write some documentation and release it before the 6th one of these appears :) so we ALL can collaborate with the same API on a bunch of Component sets like Twitter Bootstrap or Material components!
https://github.com/kissgyorgy/compone
This sounds exactly like what I was looking for. I settled on htbuilder[1], but it certainly does not feel right as it requires a fair bit of wrangling in order to fit with Django.
I'd love to help you with documentation and such; hit me up at [email protected] if you'd like a partner(:
[1] https://github.com/tvst/htbuilder
EDIT: Actually, scrolling further in this thread, it looks like https://htpy.dev fits the bill? It has explicit integration with Django, which is what I was looking for.
I'd love to help you with documentation and such; hit me up at [email protected] if you'd like a partner(:
[1] https://github.com/tvst/htbuilder
EDIT: Actually, scrolling further in this thread, it looks like https://htpy.dev fits the bill? It has explicit integration with Django, which is what I was looking for.
Looking over your examples makes me think of sxml
https://en.wikipedia.org/wiki/SXML
https://en.wikipedia.org/wiki/SXML
That looks super interesting, congratulations. I would suggest you do write lots of documentation, a more elaborate readme on github and generally push your approach. As it stands, the repo looks somewhat unfinished and inactive, unlikely to make people spend their time and energy digging into it. I hope you drive it forward!
You are totally right, but I'm not actively working on it, because core (the base library) is basically ready and I'm working on a project in production which is exclusively using it [1]. The site is using htmx, feels snappy overall and I'm even generating static parts with it (e.g. the home page).
[1]: https://findendurancecoach.com/
[1]: https://findendurancecoach.com/
> Frameworks like this are really next-gen,
How is this next-gen? It looks exactly like all current frameworks in various languages, but with more default functionality thrown in.
Something like Postgrest would, to me, be "next-gen".
I have a private/proprietary backend-based framework that I used for a few clients that has both less "magic" while simultaneously allowing more functionality with even less code than any of the examples in any current framework, including this one.
I find it hard to get impressed these days.
How is this next-gen? It looks exactly like all current frameworks in various languages, but with more default functionality thrown in.
Something like Postgrest would, to me, be "next-gen".
I have a private/proprietary backend-based framework that I used for a few clients that has both less "magic" while simultaneously allowing more functionality with even less code than any of the examples in any current framework, including this one.
I find it hard to get impressed these days.
Next gen in Python land. Nobody implemented a component framework properly yet.
Most Python web apps implement WSGI, and so can absolutely be used together. Just mount them on top of each other. Wanna use both Flask 'n Django? Go for it! Unfortunately, that's the backend story.
On the frontend, things are a little less consistent.
On the frontend, things are a little less consistent.
This is fantastic and exactly what I wanted! A very neat idea about how you separate attributes and children.
How does the performance side of this thing look like?
How does the performance side of this thing look like?
I did not measure performance yet, but I definitely will!
My hunch is that it's faster than any templating library, because those are compiling from their own DSL, but it's completely ommitted here.
Another Python framework agnostic project is ReactPy. [0]
[0]: https://github.com/reactive-python/reactpy
[0]: https://github.com/reactive-python/reactpy
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.
Streamlit is fine for the first 20 minutes and then it sucks. I switched to NiceGUI and couldn't have been happier for my internal crud app with very specific ui/interactivity requirements.
That's why I like django-ninja: it's django with fastapi like features.
But it's fully django compact.
But it's fully django compact.
At the risk of being ignorant/heretical: Why use this over "raw" templating (e.g. jinja2) at this point?
I’ve switched back to writing server-based code from writing React SPA. Text-based templates (I use jinja2) is my least favorite part of that.
It’s modeled after Django templates circa 2005, and that was designed with an idea that designers will write those templates, that they are not code.
I’m doing all this for 18 years, it was always programmers who wrote template code.
Why then we have such things as filters, in addition to functions? Untyped macros. Formatting template code is a struggle. Include tags are the worst.
The only thing I fear with regard to all these component libraries is performance. I actually wrote a PoC myself for such a library, but didn’t bring it to production quality.
It’s modeled after Django templates circa 2005, and that was designed with an idea that designers will write those templates, that they are not code.
I’m doing all this for 18 years, it was always programmers who wrote template code.
Why then we have such things as filters, in addition to functions? Untyped macros. Formatting template code is a struggle. Include tags are the worst.
The only thing I fear with regard to all these component libraries is performance. I actually wrote a PoC myself for such a library, but didn’t bring it to production quality.
My suggestion is to just try writing React for a week or two and experience the component based development. You never want to go back to templates again.
I've been writing react for years, and going back to templates, I wish I could never have to write a react rendering function again.
Components are overrated.
Their best feature is that they help build a fantastic ecosystem, which is the biggest react strength.
But for your own website?
Their cons and pros balance each other out, and all that is left is the terrible API that react exposes.
Eventually, you gain locally some reusability (provided you actually need it in your project, because there are not that many components that need reusability, and even less that couldn't be a template tag in django), but every single dev writes react code differently.
So you get a heterogeneous mess anyway.
My last SPA project (in vue), we had one component that was worth making reusable.
One. For a month and a half of work.
Turns out vanilla functions are quite reusable themselves already.
Components are overrated.
Their best feature is that they help build a fantastic ecosystem, which is the biggest react strength.
But for your own website?
Their cons and pros balance each other out, and all that is left is the terrible API that react exposes.
Eventually, you gain locally some reusability (provided you actually need it in your project, because there are not that many components that need reusability, and even less that couldn't be a template tag in django), but every single dev writes react code differently.
So you get a heterogeneous mess anyway.
My last SPA project (in vue), we had one component that was worth making reusable.
One. For a month and a half of work.
Turns out vanilla functions are quite reusable themselves already.
I love the idea of components. (been doing variations of it since 1999, starting with custom tags in ColdFusion) What I don't love is giving over to "full stack" development to gain the advantage of components (fortunately, there's options like server-side components, even when not using a JS-based framework, as well as partial-stack options like Inertia JS)
[deleted]
Dude - Fastmail was the shit back in the day
I have no interest on magical sugary functions that make something quick. The modern reactive concept doesn't impress me. What I want is a very well thought-out set of tools that allow me to do anything and everything, because I will be refactoring and fine-tuning my functions a lot, and I will do it my own way, I don't need some automatic shortcut which is not going to help me if I can't modify its full functionality. (I don't mind decorators if they make sense)
I want to see how I can manually wire and create anything I want, is what I'm saying and this demo felt like it capitalized on how fast you can do very simple functionality with a couple of functions, which was a let down.
I want to see how I can route (GET/POST), create a database schema, use the database, use CSS (this is very important) yet what I saw was a simple calls to some database store, and no CSS examples. And "a single python file" sounds unrealistic since anything complex enough is going to be split into a series of files. Maybe I'm not the target audience.
I felt very comfortable using Flask recently because it allowed me to do anything I needed.
I do like the idea of building and manipulating HTML elements through python, so hopefully something good comes out of this.
I want to see how I can manually wire and create anything I want, is what I'm saying and this demo felt like it capitalized on how fast you can do very simple functionality with a couple of functions, which was a let down.
I want to see how I can route (GET/POST), create a database schema, use the database, use CSS (this is very important) yet what I saw was a simple calls to some database store, and no CSS examples. And "a single python file" sounds unrealistic since anything complex enough is going to be split into a series of files. Maybe I'm not the target audience.
I felt very comfortable using Flask recently because it allowed me to do anything I needed.
I do like the idea of building and manipulating HTML elements through python, so hopefully something good comes out of this.
[deleted]
I have been reading about these kinds of projects for some time, and even prototyped my own a while back, but one question that keeps popping up is - all these python abstractions over how html and js and dom interact tend to be extremely leaky. So, as soon as you go beyond the simple todo example, you need to manage BOTH the standard browser model and the abstraction model in your head, and all the funny ways in which they interact. Do these kinds of libraries prove useful for people beyond their authors (who have a good mental model of a framework in their head anyway because they are developing it)?
This kind of framework helps to optimize a bit for returning hypertext (iow HTML snippets) rather than leveraging a frontend system that only interfaces with the backend via an API. From that perspective, you need to be able to send HTML snippets precisely and manage more URLs that provide the snippets. React already has a pretty strong abstraction around HTML with JSX that has been generally morphed into web components. Writing the HTML components on the server using a library that maintains valid HTML is convenient, and it also means you can deploy an application without having to bundle a bunch of template files.
I will say I do think some opinions on how to structure URLs to return snippets might be valuable. Some of these frameworks leverage headers htmx sends to use just part of the page, but I think it is easier to just have individual URLs for many use cases. I've used Go and Templ in a similar fashion and one benefit with Templ is that the snippets are effectively functions, so returning the specific section and passing args is reasonably natural when breaking something out of a page.
Overall though, the goal is to avoid duplicating your data model and abstractions in the UI in favor of relying better networks, faster browsers, and HTML improvements to create interesting interfaces with simpler code.
I will say I do think some opinions on how to structure URLs to return snippets might be valuable. Some of these frameworks leverage headers htmx sends to use just part of the page, but I think it is easier to just have individual URLs for many use cases. I've used Go and Templ in a similar fashion and one benefit with Templ is that the snippets are effectively functions, so returning the specific section and passing args is reasonably natural when breaking something out of a page.
Overall though, the goal is to avoid duplicating your data model and abstractions in the UI in favor of relying better networks, faster browsers, and HTML improvements to create interesting interfaces with simpler code.
[deleted]
We have 75 comments and no one has mentioned the awesome domain name? c'mon :D
really excited for this project. I hope it catches on. It has some really nice ideas in it, like all the stuff jeremy does!
really excited for this project. I hope it catches on. It has some really nice ideas in it, like all the stuff jeremy does!
I'm not sure if I'm alone in this, but I feel domains like this are a bit user hostile. It's cute but harder to commit to memory and it reads like fastht dot ml
Fast Hyper-Threaded Machine Learning
After creating fastmail.fm in 1999, and then fast.ai, this felt like the right name and domain to me! :D
It's a free domain from freenom and TLD for Mali :D
[deleted]
<!doctype html>
</!doctype>
No. It's not in the spec, and in almost 30 years of web development, this might be the first time I've ever seen someone use a closing tag for it.
It's also not a tag, but an SGML (?) directive (specifically a https://en.wikipedia.org/wiki/Document_type_definition) and so it is in fact invalid to produce a closing tag.
HTML5's HTML syntax is no longer SGML-based. It's still invalid but no longer because of anything related to SGML; now it's simply because the HTML5 spec says so.
[deleted]
People do all kinds of crazy useless things just in order not to do it the proper way in PHP.
While I've been a PHP hater most of my life, as I get older I start appreciating its simplicity. I still think it's a terrible language, but I would not be surprised if it went through a revival period simply because everything else has so much more unneeded complexity.
I am really interested in the comparison of PHP vs. the hundreds of templating engines used in other languages.
PHP security issues (which may have been fixed in recent versions for all I know!) aside, is there anything that these modern frameworks can do that PHP cannot?
If one argues by corporate authority as done elsewhere in this thread. Facebook used PHP, so clearly it scales (probably much better than Python).
If anyone knows a resource (including books) that explores this topic in depth, I'd very much appreciate a link.
PHP security issues (which may have been fixed in recent versions for all I know!) aside, is there anything that these modern frameworks can do that PHP cannot?
If one argues by corporate authority as done elsewhere in this thread. Facebook used PHP, so clearly it scales (probably much better than Python).
If anyone knows a resource (including books) that explores this topic in depth, I'd very much appreciate a link.
[deleted]
[deleted]
[deleted]
[deleted]
[deleted]
This is not the way to do html with python.
You can do HTML even with exel;)
Python just parsing data and injecting it back. That all up to you
Python just parsing data and injecting it back. That all up to you
That's like, your opinion, dude.
Maybe expand a bit on why it's not? Otherwise this is a useless troll comment.
Maybe expand a bit on why it's not? Otherwise this is a useless troll comment.
I wrote my first web app ~30 years ago, and have built some pretty big projects, including founding fastmail (written in Perl) and leading the first major production version of Kaggle (written in C#). Frankly, I've enjoyed creating web apps less and less over the last few years. So I decided to try to create something that I'd personally enjoy using. I like coding with Python, it's got a great ecosystem, and deployments like Dropbox and Instagram show that it can scale right up.
FastHTML brings together Python, hypermedia based apps with HTMX, the powerful and flexible ASGI/Uvicorn/Starlette trio, a new Python component system called FastTag (FT -- based on many similar projects from the functional programming world), an API design inspired by FastAPI, and a few more bits and pieces into something I've now written around a dozen apps with. I'm really loving it!
I hope some of you get a chance to try it out -- let me know what you think.