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?
FastUI: Build Better UIs Faster
61–70 of 230 posts
Re: FastUI: Build Better UIs Faster
#62> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…
Yeah for this kind of simple UIs fast I might as well use something like Streamlit.
Edit - someone who has built with this has commented that they found things snappier than using Streamlit
Re: FastUI: Build Better UIs Faster
#63> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…
You would be surprised how far a company can get with a Django admin for customer service or sales teams.
Re: FastUI: Build Better UIs Faster
#64For 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…
Fast for me was about the DX rather than performance.
Re: FastUI: Build Better UIs Faster
#65Earlier quoted context omitted.
Its a shame that RAD on the web is so far behind stuff like Qt
And Qt is leaps and bounds behind Delphi and Lazarus. It is even behind rails g scaffold when it comes to RAD.
The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since.
Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked?
That was a lovely time to work on any kind of line-of-business app.
Re: FastUI: Build Better UIs Faster
#66Is this a good way to build UI? The syntax looks very awkward. IMV, XML is the best format for any Declarative UI. Tools to generate that XML (or HTML) are better value than these systems. I would love to see an XML based UI generator in Python.
Skip the python and use xml+xslt directly in the browser if you like it
The XML+XSLT equivalent here would be an XSLT stylesheet with a bunch of predefined rich parametrized templates that you can just . Hand-coding XSLT to produce HTML (or whatever) is still rather tedious.
Re: FastUI: Build Better UIs Faster
#67Earlier quoted context omitted.
> I have worse news for you about C or C++ or anything that isn't typed exclusively based on how wide its register is I would be interested in hearing this nitpicking, I know little about C or C++
Honestly, if I'm going to nitpick myself , even that isn't a true statement. You might have an integer/float divide for your registers, like amd64 does, but even past that it's squishy and becomes human bookkeeping or compiler magic. Is %rax an 8-byte integer, or is it a pointer? Or is it garbage because you used %eax (the lower 4 bytes of %rax) for storing a 4-byte integer, and the top half is whatever(tm)? Ditto ag…
The problem with Python specifically is that the type system is such a massive bolted-on hack. It has to be, because it's such a dynamic language that all declarations and imports are executable statements - and it's hard to reconcile it with type declarations, which often need to be mutually recursive.
TypeScript is much better in that regard, though.
Re: FastUI: Build Better UIs Faster
#68Gradio does a pretty good job here.
Re: FastUI: Build Better UIs Faster
#69This remindes me to java server faces, which was not a great experience in the long run. IMHO, trying to put all the subtleties of frontend development into server side abstractions would only work for a limited set of applications, such as admin UIs.
Re: FastUI: Build Better UIs Faster
#70Earlier 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
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).