[HN Gopher] Launch HN: Pynecone (YC W23) - Web Apps in Pure Python
___________________________________________________________________
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!
Author : picklelo
Score : 304 points
Date : 2023-03-13 15:14 UTC (7 hours ago)
| zdrummond wrote:
| 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
|
| [1] https://pynecone.io/docs/getting-started/introduction
| tedmiston wrote:
| Very cool that you built your own production site in Pynecone!
|
| https://github.com/pynecone-io/pcweb
| no_butterscotch wrote:
| How performant is it?
|
| It seems like there's a slightly visible lag in some of the
| interactions (button clicks) in the docs.
| duderific wrote:
| 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.
| MH15 wrote:
| 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!
| ShakataGaNai wrote:
| 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.
| unmole wrote:
| > A lot of the python webui's are heavily focused on AI/ML
|
| I'm sorry, what?
| mynegation wrote:
| 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.
| paulgb wrote:
| 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.
| ShakataGaNai wrote:
| 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.
| pbreit wrote:
| Is there by chance a CRUD boilerplate/starter (_NOT_ a to-do
| app)?
| abraxas wrote:
| 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.
| RyEgswuCsn wrote:
| 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?
| picklelo wrote:
| Each new browser tab creates a new state. We use Redis to store
| the state and expire it after 30 minutes.
| RyEgswuCsn wrote:
| 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?
| paulgb wrote:
| 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)
| picklelo wrote:
| 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.
| bpt3 wrote:
| Maybe this is a silly question, but why not target WASM instead
| of React/NextJS?
| apetuskey wrote:
| 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.
| bpt3 wrote:
| 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?
| apetuskey wrote:
| Both, hopefully we will have some time to help contribute.
| santiagobasulto wrote:
| 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?
| picklelo wrote:
| Yes that sounds interesting, let's discuss more!
| santiagobasulto wrote:
| 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.
| bilater wrote:
| 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.
| [deleted]
| apetuskey wrote:
| Thanks! I mentioned how we are different a couple comments
| previously.
|
| Yeah we are looking into your other point about the name,
| noted.
| shrimpx wrote:
| A fundamental ergonomic difference seems to be that Streamlit
| uses Python conditionals and has no callbacks, so it feels more
| like a Python script: if state.thing:
| button = streamlit.button('Hello') if button:
| button_got_clicked() else:
| streamlit.checkbox('Stuff')
|
| Whereas Pynecone needs to construct the entire UI, including
| its conditionals (using its own `pynecone.cond`), as a Pynecone
| object that is returned from the component function. Something
| like (pseudocode): return pynecone.cond(
| state.thing, pynecone.button(
| 'Hello', on_click=button_got_clicked
| ), pinecone.checkbox('Stuff'), )
|
| Streamlit keeps re-running the Python code with state changes,
| whereas Pynecone translates the code to JS once and for all at
| the beginning, and the re-rendering happens on the frontend.
|
| The general Streamlit approach may be more performant if you
| have a really massive UI but only a tiny portion of it is shown
| on load. Pynecone needs to load that entire UI upfront, whereas
| in Streamlit the "unrendered" UI is behind conditionals and not
| constructed until it's needed. Otherwise Pynecone may be
| overall more performant since it doesn't do backend rendering
| beyond the initial load, which could be cached.
| BiteCode_dev wrote:
| 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?
| apetuskey wrote:
| Looking into it we just have a lot of people on the site rn.
| Will need to scale it up to handle this traffic
| BiteCode_dev wrote:
| Do you mean every time I click on the button, it goes to the
| backend for incrementing?
| digdugdirk wrote:
| How does Pynecone compare to Flet? I've played with the flet
| framework and it seems to have a ton of potential.
| apetuskey wrote:
| 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.
| rudi_mk wrote:
| 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.
| stale2002 wrote:
| 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?
| apetuskey wrote:
| 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
| quechimba wrote:
| Cool! I'm working on something similar in Ruby!
| runnerup wrote:
| As this is a "LaunchHN" instead of a "ShowHN"...what are your
| plans to monetize this open source project?
| apetuskey wrote:
| 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.
| jimmySixDOF wrote:
| Pyscript is a reasonably popular client side Python in the
| Browser solution so wondering how your positioned with regards to
| them ?
| shrimpx wrote:
| Congrats on a very awesome addition to the space!
|
| Do you have caching that avoids hitting the Python that generates
| the layout? I wonder how your website stands up to HN-induced
| load.
| 0xbadcafebee wrote:
| 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.
| qsort wrote:
| 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.
| Epa095 wrote:
| 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.
| shrimpx wrote:
| It turns out that as your UIs get more complex, and you need
| conditionals and loops, you get closer and closer to the stuff
| that code is really good at; the WYSIWYG starts to get in the
| way and you start looking for escape hatches.
|
| There are a bunch of WYSIWYG tools out there and they're
| plagued by the escape hatch problem. Ultimately they give you
| access to raw code (or worse, their own specialized scripting
| language) to do the parts you can't do in their UI, and that's
| a big loss because now you're doing your job in two disparate
| environments: managing a big WYSIWYG system as well as writing
| a bunch of specialized code.
|
| At least with the code-only approach you can make the API
| really ergonomic and end up with a pretty neat code-only
| experience.
| kamikaz1k wrote:
| 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
| bilater wrote:
| 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.
| bradhilton wrote:
| 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.
| hangaard wrote:
| How does Pynecone differentiate from Streamlit, Panel and Dash?
| picklelo wrote:
| 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
| hangaard wrote:
| 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.
| benn0 wrote:
| 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.
| sidcool wrote:
| Congrats on launching. Looking forward to try it.
| mark_l_watson wrote:
| 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).
| drglitch wrote:
| 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.
| apetuskey wrote:
| Thank you! Glad the finance/quant community can find it useful!
| cutler wrote:
| Wouldn't Django or Flask with Stimulus and Turbolinks be a
| better option? The hard work has already been done.
| olah_1 wrote:
| 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?
|
| https://github.com/jeffthibault/python-nostr
| apetuskey wrote:
| No you shouldn't have to do anything special, external libs
| should work as normal when used in event handlers.
| mprosperi wrote:
| why should I prefer Pynecone over NiceGUI?
| 0xFF0123 wrote:
| 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.
| apetuskey wrote:
| Thanks for pointing this out, will fix
| Labo333 wrote:
| 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.
| buremba wrote:
| 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?
| apetuskey wrote:
| 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
| abraxas wrote:
| 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.
| cutler wrote:
| 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.
| alex_lav wrote:
| 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?
| DoesntMatter22 wrote:
| Lol what a silly opinion.
| kyawzazaw wrote:
| 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.
| apetuskey wrote:
| Thanks! Definitely, we do live streams of this on our discord
| I'll make sure to record them in the future!
| LifeIsBio wrote:
| 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.
|
| [1] https://anvil.works/
| abraxas wrote:
| Nice! I haven't seen this one before. Will definitely take a
| look. Thanks for posting.
| anakaine wrote:
| 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.
| meredydd wrote:
| Anvil has self-hosting! Just "pip install anvil-app-server"
| :)
|
| https://anvil.works/open-source
|
| (I'm a founder)
| anakaine wrote:
| 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?
| amlozano wrote:
| I totally thought Anvil had self-hosting. I was seriously
| considering it for my next project. Now not so much.
| anakaine wrote:
| One of the founders corrected my statement. Apparently you
| can self host.
| tedmiston wrote:
| This is really interesting so far.
|
| I think I've found a bug when using f-strings:
| pc.text(f'count: {State.count}'),
|
| outputs: count: {state.count}
|
| while... pc.text('count: ' + State.count),
|
| outputs: count: 123
|
| (I'm otherwise using the counter example, just with a default
| value of 123.)
| lr1970 wrote:
| 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.
| candyman wrote:
| 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.
| mxuribe wrote:
| > ...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.
| anakaine wrote:
| 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.
| cutler wrote:
| Then you might like Rails 7 which defaults to Hotwire for a
| minimal-JS front-end.
| adfm wrote:
| Check out htmx.
| clocker wrote:
| Have you tried Django? https://www.djangoproject.com/
| scrollbar wrote:
| 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
| tomerbd wrote:
| wow, this is how heaven looks like.
| apetuskey wrote:
| Thank you!!
| robswc wrote:
| 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.
| skrtskrt wrote:
| 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.
| Hortinstein wrote:
| Is there any plan on releasing user management libraries or is
| there a library you would recommend that interfaces with the ORM?
| ninjaa wrote:
| Great idea.
| globuous wrote:
| 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
| kim0 wrote:
| Seems similar to https://nicegui.io/ which recently impressed me!
| Will check this out.
| jpgvm wrote:
| 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?
| caxco93 wrote:
| Because the logic is being processed at the backend and the
| data being transferred over WebSocket
| jpgvm wrote:
| 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.
| vikinghckr wrote:
| 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?
| abraxas wrote:
| Java does have Vaadin but it's a mostly proprietary software.
| But it is very good and largely under appreciated.
| riceart wrote:
| > 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.
| nu11ptr wrote:
| > 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.
| jeremycarter wrote:
| 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.
| raphinou wrote:
| Websharper[1] lets you develop web apps all in F# or C#. Its
| reactive HTML layer is particularly useful.
|
| 1: https://websharper.com/
| alanbernstein wrote:
| 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.
| nuclearnice1 wrote:
| Useful list. Dash & bokeh as two more in the space
|
| https://github.com/plotly/dash
| https://docs.bokeh.org/en/latest/
| cutler wrote:
| 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.
| RonnieOwnsLexus wrote:
| 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
| picklelo wrote:
| 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.
| grift_economy wrote:
| [dead]
| tasuki wrote:
| > 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.
| picklelo wrote:
| We're using Pydantic and our compiler has custom type-
| checking on top of Python to catch these issues.
| apetuskey wrote:
| Thank you really appreciate that!
| ativzzz wrote:
| 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.
| quechimba wrote:
| 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).
| DoesntMatter22 wrote:
| 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.
| jrumbut wrote:
| 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).
| DoesntMatter22 wrote:
| That's not really true. It's complicated because the
| language is one of the worst to manage.
| raphinou wrote:
| In java I know of https://www.webtoolkit.eu/jwt/
| RonnieOwnsLexus wrote:
| 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.
| picklelo wrote:
| 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.
| nmstoker wrote:
| 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.
| jedberg wrote:
| 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.
| mahastore wrote:
| 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)>=
| enoch2090 wrote:
| Upvote for this request! It's really not some pleasant
| experience to implement all this in Streamlit. Should also
| support some third-party authentications.
| picklelo wrote:
| We definitely will add these auth components to the core
| library
| haolez wrote:
| I've tested Pynecone recently and it's pretty good. I'm wondering
| how do you intend to create a business around this library.
| picklelo wrote:
| 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.
| sharemywin wrote:
| 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.
| mattgreenrocks wrote:
| 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.
| epoch_100 wrote:
| 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?
| [deleted]
| WillAdams wrote:
| 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.
| alex_lav wrote:
| 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!
| apetuskey wrote:
| Thank you! Feel free to put a GitHub issue ill try and fix asap
| [deleted]
| [deleted]
| felixhummel wrote:
| 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
| pplante wrote:
| 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.
| picklelo wrote:
| 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.
| pplante wrote:
| What do you think is missing?
| apetuskey wrote:
| I think a big thing is the limited supported libraries as
| of now.
| beepbooptheory wrote:
| Isn't also just the fact you need to send over like 7MB
| of wasm for even just the standard library?
| qwertox wrote:
| 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.
| picklelo wrote:
| 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
| qwertox wrote:
| Great! Thank you. Maybe also showcase an example on the
| landing page, like making only the `def decrement(self)` an
| async function.
| animex wrote:
| Is this similar to Unicorn for Django? https://www.django-
| unicorn.com/
| riemannzeta wrote:
| 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.
| dbish wrote:
| 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.
| zainhoda wrote:
| I inadvertently built something similar:
|
| https://www.pycob.com
|
| 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.
| anakaine wrote:
| I'll second this sentiment.
| samhuk wrote:
| 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 :)
| apetuskey wrote:
| 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.
| samhuk wrote:
| 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 :)
| apetuskey wrote:
| 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.
| samhuk wrote:
| Thank you very much for the insight. Best of luck with the
| future of your project.
| nu11ptr wrote:
| 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.
| patientplatypus wrote:
| 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?
| benn0 wrote:
| 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.
| RyEgswuCsn wrote:
| Not wanting to deal with Javascript the language [1], maybe?
|
| [1]: https://javascriptwtf.com/
| apetuskey wrote:
| 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.
| mattgreenrocks wrote:
| 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.
| nu11ptr wrote:
| > 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
| jedberg wrote:
| 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.
| Epa095 wrote:
| 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!
| whinvik wrote:
| 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?
| newaccount2023 wrote:
| 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
| margorczynski wrote:
| 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?
| neonate wrote:
| > In Pynecone, the frontend compiles down to a React/NextJS app
| picklelo wrote:
| 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.
| Liberonostrud wrote:
| SSR is included? Do you have some project that is completely
| build with this stack. Some real life project?
| apetuskey wrote:
| We use SSG under the hood, a good example would be our main
| website https://pynecone.io which is fully built in
| Pynecone.
| jasonjmcghee wrote:
| 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
| adamredwoods wrote:
| 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.
___________________________________________________________________
(page generated 2023-03-13 23:00 UTC)