Show HN: Pynecone – Web Apps in Pure Python(github.com)
github.com
Show HN: Pynecone – Web Apps in Pure Python
https://github.com/pynecone-io/pynecone
101 comments
A comment at the bottom of the thread (at the time of writing) explains how it works:
In Pynecone, the frontend compiles down to a NextJS/React app, and the backend is a FastAPI server. Events are sent as network calls that update the app state, and the state delta is sent back to the React app, which updates the UI.
Thanks for highlighting this comment.
A succinct explanation of the underlying design is the best way to get me from "oh that's cute" to "wow, I want to try this".
A succinct explanation of the underlying design is the best way to get me from "oh that's cute" to "wow, I want to try this".
[deleted]
That's going to be rough to maintain as they update Next/React if this thing lasts for any reasonable period of time. No tests written at all either.
This is just a question of how involved we can make our open source community and that it not true about the tests https://github.com/pynecone-io/pynecone/tree/main/tests we also a have GitHub action set up, every pr that runs these test. Today was literally our first public launch we will improve as time goes on
Apologies - posted before I went through everything.
No problem thanks for checking us out!
zackees(1)
It's worth noting you can do something similar with Django & HTMX. These two combine to provide a DX in the same rough direction as Rails Hotwire and Phoenix LiveView (although the low-level semantics are different; it seems Pynecone is more similar to LiveView if I'm following correctly).
While I've not worked with it, one example of Djangonic Components might be Wagtail's: https://docs.wagtail.org/en/latest/extending/template_compon...
Interested in others' thoughts on what Pynecone will do better.
While I've not worked with it, one example of Djangonic Components might be Wagtail's: https://docs.wagtail.org/en/latest/extending/template_compon...
Interested in others' thoughts on what Pynecone will do better.
Looks like Pynecone uses Fastapi under the hood, which is a huge win for me. I can't stand "the Django way" of doing things and find Fastapi's philosophy much more harmonious with the way I think. So if you are the kind of person that enjoys a more functional style, with dependency injection, static types, etc, this is nice. If you like dynamic everything, this is probably less appealing.
We get huge development optimizations by using django over other python frameworks.
I think a better approach would be to make the back end pluggable to put whatever backend framework you want. And then you don't have tell people "well you can't use this fancy new tool, unless you move your entire stack over to fastapi..."
I mean there doesn't seem to be any reason you can't have a PineConeView that subclasses the django View class...
I think a better approach would be to make the back end pluggable to put whatever backend framework you want. And then you don't have tell people "well you can't use this fancy new tool, unless you move your entire stack over to fastapi..."
I mean there doesn't seem to be any reason you can't have a PineConeView that subclasses the django View class...
I do like FastAPI. django-ninja looks interesting as a potential alternative in the functional & Pydantic-typed API style, while still keeping the benefits of the Django ecosystem and ORM.
This is my stack when I want to ship MVP fast. Django + HTMX help me at least 10x more productive.
> width="100%",
> height="100vh",
> bg="radial-gradient(circle at 22% 11%,rgba(62, 180, 137,.20),hsla(0,0%,100%,0) 19%)",
Smells like leaky abstractions. Surely it's possible to abstract this into a strongly typed API?
Edit: https://pynecone.io/ looks a little screwed up for me on FF 107: https://i.imgur.com/ICu29UL.png
> height="100vh",
> bg="radial-gradient(circle at 22% 11%,rgba(62, 180, 137,.20),hsla(0,0%,100%,0) 19%)",
Smells like leaky abstractions. Surely it's possible to abstract this into a strongly typed API?
Edit: https://pynecone.io/ looks a little screwed up for me on FF 107: https://i.imgur.com/ICu29UL.png
Our components can be styled using any valid CSS which is what you see here. We do have plans in the future to make a more Pythonic API for styling :)
Thanks for pointing out the UI bug, we'll work on a fix!
Thanks for pointing out the UI bug, we'll work on a fix!
It seems once a year somebody writes a library to do this. It never takes off, because the main difficulty in developing web applications is not “learning JavaScript“.
I have 3 questions for the team. Who is the target audience exactly? How is this different from Anvil, Toga, Streamlit or the previous 36 attempts? And if learning JavaScript is too difficult, what exactly makes shoving the DOM API into another language easier? You still need to learn all the same things but now there’s about 9 orders of magnitude less working examples to copy from.
I have 3 questions for the team. Who is the target audience exactly? How is this different from Anvil, Toga, Streamlit or the previous 36 attempts? And if learning JavaScript is too difficult, what exactly makes shoving the DOM API into another language easier? You still need to learn all the same things but now there’s about 9 orders of magnitude less working examples to copy from.
You make a couple points here what do you mean "it never takes off" Streamlit was a very successful project in terms of number of users and is still growing today. I talk about how we are different in some of the comments of this post aswell.
Yeah Streamlit is incredible. I don’t think it’s trying to be a Web app framework. It’s such an easy way for me to deploy my data visualization.
Anvil still seems to be kicking along too...
As someone who used to do webdev and now works in Python, I've been wanting something like this for a while.
The barrier of writing both a front and backend for a simple demo/viz tool is pretty high (relative to the time it takes).
The barrier of writing both a front and backend for a simple demo/viz tool is pretty high (relative to the time it takes).
Seems really cool for putting a frontend on a data science app. All of my data processing code is in python already, but this would be really cool to add a dashboard or other features without needing a separate tech stack.
Yes this is a great use case we're targeting. I've used Streamlit in the past and it's 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.
Indeed, I’ve tried streamlit early on but it was very limited in layouts and I had to do all kinds of gymnastics to deal with state.
Gradio seems more popular for building ML driven demos though I have not used it. (I actually am curious why it’s more popular than SL).
Anvil is another “python web app” project I poked at briefly but didn’t get far
Gradio seems more popular for building ML driven demos though I have not used it. (I actually am curious why it’s more popular than SL).
Anvil is another “python web app” project I poked at briefly but didn’t get far
I haven't evaluated the OP's package yet, but Streamlit is like an Rshiny for Python. I'm not connected to the project, just liked what I used of it.
Best guess is OP's package gives finer grained control over display elements, which definitely has a place.
[0] https://blog.streamlit.io/how-to-build-a-real-time-live-dash...
Best guess is OP's package gives finer grained control over display elements, which definitely has a place.
[0] https://blog.streamlit.io/how-to-build-a-real-time-live-dash...
Congrats on the launch! Great project and nice execution!
Very similar to what we do on Flet: https://flet.dev The major difference is that Flet uses Flutter to build UI and can target desktop, web and mobile. Also, we use WebSockets for communicating with the server which gives lower latency (the delay between a click on a button here https://pynecone.io/docs/getting-started/introduction and UI update could be annoying).
Very similar to what we do on Flet: https://flet.dev The major difference is that Flet uses Flutter to build UI and can target desktop, web and mobile. Also, we use WebSockets for communicating with the server which gives lower latency (the delay between a click on a button here https://pynecone.io/docs/getting-started/introduction and UI update could be annoying).
Thanks yeah we really like your project as well. We chose the react/nextjs ecosystem because we found it to be more developed and widely use than flutter. Which gives us benefits to be able to wrap more libraries either in our pynecone framework or make a third party component library.
We thought about adding web socket and are still debating. The latency here is not from our framework though its from our server getting slammed with hacker news and reddit from our launch lol. We found the overhead of sockets not worth to for the majority of our apps.
We thought about adding web socket and are still debating. The latency here is not from our framework though its from our server getting slammed with hacker news and reddit from our launch lol. We found the overhead of sockets not worth to for the majority of our apps.
> The latency here is not from our framework though its from our server getting slammed with hacker news and reddit from our launch lol.
Seems like this could be a major barrier to scaling, especially if /all/ reactive state has to be handled through the server. Maybe a future feature could be a WebState class that provides reactivity only on the front end?
Seems like this could be a major barrier to scaling, especially if /all/ reactive state has to be handled through the server. Maybe a future feature could be a WebState class that provides reactivity only on the front end?
It took me a while to re-find a "Python web app" project that has been posted here and that I vaguely remembered. So I am gonna post it here. It's Pglet https://github.com/pglet/pglet and Flet seems to be its spiritual successor.
First time reading about Flet. Good technical guide, a few typos but pleasure to read. Hope to try the project. Thanks for sharing.
Flet is a new one on me. Thanks for the link, I'll give it a try.
Been a lurker on Hacker News for years but I created an account just so I could say how excited I am for this! Love the effort you're putting into it. Streamlit was awesome but felt really painful to use whenever you want to do anything slightly out of the main path.
I eagerly look forward to the day this becomes stable. Looks like a project that will stick around for a long time, especially with the care being put into it.
Good luck team!
I eagerly look forward to the day this becomes stable. Looks like a project that will stick around for a long time, especially with the care being put into it.
Good luck team!
Wow thank you so much we really appreciate your support! We have worked really hard on this so its great to hear there are people who value it.
We will continue to improve the framework if there are any bugs/confusing you have in the mean time feel free to submit an issue/discussion.
We will continue to improve the framework if there are any bugs/confusing you have in the mean time feel free to submit an issue/discussion.
Thanks so much for your kind words! We think our approach can really simplify web development and make it accessible to a larger community. Excited to see what you build with it!
I don't want to knock on this accomplishment at all and I am well aware that these tools have its use-cases. However, I am just talking anecdotally and with experience with other things.
I think Google Web Toolkit started the idea of compiling X-to-Javascript. I am not sure, but it was the first I seen. I used GWT a long time ago and know it has improved a bit, but I always have sneaking feeling that the language-as-abstraction over JS feels excessive and extra work to maintain. I mean, I want to like this, but I can never justify using these toolkits. I think for something like PyQt, it really makes sense to have a language wrapper. Many people do not necessarily work in C++ or Qt's flavour of C++. But, if you are going to do anything in web dev, just learn JS/HTML/CSS. If you know that stack, these tools are really not that useful. The stack is probably the most well-documented application development space known to man now :)
However, I am always wanting to learn what people actually do and why they make tools like this. I just would never reach for this type of tool personally.
I think Google Web Toolkit started the idea of compiling X-to-Javascript. I am not sure, but it was the first I seen. I used GWT a long time ago and know it has improved a bit, but I always have sneaking feeling that the language-as-abstraction over JS feels excessive and extra work to maintain. I mean, I want to like this, but I can never justify using these toolkits. I think for something like PyQt, it really makes sense to have a language wrapper. Many people do not necessarily work in C++ or Qt's flavour of C++. But, if you are going to do anything in web dev, just learn JS/HTML/CSS. If you know that stack, these tools are really not that useful. The stack is probably the most well-documented application development space known to man now :)
However, I am always wanting to learn what people actually do and why they make tools like this. I just would never reach for this type of tool personally.
I used GWT a long time ago and it was great for being able to write a complex algorithm that had to run on the server as well as in the browser. It saved a lot of time and trouble, and you always knew that the version running on the server was the same as the one running in the browser.
If you are already adept at coding in JavaScript and you actually enjoy using JS, then you would not be the audience for these Python (or other language) web dev projects. However, if you are not a seasoned JS developer or you just don't like coding in JS as a personal preference, then I think these are worth taking a look at. I hear the phrase "just learn JavaScript" quite a bit in regards to these, but I believe learning an API is easier than learning and being proficient in an entire programming language. These tools all have their own approach as well and some are more suited to certain tasks/audiences than others.
If you are already adept at coding in JavaScript and you actually enjoy using JS, then you would not be the audience for these Python (or other language) web dev projects. However, if you are not a seasoned JS developer or you just don't like coding in JS as a personal preference, then I think these are worth taking a look at. I hear the phrase "just learn JavaScript" quite a bit in regards to these, but I believe learning an API is easier than learning and being proficient in an entire programming language. These tools all have their own approach as well and some are more suited to certain tasks/audiences than others.
Guys, you’re awesome. Congrats on making it to YC.
I’ve been waiting for it as I love streamlit but it’s so limiting.
Happy to help with anything if I can. I’d try to move our next version of our API portal to it
I’ve been waiting for it as I love streamlit but it’s so limiting.
Happy to help with anything if I can. I’d try to move our next version of our API portal to it
What do you mean by making it to YC? I couldn't find evidence of any affiliation
Do you mean being in hacker news ?
Do you mean being in hacker news ?
misunderstandling. I thought it's a Launch HN
Thanks so much! We're excited to have people start using it and are looking forward to any feedback :)
I'm familiar with Anvil, this seems to fill the same niche. Anvil offers a hosted option and lets you design the layout in a graphical interface which makes it compete with low code tools. But this can also become limiting and frustrating. Pynecone seems to have a larger choice of components and they look more polished. I'd be interested to try it to compare.
https://anvil.works/
https://anvil.works/
Thanks, I prefer the coding ergonomics to Pynecone a lot more vs Anvil. Plus it's easy to for us to add libraries such as bootstrap, material, really any react framework so I suspect we will be able to grow this by a lot in the future. For instance we could have a 3rd party package for bootstrap, or d3js if people want this incorporated.
Anvil seemed a little outdated for me to personally use but to each their own.
Anvil seemed a little outdated for me to personally use but to each their own.
I usually like frameworks with less magic, Sinatra for Ruby, Spock for Haskell, or Flask for Python.
That said, this looks like something I want to try. I learned SwiftUI about 14 months ago, enjoyed writing one app for Apple Store, then didn’t touch it again. I liked the declarative style of SwiftUI and Pynecone seems similar. Am I understanding it correctly?
That said, this looks like something I want to try. I learned SwiftUI about 14 months ago, enjoyed writing one app for Apple Store, then didn’t touch it again. I liked the declarative style of SwiftUI and Pynecone seems similar. Am I understanding it correctly?
Yup, our frontend is just a wrapper around React so it is fully declarative. We are definitely more opinionated than something like Flask, but the benefit is that you can write your whole app, including the frontend, in a single language (for small apps just a single file).
"Pure Python" but requires NodeJS?
This is actually something we are working on getting rid of. What separates us from other python frameworks is that we compile down to a nextjs/react app (the user never sees this though). This is really beneficial because it allows us to add any react library in a matter of hours vs other python frameworks where it can take a much longer time to add new ui feature. Also for performance and SEO nextjs is great.
But to keep it short there is a way to get rid of this in the future and we are currently working on it. So the only installation step will be `pip install pynecone-io`
But to keep it short there is a way to get rid of this in the future and we are currently working on it. So the only installation step will be `pip install pynecone-io`
This is what I'm trying to solve with this: https://github.com/samwillis/nodejs-pypi
The idea being that a project like yours can install node into a venv on install for use itself. No more dual stack environments!
The idea being that a project like yours can install node into a venv on install for use itself. No more dual stack environments!
Very cool I'm going to check this out!
Haha fair point. Our goal is that the developer will never see or write Javascript. But behind the scenes Pynecone compiles the app's frontend down to a NextJS app. We're trying to leverage the features of React and NextJS and making them more accessible to the Python community.
Congrats on the launch! This reminded me a lot of what we're going for with https://wasp-lang.dev/ (but for the JS/TS domain atm) and I can definitely relate to the problem.
I'm not a big python user but I can imagine how this might be a really friendly way for python devs to build their own apps. The gallery and examples are also nicely done!
I'm not a big python user but I can imagine how this might be a really friendly way for python devs to build their own apps. The gallery and examples are also nicely done!
Single-codebase full-stack in Python is an interesting thing to do, but honestly that API for UI is ugly compared to React or even React-wrapped-in-Python by way of Pyodide. [0]
[0] the approach of this blog post: https://blog.pyodide.org/posts/react-in-python-with-pyodide/
[0] the approach of this blog post: https://blog.pyodide.org/posts/react-in-python-with-pyodide/
The ugliness is something I struggled with a bit when I was first using Transcrypt to create React applications with Python. Even though that approach is more of a 1-to-1 Python-to-JS mapping instead of a Python wrapper, I felt all the calls to createElement affected readability. But once I started using a Python decorator to wrap the components in createElement, the code got a lot cleaner. Here's a basic example based on the official React tutorial:
https://github.com/JennaSys/tictacreact2/blob/main/tictacrea...
Could I use this to create a static site, which I can serve using my own server?
I like the idea of pure python, instead of messing around with jinja templates.
I like the idea of pure python, instead of messing around with jinja templates.
Yes I am going to make a blog or something of that nature soon and ill post a follow up on our GitHub discussions.
From someone who is neither a Python programmer nor a web developer, this looks pretty nice.
Thank you for putting it out there!
Thank you for putting it out there!
Glad to hear you like it!
Nice work and good luck with future progress.
One thing I could not find, skimming the docs, was where the CSS lives. Could I place my own existing css stylesheet(s) in the project? Would the snake_case equivalents just fall through to the underlying CSS, or would I need to write a CSS dictionary as a translation layer?
Thanks.
One thing I could not find, skimming the docs, was where the CSS lives. Could I place my own existing css stylesheet(s) in the project? Would the snake_case equivalents just fall through to the underlying CSS, or would I need to write a CSS dictionary as a translation layer?
Thanks.
Thanks! Yes you can use any valid CSS, see our styling docs: https://pynecone.io/docs/styling/overview. We don't have CSS classes, but you can copy your properties into our snake_case version and pass them to your components.
Thanks. I read the overview and what looked like the lack of support for existing CSS framework and stylesheets prompted my question.
Unless I'm misunderstanding how CSS support works here, I think this is a deal breaker for me at the moment. Being able to include external stylesheets/frameworks is something of a must have.
Appreciate it is Alpha level software so look forward to learning how the project evolves.
Unless I'm misunderstanding how CSS support works here, I think this is a deal breaker for me at the moment. Being able to include external stylesheets/frameworks is something of a must have.
Appreciate it is Alpha level software so look forward to learning how the project evolves.
I’m wondering how many potentially interested parties are turned off by the errors in this announcement.
An extra with; «Javascript»; «multi page» without a dash; «over 60+»; «you skill level»; or «Open up an issue if you […] contribute to existing issue.»
An extra with; «Javascript»; «multi page» without a dash; «over 60+»; «you skill level»; or «Open up an issue if you […] contribute to existing issue.»
Is this related to the IDOM project? It seems similar in concept.
https://idom-docs.herokuapp.com/docs/index.html
No not related pynecone is more full stack and handles both front/backends
Isn't it going to get expensive offering a free public Dall-E demo using your API key?
Lol yes our app will probably go down sometime today fyi to everyone
Great work!
Perhaps you could use other light weight toy examples that don't need API keys. There are simpler models on hugging face, for example.
Shouldn't it be relatively trivial for someone to get your key banned?
my advice to people newer to writing software- dont use this kind of stuff without first learning the actual things they try to abstract. with these kinds of libraries, 9 times out of 10 all you get is a more difficult debugging process.
Curious how testing works... If i could use pytest (somehow) that would be a game changer vs typical frontend testing hell.
Better than streamlit??
Congratulations on your release!
Don't let my skepticism (below) to detract from your accomplishment.
I am deeply skeptical not only about this tool in particular but about these tools (e.g., Dash, Panel, Streamlit &c.) in general. I've seen these tools work well for very simple use-cases, but they seem to require some combination of…
· cooperating requirements (matching exactly what the demos do, so you stay completely within the “regime” these tools support)
· upfront knowledge of all requirements (so that you never fall out of this regime)
· the ability to reject requirements (so that you can keep yourself within the regime, though this means the tool is leading the business, not the business leading the tool)
· the ability to accurately identify the boundaries of the regime from the tool documentation and design
For very simple examples, it's may be possible to stay within these constraints, but even when you manage to successfully use these tools, you do so at high (and, in my view, often unacceptable) risk.
In general, the risk/reward for a tool like this is about being able to learn the tool almost immediately (which must also account for time spent trawling through the documentation or the Github issues or even the `dir(module)` to figure out how to spell that one thing you need.) Basically, if you can create something in 1 day that can last for 180 days before a requirement comes along that forces you to start over from scratch, you may be okay.
You certainly never want to become good at these tools; the more you invest in the tooling, the harder it will be to abandon it when it is no longer appropriate, and the more willing you will be to accept contortions that you will inevitably regret. You certainly never want to spend more than a trivial amount of time building something with these tools, since the risk of needing to rebuild or abandon the technology is simply too high.
(Personally, I simply don't think React is that hard to learn, that hard to teach, or that onerous to use…)
In particular, this tool's API seems particularly risky. e.g., in the example code, there is a section like this:
I suspect, however, that this API is still being refined. After all, what if I wanted to trigger on two conditions? There are probably some sophisticated `metaclass` mechanisms wrapping the `State` attributes in some symbolic modelling, but SymPy shows us that this is not trivial to get right, and the Python object model constraints you in unpredictable ways. Without looking at the code, I suspect you cannot `cond(State.mode1 | State.mode2, element)` and probably have to create some sort of `State.mode1_or_mode2` subordinate data, which spirals out of control pretty quickly. And what if you want to do `cond(State.mode | mutable_global_mode)`? And so forth and so on.
There are so many structures and modalities for control flow and data flow (trivially expressible in React) that will become clumsier and clumsier to express in with this modelling, and unless you can anticipate that they won't arise, reject the business requirements that mandate them, or (with no regret) throw everything away and start over from scratch, you're going to have a good experience.
Don't let my skepticism (below) to detract from your accomplishment.
I am deeply skeptical not only about this tool in particular but about these tools (e.g., Dash, Panel, Streamlit &c.) in general. I've seen these tools work well for very simple use-cases, but they seem to require some combination of…
· cooperating requirements (matching exactly what the demos do, so you stay completely within the “regime” these tools support)
· upfront knowledge of all requirements (so that you never fall out of this regime)
· the ability to reject requirements (so that you can keep yourself within the regime, though this means the tool is leading the business, not the business leading the tool)
· the ability to accurately identify the boundaries of the regime from the tool documentation and design
For very simple examples, it's may be possible to stay within these constraints, but even when you manage to successfully use these tools, you do so at high (and, in my view, often unacceptable) risk.
In general, the risk/reward for a tool like this is about being able to learn the tool almost immediately (which must also account for time spent trawling through the documentation or the Github issues or even the `dir(module)` to figure out how to spell that one thing you need.) Basically, if you can create something in 1 day that can last for 180 days before a requirement comes along that forces you to start over from scratch, you may be okay.
You certainly never want to become good at these tools; the more you invest in the tooling, the harder it will be to abandon it when it is no longer appropriate, and the more willing you will be to accept contortions that you will inevitably regret. You certainly never want to spend more than a trivial amount of time building something with these tools, since the risk of needing to rebuild or abandon the technology is simply too high.
(Personally, I simply don't think React is that hard to learn, that hard to teach, or that onerous to use…)
In particular, this tool's API seems particularly risky. e.g., in the example code, there is a section like this:
cond(
State.mode,
element,
cond(
State.flag,
other_element,
),
)
I suspect, however, that this API is still being refined. After all, what if I wanted to trigger on two conditions? There are probably some sophisticated `metaclass` mechanisms wrapping the `State` attributes in some symbolic modelling, but SymPy shows us that this is not trivial to get right, and the Python object model constraints you in unpredictable ways. Without looking at the code, I suspect you cannot `cond(State.mode1 | State.mode2, element)` and probably have to create some sort of `State.mode1_or_mode2` subordinate data, which spirals out of control pretty quickly. And what if you want to do `cond(State.mode | mutable_global_mode)`? And so forth and so on.
There are so many structures and modalities for control flow and data flow (trivially expressible in React) that will become clumsier and clumsier to express in with this modelling, and unless you can anticipate that they won't arise, reject the business requirements that mandate them, or (with no regret) throw everything away and start over from scratch, you're going to have a good experience.
Thanks for the detailed response we really appreciate it and see where your coming from. We definitely are not for everyone but if you want to completely stay in the python ecosystem we are a solid option compared to other frameworks. I think we are in a different class to some of the frameworks you mentioned though because you can actually create fully customizable web apps with us.
For you react/js was easy to learn but a lot of people don't want to take the time to learn this. At the end of the day every one has a preference and I see where you are coming from on this.
For you react/js was easy to learn but a lot of people don't want to take the time to learn this. At the end of the day every one has a preference and I see where you are coming from on this.
"Pure Python"
"Requires NodeJS"
"Requires NodeJS"
This is actually something we are working on getting rid of. What separates us from other python frameworks is that we compile down to a nextjs/react app (the user never sees this though).
But to keep it short there is a way to get rid of this in the future and we are currently working on it. So the only installation step will be `pip install pynecone-io`
But to keep it short there is a way to get rid of this in the future and we are currently working on it. So the only installation step will be `pip install pynecone-io`
Neat! How does this compare to Phoenix/LiveView? Is it similar in principle?
I haven't used Phoenix personally, but it looks similar.
In Pynecone, the frontend compiles down to a NextJS/React app, and the backend is a FastAPI server. Events are sent as network calls that update the app state, and the state delta is sent back to the React app, which updates the UI.
In Pynecone, the frontend compiles down to a NextJS/React app, and the backend is a FastAPI server. Events are sent as network calls that update the app state, and the state delta is sent back to the React app, which updates the UI.
Just a heads up that both the name (esp. for non English speaking users) and the quite similar symbol could possibly clash with the Pinecone by Pine64.org.
https://wiki.pine64.org/wiki/PineCone
https://wiki.pine64.org/wiki/PineCone
Wait until you hear about pine cones[0]! This project predates both others by several millions years.
[0] https://botanicalgarden.berkeley.edu/glad-you-asked/cones
[0] https://botanicalgarden.berkeley.edu/glad-you-asked/cones
Actually, what I had in mind were these well known legal cases back in the day.
https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft
https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com....
https://en.wikipedia.org/wiki/Microsoft_v._MikeRoweSoft
https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com....
Lol
Tldr for those who don't know about trademarks, the whole English language is not one namespace. It's partitioned so an evaluation board and a web framework don't clash.
https://www.uspto.gov/trademarks/search/get-ready-search-cla...
https://www.uspto.gov/trademarks/search/get-ready-search-cla...
[deleted]
looks fantastic, wish this was the direction of webapp development
Is this only for ML projects? Is it a Gradio wrapper?
No definitely a much broader use case and we compile to nextjs/react and have nothing to do with gradio. With tools like gradio and streamlit you are very limited in use case. With Pynecone you can make full scale multipage web apps in pure Python that are completely stylable and customizable
Sorry, but when you do templating inside the code you lose me immediately. I expect a reply like "but you don't have to", but damage is already done.
We made Pynecone for Python devs who want to make web apps, but don’t want the overhead of having to learn or use Javascript. We wanted more flexibility than existing Python frameworks like Streamlit/Dash that don't allow the user to make real, customizable web apps.
With Pynecone, you can make anything from a small data science/python project to a full-scale, multi page web app. We have over 60+ built-in components and are adding more.
We are actively trying to grow this project so no matter you skill level we welcome contributions! Open up an issue if you find missing features/bugs or contribute to existing issue.