HN Explorer

Launch HN: Pynecone (YC W23) – Web Apps in Pure Python

550 points by picklelo ↗ HN
Hi! We’re Nikhil and Alek, founders of Pynecone (https://pynecone.io), an open source framework to build web apps in pure Python. This can be anything from a small data science/internal app to a large multi-page web app. Once your app is built, you can deploy your app with a single command to our hosting service (coming soon!), or self-host with your preferred provider.

Our Github is: https://github.com/pynecone-io/pynecone

Python is one of the most popular programming languages in the world. Webdev is one of the most popular applications of programming. So why can’t we make full-stack web apps using just Python?

We worked in the AI/infra space and saw that even skilled engineers who wanted to make web apps but didn’t know traditional frontend tools like Javascript or React found it overwhelming and time consuming to learn. On the other hand, no code and low code solutions that save time in the development process lack the flexibility and robustness of traditional web development. These tools are great for prototyping, but they can be limiting as your app becomes more complex. We wanted to build a framework that is easy to get started with, yet flexible and powerful enough so you don’t outgrow it. Our main website is fully built with Pynecone and deployed on our hosting service.

In Pynecone, the frontend compiles down to a React/NextJS app, so from the end-user’s perspective it looks like any other website. We have 60+ built-in components ranging from forms to graphing. Components are defined as Python functions. They can be nested within each other for flexible layouts, and you can use keyword args to style them with full CSS. We also provide a way to easily wrap any existing React component. Our goal is to leverage the existing webdev ecosystem and make it accessible to Python devs.

The app state is just a class. State updates are functions in the class. And the UI is a reflection of the state. When the user opens the app, they are given a unique token and a new instance of the state. We store user state on the backend, and use Websockets to send events and state updates. When a user performs an action, such as clicking a button, an event is sent to the server with the client token and the function to handle the event. On the server side, we retrieve the user's state, execute the function to update the state, then send the updated state back to the frontend for rendering. Since Pynecone is 100% Python, you can easily integrate all your existing Python libraries into your app. In the future, we hope to leverage WebAssembly to offload many operations to the client.

Once your app is built, the next big challenge is deploying it. We’re building a single-line deploy, so you can type pc deploy and get a URL of your live app in minutes. Since we specialize in hosting a single type of app, we aim to provide a zero configuration deployment process. We are still working on releasing the hosting service, but you can sign up for its waitlist on our homepage. Alternatively, you can choose to host your app with your preferred cloud provider.

Things users have built with Pynecone so far include internal apps ranging from CRM to ML tools, UIs for LLM apps, landing pages, and personal websites. If you use Python, we would love to hear your thoughts and feedback in the comments!

327 comments

[ 3.2 ms ] story [ 233 ms ] thread
haolez
I've tested Pynecone recently and it's pretty good. I'm wondering how do you intend to create a business around this library.
picklelo
Thanks! We're building a hosting service that you can deploy your apps to. Our plan is to have a free tier for your first app, then charge for additional apps. We're still finalizing this, so would love to hear any thoughts.
WillAdams
It would be nice if there was a consideration for the app being opensource for the free tier, and also integration with Github --- it would be way cool to be able to specify that a Python file on Github could be used as the source for a free app on your site.
epoch_100
Interesting — what kind of advantages would your hosting service provide over, say, packaging the Pynecone app into a Docker container and then deploying to Fly.io/Render/GCP/Azure/etc?
[deleted]
(comment deleted)
sharemywin
It would be cool if you could create a payment component that just takes money off the top. Than anyone could build practically an unlimited amount of saas apps not worry about hosting and if they get paid you get paid.

One reason I looked at Dreamhost for hosting is they have an unlimited # of websites tier that is super cheap(sucks because it's php). If you can't build a payment component then some kind of pay as you go option would be cool.

mattgreenrocks
Second this. Would love a payment component that is very low config (e.g. set Stripe creds) where some portion is taken off the top.
margorczynski
Why should I choose this over Django or Flask?

By using Python in the frontend you mean the Python is transpiled into JS? The frontend uses templating or generates a SPA app?

neonate
> In Pynecone, the frontend compiles down to a React/NextJS app
picklelo
Yes, in Pynecone you write your frontend in Python and it's compiled to a SPA, plus a FastAPI backend server to handle state updates. Django and Flask handle the backend in Python, but you still have to use Javascript for the frontend.
Liberonostrud
SSR is included? Do you have some project that is completely build with this stack. Some real life project?
candyman
I'd love to see something like this. I'm an old computer science guy and would love to write software again. I can write plenty of functionality in Python but I don't really want to learn all the JS stuff. I just don't like it. If I could abstract away the details it would be a big help. I'm not going to build anything that requires scale or commercial performance so I can afford to compromise versus the "purity" of having your own stack.
mxuribe
> ...I'm an old computer science guy and would love to write software again. I can write plenty of functionality in Python but I don't really want to learn all the JS stuff...

Back in early 2000s, i used to be more of a front-end dev...but over the years of being more of a manager (or PM or product manager) i stepped away from daily development...So, you know, I lost my touch. But a few years ago when i tried to dip back into things again, i got turned off from needing to "learn all the JS stuff". It feels all so bloated and so much work for what to me seems minimal gain. Nowadays, i much prefer back-end development (not that iots easy, but maybe it just clicks more for me without so much JS stuff)...so when i see frameworks like this one, i get more interested.

adfm
Check out htmx.
mxuribe
Thanks for this recommendation! I had actually already added htmx to my "need to research/review" list of bookmarks... since it kept coming up in HN comments so often. Now, i guess i can move it up a tad in priority.
anakaine
I'm in exactly the same boat. Ive managed to keep inntouch with core tools on the backend, but frontend has just withered on the vine, so to speak. Learning all the JS stuff is just too hard when combined with back end, data, auth, layout, display, responsive, etc.
mxuribe
> ...when combined with back end, data, auth, layout, display, responsive, etc...

Exactly! Glad to hear I'm not alone in that boat! :-)

tomerbd
Room for another one on that boat? : -)
rlawson
Permission to come aboard?
cutler
Then you might like Rails 7 which defaults to Hotwire for a minimal-JS front-end.
anakaine
In simple terms, what does Hotwire mean / provide?
cutler
Hotwire allows you to handle front-end page/view updates and state from the server instead of relying on an SPA framework. Rails sends the minimal amount of JS to update the page without a full reload and for many use cases it's all you need. When you click a link configured with Hotwire turbolinks intercepts the call, fetches the new content from Rails and strips out everything except the body tag and its contents then uses that, with a sprinkling of JS, to update the page/view.
clocker
Have you tried Django? https://www.djangoproject.com/
scrollbar
In my experience using Django for my webapps hasn't meant I can avoid HTML and javascript. Writing templates is writing HTML, and any relatively fancy UI including charting etc. requires using javascript
8organicbits
I built a recent Django site that only used JS for analytics and to implement the close button on a modal. You can do charting using server side rendered images pretty easily, especially as SVGs (although I concede, dynamic charts client side are a better UI). CSS is harder to escape if you want things to look fancy.

