[HN Gopher] Pynecone - Performant, customizable web apps in pure...
___________________________________________________________________
Pynecone - Performant, customizable web apps in pure Python
Author : gilad
Score : 94 points
Date : 2023-05-04 18:49 UTC (4 hours ago)
(HTM) web link (pynecone.io)
(TXT) w3m dump (pynecone.io)
| nextworddev wrote:
| Seems like a more ambitious Streamlit
| worik wrote:
| Don't. Just do not do this
|
| Python has a place in scripting
|
| Because you can, does not mean you should, build full
| applications with it
|
| It is a colossal waste of resources. It leads to genuine problems
| as it gets bigger that you will only find when you have
| considerable sunk costs.
|
| This is a terrible idea, it was a terrible idea in 1995 when
| people did this with Perl, it is a terrible idea now
|
| Use Python for what it is good at, not for what it is dreadful at
| abraxas wrote:
| Well then, people should also stop doing that with Typescript
| because it's often as slow as Python and much slower than
| JavaScript.
| yamtaddle wrote:
| > Well then, people should also stop doing that with
| Typescript because it's [...] much slower than JavaScript.
|
| Wuh?
| abraxas wrote:
| Typescript transpiles to JS with a bunch of runtime checks
| woven in resulting in much slower code than equivalent
| barebones JS. There are benchmarks that show this.
| slmjkdbtl wrote:
| For this software if you change to any language it will still
| use the same architecture and technology, setup a http server
| and generate HTML and some client JS code to run on browser,
| just syntax difference or maybe performance. Curious what
| exactly is the part you think Python is dreadful at that this
| software contains? You can definitely say there are better
| performance language but I'm curious about if other factors.
| worik wrote:
| > Curious what exactly is the part you think Python is
| dreadful at
|
| * A large memory foot print
|
| # Inefficient execution
|
| That's two out of the top of my head
|
| I have been badly burnt by Mailman3, pure Python, pretty
| front end, 2G needed to install it. That cost me real money.
| The difference between a cheap, and a very cheap, VPS
| slmjkdbtl wrote:
| Yeah you can definitely say that but that's true about all
| python software.
| mixmastamyk wrote:
| This is "premature optimization," IMHO.
|
| No, get the idea working first. Talk to customers... pivot...
| repeat. After finding a fit and portions are too slow look into
| Cython or offload to services in golang, etc.
|
| This looks like a great productivity booster.
| siva7 wrote:
| People also said similar things when Node.js crossed backed
| then the boundaries of our imagination. Nonetheless i agree
| that it can lead to genuine problems once it gets complex
| enough.
| worik wrote:
| Node.js is very bad
|
| It amplifies all the bad desicions ever made in software
|
| Because you can does not mean you should,
| tymonPartyLate wrote:
| It's a beautiful project and close to the Holy grail of fullstack
| software development (a single framework for building modern Web
| apps).
|
| But, be advised that it's not production ready and quite unstable
| yet.
|
| this week my deploy script was broken because version 0.1.26 was
| un-released. Which broke my docker file build with pinned
| dependencies.
|
| The file upload component was changed a few times so my UI with
| file uploads silently stopped working.
|
| I had some issues when state binding input components. Which lead
| to the backspace key no longer working inside a text box.
|
| The websocket state updates can make the ui feel sluggish.
|
| Despite all that, I love this framework and will continue
| tinkering with it. It hope it can grow to maturity before people
| lose interest!
| nine_k wrote:
| For a full-stack framework I'd take something Typescript-based
| now, because TS has better static typing than Python currently
| (with all due respect to mypy), and the async story of JS is
| much easier than that of Python. And also the JIT.
|
| But it's interesting to see that Python is able to advance so
| much in this direction; I hope it will continue.
| valray wrote:
| Any typescript frameworks you recommend?
| nine_k wrote:
| E.g. Next.js is fine.
| dennisy wrote:
| I love the idea of this!
|
| However whenever I see such good abstraction I always worry that
| when my project gets big and complicated there will be things
| which are not possible to do, and at that point switching will be
| super expensive.
| nine_k wrote:
| Do you have the same feeling when e.g. starting a project using
| React? Why?
| dragonwriter wrote:
| TBF, since this is itself an abstraction layer over React
| (well, NextJS), it is strictly a greater concern for this
| than React.
| ktbwrestler wrote:
| This looks awesome! Has anyone made a personal portfolio site/
| blog with this yet? Considering jumping from Jekyll:
| https://jeffreylikeswebsites.com
| thunky wrote:
| I followed the link to try the increment/decrement example/demo
| from the landing page (https://pynecone.io/docs/getting-
| started/introduction). There is probably almost a full one second
| delay between the time I click the "increment" button and the
| updated count being rendered.
|
| Not seeing any network requests so I can't imagine why it would
| be so laggy.
| danudey wrote:
| Two quick notes:
|
| 1. Looks like you posted this comment pretty close to when this
| was posted on HN. It's possible the server was more loaded, as
| I tried it myself and it wasn't very laggy (though there was a
| delay, it wasn't nearly the one second you experienced).
|
| 2. I copied the example code and ran it locally, and the
| latency is no worse than, say, an electron app. Better than
| most of them, to be honest.
|
| Likely this was related to server load or network latency or
| both, because the core functionality seems pretty lag-free.
| picklelo wrote:
| Yeah we're only hosting on a single region at the moment so
| there can be latency depending on your location. We're working
| on using edge computing to speed this up.
| pedrosbmartins wrote:
| is there a reason why all state is in the server? what about
| cases where you'd want to keep client-side state, like those
| strictly related to UI/UX?
|
| (very interesting project nonetheless!)
| picklelo wrote:
| Keeping the state on the server allows us to run arbitrary
| Python code and libraries in our event handlers that update
| the state. Currently only the ui is compiled to React but
| the logic stays in Python.
|
| We're working to offload more logic to the client in the
| for purely UI operations like you mention, and in the
| future want to leverage wasm once it's more mature.
| tymonPartyLate wrote:
| Clicking sends a websocket message to the backend. Which then
| responds with a state update message which updates the frontend
| react components. rhe round trip would probably take the same
| time with rest APIs, but you would have the ability to add some
| loading indicators or hints, because you'd have full control
| over client side rendering. You don't have that when using
| pynecone. It's a tradeof
| slmjkdbtl wrote:
| So it doesn't really have any client side interactivity?
| Thought it does from the example and wondering what magic
| they pulled to achieve that, they really should write this in
| big text up front cuz it's a pretty big factor when
| considering this software.
| thunky wrote:
| Ah thanks, I see that now under the State -> Overview docs
| page:
|
| _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._
| atakan wrote:
| sounds impossible to scale. but nice ui though
| slmjkdbtl wrote:
| From what I read each action is a websocket roundtrip, yikes!
| anigbrowl wrote:
| _It's just Python.
|
| The app state is just a class. State updates are methods in the
| class. And the UI is a reflection of the state._
|
| It's rare to see this sort of clarity on a landing page. Even
| more impressed to see that it carried over into the
| documentation, which is excellent.
|
| I've been a fan of the plotly/Dash framework, but this looks like
| an exciting alternative, feeling more immediately accessible
| without some of the quirks (like the pragmatic but weird-feeling
| 12 virtual columns, for example). I look forward to re-
| implementing some existing projects for comparison.
| snthpy wrote:
| I would love to hear what your experience is.
|
| We've been using Pynecone for a bit and are coming up against
| some problems.
|
| For example trying to write a wrapper for AG Grid there is no
| way to pass a custom class attribute so you can't style the
| output with a theme.
| robopsychology wrote:
| I found it very difficult to do things like rich text boxes
| for a ChatGPT clone I was writing aimed at being child
| friendly. Ended up giving up when it became a bit spaghetti-
| ish and after the documentation stopped being useful beyond
| hello world apps.
| anotherpaulg wrote:
| I also built a chatgpt UI that was focused on early readers
| and kids. Feel free to clone and modify if you like.
|
| https://github.com/paul-gauthier/easy-chat
| picklelo wrote:
| Cofounder of Pynecone here - thanks for the feedback. We're
| prioritizing improving our docs and example apps in the
| upcoming weeks and will have a ChatGPT clone example.
| Definitely want to improve the onboarding experience and
| showcase these more complex use cases.
| bjornasm wrote:
| Congratulations with the release of this very exciting
| framework! Can't wait to try it out.
| anigbrowl wrote:
| My projects are simple dashboards for internal use so I
| prioritize ugly and functional over aesthetic. technical
| verdicts from someone with more UI experience/affinity would
| likely help a lot more than my opinion.
| emmanueloga_ wrote:
| "state is just a class" brings up so many questions though. How
| do you serialize state if it is "just a class"? Serializing the
| state is useful for all sorts of things, including debugging,
| reloading, and saving and loading application state.
|
| Serializing state together with some code that operates on it
| may be doable but sounds either complicated or brittle.
| anigbrowl wrote:
| It's not that it's the best way to do it; it's just a very
| straightforward articulation of their design philosophy that
| helps a first-time visitor know what to expect and what they
| might like (or not) about it.
| dimator wrote:
| Not to be confused with https://www.pinecone.io/ the vector
| database, which is also trending.
| mellosouls wrote:
| Recent previous discussions include:
|
| https://news.ycombinator.com/item?id=33922754
|
| https://news.ycombinator.com/item?id=35136827
| mixmastamyk wrote:
| How does this compare with Anvil, besides being newer? Anvil was
| shown off here a few years back:
|
| https://anvil.works/
|
| https://news.ycombinator.com/item?id=15584124
| solarkraft wrote:
| It's not bad if your server isn't far away and you can compromise
| a bit on UX. A great tool if you need to quickly whip up a UI for
| some Python code (with more control than those machine learning-
| focused frameworks give you).
|
| Sadly it's apparently incompatible with SQLAlchemy 2.0, so I
| can't use it.
| picklelo wrote:
| Thanks for pointing out, we will update our sqlalchemy
| dependency to the newest version
| abraxas wrote:
| I played with it and subsequently turned my back on it in favor
| of alpine.js and some vanilla JavaScript to handle client state
| with Flask on the back end.
|
| The reason I gave up on Pynecone is that these things transpile
| to other already high abstraction frameworks like React. This is
| all good and well until something goes wrong and you now have
| more layers to troubleshoot. Another huge downside to this
| approach is that now I have to deal with two sets of build and
| deployment tools: python and node. And given that I have few fond
| memories of the node tool set from previous project, I refuse to
| incur this complexity unless it's absolutely unavoidable.
|
| If someone actually built something like Pynecone that targeted
| html/dom/js directly instead of wrapping node/react/next I would
| be the first to hop on the bandwagon. Because the API is very
| good but the way that sausage is made ain't pretty.
| meredydd wrote:
| > targeted html/dom/js directly instead of wrapping
| node/react/next
|
| This might not be what you're asking for, but I think this js
| more or less what we built at https://anvil.works (I'm a
| founder).
|
| We chose to expose the client/server dichotomy - in Anvil you
| write front end code in Python, using an in-browser UI toolkit,
| and we transpile to JS. (As opposed to Pynecone, where every
| change to the UI is mostly "puppeteered" from the back end.)
| This requires a little more understanding from the developer,
| but means you don't have to pipe every action down a websocket
| and back.
|
| Anvil's UI toolkit is built "straight on the DOM", and it's
| shaped like Python objects with properties, not some
| intermediate React-y abstraction. And of course, because you're
| writing in-browser code, the HTML/JS interop is pretty
| straightforward (in fact, you can import JS objects right into
| Python code).
|
| There are downsides to this approach, of course - it's really
| neat that Pynecone apps are "just one Python file", whereas in
| Anvil you do need to be handle the difference between client
| and server - but people have scaled up to some pretty big apps
| on Anvil!
| [deleted]
| swyx wrote:
| for a second i read this as Pinecone, that 700m vector database
___________________________________________________________________
(page generated 2023-05-04 23:00 UTC)