121–130 of 160 posts
Building a framework on a non-async foundation (flask) in 2025 is bizarre. The only way to scale a flask API is to use gevent, which is just problems waiting to happen. Asyncio is just better, safer and has been adopted by the industry.
Building a framework on a non-async foundation (flask) in 2025 is bizarre. The only way to scale a flask API is to use gevent, which is just problems waiting to happen. Asyncio is just better, safer and has been adopted by the industry.
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.
Earlier quoted context omitted.
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 al…
Flask is missing... pydantic, dependency injection, openapi, swagger, real async.
Hello, author of hyperflask here. I'm happy to finally announce this project as I've been working on it for quite some time. I made an announcement post here: https://hyperflask.dev/blog/2025/10/14/launch-annoncement/ I love to hear feedback!
Earlier quoted context omitted.
But what really defines client side state? If the latency was good enough you'd store everything on the server. It doesn't force you to give them the same state when they re-open your app, you can key state by session and tabid if you want.
> But what really defines client side state? You define it. And the client defines it. > If the latency was good enough It's never good enough. Worse, it can abruptly become not good enough. And you have to code additional loading states or optimistic UI for every action that is now performed on the server and takes longer than some time. > It doesn't force you to give them the same state when they re-open your app T…
Millions of users hitting the same server at the same time is a very nice problem to have. I've handled 40000r/s (script kiddies are gonna script) with 500+ concurrent users in those demos on a 5$ VPS. With all the scroll position/tab state etc not just going to the server, but to a sqlite db.
Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that you can throttle/batch. You only push view data when the server decides to. In my case that's every 100ms (because it's a 5$ server), so all changes in that time get batched.
>Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace. Not only does this make your program safer by keeping the control flow of your program under your control, it also improves performance for the same reason (you get to batch, instead of context switching on every event). Additionally, this makes it easier to maintain bounds on work done per time period.
- tiger style https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases. I like to add a pop animation on the client to register something has happened, but in a lot of situations you don't even need that.
Earlier quoted context omitted.
You mean I should be storing the state of a popup menu in my database?
Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend): https://checkboxes.andersmurphy.com
> You mean I should be storing the state of a popup menu in my database?
Earlier quoted context omitted.
sqlorm is a new orm developed as part of hyperflask. I use sqlalchemy daily, it's an amazing library, but I wanted something more lightweight and straightforward for this project. I find the unit of work pattern cumbersome
> but I wanted something more lightweight it's called "sqlalchemy core" https://docs.sqlalchemy.org/en/20/core/
Although nobody seems to use the term ORM correctly any more so it's entirely possible that neither is peewee or sqlorm.
The story behind why ORM is nowadays no longer used correctly is kind of funny:
1. Query generator sounds primitive, like cavemen banging rocks together. Software engineers are scared of primitive technologies because it makes their CVs look bad.
2. Actual ORMs attempt to present a relational database as if it was a graph or document database. This fundamentally requires a translation which cannot be made performant automatically and often requires very careful work to make performant (which is a massive source of abstraction leaks in real ORMs). People don't realise the performance hit until they've written a chunk of their application and start getting users.
3. Once enough people encountered this problem, they decided to "improve" ORMs by writing new "ORMs" which "avoid" this problem by just not actually doing any of the heavy mapping. i.e. They're the re-invention of a query generator.
Earlier quoted context omitted.
Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend): https://checkboxes.andersmurphy.com
300ms of latency to click a checkbox is a horrible experience, though.
Earlier quoted context omitted.
> But what really defines client side state? You define it. And the client defines it. > If the latency was good enough It's never good enough. Worse, it can abruptly become not good enough. And you have to code additional loading states or optimistic UI for every action that is now performed on the server and takes longer than some time. > It doesn't force you to give them the same state when they re-open your app T…
Not if you care about state being consistent between all clients. Say you want a minimap, or a presence indicator, now the server needs to know these things. Same the minute you want backend analytics. Millions of users hitting the same server at the same time is a very nice problem to have. I've handled 40000r/s (script kiddies are gonna script) with 500+ concurrent users in those demos on a 5$ VPS. With all the scr…
No idea what you mean
> Say you want a minimap, or a presence indicator, now
I struggle to see where I said that you have to have everything and anything on the client.
> Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that
That you have to actually code, create, and maintain.
> Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace.
No idea what this has to do with anything I wrote
> You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases.
Again, this hinges on the childish belief that the network is always there, is always fast, and is always low-latency.
And none of these answer the question of why you would want to save "I showed a modal on the client" in a backend database.