Given the update latency pynecone has, I can't imagine a charting library would work well.

clocker
well, I am not sure how you can build a webapp by avoiding HTML, JS and CSS.
zimmund
It could be a nice option for small projects! The companies where I saw Django in production had terrible issues. Last.fm is one of them, I can't speak directly about the other one (aerospace). Django is good for a proof of concept but once you hit real-world requirements or your developers (inevitably unaware of the nuances of Django) start adding code and exceptions, it completely breaks down. Django was a good idea back when PHP was the only way to make "interactive" pages. Nowadays -for big/real projects- is just asking for trouble.

Long time ago -for a personal project- I used CherryPy, which is simpler and easy to learn. I don't know where it stands today, but it's another option.

luispauloml 

  > Last.fm is one of them
Can you talk a little bit more about this? What kind of issues does Last.fm have that is related to or caused by Django?
zimmund
I'll try! Last.fm started many years ago, in the early '00s (pretty much like Django!). They decided to use Django to serve their website and API. As the years went by, some issues and limitations started to show up: the API has several quirks they can't fix, the frontend -even after the redesign- is slow, and interactions feel clunky and outdated (like early AJAX attempts).

The API can't be easily modified -and sometimes XML responses have info JSON don't-, the website is stuck on being served through the framework instead of relying on a modern API... They even have an "old" and "new" database for albums, so when you query some of the albums through the API they come back with no tracks because the API is in the old codebase. It's a mess. And from my experience with Django, it feels a lot like the difficulties we had trying to scale and improve our existing code. It's not that you can't do things: it's just that Django isn't agile enough to adapt. You end up adapting to Django and its -beautiful and magical- ways.

