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