yo, i'm the htmx guy

this looks awesome!

A colleague built an internal app on flask/htmx/sqlalchemy and had excellent results but couldn't get approval to open source it. Excited to see your work!

Why sqlorm and not sqlalchemy? I've been out of the Python dev space for a long time (maybe it shows), but I thought everyone used SQLAlchemy, and I never heard off sqlorm.

great to see a new framework embrace HTMX ... HTMX is inspiring many new green shoots as alternatives to JS & React

I am sure that many will like the blend of Python and Flask - and with server side HTMX I know that components are a key aspect

plus you website doesn't hurt my eyes like FastHTML

---

here's my comparison to https://harcstack.org

  Language
    Python vs. Raku
  Web framework
    Flask vs. Cro
  ORM
    ?? vs. Red
  Components
    both
  HTML
    template vs. functional
  CSS
    DaisyUI/Tailwind/Bootstrap vs. Pico

just out of curiosity: did you consider unpoly.js or alpine-ajax instead of htmx? If yes, why did you choose htmx instead of others?

excited to try out. flask <> coding agents work really well together.

As a big fan of python and htmx... I'm loving it!

Would check it out asap!

This looks awesome. I’m building an app in pure Flask using Tailwind + DaisyUI + Bootstrap Icons which looks to be the exact stack you’ve gone with. Though admittedly I am just writing raw JavaScript without a JS framework.

yeah fastapi + htmx is very effective.

> The main problem is that the state of your frontend application is in the URL.

There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL.

It's not a black or white, one actually has to think about what the application must achieve.

> modern UI where you might have many different zones, widgets, popups, etc.

This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day.

> React / Vue that all provide their version of a state store that can hold the state

And many times they duplicate what's already available server-side.

Hypermedia can do all of that fine. You don't need to stick it all in the url. Using simple session and cookie/tab id state can be shared and or isolated between tabs. Then just do a lookup in your backend database.

Hypermedia is also way better for realtime and multiplayer.

If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.

It's a dead end for your use case, let's be very clear about that.

And it's funny that you think anything about React and/or Vue is 'trivial'.

React and Vue does not solve anything users expect.

maybe for very complex use cases, but I'm using htmx(and unpoly) + alpinejs + localstorage and still didn't find a case that doesn't fit.

I thought the same but moving to fastapi the thing I missed most from Django is the applications that make up a django project.

Having migrations, static files and templates for one aspect of a project all grouped together is so useful and I didn't realise until I didn't have it.

There is Flask-Admin but it's more bare bone than Django Admin. I plan to tackle the problem in the future.

I love FastHTML!

Next stack I wanna try (right now I'm on FastAPI + Jinja2 + HTMX).

Run in console:

new WarpSpeed("warpdrive", { "speed": 20, "speedAdjFactor": 0.03, "density": 2, "shape": "circle", "warpEffect": true, "warpEffectLength": 5, "depthFade": true, "starSize": 3, "backgroundColor": "hsl(224,15%,14%)", "starColor": "#FFFFFF" });

You mean like this one? https://data-star.dev/

https://nova.app/ still the best I've seen.

The framework is composed from many extensions indeed. You can use them independently though!

The component system is not fully independent because it depends on multiple other extensions but it mostly is as this extension: https://github.com/hyperflask/flask-super-macros

On the GitHub organization there is a list of all the extensions that are built as part of the project: https://github.com/hyperflask

Thanks ! I've introduced a lot of stuff with this project and I'm glad someone noticed :D

I've also submitted SQLORM on HN if it's of interest to others: https://news.ycombinator.com/item?id=45607688

It's in sync with the Locality of Behavior [0] principle that htmx follows.

It's inspired by Astro Pages [1] which are the same thing in the javascript world. I really liked the developer experience working with them.

[0] https://htmx.org/essays/locality-of-behaviour/ [1] https://docs.astro.build/fr/basics/astro-pages/

I think you lack perspective - there is still a lot of sync code being written - I'd argue probably most deployed python is not async.

And most apps don't need crazy scale, they need simplicity.

I was surprised to use the search feature and not see Quart mentioned: https://hyperflask.dev/guides/setup/

I've been thinking about Flask and Quart pretty much interchangeably for awhile now and use Quart for Python backends. For those who aren't aware Quart is the async Flask and they share system internals, it is usually easy to use something created for Flask for Quart.

I've built SQLify with it: https://sqlify.me

This is a brand new framework.

> I wouldn’t recommend htmx for a team of more than 1 person

Why is this? Do larger teams have time for busywork that they can't fill with HTMX?

A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance.

In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic, while having negligible to zero performance improvements. Proof that most people are terrible at choosing tech stacks.

Then, AI came into the scene and people were building APIs that were essentilly front-ends to third party LLM APIs. For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation. Then people realized that can can simply access OpenAI's API instead of calling another front-end API first. But now they're already invested in FastAPI, so changing to another framework isn't going to happen.

Either way, I like FastAPI and I think Sebatian Ramirez is a great dude who knows what he wants. I have respect for a person who know how to say no. But it's unfortunate that people believe that Flask is irrelevant just because FastAPI exists.

After using both Flask and FastAPI extensively I can attest that Flask is the better technology. Flask is extremely stable and has solid organization around them via Pallets. This is a great benefit as they are keeping the ecosystem moving forward and stable.

https://palletsprojects.com/

Versus FastAPI which is lead by a single maintainer which you can search back on HN about opinions on how he's led things.

Flask also has at time of writing only 5 open issues and 6 open PRs, while FastAPI has over 150 PRs open and 40 pages(!) of discussions (which I believe they converted most of their issues to discussions).

Lastly on the technical side, I found Flasks threaded model with a global request context to be really simple to reason about. I'm not totally sold on async Python anymore and encountered odd memory leaks in FastAPI when trying to use it.

But this is about html rather than API endpoints; Flask seems like a much more appropriate choice.

Is FastAPI still (micro)managed by one person?