[HN Gopher] Show HN: Pynecone - Web Apps in Pure Python
___________________________________________________________________
Show HN: Pynecone - Web Apps in Pure Python
Hello, we just launched the alpha release of Pynecone - a way to
build full-stack web apps in pure Python. The framework is easy to
get started with even without previous web dev experience and is
completely open source / free to use. 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.
Author : picklelo
Score : 128 points
Date : 2022-12-09 16:00 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mring33621 wrote:
| From someone who is neither a Python programmer nor a web
| developer, this looks pretty nice.
|
| Thank you for putting it out there!
| appveyor wrote:
| 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).
| apetuskey wrote:
| 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.
| doteka wrote:
| 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.
| apetuskey wrote:
| 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.
| nadavwiz wrote:
| Love it! looks great
| apetuskey wrote:
| Thank you!!
| squarefoot wrote:
| 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
| cooperadymas wrote:
| 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
| apetuskey wrote:
| Lol
| killingtime74 wrote:
| 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...
| [deleted]
| jamesdutc wrote:
| 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:
| cond( State.mode, element,
| cond( State.flag, other_element,
| ), )
|
| So we're encoding the control flow defining the layout in some
| sort of object graph (some sort of pseudo-AST)? It's not going to
| take a lot of this to spiral out of control. Unless you can
| recognize that this tool is unsuitable for even mildly complex
| programmatic component layout (which is trivial to do in React,)
| you're going to hit an impassible brick wall trying to handle
| what will otherwise be considered a benign business request.
|
| 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.
| apetuskey wrote:
| 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.
| andybak wrote:
| Auto-reload of "pc run" on any edits please!
| picklelo wrote:
| This should already be a feature! (Let me know if you're
| running into issues). We enable hot-reloading of the app when
| you save your file.
| andybak wrote:
| Isn't it going to get expensive offering a free public Dall-E
| demo using your API key?
| apetuskey wrote:
| Lol yes our app will probably go down sometime today fyi to
| everyone
| nomel wrote:
| Shouldn't it be relatively trivial for someone to get your
| key banned?
| nothrowaways wrote:
| 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.
| apetuskey wrote:
| Yeah definitely will switch it out just wanted to show a
| trending model
| analog31 wrote:
| I'd love to see a graph of some data.
| augasur wrote:
| I will love to try it out!
|
| How does it compare to Flask framework?
| boxed wrote:
| Flask is just a tiny API for http. It doesn't even do
| templating.
| TekMol wrote:
| "Pure Python" but requires NodeJS?
| picklelo wrote:
| 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.
| apetuskey wrote:
| 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`
| samwillis wrote:
| 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!
| apetuskey wrote:
| Very cool I'm going to check this out!
| artembugara wrote:
| 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
| jerrygenser wrote:
| What do you mean by making it to YC? I couldn't find evidence
| of any affiliation
|
| Do you mean being in hacker news ?
| picklelo wrote:
| Thanks so much! We're excited to have people start using it and
| are looking forward to any feedback :)
| thatwasunusual wrote:
| 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.
| rahimnathwani wrote:
| 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.
|
| EDIT: The gallery is also useful:
| https://pynecone.io/docs/gallery
| stevesimmons wrote:
| 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".
| zackees wrote:
| The maker of FastAPI says his app should not be used in
| production.
| folkrav wrote:
| Any source for this? FastAPI advertises itself as production
| ready:
|
| > Robust: Get production-ready code. With automatic
| interactive documentation. [1]
|
| > FastAPI framework, high performance, easy to learn, fast to
| code, ready for production. [2]
|
| [1] https://fastapi.tiangolo.com/ [2]
| https://twitter.com/FastAPI
| theptip wrote:
| 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.
| kortex wrote:
| 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.
| bb88 wrote:
| 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...
| xcdzvyn wrote:
| > 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
| picklelo wrote:
| 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!
| ollien wrote:
| Neat! How does this compare to Phoenix/LiveView? Is it similar in
| principle?
| picklelo wrote:
| 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.
| SleekEagle wrote:
| Is this only for ML projects? Is it a Gradio wrapper?
| apetuskey wrote:
| 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
| makestuff wrote:
| 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.
| picklelo wrote:
| 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.
| tomrod wrote:
| 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...
| andybak wrote:
| Any plans for three.js or any kind of WebGL component?
| apetuskey wrote:
| Definitely we can add any react library just submit a feature
| request on our GitHub issues and ill get on it
| digitalsankhara wrote:
| 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.
| picklelo wrote:
| 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.
| rmorey wrote:
| really interesting! _compiling_ to NextJS and keeping it mostly
| hidden from the user is a smart move. and it uses bun! will be
| trying this
| apetuskey wrote:
| Thank you! Yeah we love bun too
| FranklinMaillot wrote:
| 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/
| apetuskey wrote:
| 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.
| dankle wrote:
| Better than streamlit??
| apetuskey wrote:
| With Pynecone you can create full web apps vs streamlit is a
| little limited in use case and worse performance but to each
| their own.
|
| We actually make our whole website and docs in Pynecone where
| as streamlit could never do this.
___________________________________________________________________
(page generated 2022-12-09 23:00 UTC)