Why I use Flask and htmx: the framework doesn’t make the engineer

Picking a framework doesn't mean you've designed the system.

Questions come first:

• what does the product need to do?
• who uses it and how?
• who can see or change what?
• what happens when something fails?
• how much time and budget is there?

Then I pick the tools.

Adding FastAPI doesn't solve security and performance by itself. Picking Flask doesn't give me permission to ignore them.

The framework helps. But when something breaks, I'm the one in the meeting.

I like a flow I can follow: a request comes in, I do what's needed, I respond.

For a lot of interfaces I'd rather render HTML on the server and use htmx to update just the parts that change. A filtered table, a form, a task status.

A separate frontend? Only if I can explain what I gain.

That doesn't mean zero JavaScript, zero complexity or zero problems. I wish. I'd have finished a lot of things by now.

If I know a tool well, I know where to look when it breaks. That counts.

Between work, university and projects, time isn't a detail. Learning, integrating and maintaining a new technology costs.

I like studying, don't get me wrong. But these are two different things:

• learning a new technology;
• delivering work with constraints.

Sometimes they overlap. Often they don't.

Familiarity doesn't erase a technical limit. But if that limit doesn't bother the project, switching stacks isn't mandatory. The to-do list is creative enough already.

I've used FastAPI and Next.js. They're not enemies to beat to justify Flask.

"Flask vs Next.js" isn't even a complete question. Am I choosing the backend? The API? The UI? The whole app? Different decisions.

Same for Flask and Quart: if concurrency matters, I say it out loud, I don't hide it under a label.

I don't need to prove my stack always wins. I need to explain why I picked it that time.

I didn't sign a loyalty contract with Flask.

I switch if:

• there are lots of concurrent operations, persistent connections or streaming updates;
• I need to expose an API to several clients;
• the UI has a lot of logic in the browser;
• I join a team that already works another way;
• the numbers say it doesn't hold.

And at that point the question isn't "how do I defend Flask?". It's "what do I need to change?". Maybe a query, maybe config, maybe the framework. Find the problem first, then decide.

Simple doesn't mean everything in one file hoping nobody clicks two buttons at once.

You still need:

• input validation and permissions;
• protection for data and secrets;
• error and timeout handling;
• tests on what matters;
• deploys, updates, backups;
• documentation.

If I say "less complexity" and skip these, I'm not simplifying. I'm postponing problems.

And calling it tech debt doesn't make it interest-free.

"Because I like them" isn't enough of an answer. I want to be able to say:

1. what the requirements are;
2. why this solution fits;
3. what I ruled out;
4. which limits I accept;
5. how I check it works;
6. what would change my mind.

No thesis needed for every project. Just reasoning people can read.

The stack's name is the start of the explanation, not the end.

So yes, I use Flask and htmx when they make sense. Not because they're the best. Not because the rest is useless. But also because I know them, and that's worth something.

If the requirements change, so do I. What I won't do is swap tools just to feel more "professional".

The framework isn't the engineer.

And sadly, it doesn't answer client emails either.

How do you pick your stack?