Show HN: Pynecone – Web Apps in Pure Python (github.com)

Neat! How does this compare to Phoenix/LiveView? Is it similar in principle?

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.

"Pure Python" but requires NodeJS?

> 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

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

Isn't it going to get expensive offering a free public Dall-E demo using your API key?

Is this only for ML projects? Is it a Gradio wrapper?

Any plans for three.js or any kind of WebGL component?

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.

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:

    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.

Auto-reload of "pc run" on any edits please!

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

Love it! looks great

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

I will love to try it out!

How does it compare to Flask framework?

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.

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

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.

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/

From someone who is neither a Python programmer nor a web developer, this looks pretty nice.

Thank you for putting it out there!

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).

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.

"Pure Python"

"Requires NodeJS"

looks fantastic, wish this was the direction of webapp development