FastUI: Build Better UIs Faster

After years of crispy forms and HTML-in-Python hackery, I am firmly on the side that the presentation layer shouldn&#x27;t be so tightly coupled to the code that renders it.<p>A template language (that isn&#x27;t Python) is sufficient. Even better if you can render the templates from different languages.<p>I&#x27;ll never be defining web app presentation in Python.

We built an app with it -- <a href="https:&#x2F;&#x2F;blog.dagworks.io&#x2F;p&#x2F;building-a-lightweight-experiment">https:&#x2F;&#x2F;blog.dagworks.io&#x2F;p&#x2F;building-a-lightweight-experiment</a>. You can see the code here <a href="https:&#x2F;&#x2F;github.com&#x2F;DAGWorks-Inc&#x2F;hamilton&#x2F;blob&#x2F;main&#x2F;hamilton&#x2F;plugins&#x2F;h_experiments&#x2F;server.py">https:&#x2F;&#x2F;github.com&#x2F;DAGWorks-Inc&#x2F;hamilton&#x2F;blob&#x2F;main&#x2F;hamilton&#x2F;...</a>.<p>Usually we&#x27;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.

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.<p>I don&#x27;t know why someone would say &quot;Build UIs&quot; and not mention html, it seems pretty myopic to think a UI automatically means a web page.

This isn&#x27;t a new concept, other examples include Solara (React-based) and NiceGUI (Vue-based). It&#x27;s very practical for internal apps, if you accept that all controls have a small delay due to events being processed server-side.

I was looking at this space and nicegui seemed like the best ootb experience.<p><a href="https:&#x2F;&#x2F;nicegui.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nicegui.io&#x2F;</a><p>Fastui seems prettty barebones mostly a form adapter to pydantic models that I can see.

Call me old fashjioned but what is wrong with django and htmx?<p>Works beautifully and fast, send only rendered code to the front. Have db admin for when you scale

For me, the main technical difference with Pydantic over the host of other similar libs is runtime validation. Which, with modern typed Python, you often don&#x27;t need and which you pay for in speed: even Pydantic v2 is still relatively slow.<p>&quot;Pydantic models for UI components&quot; seems odd to me. Surely runtime validation is unnecessary in this application and static analysis is a better fit. I am guessing it&#x27;s the close integration with FastAPI that really holds the value here. For me, ideally this wouldn&#x27;t use Pydantic but given the author and their situation, using Pydantic is probably the main reason this project actually exists.

This 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.

What&#x27;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?

It’s amazing how many front end frameworks now exist that require running a backend server to even render basic HTML. This, remix, next, Astro, and so many others.<p>Do the features offered by these really warrant the complexity?

