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 of the quirks (like the pragmatic but weird-feeling 12 virtual columns, for example). I look forward to re-implementing some existing projects for comparison.
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.
I found it very difficult to do things like rich text boxes for a ChatGPT clone I was writing aimed at being child friendly. Ended up giving up when it became a bit spaghetti-ish and after the documentation stopped being useful beyond hello world apps.
Cofounder of Pynecone here - thanks for the feedback. We’re prioritizing improving our docs and example apps in the upcoming weeks and will have a ChatGPT clone example. Definitely want to improve the onboarding experience and showcase these more complex use cases.
That’s awesome - it looks like a really interesting project. Would you be able to address the specific criticism raised by parent, on rich text boxes? Is this a case of a documentation shortfall, or something more fundamental?
We want to support any UI feature that you can build with React/NextJS. We will expand our core to include components like rich text inputs but we also have a way to wrap any React library so you're not locked into the components we provide: https://pynecone.io/docs/advanced-guide/wrapping-react
Hey! Don't take my comment as too negative, I do like the idea & enjoyed using Pynecone right to the point I got stuck. Best of luck improving it, I'll definitely circle back in the future
My projects are simple dashboards for internal use so I prioritize ugly and functional over aesthetic. technical verdicts from someone with more UI experience/affinity would likely help a lot more than my opinion.
"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.
While I applaud the attempt, stating it's "performant" is misleading, as any calculation that could happen client side means a call to the network with Pynecone.
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.
> 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!
Anvil has been great. I'm a happy subscriber. As someone requested above for Pynecone, could Anvil also make a tutorial for creating ChatGPT clone (UI wrapper for ChatGPT/gpt-4) using Anvil?
Agree a little different approaches, we found many developers wanted to stick with a 100% code approach and avoid the constraints of using an online drag and drop builder like retool/anvil etc. Instead opting to stick a traditional code tech stack that provides benefits like easier version control with ui and reviews with larger teams. Where as with a low code tool you are now forced to develop on the ui platform and locked in by the vendor.
We have also had some users build some fairly large Pynecone apps including our whole website built in our own framework.
Oh, yeah - "text in a Git repository" is table stakes for developers. Ditto being open source to avoid lock-in. (Which is why Anvil has both! You can check your code out, edit in VS code, and host locally.) But if you want a visual UI editor, you gotta have the tooling somewhere...
Aside: I get grouchy about the term "low-code", mostly because it's almost always a lie (you're going to need the code, and most "low-code" systems just hide how much that's going to hurt - which is why we put the code front and centre), and it causes people to lump Anvil in with, eg, Retool rather than, eg, Pynecone/Viola/Beeware...but this is definitely getting off topic ;)
Interested to hear how your scale-up/B2C users deal with the round-trip delays - I guess that's less of a deal with websites than interactive apps? (Should probably have grabbed you at PyCon to ask, but we were both pinned down pretty hard! I did manage to wave at you though, I think...)
Will be improved in the future as we start to offload client side actions with wasm, starting to do this but the python wasm ecosystem is still maturing
slight aside, but it's refreshingly pleasant to see a cordial discussion between representatives of two competing aproaches. HN is better than some other sites, but there's still a fair bit of polarised "my choice is right and so yours is wrong".
I didn't know about either Pynecone or Anvil, and have a side project for a friend that might be well suited to one/both. So I'm both more enlightened on options, and more predisposed to both given the positive dialogue here. Thanks for both.
There are a few options I’ve seen for “liveview” type approaches in Python, see e.g. reactpy and streamlit. (Assuming you are not looking specifically for something that transpiles to JS.)
For a full-stack framework I'd take something Typescript-based now, because TS has better static typing than Python currently (with all due respect to mypy), and the async story of JS is much easier than that of Python. And also the JIT.
But it's interesting to see that Python is able to advance so much in this direction; I hope it will continue.
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.
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
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.
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.
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.
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.
> Now everyone can work across the full-stack.
>
> With Pynecone every engineer can work across the whole stack allowing for a more efficient and productive workflow.
I assume what is meant is that having a single language is allowing people who know Python to work "full stack". I don't believe in that argument
1. JS has brought you that since Node.
2. You can transpile Python to JS, the fact that it's the same language is only a marginal gain. Certainly you'll skip the few quirks of JS, but front end dev is arguably another paradigm from back-end, using the same language is not the biggest hurdle to learning front end dev.
3. This is proposing to learn a specific and niche framework that will probably not used in your next project or job, rather than spending similar time learning the proper, mainstream tools of front-end.
Awesome! Now that I've seen this framework, it tempts me though...
I have this personal side project which in the wee days of me career I wrote in CherryPy; I love Python and have been exploring frameworks. I didn't really get a lot written in it because eventually I realized the project is frontend-heavy and I was never in the mood to write the JS for it.
Recently I had the need for this side project again so I thought, why not rewrite it using a framework that would avoid me having to deal with the madness that is the Node.js ecosystem? For one reason or another I ended up with Vaadin.
I've nothing against Java. If it works, it works. I got over the initial bump that is Spring and I got a "core" backend running, with tests too. My grievance with it is the usual Java fault of needing to write a lot of boilerplate just to shoehorn my app into the framework's philosophy. (Man, part of my initial consideration was even the tooling, editor, autocomplete, and all that, because damn me if I try Spring without these modern conveniences!)
And this...this is all the things that attracted me to Vaadin---but in Python! I am so tempted to rewrite again. My experience and your documentation should make this a two hour job, right? Right?
No, get the idea working first. Talk to customers... pivot... repeat. After finding a fit and portions are too slow look into Cython or offload to services in golang, etc.
For this software if you change to any language it will still use the same architecture and technology, setup a http server and generate HTML and some client JS code to run on browser, just syntax difference or maybe performance. Curious what exactly is the part you think Python is dreadful at that this software contains? You can definitely say there are better performance language but I'm curious about if other factors.
> Curious what exactly is the part you think Python is dreadful at
• A large memory foot print
▪ Inefficient execution
That's two out of the top of my head
I have been badly burnt by Mailman3, pure Python, pretty front end, 2G needed to install it. That cost me real money. The difference between a cheap, and a very cheap, VPS
There are a lot of success stories, big and small, with apps built with Python, Ruby, PHP.
So, if you are already familiar with the language and build something now, go with it.
On the other hand, also be aware of the other side of the coin.
It'll probably be much more productive to build long lived applications in a better language more suited to it.
I've built 30+ apps and wrote hundreds of thousands of lines of code with Python for ~10 years.
I've switched to C#/.NET now, and couldn't be happier. It allows me to almost all the dynamic things I had done in Python, in a type safe way, thus making everything easier.
I wish the modern, cross-platform .NET existing when I've started my journey in Python.
People also said similar things when Node.js crossed backed then the boundaries of our imagination. Nonetheless i agree that it can lead to genuine problems once it gets complex enough.
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.
However whenever I see such good abstraction I always worry that when my project gets big and complicated there will be things which are not possible to do, and at that point switching will be super expensive.
After testing it a bit, why the f** is this so wasteful? Just starting the base helloworld-project is already wasting 30% CPU on idle. And apparently is running multiple servers, so I'm not even sure whether this is the whole story. How do they except anyone do use this for real?
Just a heads up, on mobile Firefox (Android) I opened the increment/decrement example and after pressing any of the buttons there is a 500ms very long lag.
I suppose this is not expected
Edit: nevermind, its expected in slow connection due to a client-erver round-trip
Looking at some of the examples in the docs [1]. Seems very odd that the mixin class they provided essentially lets you use bounded/instance variables and methods as class attributes and class method. Nevertheless, this seems very promising and I'm happy someone spent time on this
It's not bad if your server isn't far away and you can compromise a bit on UX. A great tool if you need to quickly whip up a UI for some Python code (with more control than those machine learning-focused frameworks give you).
Sadly it's apparently incompatible with SQLAlchemy 2.0, so I can't use it.
Looks awesome! Is there a document to learn more about how it works really work under the hood ? I took a look at the source code but have yet to dive deep yet.
i never undestood how python can make .exe and other os supported binaries with gui?
I tried one (forgot the name) and it looked like shit. Nothing like what you can get with vue+bootstarp or quasar + electron
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 of the quirks (like the pragmatic but weird-feeling 12 virtual columns, for example). I look forward to re-implementing some existing projects for comparison.