In another comment, OP explains the framework uses websocket to send and get values from the python functions you declare.

The python functions are NOT executed on the frontend.

Gotcha. So the basic "structural" stuff is translated to JS but any non trivial logic remains on server?

That's my understanding.

While it is possible to run Python on the browser, the typical solutions to do so has a lot of drawbacks:

- brython (https://brython.info/) doesn't work with pip, doesn't implement full python spec, and has very limited tooling. I never could find a use for it professionally.

- pyodide (https://pyodide.org/en/stable/) is very slow to load and execute. It's mostly (but very) useful for teaching.

Plus, pynecone would have to solve the complicated problem of finding out how to delimitate what's python on the server side and on the client side, which we don't see in the API (and would complicate things for their target customer, somebody with little web dev experience).

So the decision makes sense knowing their goals and constraints.

You just have to understand the price you pay for it: anything calling a python function will cost a roundtrip. You will have to write you app with that in mind, and don't expect miracles either.

I can see myself using the product when I need to hack something quickly that is a one page interactive program. Or for some one of my clients with quants, geographers and the likes, that often needs to make a small utility available but have only knowledge of basic python.

It also could be a good companion to tauri (https://tauri.app/) to create desktop app. To me that would be even more valuable to have finally an easy way to do a decent UI in python. Because QT, WX, GTK and Tkinter are not fun at all, and the web is an amazing platform.

I just hope they are not going to eventually lock you into their hosting solution. But given that it's on github and open source, I feel confident. Plus the doc is very good, which is a sure sign of good human beings presents in the team.

Try using the example with WiFi off. The counter increments when WiFi is turned back on. OP is misleading.

That sounds like something you could write either way (update first, update after success, update in a gray or provisional-looking way until server success or error) in any react app, depending on your needs rather than a property of this framework.

Sibling comment about Websockets perhaps more interesting explanation

If the update business logic is server-side (which it probably is if it's written in Python), there's no way the front end can update without connectivity. Anything else would imply some neat but difficult transpiling of Python to JS/webasm to make that update code available in the frontend.