Of course we could blame it on poor design choices, lack of Django knowledge or just call it technical debt... but I believe the framework is the major culprit.

For context: I haven't worked for last.fm, but I manage a third-party client (Open Scrobbler). I've been using their API for more than five years now, had interactions with their devs, read many replies in the API support forum and even tried to find undocumented endpoints that could help me (during this time I found some old profiles and test pages where you can even see screenshots of Django logs!).

siva7
What you described would have happened with any other framework available at that time when you make poor design choices. I don't see anything django specific there
andybak
> but I believe the framework is the major culprit.

Yet somehow the decades long popularity of Django, it's widespread usage and presumably many successful real-world deployments doesn't make you question your own belief?

oefrha
Yeah, Django is a nice option for small proof of concepts like Instagram.
jpgvm
Why is the counter demo so slow? If you are compiling to JS/React I would expect it to be close to native perf no?
caxco93
Because the logic is being processed at the backend and the data being transferred over WebSocket
jpgvm
Huh it totally is.

https://pynecone.io/docs/state/overview outlines that is the case but leaves out the detail that it's using Socket.io.

Gather if you want to use this then and have it not suck you are going to need some form of edge compute.

moffkalast
Wait, it can't generate static sites? This is gonna melt if more than a few hundred users join. Python's socket.io implementation is slow at best.
jpgvm
Something tells me it's not designed for hundreds of users and more like "Here is my data-scientist quasi-code thing and I want a web interface for it to show the non-code folk in my business unit".
moffkalast
Fair enough, that does seem like the most common use case.
hangaard
How does Pynecone differentiate from Streamlit, Panel and Dash?
picklelo
I've used some of these in the past and they're easy to get started with, but I found limitations in terms of components, styling, and performance. Since we compile down to a NextJS app, we aim to have the flexibility of traditional webdev with the ergonomics of Python
hangaard
It makes sense. These are also dashboard focused and not for general apps. I'm also reminded of ipyvuetify, but that one is even more limited, focused on widgets, works out of Jupyter notebooks but can be hacked into a dashboard using Voila. Very interesting, looking forward to trying Pynecone out one of these days.
benn0
Thanks for this. I'm interested in how you compare yourselves to dash in particular - having a quick look at the network calls, the way you interact with the back-end looks fairly similar. I've written some relatively complex apps in Dash and have been hitting some limitations there, so I'm keen to see how Pynecone might help get past some of these.
robswc
I started as a backend dev, moved to full-stack and initially didn't find JS too alluring. I've since liked JS for frontend stuff (not so much backend still). I _really_ like Dash for some things but quickly find myself hitting the boundaries of it's use cases.

I will def have to check this out and keep it on my radar. I used to work for a consulting place where we would have to spin up tons of one-off apps and this seems perfect for that.

iamcreasy
What are the edge cases of Dahs you ran into?
robswc
Basically handling user input/dynamic content becomes a bit painful. Usually this is just a case of trying to extend Dash beyond what it was designed to do though.

Say for example, you have Model A on a server which has parameters X, Y and Z.

To load Model A in Dash is easy enough. To load its parameters as inputs with all those callbacks and imports becomes a bit messy. I've found react to just be better for that, at the end of the day.

riemannzeta
Your ideas seem really cool. I'm sad that you chose a name so close to another great startup that does vector databases and search. https://www.pinecone.io/

You're headed into a place where some customers may confuse you.

