Show HN: Pynecone – Web Apps in Pure Python

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.

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.

> 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

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.

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.

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

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

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'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/

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?

"Pure Python" but requires NodeJS?

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!

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/

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.

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

Thank you for putting it out there!

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.

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

Is this related to the IDOM project? It seems similar in concept. https://idom-docs.herokuapp.com/docs/index.html

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

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??

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

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

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.

"Pure Python"

"Requires NodeJS"

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

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

looks fantastic, wish this was the direction of webapp development

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

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

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

I will love to try it out!

How does it compare to Flask framework?

Love it! looks great

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.