41–50 of 230 posts
This isn't a new concept, other examples include Solara (React-based) and NiceGUI (Vue-based). It's very practical for internal apps, if you accept that all controls have a small delay due to events being processed server-side.
> 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…
Its a shame that RAD on the web is so far behind stuff like Qt
Earlier quoted context omitted.
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…
Oh No. Is it that time again? Someone who isn't really a front-end developer reinventing front-end development. I can't wait to be handed an application by my data scientists that uses this and is a complete trash fire that I need to rebuild from scratch... Again. I guess streamlit has competition.
Oh No. Is it that time again? Someone who isn't really a front-end developer reinventing front-end development. I can't wait to be handed an application by my data scientists that uses this and is a complete trash fire that I need to rebuild from scratch... Again. I guess streamlit has competition.
It comes from a place of necessity, not want. In many product engineering teams, a solution doesn't exist until there is a UI experience to interact with it. It allows data scientists to showcase the benefit of their model as a full experience. I wouldn't use it for a large scale app. But tools like these are excellent for quickly mocking up a sample UI to sell an idea to your leadership. Too often leadership does no…
The focus of these products should be 0 to 1 rather than 1 to Inf.
This seems way slower (in dev time) and more verbose than iommi https://docs.iommi.rocks/
> 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…
Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.
Earlier quoted context omitted.
Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.
The kind of site that gets all of their data stolen. It can be a cool pattern.