[kylerush]

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]

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]

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]

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]

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

[zelcon]

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