Flet (<a href="https:&#x2F;&#x2F;flet.dev" rel="nofollow">https:&#x2F;&#x2F;flet.dev</a>) might be easier for backend devs as it doesn&#x27;t assume any web experience at all. You use controls (aka widgets) with events (not request&#x2F;response) and can build not only web, but desktop and mobile apps - all with a single codebase. Disclaimer: I&#x27;m Flet developer.

It doesn&#x27;t seem better or faster but apart from that, great!

Is this a good way to build UI?<p>The syntax looks very awkward.<p>IMV, XML is the best format for any Declarative UI. Tools to generate that XML (or HTML) are better value than these systems.<p>I would love to see an XML based UI generator in Python.

I used to believe in the use case of projects like these but I think AI is making their case significantly weaker. The idea of &quot;hey, you&#x27;re a backend dev and can just quickly generate a UI in your own language&quot; is quite a valid one, but these days you spend a a couple hours on ChatGPT and get a pretty decent UI out of it, without needing to really know frontend.<p>I&#x27;m far from being one of those people that&#x27;s like all in on AI, but I&#x27;ve definitely been super impressed with its abilities to generate basic boilerplate code when you&#x27;re working on project from scratch.

I write my side projects in dart&#x2F;flutter. Least friction, less hassle. If I needed to write a web app and flutter wouldn&#x27;t cut it, I&#x27;d probably go htmx.<p>EDIT: my main issue is figuring out how to simply deploy a website.

This seems to mainly be useful for spinning up quick and dirty internal tools.<p>But for that use-case, isn&#x27;t it easier to use something visual and established like Retool (<a href="https:&#x2F;&#x2F;retool.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;retool.com&#x2F;</a>) or that generates nice react code, like MUI Toolpad (<a href="https:&#x2F;&#x2F;mui.com&#x2F;toolpad&#x2F;" rel="nofollow">https:&#x2F;&#x2F;mui.com&#x2F;toolpad&#x2F;</a>)?

Once upon a time there was Google Web Toolkit (GWT), ASP.NET WebForms. What approach do they use, the same as FastUI? Now there is Blazor for C#, how does its approach differ from FastUI? I think they all promise to write UI for Web without writing JavaScript code.

This is a better retool alternative

&gt; Beyond Python and React ... Implementing frontends for other platforms like mobile ...<p>I&#x27;m building something like this for mobile: <a href="https:&#x2F;&#x2F;www.applin.dev" rel="nofollow">https:&#x2F;&#x2F;www.applin.dev</a>

Use this and after a while you find yourself building UIs slower.

How does this compare to React Server Components?<p>Which are basically just server side routes &#x2F; rendering + optional pre-rendering ala static site generators using simplified react components?

It&#x27;s like GWT for Python. Is that a fair assessment, you&#x27;d say?

The stated goal&#x2F;outcome seems pretty good. Glad to see more of this in Python in particular.<p>To those dissing it for production use case over a hand build frontend by a frontend dev: yeah, no shit. But not everything needs such work put in. This is perfect for internal tools, and there&#x27;s plenty of indie hackers out there proving that you don&#x27;t need an immaculate UI to get customers anyway. Use it for what it is good for.<p>We need more tools like this, because it cuts the development effort in half when it hits its stride. That&#x27;s very valuable for internal tools especially, where you need something functional first and pretty second.<p>That being said, as a biased Laravel developer, I can highly recommend Filament both as an admin panel builder and declarative UI component kit like FastUI. It&#x27;s Livewire based instead of React&#x2F;Vue&#x2F;etc and so firmly within the Laravel ecosystem, if that bothers you. <a href="https:&#x2F;&#x2F;filamentphp.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;filamentphp.com&#x2F;</a>

Sounds promising! Gonna check it out.

Gradio does a pretty good job here.

&gt; If you&#x27;re a frontend developer — you can concentrate on building magical components that are truly reusable, no copy-pasting components for each view.<p>Please tell me this isn’t common. It’s been a solved problem for at least 15 years now. At least since PHP had any form of prominence on the backend in the late 90s early 2000s. At a minimum going all the way back to knockout.js, handlebars, YUI and ember.<p>If this is common in 2024 I have lots of questions

Oh No. Is it that time again? Someone who isn&#x27;t really a front-end developer reinventing front-end development.<p>I can&#x27;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.

...and yet, it is slow.

&gt; 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.<p>I know a lot of backend developers who are backend developers specifically because they don&#x27;t enjoy frontend work and prefer to leave that work to people who actually enjoy it. And I know a lot of frontend developers who feel the same way, only from the other side.<p>The tagline of FastUI is &quot;Build Better UIs Faster,&quot; but I think this will likely end up being &quot;Build Passable UIs Faster,&quot; because yes, for simple cases, you can represent HTML components as Python or Javascript or whatever other language you want, but once you need to build something complex on the frontend, it becomes very irritating very fast when you have to work like this -- and good luck getting your frontend buddies to help you, because now they have to get up to speed on a new framework to understand what it&#x27;s doing.

It seems the big selling point is building websites without JS.<p>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).<p>I wrote a post recently about how I feel like this loathing of all things FE&#x2F;JS is overblown: <a href="https:&#x2F;&#x2F;bower.sh&#x2F;front-end-complexity" rel="nofollow">https:&#x2F;&#x2F;bower.sh&#x2F;front-end-complexity</a>

For something called &quot;FastUI&quot; it sure does seem pretty slow at making a basic website with simple 2000s-era HTML...

This seems way slower (in dev time) and more verbose than iommi <a href="https:&#x2F;&#x2F;docs.iommi.rocks&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.iommi.rocks&#x2F;</a>