return to table of content

FastHTML – Modern web applications in pure Python

kissgyorgy
19 replies
13h57m

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

port19
4 replies
8h12m

At the risk of being ignorant/heretical: Why use this over "raw" templating (e.g. jinja2) at this point?

kissgyorgy
2 replies
5h57m

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.

bdcravens
0 replies
4h33m

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)

BiteCode_dev
0 replies
5h45m

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.

murkt
0 replies
6h19m

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.

murkt
1 replies
6h17m

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?

kissgyorgy
0 replies
6h0m

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.

lelanthran
1 replies
5h46m

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.

kissgyorgy
0 replies
4h51m

Next gen in Python land. Nobody implemented a component framework properly yet.

inbetween
1 replies
12h58m

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!

kissgyorgy
0 replies
10h19m

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/

bruh2
1 replies
12h0m

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 smart.tent1246@fastmail.com 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.

barrenko
1 replies
7h46m

But I cant use this instead of jinja?

murkt
0 replies
6h25m

yes you can

shakna
0 replies
7h13m

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.

magnio
0 replies
5h37m

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.

BiteCode_dev
0 replies
5h50m

That's why I like django-ninja: it's django with fastapi like features.

But it's fully django compact.

bruce343434
13 replies
11h8m

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.

timkofu
2 replies
9h46m

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.

asdfkl
0 replies
7h48m

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.

sk11001
2 replies
10h43m

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.

bruce343434
1 replies
4h8m

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.

sk11001
0 replies
2h26m

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.

mkesper
2 replies
11h0m

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?

jillesvangurp
0 replies
9h7m

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.

bruce343434
0 replies
4h10m

You're the one starting about JS... I never said I liked JS either

pacha--
0 replies
10h40m

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

mronetwo
0 replies
10h57m

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.

awahab92
0 replies
9h49m

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.

asdfkl
0 replies
7h40m

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.

harel
11 replies
16h48m

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.

mixmastamyk
7 replies
15h46m

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.

harel
6 replies
7h19m

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.

idf00
3 replies
5h22m

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.

harel
2 replies
1h34m

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.

mixmastamyk
1 replies
43m

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.

harel
0 replies
22m

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.

pelme
0 replies
5h30m

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.

mixmastamyk
0 replies
50m

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.

jph00
1 replies
16h31m

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.

harel
0 replies
10h42m

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.

nprateem
0 replies
6h33m

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.

EternalFury
10 replies
13h32m

Python is fast compared to something? Maybe fast enough to generate HTML.

jph00
4 replies
13h5m

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

curioussavage
3 replies
11h39m

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.

nl
1 replies
9h20m

Cdn caches etc. we all know this.

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

idf00
0 replies
5h11m

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

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

Shorel
0 replies
11h11m

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

awahab92
0 replies
9h44m

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

Shorel
0 replies
11h28m

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.

throwaway89988
5 replies
11h30m

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?

jph00
3 replies
10h14m

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

throwaway89988
1 replies
9h49m

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

jph00
0 replies
9h14m

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.

vaylian
0 replies
8h29m

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

pydanny
0 replies
9h41m

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

polyrand
5 replies
13h17m

Very cool! After trying different approaches to render HTML from Python objects (including lxml, xml, etc.) I ended up liking htpy[0] the most, and the apps I built look similar to the examples in the FastHTML docs. I'll definitely try it.

One pattern I use is putting all the functions that generate HTML inside their own class. That way, I can more easily create and reuse components like:

  class Views:
      ...

  def comp1(self):
      return Div(self.header(), P("too"))
Then `self.header()` can be reused in other parts, or to return partial HTML. It also makes it easy to pass the "request" object to the class, and do conditional rendering based on it (cookies, auth, language, etc).

[0]: https://htpy.dev/

jph00
4 replies
13h10m

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

pelme
3 replies
8h57m

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!

jph00
1 replies
7h17m

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

pelme
0 replies
5h27m

Thanks, that makes sense! :)

polyrand
0 replies
5h44m

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

kylerush
5 replies
19h4m

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.

jph00
3 replies
18h55m

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

kylerush
2 replies
18h20m

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!

jph00
1 replies
17h8m

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.

synparb
0 replies
3h50m

I've added fasthtml (and its dependencies) to conda-forge, so it's available in conda/mamba now.

zelcon
0 replies
12h29m

The asyncio runtime should suspend while waiting for a LLM API response, not block

CodeCompost
5 replies
13h10m

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?

jph00
2 replies
13h0m

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.

mrweasel
0 replies
2h9m

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

CodeCompost
0 replies
12h41m

I disagree. But ... I am somebody who listens and am able to change my mind. I'll experiment with this.

vaylian
0 replies
11h25m

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.

slightwinder
0 replies
3h45m

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.

tiffanyh
4 replies
5h5m

  <!doctype html>
  </!doctype>
OT: is there a reason to open/close the DocType at the beginning of the homepage source?

bdcravens
3 replies
4h30m

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.

electroly
0 replies
3h32m

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.

rasmus1610
3 replies
11h31m

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!

goosejuice
1 replies
11h8m

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

trvz
0 replies
10h57m

Fast Hyper-Threaded Machine Learning

jph00
0 replies
10h17m

After creating fastmail.fm in 1999, and then fast.ai, this felt like the right name and domain to me! :D

jeanlucas
3 replies
18h40m

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.

jph00
2 replies
16h58m

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."
globalnode
1 replies
16h37m

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?

jph00
0 replies
16h27m

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

