11–20 of 230 posts
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.
For something called "FastUI" it sure does seem pretty slow at making a basic website with simple 2000s-era HTML...
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 overwhelmingly faster… in fact it is still slower than my pure python library in some cases.
But, I guess having "fast" in the name sounds good!
https://ltworf.github.io/typedload/performance.html (I re-run them every time I release).
I guess building UIs in this case means building html forms in python, although the examples look more complicated then just building a web page and responding to http requests. I don't know why someone would say "Build UIs" and not mention html, it seems pretty myopic to think a UI automatically means a web page.
For something called "FastUI" it sure does seem pretty slow at making a basic website with simple 2000s-era HTML...
For something called "FastUI" it sure does seem pretty slow at making a basic website with simple 2000s-era HTML...
It seems the big selling point is building websites without JS. To each their own but typescript is one of the best programming languages I’ve used. I do enjoy python a lot but whenever I use it I feel like I’m going a decade into the past, especially with their tooling (lint, types, formatters, package manager, venv, etc). I wrote a post recently about how I feel like this loathing of all things FE/JS is overblown:…
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…
This seems way slower (in dev time) and more verbose than iommi https://docs.iommi.rocks/
Earlier quoted context omitted.
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…
I am certainly not in love with how the FastAPI team handles comparisons or development. Hiding superior benchmarks. Immediately closing Github issues (they refile as Discussions to keep the issue count low). So on and so forth.
But that's just my own conspiracy. I have no idea. Perhaps things changed since I last ran the benchmarks.
Benchmarking isn't easy. I know that my software using my library mostly loads Unions, so that's a focus in my benchmarks. However I have absolutely no idea of what the other users are doing with it, and my benchmarks might not be relevant to them.
In the end I wrote them for myself mostly, to check for possible regressions in performances.
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.