Hacker News Reader

Comment by thunky | Hacker News Reader

I followed the link to try the increment/decrement example/demo from the landing page (https://pynecone.io/docs/getting-started/introduction). There is probably almost a full one second delay between the time I click the "increment" button and the updated count being rendered.

Not seeing any network requests so I can't imagine why it would be so laggy.

View on HN

Clicking sends a websocket message to the backend. Which then responds with a state update message which updates the frontend react components. rhe round trip would probably take the same time with rest APIs, but you would have the ability to add some loading indicators or hints, because you'd have full control over client side rendering. You don't have that when using pynecone. It's a tradeof

Ah thanks, I see that now under the State -> Overview docs page:

All user state is stored on the server. Behind the scenes, events are sent as API calls to update the state on the server. The state delta is then sent to the frontend, which updates the UI to reflect the new state.

So it doesn't really have any client side interactivity? Thought it does from the example and wondering what magic they pulled to achieve that, they really should write this in big text up front cuz it's a pretty big factor when considering this software.

Two quick notes:

1. Looks like you posted this comment pretty close to when this was posted on HN. It's possible the server was more loaded, as I tried it myself and it wasn't very laggy (though there was a delay, it wasn't nearly the one second you experienced).

2. I copied the example code and ran it locally, and the latency is no worse than, say, an electron app. Better than most of them, to be honest.

Likely this was related to server load or network latency or both, because the core functionality seems pretty lag-free.

Yeah we’re only hosting on a single region at the moment so there can be latency depending on your location. We’re working on using edge computing to speed this up.

is there a reason why all state is in the server? what about cases where you'd want to keep client-side state, like those strictly related to UI/UX?

(very interesting project nonetheless!)

Keeping the state on the server allows us to run arbitrary Python code and libraries in our event handlers that update the state. Currently only the ui is compiled to React but the logic stays in Python.

We’re working to offload more logic to the client in the for purely UI operations like you mention, and in the future want to leverage wasm once it’s more mature.

Reply on news.ycombinator.com