pokipoke
2 replies
9h14m

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

dsissitka
0 replies
7h20m

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

crabbone
0 replies
5h16m

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.

mloncode
2 replies
19h43m

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

nknealk
1 replies
19h29m

Take a look at streamlit as well. It’s got a few weird sharp edges but is really easy to pick up

pydanny
0 replies
7h56m

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.

looop101
2 replies
14h42m

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"

jph00
1 replies
14h17m

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

looop101
0 replies
13h12m

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.

jwmoz
2 replies
12h24m

This is not the way to do html with python.

mtxlan
0 replies
8h19m

You can do HTML even with exel;)

Python just parsing data and injecting it back. That all up to you

isoprophlex
0 replies
12h18m

That's like, your opinion, dude.

Maybe expand a bit on why it's not? Otherwise this is a useless troll comment.

hyuuu
2 replies
18h30m

does this integrate with django?

halfcat
1 replies
17h45m

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/

jph00
0 replies
17h2m

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.

giancarlostoro
2 replies
5h31m

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.

giancarlostoro
0 replies
7m

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.

darkteflon
2 replies
15h7m

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!

gkhartman
1 replies
14h55m

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.

simonbarker87
0 replies
11h11m

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.

cynicalsecurity
2 replies
6h54m

People do all kinds of crazy useless things just in order not to do it the proper way in PHP.

lkambnr
0 replies
3h31m

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.

ibz
0 replies
6h42m

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.

BerislavLopac
2 replies
11h2m

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.

simplecto
0 replies
10h33m

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

shawnz
0 replies
7m

Is FastAPI really "batteries included"? I would say that it's orders of magnitude lighter than Django

098799
2 replies
10h26m

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.

jph00
1 replies
10h18m

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.

098799
0 replies
10h12m

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:

    F811 redefinition of unused 'get' from line xx
from flake8 and

    error: Name "get" already defined on line xx  [no-redef]
from mypy.

vaylian
1 replies
11h54m

This looks really impressive. What is the idiomatic way to test webapps created with FastHTML?

jph00
0 replies
11h45m

We've been using Starlette's testclient, which works really well.

throwaway86586
1 replies
15h12m

Did you try Reflex.dev? Any opinions on it?

jph00
0 replies
14h13m

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!

skeledrew
1 replies
15h47m

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.

jph00
0 replies
14h19m

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!

pzo
1 replies
14h12m

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?

jph00
0 replies
12h58m

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.

lyjackal
1 replies
16h36m

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?

langcss
1 replies
13h44m

Are there any UI libraries developed for this? Or other ecosystem stuff.

jph00
0 replies
12h54m

It was just launched today so the ecosystem is just what we've built so far. I've create initial starting points for UI libs for boostrap and flowbite, and we have examples showing how to use daisyUI.

jll29
1 replies
15h3m

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.

langcss
0 replies
13h57m

Can you explain how this doesn't keep data and code separate? Not sure what you mean.

ironfootnz
1 replies
13h39m

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.

btreecat
0 replies
13h33m

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.

hopfenspergerj
1 replies
15h3m

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?

Yenrabbit
0 replies
14h55m

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.

durraniu
1 replies
14h33m

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.

jph00
0 replies
14h23m

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

chompychop
1 replies
13h7m

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.

bbminner
1 replies
3h53m

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)?

ionrock
0 replies
3h9m

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.

odie5533
0 replies
3h43m

Streamlit is for small, interactive, data-driven applets. FastHTML is for building entire websites with direct control over the HTML output.

yashbindal
0 replies
6h48m

This is so cool

wodenokoto
0 replies
14h22m

How does this compare to streamlit?

vikaspooddar001
0 replies
13h43m

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

ultrasounder
0 replies
14h13m

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.

truth_seeker
0 replies
11h33m

will it compatible with pypy now or in future to speed it up ?

sweca
0 replies
13h19m

Fantastic design!

smrt
0 replies
15h32m

Jeremy, this is awesome. I hope this catches on

sadlion
0 replies
13h42m

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.

ptero
0 replies
16h51m

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.

pietz
0 replies
5h41m

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.

ostwilkens
0 replies
7h9m

"What's the FastAPI of frontend?" - A tweet I wrote 2022 I'll give this a go for my next project!

openrisk
0 replies
9h45m

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

nothrowaways
0 replies
1h24m

Cool domain, fastHT.ML

lofaszvanitt
0 replies
6h2m

This is the future, right after React.

leke
0 replies
2h28m

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.

jph00
0 replies
19h47m

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.

jaehong747
0 replies
11h46m

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]

ianbutler
0 replies
15h25m

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.

hum3hum3
0 replies
11h3m

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.

fraugdib
0 replies
6h19m

Dude - Fastmail was the shit back in the day

crimsoneer
0 replies
14h6m

Honestly, Jeremy and the Fast.ai team really deserve some kind of award/medal of honour/general sainthood at this point.

bartron
0 replies
4h24m

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

bapetel
0 replies
6h15m

Python to Python HTML to HTML JS to JS CSS to CSS

That's it, no more complexity

ammar_x
0 replies
4h55m

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?

Yenrabbit
0 replies
16h51m

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.

Nathanael_M
0 replies
13h54m

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!

MemphisTrain
0 replies
6h4m

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.

Iacjr
0 replies
1h17m

IS It work in termux?

DonnyV
0 replies
4h2m

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.

Art9681
0 replies
36m

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.

65
0 replies
1h50m

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.

2wrist
0 replies
4h30m

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.