Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We built an app with it -- https://blog.dagworks.io/p/building-a-lightweight-experiment. You can see the code here https://github.com/DAGWorks-Inc/hamilton/blob/main/hamilton/....

Usually we've been prototyping with streamlit, but found that at times to be clunky. FastUI still has rough edges, but we made it work for our lightweight app. Note: we generally found it snappier than streamlit.



Can you share anything specific about what was clunky/ not snappy about streamlit? I've been exploring streamlit, and it took a little bit to figure out how to use it well, and deploy it appropriately.


On the same team — I’ve really enjoyed strsmlkt and built an app (that made it to the HN front page!) https://share.streamlit.io/-/auth/app?redirect_uri=https%3A%....

That said, I’ve found it to be clunky in a few ways:

1. State management is not intuitive — anything that involves rendering complex state/reacting at it changes requires a ton of session state type stuff.

2. I’ve very often had to go into css/markdown hacks

3. The control flow of when it’s running/executing makes for clunky interactions

4. Some API decisions are painful. For instance, a block str comment in the file will render as st.write

5. Long running (or even not instant tasks) make for some annoying engineering challenges — the UI is tied to the compute, so you have to be smart about juggling it

6. Caching is not smart — it’s quite useful, but it’s easy to get lost in caching/state

I’ve been dreaming about streamlit but a little more state/function oriented. E.g. react-based. Not far from fastUI

These are both great tools for prototyping, but I’ve found that I’ll pull up tailwind + some UI framework when I want something slick and it’ll take a few times as long.


The first point you made is what myself and my team have struggled with. We have built simple apps for customers to upload a document to interact with and having the state be accurate to the document that the user uploaded was a major pain. Felt easier at that point to build something from scratch than to keep messing around with streamlit's session states


Would you consider giving Shiny (for Python) a try? https://shiny.posit.co/py/ It's (I hope) pretty close to Streamlit in ease of use for getting started, but reactive programming runs all the way through it. The kind of app you're talking about are extremely natural to write in Shiny, you don't have to keep track of state yourself at all.

If you decide to give it a try and have trouble, please email me (email in profile) or drop by the Discord (https://discord.gg/yMGCamUMnS).


Haven't used Shiny on Python yet, but we use the R version a lot. It's been a good experience: solid, reliable framework, good set of widgets, decent styling out the box.

The Python version is a port from its R stablemate (well, maybe more than a port: a re-engineering). If it's as solid as its R parent then it'll be a very useful addition to the Python UI landscape.


Didn't know that there was shiny for python, so I'd definitely be interested in trying it out


That looks slick! Didn’t have any idea shiny was in python, but IIRC data scientists I’ve worked with in the past love it.


Yep agreed, I really found it good for the first something — e.g. a more advanced figma. Past that it was a bit of a gamble.


Streamlit's state management is so painful, feels like constantly writing hacks.


I don't think a tool is doing its job well when you make it work for your app. By contrary, it should make your app work




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: