Launch HN: Pynecone (YC W23) – Web Apps in Pure Python
Hi! We’re Nikhil and Alek, founders of Pynecone (https://pynecone.io), an open source framework to build web apps in pure Python. This can be anything from a small data science/internal app to a large multi-page web app. Once your app is built, you can deploy your app with a single command to our hosting service (coming soon!), or self-host with your preferred provider.
Our Github is: https://github.com/pynecone-io/pynecone
Python is one of the most popular programming languages in the world. Webdev is one of the most popular applications of programming. So why can’t we make full-stack web apps using just Python?
We worked in the AI/infra space and saw that even skilled engineers who wanted to make web apps but didn’t know traditional frontend tools like Javascript or React found it overwhelming and time consuming to learn. On the other hand, no code and low code solutions that save time in the development process lack the flexibility and robustness of traditional web development. These tools are great for prototyping, but they can be limiting as your app becomes more complex. We wanted to build a framework that is easy to get started with, yet flexible and powerful enough so you don’t outgrow it. Our main website is fully built with Pynecone and deployed on our hosting service.
In Pynecone, the frontend compiles down to a React/NextJS app, so from the end-user’s perspective it looks like any other website. We have 60+ built-in components ranging from forms to graphing. Components are defined as Python functions. They can be nested within each other for flexible layouts, and you can use keyword args to style them with full CSS. We also provide a way to easily wrap any existing React component. Our goal is to leverage the existing webdev ecosystem and make it accessible to Python devs.
The app state is just a class. State updates are functions in the class. And the UI is a reflection of the state. When the user opens the app, they are given a unique token and a new instance of the state. We store user state on the backend, and use Websockets to send events and state updates. When a user performs an action, such as clicking a button, an event is sent to the server with the client token and the function to handle the event. On the server side, we retrieve the user's state, execute the function to update the state, then send the updated state back to the frontend for rendering. Since Pynecone is 100% Python, you can easily integrate all your existing Python libraries into your app. In the future, we hope to leverage WebAssembly to offload many operations to the client.
Once your app is built, the next big challenge is deploying it. We’re building a single-line deploy, so you can type pc deploy and get a URL of your live app in minutes. Since we specialize in hosting a single type of app, we aim to provide a zero configuration deployment process. We are still working on releasing the hosting service, but you can sign up for its waitlist on our homepage. Alternatively, you can choose to host your app with your preferred cloud provider.
Things users have built with Pynecone so far include internal apps ranging from CRM to ML tools, UIs for LLM apps, landing pages, and personal websites. If you use Python, we would love to hear your thoughts and feedback in the comments! I'm not exaggerating but this might just be the highest impact library I've seen. As a backend developer who has lots of great project ideas but bail at the thought of having to use JavaScript and HTML, this library is a godsend! My only question is why it took so long for someone to implement it? And where are the equivalent libraries for Go, Rust and Java? Well, I haven't looked into this one deeply yet, so I'm not sure what the differences are exactly. But there are many existing, broadly similar, projects. I see this as a solution to "I want to make an interactive website, and I don't want to touch the JS ecosystem at all and/or I really prefer python-specific libraries". This is my position exactly, so I sort of keep track of what's available. From that perspective, this is in the same space as: web2py, pyjs, streamlit, brython, pyodide, pywebio, gleam. I'm sure there are others. This is a futile pursuit simply because you are creating a layer of abstraction over JS using another dynamic language so there's no real gain other than syntactic sugar. Would you say the same thing about web assembly and emscripten? At least one of the above is based on those. Using scientific and numeric packages from the python ecosystem is more than syntactic sugar, IMO. It seems like the JS world mostly ignores that stuff. I have yet to try a real project with any of those python web tools. I know just enough HTML, vanilla JS and DOM API to cobble together ugly sites when I need to, so that's what I do. But I am optimistic that a better alternative will emerge eventually. These tools are a waste of time. They take longer to learn then basic js and then in 3 years support is dropped you might have well learned a bit more js. It's a bit big but just run nextjs, it solves almost everything for you. Even deployment is one click away. Would take 5 mins to get started. And a few hours to understand for a seasoned dev. I'm not familiar with nextjs, will try it out. I honestly want to understand this viewpoint, so I can make informed decisions when looking at these tools. So let me ask... I agree that some of these older python things are probably not worth using. But I'm a bit confused that you're entirely dismissing web assembly. I think it's well understood that using JavaScript as the foundation of front end software was a complete historical accident. It's a huge amount of inertia to compete with, but that doesn't mean it's insurmountable. My understanding is that wasm is a major industry initiative, and it isn't going away. Emscripten seems to be nearly as stable. Now, maybe two or three non-js languages will emerge as the core of wasm-based development, and maybe python won't be in that small group. I'd rather learn, say, rust than continue writing JavaScript. Where do you disagree? You think wasm will be shut down completely in a year? You think none of these languages will take off in terms of web-specific tooling? Something else? Whether it was a mistake or not. It's taken over. And many people have worked hard to make it a modern language the last 20 years. I've seen many attempts to take over js, thusfar they all failed. At the same time JS got more and more powerful. Js is so integrated in every corporate it will not go away any time soon. JS solves so many issues know and the css layout is much more mature than then any under native system (native apps, flash etc are much worse at responsive layouts) Wasp sounds fun, it's very early stage and doesnt sound like it has anything to do with webpages but runs a binary in a browser sandbox. Kind of like flash without a plugin. Can have a lot of cool features, mainly games etc. But sounds like an addition not a replacement. But who knows! Haha yeah its amazing how the lengths people will go to not learn something simple but new! I have been using JavaScript for decades, and I have never liked using it. I want to enjoy making interactive browser-based apps. Sorry that I don't buy into the cult of infinitely complex front end build tooling. I am consciously opting out of that ecosystem because it isn't for me. The frontend gets compiled to JS, not unlike how TS gets compiled to JS. Useful list. Dash & bokeh as two more in the space https://github.com/plotly/dash
https://docs.bokeh.org/en/latest/ Bokeh, Dash, Gradio, Pglet, Idom, Anvil I think all LiveView frameworks should be part of this. Here are two Python ones I've tried: https://www.django-unicorn.com/
https://github.com/edelvalle/reactor So ruby has a JS transpiler - opal - https://opalrb.com/ I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need a fancy JS solution in the first place. JS only becomes complex when you are trying to create an enterprise version of your app along with a build platform. You can always just sprinkle in <script> tags in your HTML for simple one liners without getting into the weeds. You are assuming people use Opal because they don't want to learn JS. In reality it's that JS is a very messy language compared to ruby. You can be a lot more productive if you avoid JS entirely. Absolutely agreed, hence the many Python to JS transpilers out there. https://transcrypt.org
https://yourlabs.io/oss/ryzom#javascript
https://github.com/am230/py2js We get so much satisfaction out of writing JS in Python, it's worth all the IDEs in the world for us! JS is a totally fine language. The entire browser ecosystem makes JS an incredible productive language for working on the web. You can disagree if you don't like the language personally but that doesn't change the fact JS gets the job done "incredible productive language for working on the web" You can disagree if you want but that doesn't change the fact that JS is a huge pain in the neck to get the job done with. I'm working on https://github.com/mayu-live/framework which is 100% server side Ruby. It's kinda like React/Preact, but server side, and Ruby. No JavaScript required (it's not even supported). That's pretty neat. In general I think stuff like this is cool and works pretty well as a starter kit for simple CRUD apps if you don't already know Rails + JS, but like I said in my OP, once your app gets more complex, you hire some UX designers and you try to make your app more interactive, not having easy JS access makes it hard to do interesting things. So could be useful for small projects but I wouldn't pick a solution like this for projects I would want to grow larger JS is complicated because the browser environment is complicated. If it's going to be rendered by and live in a web browser it will either be complicated or limited in some way (like low code/no code tools). That's not really true. It's complicated because the language is one of the worst to manage. It's not really any worse than Python or Ruby, but you also get TypeScript which helps I posit that it is both. Dealing with interactivity in the browser is subtle, complex and full of edge cases. JavaScript is also a horrible, broken language that’s not really fit for purpose. We’ve collectively invested a lot of time and resources trying to improve the experience of working with it, but the point still stands. > And where are the equivalent libraries for Go, Rust and Java? Not aware of anything yet for Go/Rust, but Java and Python have had libs like this for a while now (to the point that Pyjamas hasn't been updated in a decade): * GWT (Java) * Pyjamas (Python) * Vaadin (Java) Those are general purpose. After that you have the sci/data-oriented python frameworks like dash, streamlit, etc. actually, as per the docs the framework is converting python code to Javascript. So you would need to JS skills to debug. Most of the problems in web front have been solved in JS (think CSS styles, state management)
re-writting it in python would be pain, especially when everything compiles to js Our goal is for the user to never have to see JS. We try to catch most errors in Python during compile time. We're also not trying to reinvent things like CSS styles, just make them accessible in Python. > We try to catch most errors in Python during compile time. I feel Python is not the best language for catching most errors during compile time. We're using Pydantic and our compiler has custom type-checking on top of Python to catch these issues. That's not gonna happen if they have to solve browser runtime errors. And with there being so much variance between browsers and random nonsense to hack around, how can you possibly get around that? Besides, python and js are so similar it's really funny to see people not wanting to use one but cling to the other. The available libraries are quite different between the two languages. Does this thing also convert python libraries for use on the web? Can it compile say keras or pytorch to javascript? I guess that would indeed be super neat to have on the browser client side. I don't know much about Pynecone, but that is indeed what pyodide does: > These include many general-purpose packages such as regex, pyyaml, lxml and scientific Python packages including numpy, pandas, scipy, matplotlib, and scikit-learn. Again, not super familiar, so I don't know the level of effort required to support these libraries. Maybe adding pytorch would be infeasible, maybe they just need enough people to express interest. State management hasn't really been solved. Hence the whole debate about signals vs no signals last week. :) XState is the bee's knees if you're writing any Javascript > My only question is why it took so long for someone to implement it? Uhhhh. Because it didn’t. Google GWT was huge on the hype cycle about 15 years ago. You know this has been done before over a decade ago, multiple times in Java and Python. Not saying the space can’t be improved upon but I fail to see how it’s any more revolutionary now. I have seen a .NET project that did something similar to this, it was called Bridge. That was 8 years ago no sure if it's still available. These days, in the .NET ecosystem, there is Blazor. You write your whole web app in HTML, CSS and C# (frontend and backend). There are several different deployment models; Wikipedia gives a good summary: Websharper[1] lets you develop web apps all in F# or C#. Its reactive HTML layer is particularly useful. Serious question, why not Typescript? Are you not aware of it or do you have other reasons? You may not realise this, but TS is just JS + Types. You may not realize this, but that makes all the difference in the world. You may not realise this, but this post is about a framework that let's python devs make modern web apps without touching the JS ecosystem. The root comment appreciates the framework, and shares their unwillingness to write JavaScript and HTML. The reply to that comment asks why don't they try TypeScript. I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd. I know and realise the fact that JS+Types is way better than plain JS, and infact I write TypeScript on everyday basis. > I think that reply is absurd because asking someone to write TypeScript when they dislike JavaScript in the first place is absurd. I don't think it's absurd to ask someone to try Typescript first before jumping through hoops just to make Python run on the web, which certainly brings a lot of problems of its own. You do have to actually try it to see how it's a completely different experience, even if the types are just bolted on. Hmm? In 90s and 2000s most web frameworks did not rely on JS at all, they were completely server-side. I.e. the server renders a page. User clicks a button, browser collects data from a form and sends request to the server. The server updates its state and renders a new page. There are some downsides to that approach, but it can be pretty good if you just need to get some information and/or let user browse a data collection. Compile-to-JS approach started to appear in mid 2000s. In java I know of https://www.webtoolkit.eu/jwt/ Java does have Vaadin but it's a mostly proprietary software. But it is very good and largely under appreciated. Maybe I am an optimist, but I'd say Vaadin is mostly Open Source (Apache License). You can build complete web applications with the open source version. Only some advanced components (e.g. an Excel-like grid, a WYSIWYG editor, Highcharts components) are proprietary and require a subscription for development, while the builds can be freely distributed. .NET has Blazor, seen something similar in Rust. I believe there are tons of similar libs > My only question is why it took so long for someone to implement it? This is by far the first front-end python implementation/framework. Skulpt, Brython, Anvil, PyFyre, PyScript, PyWebIO, and the list goes on… Nope, but something better, e.g. Leptos for Rust which enables you to write Rust code and RsX (JsX equivalent) that runs on the server until all WASM is loaded to run it in the browser Thank you really appreciate that! I get get benefit from it, and I saw what Dash and plotly can do for people with a bit of Python and a need for a quick UI. So I get the point of the project, I can see a mathematicians getting value out of this. Still, I would advice against using this for anything else than a small project (in the current state): - any action your perform means a round trip to the server. This is why the counter seems so slow. Everytime you click on increment, it goes through the entire internet, ask for +1, and get the answer, then update the page. - easy things will be easy, but even the average things are going to be hard. Every time you will want something that is not provided out of the box, the workaround is going to be painful. - you are coding with react, one of the most complicated framework there is, but with a layer of indirection turning it into a black box. You better hope everything goes well because I don't wish debugging that on anyone. - the database layer is going to bite you if you start to get fancy. Guaranteed. - if you need this, you probably can't assess security. So no way to know if your website is secured. In fact, you can pretty much bet it is not. This means if you use it for something big, you will eventually hit some kind of a big wall. Or something kind of painful experience that will possibly harm the project. But of course, if the alternative is to never having started the project in the first place, you should definitely go for it. The deployment being a pain for most python dev, this alone will make your life way easier, and 99% of projects don't have more that a few requests per minutes and a couple of pages anyway. Just know what you get into: this is a trade off, as everything in engineering, not a unicorn. Also, this is the Y combinator, so I assume there is a bigger plan behind this. Good luck to the creators though, anything that move the needle even is good to attempt. Your > any action your perform means a round trip to the server. This is why the counter seems so slow. Everytime you click on increment, it goes through the entire internet, ask for +1, and get the answer, then update the page. Seems inconsistent with OP's > the frontend compiles down to a React/NextJS app, so from the end-user’s perspective it looks like any other website In another comment, OP explains the framework uses websocket to send and get values from the python functions you declare. The python functions are NOT executed on the frontend. Gotcha. So the basic "structural" stuff is translated to JS but any non trivial logic remains on server? That's my understanding. While it is possible to run Python on the browser, the typical solutions to do so has a lot of drawbacks: - brython (https://brython.info/) doesn't work with pip, doesn't implement full python spec, and has very limited tooling. I never could find a use for it professionally. - pyodide (https://pyodide.org/en/stable/) is very slow to load and execute. It's mostly (but very) useful for teaching. Plus, pynecone would have to solve the complicated problem of finding out how to delimitate what's python on the server side and on the client side, which we don't see in the API (and would complicate things for their target customer, somebody with little web dev experience). So the decision makes sense knowing their goals and constraints. You just have to understand the price you pay for it: anything calling a python function will cost a roundtrip. You will have to write you app with that in mind, and don't expect miracles either. I can see myself using the product when I need to hack something quickly that is a one page interactive program. Or for some one of my clients with quants, geographers and the likes, that often needs to make a small utility available but have only knowledge of basic python. It also could be a good companion to tauri (https://tauri.app/) to create desktop app. To me that would be even more valuable to have finally an easy way to do a decent UI in python. Because QT, WX, GTK and Tkinter are not fun at all, and the web is an amazing platform. I just hope they are not going to eventually lock you into their hosting solution. But given that it's on github and open source, I feel confident. Plus the doc is very good, which is a sure sign of good human beings presents in the team. Try using the example with WiFi off. The counter increments when WiFi is turned back on. OP is misleading. That sounds like something you could write either way (update first, update after success, update in a gray or provisional-looking way until server success or error) in any react app, depending on your needs rather than a property of this framework. Sibling comment about Websockets perhaps more interesting explanation If the update business logic is server-side (which it probably is if it's written in Python), there's no way the front end can update without connectivity. Anything else would imply some neat but difficult transpiling of Python to JS/webasm to make that update code available in the frontend. Plan probably is around a hosted apps model where apps can be embedded in iframes or similar. Vercel to fly, everyone is basically selling a flavour of Heroku with a desirable outcome of lower maintenance overhead. But yes, it is a tradeoff and the abstractions underneath are leaky. It is not just React but NextJS and then the whole NodeJS ecosystem which is surely one of the most challenging ones. That client/web part could have been tackled by writing a micro library in pure JS with no transpilers of any sort - and probably they might do it in future not sure how, but something like Brython[0] could be interesting. > any action you perform means a round trip to the server Meaning your server-side app is not stateless? Is there an instance for every client? Since it's using websocket, there is no way around that: you need to have some sort of persisting instance for every connection. I'd love to see something like this. I'm an old computer science guy and would love to write software again. I can write plenty of functionality in Python but I don't really want to learn all the JS stuff. I just don't like it. If I could abstract away the details it would be a big help. I'm not going to build anything that requires scale or commercial performance so I can afford to compromise versus the "purity" of having your own stack. > ...I'm an old computer science guy and would love to write software again. I can write plenty of functionality in Python but I don't really want to learn all the JS stuff... Back in early 2000s, i used to be more of a front-end dev...but over the years of being more of a manager (or PM or product manager) i stepped away from daily development...So, you know, I lost my touch. But a few years ago when i tried to dip back into things again, i got turned off from needing to "learn all the JS stuff". It feels all so bloated and so much work for what to me seems minimal gain. Nowadays, i much prefer back-end development (not that iots easy, but maybe it just clicks more for me without so much JS stuff)...so when i see frameworks like this one, i get more interested. I'm in exactly the same boat. Ive managed to keep inntouch with core tools on the backend, but frontend has just withered on the vine, so to speak. Learning all the JS stuff is just too hard when combined with back end, data, auth, layout, display, responsive, etc. > ...when combined with back end, data, auth, layout, display, responsive, etc... Exactly! Glad to hear I'm not alone in that boat! :-) Room for another one on that boat? : -) Permission to come aboard? Check out htmx. Thanks for this recommendation! I had actually already added htmx to my "need to research/review" list of bookmarks... since it kept coming up in HN comments so often. Now, i guess i can move it up a tad in priority. Then you might like Rails 7 which defaults to Hotwire for a minimal-JS front-end. In simple terms, what does Hotwire mean / provide? Hotwire allows you to handle front-end page/view updates and state from the server instead of relying on an SPA framework. Rails sends the minimal amount of JS to update the page without a full reload and for many use cases it's all you need. When you click a link configured with Hotwire turbolinks intercepts the call, fetches the new content from Rails and strips out everything except the body tag and its contents then uses that, with a sprinkling of JS, to update the page/view. That's sounds pretty good, actually. Try Svelte What makes Svelte easier than other approaches? Have you tried Django? https://www.djangoproject.com/ In my experience using Django for my webapps hasn't meant I can avoid HTML and javascript. Writing templates is writing HTML, and any relatively fancy UI including charting etc. requires using javascript I built a recent Django site that only used JS for analytics and to implement the close button on a modal. You can do charting using server side rendered images pretty easily, especially as SVGs (although I concede, dynamic charts client side are a better UI). CSS is harder to escape if you want things to look fancy. Given the update latency pynecone has, I can't imagine a charting library would work well. well, I am not sure how you can build a webapp by avoiding HTML, JS and CSS. It could be a nice option for small projects! The companies where I saw Django in production had terrible issues. Last.fm is one of them, I can't speak directly about the other one (aerospace). Django is good for a proof of concept but once you hit real-world requirements or your developers (inevitably unaware of the nuances of Django) start adding code and exceptions, it completely breaks down. Django was a good idea back when PHP was the only way to make "interactive" pages. Nowadays -for big/real projects- is just asking for trouble. Long time ago -for a personal project- I used CherryPy, which is simpler and easy to learn. I don't know where it stands today, but it's another option. Yeah, Django is a nice option for small proof of concepts like Instagram. I'll try! Last.fm started many years ago, in the early '00s (pretty much like Django!). They decided to use Django to serve their website and API. As the years went by, some issues and limitations started to show up: the API has several quirks they can't fix, the frontend -even after the redesign- is slow, and interactions feel clunky and outdated (like early AJAX attempts). The API can't be easily modified -and sometimes XML responses have info JSON don't-, the website is stuck on being served through the framework instead of relying on a modern API... They even have an "old" and "new" database for albums, so when you query some of the albums through the API they come back with no tracks because the API is in the old codebase. It's a mess. And from my experience with Django, it feels a lot like the difficulties we had trying to scale and improve our existing code. It's not that you can't do things: it's just that Django isn't agile enough to adapt. You end up adapting to Django and its -beautiful and magical- ways. Of course we could blame it on poor design choices, lack of Django knowledge or just call it technical debt... but I believe the framework is the major culprit. For context: I haven't worked for last.fm, but I manage a third-party client (Open Scrobbler). I've been using their API for more than five years now, had interactions with their devs, read many replies in the API support forum and even tried to find undocumented endpoints that could help me (during this time I found some old profiles and test pages where you can even see screenshots of Django logs!). > but I believe the framework is the major culprit. Yet somehow the decades long popularity of Django, it's widespread usage and presumably many successful real-world deployments doesn't make you question your own belief? What you described would have happened with any other framework available at that time when you make poor design choices. I don't see anything django specific there At first I was very skeptical, but after looking further at the examples I feel like you pretty much nailed the developer experience. I have not used this yet but I will definitely check it out. Is there a roadmap? I see the GitHub project board is pretty focused on v0.1.20. I am curious what are your plans for client side code via wasm? I feel like that is a critical missing piece for me. Thanks! We're using GH Projects for everything, we will update the board with a more long-term roadmap. Python support for wasm isn't where we need it yet, but we definitely want to integrate it when it's ready. What do you think is missing? I think a big thing is the limited supported libraries as of now. Isn't also just the fact you need to send over like 7MB of wasm for even just the standard library? Presumably you could optimize that by analyzing a running site and stripping out the unnecessary libraries. I'm sure that will come with time. My opinion on this : * Web with python : yes, make sense, python is very friendly it's kind of the closest to no-code we can do * No benchmark : ouch, no way I am touching this without knowing, at least in the big picture, what to
expect * Front-end : so this is a wrapper of Chackra UI which is itself a wrapper of React (which is the slowest framework out there) -> not really what I am looking for. I can understand that for some quickly made website this can be OK. For a serious dev I don't think this will have much appeal. I guess you need to target casual users. * Not much bloat on the dependencies so this is quiet good on that front, I was expecting way worse. * Your a startup and backed by YC and I see no business plan, priced service nor anything alike This is very suspect, for me as long as I don't understand how you are meant to work in the long run I will not involved myself using your library. I am probably not your target user, I will stick with flask/tornado for prototyping my back-end and use lesser known but amazingly light and fast front-end framework. Good luck going forward. Any source on react being one of the slower frameworks and recommendations for alternatives? Just asking out of curiosity. I've been using Angular at work and always heard that React was a more performant framework. https://krausest.github.io/js-framework-benchmark/index.html My personal favorite is Svelte ChakraUI isn’t a wrapper, it’s a component library for React. Also one of the best imho. If you don't mind, can you clarify what is the fast front-end framework that you mentioned above? I think they had a typo and meant to say Chakra UI: https://chakra-ui.com/ I went to the button component page [1] and to the section of the counter and two increment and decrement buttons. Clicking on either takes something like 0.5 seconds for the counter to update it's value. Using Android and Samsung internet. Edit: I took a video screenshot
https://voicer.com/v/HSpS9 I also had an irritating amount of delay on that button. Also using Android (GrapheneOS) with the Vanadium browser (Chromium-based). Edit: Seeing the comment about websockets and server location, I am in the EU so it's possibly that. I don't get why state of the frontend is stored on the backend though. Seems an obvious performance issue. We use Websockets for state interactions, so the latency may depend on your internet connection + distance to server. We will improve this in the future by leveraging more edge computing and WebAssembly to execute closer to / on the client. Why is the frontend state stored on the backend? The state is updated through Python functions that are run on the server, so the state needs to be on the server Why don't you just transpile the frontend Python code to JS at build time and just have normal HMTL/JS/CSS in the final deployed web app with a Python backend? You've mentioned no-code tools. For a client, I had to work with the no-code tool Bubble a lot. They do something similar, where the front-end is not built statically but dynamically and uses WebSockets to communicate with the back-end. I don't think this is a good idea (and that's why Bubble is also trying to switch to static pages now, but you can imagine what it takes to do that once you reach a certain size). > front-end is not built statically In fact the Pynecone frontend is built statically. But UI event handlers are run on the backend. The latency scenario is identical to if you used HTMX or Hotwire or a traditional web server. You click, it gets posted to the backend, an output comes back and is rendered. The click counter thing is contrived and maybe Pynecone should have avoided centering on that, since the users they're targeting for sure don't care about frontend-only click counters. Is it possible to take the optimistic approach and update the UI before getting response from the back end? Obviously for simple things, like counters, that need an immediate update to the UI. You could designate some handlers to be “frontend-only” and then compile them to wasm or js and run them in the browser. There might be usability/ergonomics issues with having “special” functions that don’t really work like normal ones. Edge computing isn't a universal fix. At the moment I'm on a corp network that routes traffic through a proxy a couple states away (security reasons), I rarely see <200ms latency and occasionally see >500ms latency. The counter and slider example don't feel right at that latency. Also, I turned off WiFi and then clicked the counter a couple times. Obviously the clicks didn't render. When I turned it on, then the counter updated one at a time at what felt like 300ms intervals. I often use the web from the train as I commute and data service can be spotty. I expect I'd see input latency in the minutes if I tried. I think this is only viable if you're certain all your users have ping <100ms, and are on stable connections. If you have to use this model, try batching user events (10 clicks => increment by 10) and cancelling old events (slider events at 5, 10, 20; only send slider=20 event). Same here, but I think it's because that's not really a good use case. If you are going to use it to actually run some computations in the backend (that have to be in the backend, say, GPU-powered ML stuff maybe? Or anything else that you can run easily in Python but not in JS) then it sounds like a good alternative. I inadvertently built something similar: We should talk. If your open source roadmap includes getting rid of your npm dependency then we might just migrate to Pynecone for our front-end. I'll second this sentiment. In earlier life, I authored this exact product (including distributed deploy) for a large investment bank and a fintech startup :) This is immensely valuable to a lot of Python devs, especially in finance/quant community. Great work! Edit: The reason why this is so impactful is b/c most users have no idea how to build a react app (along with the circus of build/deploy train one typically entails). They just want a quick-and-dirty UI for their Python model they developed in Jupyter or similar. If the model has legs, a separate FE dev would build a fancier front end later. Thank you! Glad the finance/quant community can find it useful! Wouldn't Django or Flask with Stimulus and Turbolinks be a better option? The hard work has already been done. Looks promising specially if it is available via Open-source with the choice of self hosting. It would be great if you add a library to make it easy for sign up and login to the web apps as this is a feature that is universally needed. (And if you do please keep it part of the OS version)≥ We definitely will add these auth components to the core library Upvote for this request! It's really not some pleasant experience to implement all this in Streamlit. Should also support some third-party authentications. It took me a bunch of iterations to figure out the value prop, but hmm...it's actually pretty good. I can see all the SwiftUI[0] inspiration in how to make compositions, instead of relying on CSS only. Recently there was Rux[1] which is JSX in Rails, but that is really only dealing with ergonomics oh having Components in a nice DSL. Then there is actual deployment story. I recently made a DRF + Next App, and I spent too much time thinking about deployment. And yea, for the volume I need to server, having a single artifact deployed, with SSR, is wonderful. How is the intellisense support? That's one of the best features of recent JS/TS frameworks on VSCode, and I don't use JetBrains IDEs. Are there JS/CSS escape hatches? Is the goal to focus on speed of deployment or, a Python DSL over JS libraries? Good luck either way! [0] https://developer.apple.com/xcode/swiftui/
[1] https://github.com/camertron/rux I'm extremely familiar with both Plotly Dash and Streamlit, two frameworks which accomplish the same thing. How does this compare? Please please tell me you're aware of those two and didn't build this unaware of those options. Background:
I was commissioned by a previous employer to fork Plotly Dash and build a drag and drop BI tool with it. This looks cool. As someone who is CSS challenged, I have been waiting for more frameworks like this (seems similar in concept to pyjamas/vaadin/gwt). Ideally, with an even lower barrier of entry and hopefully well maintained. EDIT: I see that the website is generated using pynecone itself. Looks very nice - cool stuff. I started as a backend dev, moved to full-stack and initially didn't find JS too alluring. I've since liked JS for frontend stuff (not so much backend still). I _really_ like Dash for some things but quickly find myself hitting the boundaries of it's use cases. I will def have to check this out and keep it on my radar. I used to work for a consulting place where we would have to spin up tons of one-off apps and this seems perfect for that. What are the edge cases of Dahs you ran into? Basically handling user input/dynamic content becomes a bit painful. Usually this is just a case of trying to extend Dash beyond what it was designed to do though. Say for example, you have Model A on a server which has parameters X, Y and Z. To load Model A in Dash is easy enough. To load its parameters as inputs with all those callbacks and imports becomes a bit messy. I've found react to just be better for that, at the end of the day. The delay in increment/decrement example is not acceptable for a web UI that is expected to update instantly. I believe it should be less than 150ms to become noticeable for the user. There are a few others - https://pynecone.io/docs/library/forms/slider for example Using the top slider on that page, try dragging the slider back and forth quickly. Random numbers will pop up at 500ms(?) intervals. When you let go of the slider it will keep updating with random numbers for a long time (I watched it go for 30 seconds). > For performance reasons, you may want to trigger state change only when the user releases the slider. Not a great workaround, now I can't see the number I'm selecting. With the 500ms render time, it's going to feel really slow to pick a value. The perf needs to be fixed for this to be usable. It just desperately needs some debouncing.. Why is the counter demo so slow? If you are compiling to JS/React I would expect it to be close to native perf no? Because the logic is being processed at the backend and the data being transferred over WebSocket Huh it totally is. https://pynecone.io/docs/state/overview outlines that is the case but leaves out the detail that it's using Socket.io. Gather if you want to use this then and have it not suck you are going to need some form of edge compute. Wait, it can't generate static sites? This is gonna melt if more than a few hundred users join. Python's socket.io implementation is slow at best. Something tells me it's not designed for hundreds of users and more like "Here is my data-scientist quasi-code thing and I want a web interface for it to show the non-code folk in my business unit". Fair enough, that does seem like the most common use case. The slider component needs some work. Would be nice to have the option to update the local UI in realtime as you slide, then send the state change once it's dropped (on_change_end). Right now it's way too laggy and feels unnatural. And you can't be precise with the slider unless you have the indication it's in the right place. I haven't seen anyone mention Anvil[1] yet, but it lets you "Build web apps with nothing but Python." and is lovely tool that I've successfully used for a handful of side projects. But as someone who feels most at home with Python, I always love to see new competition in this space. EDIT: My following statement about self hosting is incorrect. You can, infact, self host. This looks wonderful, but the inability to self host is a killer from the solo developer point of view. Being limited to 50,000 database rows on the free account isn't ideal. Anvil has self-hosting! Just "pip install anvil-app-server" :) https://anvil.works/open-source (I'm a founder) Well, I stand corrected! I was looking through the mobile site and didn't spot it. This makes me want to look a bit harder. When self hosting, do you gain or miss out on paid features? I totally thought Anvil had self-hosting. I was seriously considering it for my next project. Now not so much. One of the founders corrected my statement. Apparently you can self host. Nice! I haven't seen this one before. Will definitely take a look. Thanks for posting. Is this similar to Unicorn for Django? https://www.django-unicorn.com/ It does seem very familiar to me. Down to the counter example: Would love to see someone building a web project with this from scratch. Preferably a Twitch stream or YouTube video. This will be so useful for Computer Science students to easily have an app ready right after their first semester. (Or even Stats major, etc) Often times, a webapp creation usually involves student learning JS and all the ecosystem. Thanks! Definitely, we do live streams of this on our discord I'll make sure to record them in the future! Could you add links to this part? Join the growing open-source community of Pynecone developers. 3000+
Projects created per month 5700+
GitHub stars 600+
Discord community members Looks great. I am excited to play with it. One nit, on your landing page it has a typo, missing "framework /that/ doesn't"
> Never get locked into a framework doesn't support your existing tech stack. Also, your Gallery has highly responsive SPAs, but for some reason the counter here[1] is very slow on a cold load Love the idea. As someone who's not trying to build The Next Big Thing (TM), but just get some stuff done - I appreciate the focus on the basics. A lot of the python webui's are heavily focused on AI/ML related stuff, which is cool - but what about those of us who just want to build an internal tool that does 5 specific things and nothing more? I try to avoid javascript if at all possible, so "python front to back" is really appealing. > A lot of the python webui's are heavily focused on AI/ML I'm sorry, what? They probably meant that most of the time Web UI is implemented in Python, it is by someone who does not care much about design and complicated interactions and does not want to learn JavaScript, it is someone doing AI/ML who just wants some buttons, sliders and charts to quickly experiment. Gradio, which is similar to Pynecone, explicitly targets this audience and frameworks like Streamlit and Dash are also used by AI/ML community. I assume GP is referring to frameworks like Gradio (https://gradio.app/) and to a lesser extent Streamlit. Existing web UI frameworks for Python are somewhat opinionated around particular use cases, of which AI/ML is a prominent one. Yes. As the other commenters said, and perhaps I should have been more explicit. When you look for python web application frameworks, there are the traditional answers like django and flask... but when you try to find something that's more "webui included" there are also a lot of newer solutions (as mentioned, like Gradio) that are specifically designed for ML. As anyone in the Python world knows, it's a super popular use case for the language these days. I've just happened to run across a few of them recently as I was looking to see what else was new out there for easier ways to build quick and dirty web apps. I love this! This solves a big problem for me, which is writing/packaging/deploying JS/HTML. Question: I see that the ORM assumes a SQL backend. Do you have any plans to support key/value stores, or is it easy to change out the ORM? I'm thinking this would be perfect for deployment into AWS Lambda for the backend, Cloudfront for the front end, and DynamoDB for the data. The ORM is a wrapper around SQLAlchemy, so only SQL databases for now. But since everything is in Python, you can still connect to any other database/service like you normally would. This is amazing! Definitely it has advantages over Streamlit in terms of utilities and customization. Please change the name, if you can, as it's conflicting with Pinecone, another good tool I use. Totally agree on both the incredible utility of this -- but also the name change. It feels like there's way too much overlap between these two. Before long we're going to be building a UI for "Pinecone" using... "Pynecone". That is just too confusing! What is / which Pinecone? I'm not seeing any one obvious candidate in the GitHub repo results if this is a popular tool. https://github.com/search?utf8=%E2%9C%93&q=Pinecone&type=rep... Pyscript is a reasonably popular client side Python in the Browser solution so wondering how your positioned with regards to them ? I like it. Reminds me of Vaadin and friends. One question regarding the states: when do I get a new State allocated? Is it with every new tab? It's definitely not per-browser-session: if I open a new tab I seem to get a new state, while undoing a closed tab seems to recover its state with it though. Also are old states gc'ed? Each new browser tab creates a new state. We use Redis to store the state and expire it after 30 minutes. Nice to know, thanks! I am not very familiar with how modern Python wsgi servers manage states, but in Java e.g. states can be cached in the heap of the one and same JVM --- can one say that the need to use an external state store like Redis is a direct result of the underlying web server having to launch multiple Python processes in order to scale up for greater loads? Does that place some restrictions on what can be done with the state? e.g. does it need to be pickleable and relatively small since it needs to be loaded from redis on every event? (Pretty cool, btw! Congrats on the launch) We use the `cloudpickle` library which supports most data types. We found the state size doesn't impact performance too much - our main website's state is quite large but the Redis loads stay fast. There are other apps with somewhat similar philosophy like Plotly Dash. The problem I have faced is that it's almost impossible to debug because you cannot step through code the same way you could in a JS app. Do you plan to solve this? It really reminds me of https://github.com/miyakogi/wdom but also https://github.com/jupyter-widgets/ipywidgets and https://github.com/flexxui/flexx The only different aspect is that the goal of Pynecone seems to be web apps over the network and not web interfaces to local programs. This looks fantastic! I've sent it to my friend who's built a few flask websites and always complains there's not enough python web frameworks, I've got one suggestion / question that sounds a bit odd... On this page [1] when I press Decrement / Increment it feels like there's well over a second delay. The API seems pretty similar to Streamlit, another library to create data apps with Python Given thar it’s more popular compared to Pynecone based on Github, how do you plan to differentiate?
I would love to hear about the way that you compile to NextJS because that’s a challenge with Streamlit. I have looked into your docs for custom components but I wonder if it’s possible to use compiled NextJS and bring my custom components there instead of bringing my components to Python? I think the biggest differentiation is that Pynecone apps are completely customizable and don't re render based on State changes. Streamlit is great for dashboard type apps but when you want to expand on your app you can be limited in terms of flexibility and customizability. The whole Pynecone website is made in Pynecone vs other frameworks like streamlit cannot do this because they are limited in what they can build. See here for bringing your own components: https://pynecone.io/docs/advanced-guide/wrapping-react This is absolutely true. I love Streamlit whenever I need to get a small proof of concept off the ground and hate it the moment I need to customize it even slightly beyond the rail guards it puts in place. Congrats. Looks really cool! I'm curious how this compares to other efforts like this such as Streamlit? I do like the fact you compile to React/Next.js as that opens up the possibility of tapping into that rich ecosystem. Also others have mentioned, and it might not be fair, but the name Pinecone (and variations) has sorta been taken at this point by the vector DB startup since they launched first. So I'd just bite the bullet and change this before the cost of switching rises later on. Thanks! I mentioned how we are different a couple comments previously. Yeah we are looking into your other point about the name, noted. Niiiice ! So we should also be able to unit test ou components in pytest and debug them with PDB ? Gonna check this out real soon :) As a react dev turned django dev, I cannot wait to get my hands on this! Edit: how come the counter example is so slow on my iPhone 11 though ? That seems real weird https://pynecone.io/docs/getting-started/introduction Looks similar to Nitro https://nitro.h2o.ai/ and Wave https://wave.h2o.ai/ - both open source. Nitro already works with WebAssembly via Pyodide. (Author here) Hey! What's the difference between Nitro and Wave? Wave seems like a great fit for my usage. Nitro has no events or callbacks. To display a page, you call a function, and the return value of the function is a tuple of inputs entered by the user. You then deal with those inputs, and display another page, and so on. There’s no ceremony. Like the readme shows, a seven page app is just seven statements one after the other. This paradigm makes it possible to write incredibly compact code. As an example, here is a macOS calculator clone in ~50 lines of Python: https://twitter.com/crunchingdata/status/1563300652918325249... Maybe this is a silly question, but why not target WASM instead of React/NextJS? We definitely plan on doing this in the future to offload on the server. Unfortunately python WASM libraries aren’t at the level we would need yet. Thanks for the answer. Maybe it would have been better for me to ask if you are planning to improve the python WASM libraries yourself or are you going to wait for the existing community to get them to the point where they're usable for a project like this? Both, hopefully we will have some time to help contribute. This is great. I received a lot of comments on my previous Python web apps saying it looked kind of scammy or it looked really old. Glad this came out :) Nothing beats true productivity like a frontend Python stack. Streamlit was nice but it was built for newbie web developers - not web developers who didn't want to touch JS/TS - whereas this hits that niche quite well. This is wonderful and a much welcome addition for those of us who don't need to pixel peep but still want to assemble a web app quickly to test product market fit. I'll certainly try to get a feel for what you built and how it differs from stuff like Streamlit. I have a love hate relationship with the latter and constantly looking for a more mature and faster moving alternative. I've tested Pynecone recently and it's pretty good. I'm wondering how do you intend to create a business around this library. Thanks! We're building a hosting service that you can deploy your apps to. Our plan is to have a free tier for your first app, then charge for additional apps. We're still finalizing this, so would love to hear any thoughts. Interesting — what kind of advantages would your hosting service provide over, say, packaging the Pynecone app into a Docker container and then deploying to Fly.io/Render/GCP/Azure/etc? It would be cool if you could create a payment component that just takes money off the top. Than anyone could build practically an unlimited amount of saas apps not worry about hosting and if they get paid you get paid. One reason I looked at Dreamhost for hosting is they have an unlimited # of websites tier that is super cheap(sucks because it's php). If you can't build a payment component then some kind of pay as you go option would be cool. Second this. Would love a payment component that is very low config (e.g. set Stripe creds) where some portion is taken off the top. It would be nice if there was a consideration for the app being opensource for the free tier, and also integration with Github --- it would be way cool to be able to specify that a Python file on Github could be used as the source for a free app on your site. Well done. Nice idea. Cool that YC invests in open source developer tools. My only concern would be the time old problem of another level of abstraction. If the user has a problem they need to see if it is their problem, your problem, or a nextjs peoblem. But it might be worth it for Python enthusiasts to use there language. The single file frontend/backend looks very compelling too. Love anything that helps developing apps without knowledge of react or typescript etc. I’ve played quite a bit with Streamlit, and I know lots of demo apps are built with Gradio. These two tools also aim to help build apps with only python. I remember my Streamlit app code turned into a mess when trying to manage state to support multiple user interactions. Any comparisons with these frameworks? Thanks Nice product!
I'd be interested to see what it looks like to integrate an old-school style JS "component" like LeafletJS, especially with a plugin like this: https://github.com/Leaflet/Leaflet.markercluster Impressive that your demo on wrapping React (https://pynecone.io/docs/advanced-guide/wrapping-react) only downloads 2.2mb. That seems quite low for both React and your library. Promising tech! Hello Nikhil and Alek! Pynecone looks great! I saw your Show HN a couple of months ago, but I hadn't tracked its progress since. I'm a fellow founder in the Education space; would you be interested in building a series of "Tutorials" (we have to find the best shape for this) of building Pynecone apps? Yes that sounds interesting, let's discuss more! Awesome Nikhil, I'll shoot you an email. We're in the Data Science education space, so even if we don't end up collaborating, your feedback will be highly appreciated. In the documentation, I don't see any mention of including external libraries. For example, do you have to do something special to use this nostr library with Pynecone? No you shouldn't have to do anything special, external libs should work as normal when used in event handlers. I see none has mentioned h2o wave. If also let's you code in python, manage state (per tab/session/user/global) and has a bunch of prebuilt components so you don't have to write html or java script. But what's the difference between them? Idk! You should feel really proud of building something so big! That being said, what's with the bad performance? When I go to this page on Mobile: https://pynecone.io/docs/getting-started/introduction and I press the "increment" button, it lags. It's subtle but would guess it takes over 100ms to respond. If I mash the button repeatedly, sometimes it will actually lag so bad I can watch it continue to increment to "catch up" after I've stopped pressing. As a professional full stack with specialization on frontend, this is not something I would find acceptable in boutique products. Thanks! We are in the process of making it faster, the projects still new and there's a lot of different ways we can improve and speed things up. Especially since we want to start incorporating web assembly in the future. This looks really interesting for a simple way to build a rudimentary but full-featured webapp, for example for the intranet. But I wonder how this can be used with `asyncio`, since the handlers are pure `def` and not `async def`. Searching the docs for `async` does return any results. I'll look why the search doesn't bring it up - see our event chain example here for how we do async event handlers: https://pynecone.io/docs/state/events Great! Thank you. Maybe also showcase an example on the landing page, like making only the `def decrement(self)` an async function. As someone who basically focuses on infra engineering, I sometimes want to throw together quick UIs for automating stuff. Always been terrified of React/Vue. This is practically a godsend - can't wait to build some tools for myself. Just tried signing up for the hosting waitlist, but the webpage errors with "The domain name zzz@domain.uk does not exist". I'd suggest removing whatever checking is in place there, unless you plan to keep the gTLDs up to date. Thanks for pointing this out, will fix I took a look and didn't see any element to show video (real time video streaming? showing a webcam demo maybe?) which I find like an interesting application.
Making GUIs is always a fair amount of work/overhead on whatever you are working on, and I like to stay in Python when possible (I've used REMI (https://github.com/rawpython/remi) to create web apps before in Python). Thanks for creating this. I look forward to updates! My only interaction in this space is helping out a friend of mine with Streamlit. I'm surprised you haven't mentioned anything about it in your HN comment, given it seems, at least on the face of it, extremely similar. Are you able to go into a bit more detail about why Pynecone and not others? Did you ever consider contributing to Streamlit instead or forking it? if so, why didn't that work out? What do you do better? Etc. Disclaimer: I'm not too knowledgeable about this niche, however, so if I'm very off-base here then please let me know :) We didn't consider forking it because our architecture if fundamentally different. This allows us to customize our apps more and make larger apps. We compile down to a react/next app vs streamlit who uses tornado and has to re-render based on changes to the app. I think the idea's behind the projects are a little different. Streamlit - small data science apps vs Pynecone - A more generalized framework to built a broader range of applications. Thanks! I asked a question and now see you had already answered it. For those who are curious why these frameworks are great: I'm an experienced full stack developer, and I can write React apps in my sleep and I've used a bunch of different state management frameworks including redux/mobx/etc, but my current startup is a back-end API as a service company and I simply don't have the time to hand-code front-ends with whatever flavor of the month developments in the JS front-end ecosystem. Frankly, I'm sick and tired of the entire front-end ecosystem. It changes too fast for very little gain. So so so so many new tools that empower you but then come with baggage. I don't want to deal with it for some internal apps or basic things like allowing my customers to check their usage balances.... this looks promising! Thank you very much for the insight. Best of luck with the future of your project. I posted an answer to this in one of the other comments but in short Pynecone is much more customizable and flexible in terms of what your can build. Just read it. Thanks! I agree that Streamlit was very limited feature-wise. Basically for extremely simple PoCs, etc. I like how you dog-food Pynecone for Pynecone's website :) Very cool. I tried building some demos, looked at the code. I agree with the comment about being somewhat like SwiftUI (which I like, even though I have only published one app to the App Store). Looks cool. I am not a web dev. How much Javascript/React/NextJS do I need to learn to build rich custom UI components+behaviour? Can I do it in entirely in Python? Yes its entirely in python. No Javascript/React/NextJS needed. Do you need to know Javascript to use externa library like Plotly? At first glance this looks very cool. For me to be able to write a cool test app I'd need a working date picker and some kind of radio button feature (so that I could ask you to select a date and then display a list of offers on screen to select.) I checked the docs and it seems there's a radio button, but no date picker yet. Plus maybe the option to push a pdf result. (My usecase: I'm a backend dev for a booking api and it would be fun to quickly build a frontend to test the API on my phone) Very cool that you built your own production site in Pynecone! How does Pynecone differentiate from Streamlit, Panel and Dash? I've used some of these in the past and they're 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 Thanks for this. I'm interested in how you compare yourselves to dash in particular - having a quick look at the network calls, the way you interact with the back-end looks fairly similar. I've written some relatively complex apps in Dash and have been hitting some limitations there, so I'm keen to see how Pynecone might help get past some of these. It makes sense. These are also dashboard focused and not for general apps. I'm also reminded of ipyvuetify, but that one is even more limited, focused on widgets, works out of Jupyter notebooks but can be hacked into a dashboard using Voila.
Very interesting, looking forward to trying Pynecone out one of these days. Seems nice, but also very basic. From what i've seen in the examples, the components lack any deeper interaction-ability. Tables seems to lack editing, or any more complex filtering. There is no tree-component (heck, why are all those framework lacking trees?) or any kind of drag n'drop-support. And so on... So seems to be more for creating basic forms and documents, not a state-of-the-art web app. It's funny that I'm currently going in the completely opposite direction of using JavaScript to build AI apps (with tensorflow.js). I'm a frontend dev of course. I think using one language for everything does have the benefit of reducing context switching. It's about picking your comfort language for higher productivity, while making sacrifices somewhere like performance and less idiomatic. It’s pretty obvious that cloning ML APIs (which are a collection of well defined independent math operations) is a better long term solution than shoehorning an entire language into the browser. One other recommendation: If you can please don't build the code as Class based. We front end devs thankfully have moved away from this gross paradigm with react and other libraries and frameworks. I do believe this move towards functional code has been one of the reasons the Frontend has had such a rapid improvement in developer tooling and output over the last decade. I think they struck the right balance. Pages are declarative functions much like React and they only appear to use classes for state or component wrappers. Is there any plan on releasing user management libraries or is there a library you would recommend that interfaces with the ORM? This is really interesting so far. I think I've found a bug when using f-strings: so thankful that this space keeps evolving. modern vanilla JS/TS isn't so bad but as a backend engineer I just cannot stay up with all the associated tooling required for building, packaging, etc. with front ends. When it's time to put up a front end for something, my productivity craters to like 1% coding, 99% struggling with JS tooling. This is really crazy. Are we running out of words to name companies: * https://pinecone.io/ - Long-term Memory for AI * https://pynecone.io/ - Frontend. Backend. Hosting. Pure Python. Just one letter difference 'i' -> 'y'. In other context I would suspect phishing. How performant is it? It seems like there's a slightly visible lag in some of the interactions (button clicks) in the docs. It's probably because the state is managed in the server rather than the client, so you will always be beholden to network latency at some level. This sounds fine for a very narrow subset of use cases which follow the Happy Path but a complete disaster for anything else. I mean, come on, there are so many React devs who struggle to get it right so how on earth is a Python abstraction layer going to be any better? Just learn JS. I'm not arguing with you, but I'm curious why you'd think a person should "Just learn JS" if you also seem to think that people that know and like JS can't get it right? Isn't the purpose of libraries like this to remove the burden of "Just learn ____" from solving similar problems? Lol what a silly opinion. I love this. I tried to get a small PoC working last week and encountered a bug on a very trivial case (rendering a python list to an unordered list element), so may be a bit early for my blood, but I'm excited to see how this project matures and will continue to follow along! Thank you! Feel free to put a GitHub issue ill try and fix asap Does https://pynecone.io/docs/database/overview use a SQLLite database on the front end (ie a cross compiled version in the browser) or on the server? Pynecone comes with a built in sqlite database on the server only not on the browsers. you can also easily connect to any external db by changing the pcconfig This was interesting, saving user state back to the server. >> All user state is stored on the server.
Behind the scenes, events are sent as API calls to update the state on the server. The state delta is then sent to the frontend, which updates the UI to reflect the new state. Interesting stuff. A few questions: How does it scale? Your deployment example (self-hosted?) just shows you how to run what looks like a simple server. Do you just run a lot of those and throw a load balancer in between? Any thoughts on integrating with Django, FastAPI, or Flask? What about mobile apps? Went to your docs, saw the counter, pressed the button and saw a delay on increment when clicking a button (the simplest utility imaginable).
I don't want to hate, but if THIS has delay I don't even want to think about more complex state updates. We are working on improving the performance, we are still pretty new but there are a few different ways we can speed state updates up. For state updates like pressing the counter a lot of times it can been seen, we will improve this. Congratulations on the launch! At least the site and the example counter app seem heavily dependant on low latency. I'm overseas and it took a second or so for the hamburger menu (on mobile) to open. Maybe pairing this with edge hosting service like fly.io would make sense. This looks pretty clean, I actually built a framework when I was at Bank of America ~9 years ago called webgems that’s built on very similar architecture. Even using the repr for rendering nested. Curious if any
Contributors worked in it. So what makes this better than Streamlit for example? Either today or in the future So the state is managed by backend similar to signalr blazor? If this statement is correct then it's safe to say this approach doesn't scale well. What would have been interesting is creating blazor web assembly equivalent for python. Looks really promising. Have you consider some sort of framework construct to more clearly denote where code runs? Might help readability and make it easier to understand perf implications of code vs the model you have now. Whats the landing page design style called? Vercel? Are they the ones that did it first? I see it everywhere. Because I noticed vercel doing it first I think every website that does it is a vercel company. As a somewhat active Dash user, I wonder why is it that most of these frameworks have chosen to go this "write-HTML-in-Python" way, instead of what seems to me a much more natural approach: write some basic, stripped down HTML/CSS in a separate file, then connect that automatically to your backend by e.g. using the right IDs. Let me give an example. In the Increment/Decrement we see the following Python code: I understand that many (most?) Python developers would like to stay away from JS, but I expect that most developers will know 80% of what is needed from basic HTML/CSS in order to do something like this. If they don't, it should be really easy to learn. I mean, come on, basic HTML/CSS is like a foundational building block of computing, and anyway, to write "HTML-in-Python" you still need to learn the basics (and then twist them into their Python doppelganger). I'm also using Dash to create a quite complex multi-page app. And I agree with you, at the beginning, it somewhat annoyed me, that this can lead to very verbose nested statements, but since I started refactoring most code into reusable components (AiO), I don't think anymore, that separated html-files would lead to a better usability. I would have a lot of small html-files.
Also, I want to dynamically set the ids, so I can connect some components.
Hence, I would need to use some templating engine for inserting the ids. This works well with django, which I used for a long time, but I don't think it works with React-based apps, which are very component-driven. I think it's a more natural approach to you (and many others, including me a couple of years ago) because that's the way we used to do things, both on web (JavaScript, CSS, HTML) and Android (Java, XML), and who knows where else. If you stop for a second and think about whether or not it's actually natural, you'll quickly realize that it's not, it's just something you are used to. I cannot give you anything Python specific, but I can share my experience with Flutter and Dart. In Flutter, you build your UI using regular Dart code and it feels great. This approach, btw, is also similar to Compose and SwiftUI (and to a lesser degree, JSX). Here are the pros: You don't need to switch from Java to XML, or from JavaScript to CSS/HTML, you can do everything using the same language. Instead of learning 2 or 3 languages (and their respective tools for testing, analyzing, linting, coding conventions), you can learn one well. You need to do some semi-advanced logic on the button label or classes? No problem, just write the language you write everywhere. An IIFE solves your problem nicely? It's okay, you can just use it. If you like working with Rx streams, or any other library, you can keep using them in your UI, no glue-libraries are needed. Need to debug or add logging, printing, error reporting? Your toolchain already supports that. Your IDE has terrible support for "insert templating language"? Not gonna happen here, if your IDE supports Dart (or in Pynecone's case, Python), you are good to go: you can jump to definitions, you can refactor argument names, and you can lookup usages exactly the way you are used to. You don't need to learn special syntax for conditionals, for loops, and whatnot, you just use your primary language. In Dart's case, you also win with the typing: if a widget expect a callback that receives a User instance and returns an integer, you can define that and making sure that instead of runtime errors, you will see the errors in your IDE as you type. You also don't need to worry about different naming conventions. If you app calls it userIds, your UI will also call it userIds, instead of "user-ids", or "user_ids". I am curious to know how python is transpired in to JavaScript for tricky cases involving promises/async await
Since python usage is quite different from javascript and for promises it doesnt even exists. Only the frontend is compiled to JS/React. All the logic and state updates stay in Python and are run on the server, so we don't have to transpile arbitrary Python. Thanks. I guess this is all quite new but it would help if it was clearer about what can be run where. From this, it seems like the frontend parts can't have arbitrary Python included and it's the backend parts where you can drop in some Python for the logic. Making this clear early will help people get the right mental model of what this is really doing. Anyway, good luck with this! I will keep an eye on it for sure. Is there by chance a CRUD boilerplate/starter (_NOT_ a to-do app)? Question, how does your framework compare with Gradio, the other leasing python/full stack framework that most people are using? How is it better than Gradio, and what additional features does it have? I think the comparison is similar to the comment I mentioned about how we are different than streamlit: more customizable, flexible, and you can make larger web apps So I tried the example in the doc: there is a huge latency between the moment I click on "+" and the moment the counter increment. Is that what we can expect performance wise? What causes this? Looking into it we just have a lot of people on the site rn. Will need to scale it up to handle this traffic Do you mean every time I click on the button, it goes to the backend for incrementing? Seems similar to https://nicegui.io/ which recently impressed me! Will check this out. I was excited while I was under the mistaken impression that Pynecone would simplify Python/WebASM. It seems we are very close to that Nirvana. Cool! I'm working on something similar in Ruby! Congrats on launching. Looking forward to try it. How does Pynecone compare to Flet? I've played with the flet framework and it seems to have a ton of potential. Pynecone is specifically designed for web apps and I think it does better on more complex, larger web apps. This can be seen in Pynecone's main website being made in Pynecone and while Flet's website is made in JS not Flet. Both are good frameworks and Flet has advantages of creating mobile/desktop apps because it compiles down to flutter while Pynecone is great for web because it compiles down to nextjs/react frontend. The response time of buttons is glaring. Is it a quirk of the implementation or that the system is slow? It looks cool, but I'm not clear on what the add is over existing solutions like Plotly/Dash? As this is a “LaunchHN” instead of a “ShowHN”…what are your plans to monetize this open source project? Planning on building a hosting service to host Pynecone apps. Still finalizing the details but as pickelo said in one of the other comments. >Thanks! We're building a hosting service that you can deploy your apps to. Our plan is to have a free tier for your first app, then charge for additional apps. We're still finalizing this, so would love to hear any thoughts. Looks nice, reminds me of swiftUI :) Thank you :) Nice.
FYI, on iOS Safari you can’t scroll the page if the swipe starts on a chart component. wow, this is how heaven looks like. Thank you!! the world is flooded with js coders, toolkits, drag-and-drool site builders this is a neat demo but why do I need to get python in the client when it is even easier to get js in the server? webdev is basically a solved problem at this point very nice blog.
http://virtuelcampus.univ-msila.dz/facsegc/ Might want to think about the name. Pinecone is a relatively recent startup specializing in vector databases. hm.. making it only do web seems like a missed opportunity. How hard would it be to make it run on native or other platforms? Your ideas seem really cool. I'm sad that you chose a name so close to another great startup that does vector databases and search. https://www.pinecone.io/ You're headed into a place where some customers may confuse you. Agreed. Maybe I’m too focused on ML, but my first thought was the vector db. Cool idea though. Personally I use flask/quart to write the backend in Python but still end up writing a lot of JavaScript so this could be fun to use for prototyping quickly. I’ll have to play with it to see how it handles the client stuff like canvas drawing, or any of the client/server comms needed like using websockets. great work! can't help but wonder how this is different from Dash app from Plotly I am wondering about the same question. Even the interface looks alike. Great idea. why should I prefer Pynecone over NiceGUI? I summarized my thoughts on this about two month ago on Reddit (https://www.reddit.com/r/Python/comments/10h6l7e/comment/j5x...). Here the recap: - NiceGUI was initially build for accessing and controlling hardware as shown in our webcam demo); I'm not sure how it would be done with Pynecone - NiceGUI encourages the use of standard Python (callbacks, if-statements,..), Pynecone on the other hand uses explicit State classes and provides constructs like pc.cond and pc.foreach. - NiceGUI uses Vue/Quasar for the frontend while Pynecone is build on NextJS - NiceGUI generates HTML/JS/CSS via templates on the fly while Pynceone has an explicit compile step; so NiceGUI can be run with normal "Python" instead of using a command like "pc" - while both frameworks use FastAPI for the backend, in NiceGUI you can actually use your own App and simply extend it with NiceGUI to provide additional UI; Pynecone hides FastAPI which makes it harder to provide other API endpoints (for example to serve images from memory instead of files). looks like swiftUI Why should I choose this over Django or Flask? By using Python in the frontend you mean the Python is transpiled into JS? The frontend uses templating or generates a SPA app? Not affiliated, but this isn't just a Back-end API that supports delivering html- it's much more similar to streamlit afaict. Here's one of their examples https://pynecone.io/docs/getting-started/introduction > In Pynecone, the frontend compiles down to a React/NextJS app Yes, in Pynecone you write your frontend in Python and it's compiled to a SPA, plus a FastAPI backend server to handle state updates. Django and Flask handle the backend in Python, but you still have to use Javascript for the frontend. SSR is included? Do you have some project that is completely build with this stack. Some real life project? We use SSG under the hood, a good example would be our main website https://pynecone.io which is fully built in Pynecone. I don't want to downplay the library, but how hard is Javascript/HTML for the majority of python programmers? You might not make the most beautiful websites, but you can make a functional website if what you're displaying is primarily data to users because you're doing big data/AI and so forth and not setting up a consumer facing marketing platform. What's the use case here? It's a big mental hurdle. I don't really care about HTML/CSS/JS. I really don't care about React. But the four of those form this gigantic cottage industry of tribal knowledge that requires so much fiddling. In short, I don't want to be a webdev. I just want to use the browser as a dumb display device and a software delivery mechanism. I want the UI to be as simple as possible until I start getting traction, then I'll get someone to add some paint to make it passable. The dream is a VB-like product that lets me focus on creating features, not worrying about technical inanities like getting CORS configured right for the 5000th time. I hear your sentiment. As a backend / ML guy who tried to ship projects as a solo dev: I do understand JS/HTML. I understand the programming model of web and still build things the conventional way: templating on server which returns HTML. But lot of time still goes in CSS, to get things exactly working the way we want. The catch is trying to keep up with Javascript complexity. Javascript/react world is entirely different beast. Spent some time understanding class based React. But then things moved to hooks. I sort of started grokking hooks. But now there is new clamour (not yet mainstream) about something new like server side components or signals or hydration or what not. Same is the case with Svelte. I tried the basic tutorials, understood it. But Svelte kit started talking about 100 different ideas about server pre-rendering components etc. I thought why bother? Jinja2 templating and bit of inline JS looked a better option. Python devs want to stick to Python because it is still second best language to get something out there, quickly. Except for UI. Currently I'm looking into using HTMX as much as possible. If this thing solves for UI side of it then I'll definitely give it a try. I don't think Jacascript/HTML is the hurdle - for me it's all of the tooling around the ecosystem that makes me want to avoid it. That said, these types of tools have been a good entry point into front-end work, and I'm now at a point where building directly in JS makes more sense. One thing that is a huge win for the work I am doing - using Dash, I'm able to prototype an informal API and build the visualisations in a single step, which is great when it's unclear what is going to be useful. Long-term it definitely makes maintenance harder, and I think that's where there is a gap in the ecosystem - ideally I want to eject the front-end and convert the API to something more formal to hand off to a real front-end developer. Writing Javascript and HTML isn't the hard part. It's packaging and deploying it that is a whole new thing to learn where nothing you know from the past applies. > I don't want to downplay the library, but how hard is Javascript/HTML for the majority of python programmers? Not easy, esp. when you throw in CSS and the build systems As someone who is good at Python but knows nearly nothing about javascript: Very hard. Of course I can just write everything into a big js file, but if you want to structure things, it's hard. You have to learn all about this NPM and NODE stuff, learn how to refresh and debug things. And if you make the tiniest mistake, this thing will not crash with proper error messages like python. Definitely understand where you coming from, but I think there are a lot of engineers and data scientists who don't agree or don't have the time/drive to learn frontend technologies. Not wanting to deal with Javascript the language [1], maybe? You could make about a trillion dollars if, instead of asking people to write Python, you just gave them a WYSIWYG and let them build web apps by pointing and clicking like in MS Publisher/Powerpoint. Literally everyone in the world would buy it to make their own web pages. I get that nerds like to write code, but it is really depressing that we still can't just point and click and share content on the internet, we need to hire a nerd to write some special language just to make some text boxes and images show up on a screen. I mean, it's 2023. We have rovers discovering ice on freaking Mars. But just making a web page by pointing and clicking is impossible, or limited only to specific web hosting companies. Nerds like to write code, as you put it, because it's easier than the alternative. Seen from the other side, it's amazing to what lengths people will go to avoid learning some very light scripting. Historically the 4GL/nocode/lowcode movement has been a miserable failure, and not for lack of attempts to push that idea down people's throats. > it's amazing to what lengths people will go to avoid learning some very light scripting It's amazing that a person would want to do more work for a computer, rather than the other way around. > Historically the 4GL/nocode/lowcode movement has been a miserable failure Because they were created by people with no imagination, to fit into a paradigm that is inherently flawed but makes lots of money. MS Publisher was created 32 years ago. It still works great. Anyone can sit down and create and share mixed media by pointing and clicking. But all the techies in the world can't fathom how to make the same exact thing work over a hyper text protocol. Because they have no imagination, and prefer to play with their legos rather than make useful tools that regular humans can use. The only reason web pages are so complicated is the simpler and easier to use solution isn't sexy. Techies want their tech to be complicated, because they like all the bells and whistles and knobs and syntax and grammar and frameworks. It gratifies their need to keep reconfiguring their legos to make new toys. They like the ego boost of believing that all this is necessary and they are some kind of geniuses doing great work. When really it's all just a poorly designed layer cake of crap that keeps them in money to buy more toys. It's like how cities are full of streets designed for 2-ton balls of steel and wire and a continuously exploding mechanical machine. The city's design - and the vehicles - are needlessly complex, expensive, and resource-wasting. But we don't fix it, because fixing it is more work than maintaining the status quo, and there's money in the status quo. Many have tried the lowcode. Appfarm. Anvil. Even Microsoft power platform. Only the last make "trillions", and its not their low code platform which does it. Most graphical tools with WYSIWYG miss version control and the ability to show diffs between versions. But this is very important for debugging web apps and also for collaboration between developers. Also if the logic is more complex than a simple If-Else, you can express that much shorter and more efficient with text instead of a graphical representation of some tree. But note there is one area where GUIa are used for coding: game development. But Unreal 5, Unity etc. don't exactly have a simple GUI. Frontpage and dreamweaver! Haha. Wysiwyg. Joke aside, some say that with AI... Writing code is getting ever easier... Even easier than using a nocode tool.
Can you talk a little bit more about this? What kind of issues does Last.fm have that is related to or caused by Django? > Last.fm is one of them
outputs: pc.text(f'count: {State.count}'),
while... count: {state.count}
outputs: pc.text('count: ' + State.count),
(I'm otherwise using the counter example, just with a default value of 123.) count: 123
Which is supposed to build the interface for this almost-too-simple example. Note how there is a lot of custom Python code for simple HTML and CSS things that are already directly available in, well, HTML and CSS. This is how it might look like instead (pardon the inline CSS, it's just a quick comment, you can of course make this much better by writing the CSS separately): def index():
return pc.hstack(
pc.button(
"Decrement",
color_scheme="red",
border_radius="1em",
on_click=State.decrement,
),
pc.heading(State.count, font_size="2em"),
pc.button(
"Increment",
color_scheme="green",
border_radius="1em",
on_click=State.increment,
),
)
Then in the Python side, something like: <button id="dec_btn" class="red" style="border-radius: 1em;">Decrement</button>
<h2 id="count_h" style="display: inline; font-size: 2em">0</h2>
<button id="inc_btn" class="green" style="border-radius: 1em;">Increment</button>
This way, presentation is separated from business logic, and 'everything in its right place' (c). pc.event(id='dec_btn', type='on_click', action=State.decrement)
pc.event(id='inc_btn', type='on_click', action=State.increment)
# Runs everytime the State changes (or something)
def global_update():
pc.print(id="count_h", f'{State.count}')