dbish
Agreed. Maybe I’m too focused on ML, but my first thought was the vector db. Cool idea though. Personally I use flask/quart to write the backend in Python but still end up writing a lot of JavaScript so this could be fun to use for prototyping quickly. I’ll have to play with it to see how it handles the client stuff like canvas drawing, or any of the client/server comms needed like using websockets.
digdugdirk
How does Pynecone compare to Flet? I've played with the flet framework and it seems to have a ton of potential.
apetuskey
Pynecone is specifically designed for web apps and I think it does better on more complex, larger web apps. This can be seen in Pynecone's main website being made in Pynecone and while Flet's website is made in JS not Flet. Both are good frameworks and Flet has advantages of creating mobile/desktop apps because it compiles down to flutter while Pynecone is great for web because it compiles down to nextjs/react frontend.
sidcool
Congrats on launching. Looking forward to try it.
[deleted]
(comment deleted)
[deleted]
(comment deleted)
bpt3
Maybe this is a silly question, but why not target WASM instead of React/NextJS?
apetuskey
We definitely plan on doing this in the future to offload on the server. Unfortunately python WASM libraries aren’t at the level we would need yet.
bpt3
Thanks for the answer. Maybe it would have been better for me to ask if you are planning to improve the python WASM libraries yourself or are you going to wait for the existing community to get them to the point where they're usable for a project like this?
apetuskey
Both, hopefully we will have some time to help contribute.
kamikaz1k
It took me a bunch of iterations to figure out the value prop, but hmm...it's actually pretty good.

I can see all the SwiftUI[0] inspiration in how to make compositions, instead of relying on CSS only.

Recently there was Rux[1] which is JSX in Rails, but that is really only dealing with ergonomics oh having Components in a nice DSL.

Then there is actual deployment story. I recently made a DRF + Next App, and I spent too much time thinking about deployment. And yea, for the volume I need to server, having a single artifact deployed, with SSR, is wonderful.

How is the intellisense support? That's one of the best features of recent JS/TS frameworks on VSCode, and I don't use JetBrains IDEs. Are there JS/CSS escape hatches? Is the goal to focus on speed of deployment or, a Python DSL over JS libraries?

Good luck either way!

[0] https://developer.apple.com/xcode/swiftui/ [1] https://github.com/camertron/rux

zainhoda
I inadvertently built something similar:

https://www.pycob.com

We should talk. If your open source roadmap includes getting rid of your npm dependency then we might just migrate to Pynecone for our front-end.

zdrummond
Looks great. I am excited to play with it.

One nit, on your landing page it has a typo, missing "framework /that/ doesn't" > Never get locked into a framework doesn't support your existing tech stack.

Also, your Gallery has highly responsive SPAs, but for some reason the counter here[1] is very slow on a cold load

[1] https://pynecone.io/docs/getting-started/introduction

pplante
At first I was very skeptical, but after looking further at the examples I feel like you pretty much nailed the developer experience. I have not used this yet but I will definitely check it out.

Is there a roadmap? I see the GitHub project board is pretty focused on v0.1.20. I am curious what are your plans for client side code via wasm? I feel like that is a critical missing piece for me.

picklelo
Thanks! We're using GH Projects for everything, we will update the board with a more long-term roadmap. Python support for wasm isn't where we need it yet, but we definitely want to integrate it when it's ready.
pplante
What do you think is missing?
apetuskey
I think a big thing is the limited supported libraries as of now.
beepbooptheory
Isn't also just the fact you need to send over like 7MB of wasm for even just the standard library?
ttul
Presumably you could optimize that by analyzing a running site and stripping out the unnecessary libraries. I'm sure that will come with time.
nu11ptr
This looks cool. As someone who is CSS challenged, I have been waiting for more frameworks like this (seems similar in concept to pyjamas/vaadin/gwt). Ideally, with an even lower barrier of entry and hopefully well maintained.

EDIT: I see that the website is generated using pynecone itself. Looks very nice - cool stuff.

