111–120 of 230 posts
After years of crispy forms and HTML-in-Python hackery, I am firmly on the side that the presentation layer shouldn't be so tightly coupled to the code that renders it. A template language (that isn't Python) is sufficient. Even better if you can render the templates from different languages. I'll never be defining web app presentation in Python.
What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?
> Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI? Hold on I thought HN is all hyped about HTMX now? Isn't that what that does too?
For something called "FastUI" it sure does seem pretty slow at making a basic website with simple 2000s-era HTML...
Well FastAPI was originally based on pydantic 1.x, which was extremely slow (so slow in fact that they removed the benchmarks from the website). I am the author of typedload, a similar library written in pure python. Mostly for fun I started to see how much I could improve performances, benchmarking against other libraries. I was very surprised to find out that pydantic2, despite the rewrite in rust, wasn't overwhelm…
Earlier quoted context omitted.
Web development used to have a RAD experience in the ages of PHP 4/ASP Classic and Dreamweaver. For better or worse, we lost this capability in the path for code purity, RESTful services and SPAs.
and accessibility, and standards compliance, and maintainable code...
In a way I disagree with you.
On accessibility: I see more custom components that nobody cares to make it properly working with keyboard interaction compared to native HTML input components.
On standards - mixed feelings: we had XHTML, now we don’t. We had IE and jQuery to deal with it, now we don’t need it, but I still see many places that have the old “works best with” message, now with Chrome instead.
On maintainable code: it’s a different shit show, we exchanged spaghetti code for billions of npm dependencies that break if you dare to try and upgrade something.
Earlier quoted context omitted.
and accessibility, and standards compliance, and maintainable code...
That’s why I said for better or worse :) In a way I disagree with you. On accessibility: I see more custom components that nobody cares to make it properly working with keyboard interaction compared to native HTML input components. On standards - mixed feelings: we had XHTML, now we don’t. We had IE and jQuery to deal with it, now we don’t need it, but I still see many places that have the old “works best with” messa…
What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?
Earlier quoted context omitted.
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…
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
Earlier quoted context omitted.
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 pro…
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.