pydantic / FastUI

Build better UIs faster.
https://fastui-demo.onrender.com
MIT License
8.2k stars 315 forks source link

Difference from Gradio #69

Closed fakerybakery closed 10 months ago

fakerybakery commented 10 months ago

Hi, great library. Just wondering how this is different from Gradio

samuelcolvin commented 10 months ago

No idea, never used gradio. Would be great if someone could tell us though...?

Zaubeerer commented 10 months ago

https://www.gradio.app/guides/quickstart seems similar to https://streamlit.io/: "define data/web app in python script"

So, I guess that a development flow could be as follows:

  1. Prototype with streamlit or gradio or similar
  2. When streamlit/gradio are limiting: I. Implement FastAPI as backend for the frontend II. Implement more tailored frontend with FastUI

Until FastUI gets simple & powerful enough that one directly starts with FastUI & FastAPI (e.g. have a FastUI-Streamlit template repo that looks similar to streamlit and is almost as easy to use as writing a python script) :)

samuelcolvin commented 10 months ago

Makes sense, my guess is we can make FastUI easy enough to use that it works from day one.

hasansezertasan commented 10 months ago

@fakerybakery GradIO is simply "IO" based User Interface technology, it's quite limited if you want to build large applications.

GradIO performs communication between backend and frontend via websocket but FastUI doesn't do that. Think of it like GradIO is a "drag and drop UI builder with tons of limitations" and FastUI is a (almost) fully fledged UI Framework.

On the other hand, GradIO has it's own syntax and pattern to build interfaces, it's not easy (or possible) to build routes with custom forms/elements but you can use FastUI to implement routes with different components, elements, forms.

Major downside of GradIO is using websocket to communicate with backend and interface limitations. I think the answer to your question is similar to @samuelcolvin's answer on #67. We can not (you can but doesn't makes sense) compare sandwiches with Tesla Model X

@samuelcolvin I think you should add a comparison/alternatives section in the docs when you are writing the docs...

Another thing is this module: metaperl/pure-python-web-development: Avoid the CSS/JS/HTML soup - develop web apps entirely in Python, I do recommend you to check this one out!

fakerybakery commented 10 months ago

Thank you for your detailed explanation! That makes sense. So basically Gradio is a more basic framework for making simple webapps and FastUI is for making production-ready more complex apps?

hasansezertasan commented 10 months ago

Thank you for your detailed explanation! That makes sense. So basically Gradio is a more basic framework for making simple webapps and FastUI is for making production-ready more complex apps?

I believe you're correct for FastUI part but partially correct for GradIO. GradIO is used for mostly demoing purposes and some applications like AUTOMATIC1111/stable-diffusion-webui: Stable Diffusion web UI. But customization is a pain, most probably because of the abstraction level.

You can pick one of these if you are in hurry: GradIO, PyWebIO, Streamlit. They are mostly IO based. You can pick one of these for more advanced applications: NiceGUI, Reflex or Flet. All used in production with different advantages and disanvantages.

All of the above uses websockets to communicate with the backend. BTW, using websocket for UI interactions is not a new thing, check this repo out if you are interested in those: liveviews/liveviews: Phoenix LiveView workalikes for different languages and frameworks.

FastUI 0.1.0 also used this approach for such a thing.

@samuelcolvin, I'd like to know why did you people quit using websocket? What was the motivation/reason?

skullcrash commented 8 months ago

What about 'Reflex' ? reflex.dev What are the differences with FastUI ?

hasansezertasan commented 8 months ago

What about 'Reflex' ? reflex.dev What are the differences with FastUI ?

Reflex and NiceGUI is quite different from FastUI.

Reflex and NiceGUI automatically handles routing and communication between frontend and backend via websockets (similar to liveview). You don't need to think about routing.

With FastUI, it's your job to think about it, you need to write the routes and do the connections (tell your application when this happens, navigate to the x path) by yourself.

Also, reflex has its own ORM abstraction over the SQLAlchemy.

They all use some JacaScript frontend framework.

Edit: I did look at the source code of all these packages. I am planning to write some stuff about it in the future.

skullcrash commented 8 months ago

Reflex is using FastApi and SQLModel underneath. PyScript is also interesting. All these python initiatives are very different and indeed it it not easy to catch the differences sometimes.

hasansezertasan commented 8 months ago

Reflex is using FastApi and SQLModel underneath. PyScript is also interesting. All these python initiatives are very different and indeed it it not easy to catch the differences sometimes.

NiceGUI also uses FastAPI as its backend core. One other downside of reflex is its dependencies, its too many and versions are so strict.

WASM is not there yet and I think it won't be in the near future (I am talking about small size applications).

FastUIs approach is not quite new. Check aout baidu/amis and json schema form builders (there are many implementations but I do recommend checking json-editor). These technologies depends on backend to build the UI in a JSON based specs.