ShakataGaNai
Love the idea. As someone who's not trying to build The Next Big Thing (TM), but just get some stuff done - I appreciate the focus on the basics. A lot of the python webui's are heavily focused on AI/ML related stuff, which is cool - but what about those of us who just want to build an internal tool that does 5 specific things and nothing more? I try to avoid javascript if at all possible, so "python front to back" is really appealing.
unmole
> A lot of the python webui's are heavily focused on AI/ML

I'm sorry, what?

paulgb
I assume GP is referring to frameworks like Gradio (https://gradio.app/) and to a lesser extent Streamlit. Existing web UI frameworks for Python are somewhat opinionated around particular use cases, of which AI/ML is a prominent one.
mynegation
They probably meant that most of the time Web UI is implemented in Python, it is by someone who does not care much about design and complicated interactions and does not want to learn JavaScript, it is someone doing AI/ML who just wants some buttons, sliders and charts to quickly experiment. Gradio, which is similar to Pynecone, explicitly targets this audience and frameworks like Streamlit and Dash are also used by AI/ML community.
ShakataGaNai
Yes. As the other commenters said, and perhaps I should have been more explicit. When you look for python web application frameworks, there are the traditional answers like django and flask... but when you try to find something that's more "webui included" there are also a lot of newer solutions (as mentioned, like Gradio) that are specifically designed for ML. As anyone in the Python world knows, it's a super popular use case for the language these days.

I've just happened to run across a few of them recently as I was looking to see what else was new out there for easier ways to build quick and dirty web apps.

RyEgswuCsn
I like it. Reminds me of Vaadin and friends.

One question regarding the states: when do I get a new State allocated? Is it with every new tab? It's definitely not per-browser-session: if I open a new tab I seem to get a new state, while undoing a closed tab seems to recover its state with it though.

Also are old states gc'ed?

picklelo
Each new browser tab creates a new state. We use Redis to store the state and expire it after 30 minutes.
paulgb
Does that place some restrictions on what can be done with the state? e.g. does it need to be pickleable and relatively small since it needs to be loaded from redis on every event?

(Pretty cool, btw! Congrats on the launch)

picklelo
We use the `cloudpickle` library which supports most data types. We found the state size doesn't impact performance too much - our main website's state is quite large but the Redis loads stay fast.
RyEgswuCsn
Nice to know, thanks!

I am not very familiar with how modern Python wsgi servers manage states, but in Java e.g. states can be cached in the heap of the one and same JVM --- can one say that the need to use an external state store like Redis is a direct result of the underlying web server having to launch multiple Python processes in order to scale up for greater loads?

jimmySixDOF
Pyscript is a reasonably popular client side Python in the Browser solution so wondering how your positioned with regards to them ?
no_butterscotch
How performant is it?

It seems like there's a slightly visible lag in some of the interactions (button clicks) in the docs.

duderific
It's probably because the state is managed in the server rather than the client, so you will always be beholden to network latency at some level.
rudi_mk
As someone who basically focuses on infra engineering, I sometimes want to throw together quick UIs for automating stuff. Always been terrified of React/Vue. This is practically a godsend - can't wait to build some tools for myself.
mprosperi
why should I prefer Pynecone over NiceGUI?
rodja
I summarized my thoughts on this about two month ago on Reddit (https://www.reddit.com/r/Python/comments/10h6l7e/comment/j5x...). Here the recap:

- NiceGUI was initially build for accessing and controlling hardware as shown in our webcam demo); I'm not sure how it would be done with Pynecone

- NiceGUI encourages the use of standard Python (callbacks, if-statements,..), Pynecone on the other hand uses explicit State classes and provides constructs like pc.cond and pc.foreach.

- NiceGUI uses Vue/Quasar for the frontend while Pynecone is build on NextJS

- NiceGUI generates HTML/JS/CSS via templates on the fly while Pynceone has an explicit compile step; so NiceGUI can be run with normal "Python" instead of using a command like "pc"

- while both frameworks use FastAPI for the backend, in NiceGUI you can actually use your own App and simply extend it with NiceGUI to provide additional UI; Pynecone hides FastAPI which makes it harder to provide other API endpoints (for example to serve images from memory instead of files).