Hi all. Jeremy here -- I created this project. Thank you @bpierre for sharing it!
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.
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
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?
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
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.
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.
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.
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."
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?
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
> 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 guess it's a personal preference. I tried it, and it looked a mess in my eyes.
Take a strong tag:
Div(
"If you click '",
Strong('Accept all'),
"', we and",
A('our partners', href='/v2/partners', target='_blank'),
...
It just verbose, very Java like, and feels like a step back in a commercial setting. It's absolutely fine if you're a single developer, HTML disgusts you, and Javascript is an abomination. I know people who think that way and I know they would love it. But I'm as comfortable with JS and I am with Python (after over 25 years using both). Someone likened JSX to it - but it's not even close - JSX brings the tag structure INTO JavaScript, not takes it away, to achieve the exact opposite result of fastHTML.
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.
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.
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
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.
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.
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:
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.
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!
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.
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!
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.
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.
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'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.
228 comments
[ 3.2 ms ] story [ 218 ms ] threadI 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.
Also, because FastHTML is powered by starlette, it handles async really well. That means web sockets have been a trivial implementation.
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.
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
> 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!
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.
Maybe I'm not the ideal user, but would like to know from you who do you think this is for.
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."
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/
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.
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.
- 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.
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.
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 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.
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.
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.
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 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.
Take a strong tag:
It just verbose, very Java like, and feels like a step back in a commercial setting. It's absolutely fine if you're a single developer, HTML disgusts you, and Javascript is an abomination. I know people who think that way and I know they would love it. But I'm as comfortable with JS and I am with Python (after over 25 years using both). Someone likened JSX to it - but it's not even close - JSX brings the tag structure INTO JavaScript, not takes it away, to achieve the exact opposite result of fastHTML.I do prefer lower case callables but that’s a minor nitpick, and “htpy” and other libs can do that.
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.
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
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.
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.
i don't know many designers who can program at all? is it really needed?
You can definitely do this with FastHTML: https://h2x.answer.ai/
https://github.com/AnswerDotAI/fh-bootstrap
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'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.
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!
I'm only really familiar with Django and DRF, but if love to switch at some point.
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.
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.