what's the difference between pynecone and streamlit/gradio?

[Kiris-tingna]

anyway this is an awesome project.

[Alek99]

Thanks! I think the biggest difference is that you can create real websites with Pynecone. Tools like streamlit and radio are ok for dashboard type apps but when adding complexity in terms of UI, state management, and performance they are very limited.

I think a good demonstration of this is that we created our whole website and docs in Pynecone. Streamlit/Gradio could never create their own website or anything beyond an interactive dashboard because of their inherent limitations. These limitation were some of the main reason why we decided to create Pynecone.

[Alek99]

Converting to a discussion

[gsal]

I was about to ask a similar question but regarding Streamlit, instead; which I see it was referenced above.

During my search for pure-Python web frameworks, I don't recall running into Gradio; on the other hand, it's difficult to not find Streamlit, as it is very popular.

I did put together a small app with Streamlit and I was having a bit of hard time understanding initial values to my state variables given that they indicate that after every change, the entire script gets re-run from the beginning...

...which brings me to the question I was/am going to ask.

Can somebody make an additional comment about Streamlit in regards to how they indicate it functions? That thing where Streamlit keeps re-running the entire script from the beginning, over and over, during the life of the app?
How is Pynecone differrent in that regard?

P.S. Maybe the title of this discussion could be change to ...between pynecone and gradio and streamlit

[picklelo]

We aim to be more flexible and performant than Streamlit while being as easy to use.

• Since we compile down to a NextJS app, from the end user's perspective Pynecone looks like any other website. For example, our homepage is built completely in our framework, whereas you would not make a production user-facing site with Streamlit. This includes easily making multi-page websites.
• We have the ability to wrap any React component, so we can leverage it's ecosystem to provide more components to build your app.
• In Pynecone you can style your components using any CSS, giving you full flexibility. One limitation of Streamlit is that all the apps end up looking more or less the same, and customization is limited.
• Performance - like you mentioned Streamlit reruns the script with every state change (though there are methods to cache, etc.). In Pynecone, the state is held in the backend and state deltas are sent to the frontend through a web socket. This leads to more performant interactions and (from our perspective) a state model that is easier to reason about as it grows.

So in short, Streamlit is great for prototyping but you can easily outgrow it as you try to add more features to your app. Our goal with Pynecone is to create a framework that's suitable for anything from small hobby projects to large multi-page websites, while giving devs the same flexibility they would get from a traditional web framework.

Hope that helps!