Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pynecone – Performant, customizable web apps in pure Python

pynecone.io

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Pynecone – Performant, customizable web apps in pure Python

#41

Post by abraxas »

I played with it and subsequently turned my back on it in favor of alpine.js and some vanilla JavaScript to handle client state with Flask on the back end.

The reason I gave up on Pynecone is that these things transpile to other already high abstraction frameworks like React. This is all good and well until something goes wrong and you now have more layers to troubleshoot. Another huge downside to this approach is that now I have to deal with two sets of build and deployment tools: python and node. And given that I have few fond memories of the node tool set from previous project, I refuse to incur this complexity unless it's absolutely unavoidable.

If someone actually built something like Pynecone that targeted html/dom/js directly instead of wrapping node/react/next I would be the first to hop on the bandwagon. Because the API is very good but the way that sausage is made ain't pretty.

Re: Pynecone – Performant, customizable web apps in pure Python

#42

Post by yamtaddle »

abraxas wrote: post #35
worik wrote: post #18

Don't. Just do not do this Python has a place in scripting Because you can, does not mean you should, build full applications with it It is a colossal waste of resources. It leads to genuine problems as it gets bigger that you will only find when you have considerable sunk costs. This is a terrible idea, it was a terrible idea in 1995 when people did this with Perl, it is a terrible idea now Use Python for what it is…

Well then, people should also stop doing that with Typescript because it's often as slow as Python and much slower than JavaScript.

> Well then, people should also stop doing that with Typescript because it's [...] much slower than JavaScript.

Wuh?

Re: Pynecone – Performant, customizable web apps in pure Python

#43

Post by picklelo »

pedrosbmartins wrote: post #38
picklelo wrote: post #16

Earlier quoted context omitted.

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.

Re: Pynecone – Performant, customizable web apps in pure Python

#45

Post by abraxas »

yamtaddle wrote: post #42
abraxas wrote: post #35

Earlier quoted context omitted.

Well then, people should also stop doing that with Typescript because it's often as slow as Python and much slower than JavaScript.

> Well then, people should also stop doing that with Typescript because it's [...] much slower than JavaScript. Wuh?

Typescript transpiles to JS with a bunch of runtime checks woven in resulting in much slower code than equivalent barebones JS. There are benchmarks that show this.

Re: Pynecone – Performant, customizable web apps in pure Python

#46

Post by anigbrowl »

emmanueloga_ wrote: post #40
anigbrowl wrote: post #2

It’s just Python. The app state is just a class. State updates are methods in the class. And the UI is a reflection of the state. It's rare to see this sort of clarity on a landing page. Even more impressed to see that it carried over into the documentation, which is excellent. I've been a fan of the plotly/Dash framework, but this looks like an exciting alternative, feeling more immediately accessible without some o…

"state is just a class" brings up so many questions though. How do you serialize state if it is "just a class"? Serializing the state is useful for all sorts of things, including debugging, reloading, and saving and loading application state. Serializing state together with some code that operates on it may be doable but sounds either complicated or brittle.

It's not that it's the best way to do it; it's just a very straightforward articulation of their design philosophy that helps a first-time visitor know what to expect and what they might like (or not) about it.

Re: Pynecone – Performant, customizable web apps in pure Python

#47

Post by meredydd »

abraxas wrote: post #41

I played with it and subsequently turned my back on it in favor of alpine.js and some vanilla JavaScript to handle client state with Flask on the back end. The reason I gave up on Pynecone is that these things transpile to other already high abstraction frameworks like React. This is all good and well until something goes wrong and you now have more layers to troubleshoot. Another huge downside to this approach is th…

> something like Pynecone that targeted html/dom/js directly instead of wrapping node/react/next

This might not be what you were imagining, but I think this js more or less what we built at https://anvil.works (I'm a founder).

Anvil's UI toolkit is built "straight on the DOM", and it's shaped like Python objects rather than going via some other React-y abstraction. This is possible because we expose the difference between client and server code - even though they're both in Python (transpiled as necessary), and you can make mostly-transparent function calls from one to the other. Contrast Pynecone, where the UI is "puppeteered" from the back end over a websocket, so every update is a round-trip. And of course, because you're writing in-browser code, the HTML/JS interop is pretty straightforward (in fact, you can import JS objects right into Python code).

There are downsides to our approach, of course - the developer needs to understand the difference between code in the browser and on the server, which can be a hurdle, and it's really neat that Pynecone apps can be a single Python file - but you don't have to round-trip every UI update to the server, and we've seen people have scaled up to some pretty big apps with Anvil!

Re: Pynecone – Performant, customizable web apps in pure Python

#48

Post by danudey »

thunky wrote: post #8

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.

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.

Re: Pynecone – Performant, customizable web apps in pure Python

#49

Post by barapa »

worik wrote: post #18

Don't. Just do not do this Python has a place in scripting Because you can, does not mean you should, build full applications with it It is a colossal waste of resources. It leads to genuine problems as it gets bigger that you will only find when you have considerable sunk costs. This is a terrible idea, it was a terrible idea in 1995 when people did this with Perl, it is a terrible idea now Use Python for what it is…

Don't. Just do not write this comment.

Re: Pynecone – Performant, customizable web apps in pure Python

#50

Post by JPKab »

anigbrowl wrote: post #2

It’s just Python. The app state is just a class. State updates are methods in the class. And the UI is a reflection of the state. It's rare to see this sort of clarity on a landing page. Even more impressed to see that it carried over into the documentation, which is excellent. I've been a fan of the plotly/Dash framework, but this looks like an exciting alternative, feeling more immediately accessible without some o…

Several years ago, I worked at an enterprise software company that partnered with plotly and we had to use Dash to build a Tableau-like drag and drop dashboard builder.

Dash had some amazing ideas and architecture, but suffered from too little hardcore developers working on the repo. Pynecone looks a whole lot like it was heavily inspired by Dash, but re-architected with the lessons of Dash power users.

I find the project incredibly impressive and well thought out. I cringe at transpilation into Next.js, but the target code is actually extremely clean and easy to follow/read/debug. Kudos to the team.

Post reply on HN