FastUI: Build Better UIs Faster (opens in new tab)

I think you might be colored by having used a bad system. It's like all those people who say ORMs are bad and evil, and somehow almost all of them have been forced to use Hibernate :P

You might want to try (my project) iommi https://docs.iommi.rocks/ It's very different.

Why not Python? I've never seen huge differences between Jinja, Razor, or Blade. Is there something about it you find extra annoying?

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.

I don't think a tool is doing its job well when you make it work for your app. By contrary, it should make your app work

Yeah I was originally wondering which toolkit it was using, and how it would compare against PyQt for example… but it seems a completely different thing.

Thanks for sharing! I wasn't aware of these frameworks. As for the events being processed server-side, this is exactly where FastUI differs from any other framework I've stumbled so far - the widgets are sent to the client, and it knows how to render them, so just like any other js framework there's no roundtrip for every keystroke.

Is there anything similar for Go?

> old fashjioned

> htmx

Htmx went 1.0 a little over three years ago. Is it really something you can call old fashioned?

I'm currently writing an app with Django. It's such a breeze. Everything just works and I only have to think about the problem I want to solve. The documentation is as fantastic as it was 10-15 years ago.

I'm not even really fan of Python and I really miss static typing (renaming things is painful) but oh well, I'm so productive with it that I can live with this.

Honestly, I think it's the only framework that I've ever used (never tried RoR though) which allows total flexibility while never bothering you with technical thoughts.

It's still as shitty to deploy as it was a decade ago but now we have containers so who cares.

I'm writing this app during a pause in my career (mainly frontend) after a burnout and it's reigniting my love for writing web apps.

Actually, FastUI is repeating the same thing. It's cool but don't we get the same thing if we return HTML instead of JSON, combined with HTMX? We rely on the browser and battle-tested Django forms. No need to invent the wheel.

> Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?

Hold on I thought HN is all hyped about HTMX now? Isn't that what that does too?

I recieved a "secure patient portal message" in email from my doctor. Navigating to the actual message took 5 clicks, and each click involved waiting 3 to 12 seconds for pages to load, while all sorts of react-y things happened like hydration, spinning loading icons, placeholders. This is on gigabit internet with 50 ms ping. Shipping javascript to provide snappy UI has utterly failed, please let us go back to 1 round trip to the server for each client interaction.

It can be.

1. It can save a lot of repetitive boilerplate code

2. You can keep validation rules in one spot.

I've been working with some toolkits like these after years of 'backend api, frontend vue/react/angular' and it definitely can save a lot of time. It's not always the best fit, but there isn't one approach to all applications that is the best fit. Everything has tradeoffs.

The ingenuity here is exactly not needing a roundtrip for every interaction. You request a page -> fastapi sends the client a json defining the components -> the frontend knows how to render this json into react components that run locally just like any other js framework.

It's even called "FastUI", that is hilarious.

Htmx and phoenix liveview do this, and they’re quite popular

Internal tooling

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

---

> This

Yeah, this uses Python and is not specifically an SSG, so it makes sense for a server to be needed. Making an SSG that uses this would probably be possible, though.

> Remix

Remix is a fullstack app framework with a focus on data flow, directly going against the JAMStack current. Makes sense that it needs a backend server.

> Next

NextJS offers static site generation support. https://nextjs.org/docs/pages/building-your-application/rend...

> Astro

Astro started out as an SSG, and even now that server rendering is supported first-class, static site generation is the default and on-demand rendering needs to be opted into by the developer. https://docs.astro.build/en/basics/rendering-modes/#server-o...

Making initial page loads significantly faster, especially on intermittent mobile connections (which is an extremely common situation often underestimated by web developers) is worth a little bit of complexity, yes. And the entire point of these frameworks is to abstract away most of that complexity.

Big reason why i love jekyll, it's just a shame that development is so slow it feels abandoned and the plugin ecosystem is lacking

This is nothing new. HTML has always been rendered from a sever.

> When you run flet build <target_platform> command it ... Packages Python app using package command of serious_python package. -- https://flet.dev/docs/guides/python/packaging-app-for-distri...

It looks like Flet is for client-side code. It lets you write Flutter apps with Python instead of Dart.

> Simple Architecture - No more complex architecture with JavaScript frontend, REST API backend, database, cache, etc. With Flet you just write a monolith stateful app in Python only and get multi-user, realtime Single-Page Application (SPA). -- https://flet.dev

If I'm writing Python that runs on the mobile device, it must talk to a server to read & write data. Doesn't this still require an API backend, database, cache, etc?

I discovered Flet via HN a few months ago, and it has been really fun to play with (although it's a bit tricky to figure out the right path to make updates happen to nested controls).

Thanks for your work on it, and (shameless nudge!) I'm really looking forward to iOS camera access, and easy iOS deployment!

Unfortunately Flutter (which seems to be the backend for Flet), is IIRC rendered in a HTML5 canvas, which yields bad accessibility and is overall a pretty bad way to build web apps.

It's kind of unbalanced, as web tech, on the other hand, is pretty good at building desktop apps.

Skip the python and use xml+xslt directly in the browser if you like it

Most of the cost of a software project is from ongoing maintenance. When we make it easy to write the first version and make maintenance harder, the total cost of the project goes up.

Projects like FastUI allow maintenance of a project with fewer skills, directly reducing the cost of maintenance: owning teams spend less time learning and maintaining their skills and there are fewer bugs due to engineers making mistakes because of low skill-level in a technology.

Also, projects like FastUI make the project's tech stack much simpler. Simplicity helps reliability, incident resolution, security, testing, adding features, removing dead code, refactoring, etc. Highly-productive teams apply these ideas and keep their systems as simple as possible. As tools like FastUI mature, they will become standard in healthy engineering orgs.

Netlify is my goto for deployment, they make it super simple. Link your repo and set your production branch, build command, and directory to publish and whenever you commit it'll automatically deploy.

React code is basically the opposite of nice. Bad language and horrible ecosystem :D

Seriously, I first tried it in 2013, used it for work from 2014-2016 and here and there for odd projects later, and the amount of churn and complexity of the ecosystem has been surprising every time I check back on it.

My Obj-C from even longer ago pretty much all runs fine and is fairly understandable even for most iOS devs who started after Swift was the default.

It's essentially worse. The target audience is people like data scientists who are only familiar with Python, but it won't replace isomorphic javascript anytime soon or ever.

The main difference is there’s at least 1 company using FastUI

/s (but only half)

> where you need something functional first and pretty second.

Yet Filament manages to be fairly 'pretty' out of the box. I did a POC for a client project, and replicated about 10% of their current system in about a month, and got a fair amount of praise from folks at both the professional look/style/feel, yet... I did 0 on the styling, just used the defaults.

Yes, Filament has some rough edges when you try to color outside the lines, as with any toolkit. However, I don't think I've found anything else that comes remotely close to the combination of productivity and decent styling out of the box. Not just in PHP, but in any stack.

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 not get the benefits of a ML/AI/DataScience driven feature if they can't see it inside something that resembles a UX.

Front end people don't get this pain, because their work has immediate visible impact. Backend work doesn't need to be sold because it naturally emerges out of the needs of supporting a certain number of users. ML work, lacks visibility just like backend but isn't as self evident as backend work.

Tools like streamlit fill that gap.

While the sentiment is relatable, I think it’s too harsh. Frontend devs would better thought why people ignore their mainstream and use simpler tools instead. For what’s worth, the scenario you described assumes they did something useful behind that trash fire and for some reason avoided dealing with a frontend team/guy. Explanation through pure incompetence fails to see and meet their needs.

> to build something complex on the frontend

But, unlike frontend devs, designers and product managers believe these complex things are needed, they almost never are and actually bring a lot of issues with them instead. I rarely see a complex component/combination (in a SaaS, let alone on some landing/public page) and think, "well, that adds real value over just a standard component". If you can point some out, please do; there are very obvious cases where something else than standard is needed, but that also depends on your definition of standard; if I can buy complex off the shelve somewhere, you are not building something complex in the frontend and so you can use simple means to hook them up without the complexity.

You would be surprised how far a company can get with a Django admin for customer service or sales teams.

I’m primarily a backend developer these days, because that’s just how it’s played out where I work. But we’ve made the choice to do most things with Typescript since it lets us share resources, libraries and cooperate better with code reuse/reviews and such. So I can fairly easily switch to working on our React frontend, what I can’t do, is to make quick frontends for the services which will sort of need an “excel” type frontend. We even have a fairly generic component for it, but it very rarely does the job because our business is… well demanding things they might not really need.

This looks like a good thing. In that regard. Maybe not for us, but definitely a very useful tool for all developers because it can potentially let you deliver business value rapid.

Which is what I read from the lines you quote. I see no backend vs frontend discussion here, I only see a useful tool.

Even if you want to eventually build it into your React frontend, a tool like this will offer immense value for internal testing by users who won’t be able to do it through something like Postman, which is basically 99% of the employees in non-tech enterprise.

My approach to what they are doing in my last job was to augment our models with more fine-grained information than what the database schema held, as well as with metadata about which views made sense or were needed, and then output schema information in our API. The raw base case was generated directly from the live database schema, so even without a line of code you had something once you'd enabled it (default off for anyone but people with devops level admin rights because giving a default on view of a raw table is a recipe for leaking data), and most of what the models provided were just more structured forms of what the models already needed, such as validations.

Then we built a set of generic frontend components for that in React once.

And we then had an instant UI for 50+ models, but the frontend devs could trivially selectively override both the whole page for models where the default was too simplistic, or how to render specific types of fields or for specific fields of specific models.

The "instant UI" was flexible enough that for most "backend" views we never customised it on the frontend. But being able to have the frontend devs customise the user visible things was essential, and thanks to having the ability to replace things bit by bit they could focus on the things that didn't look or work right, instead of "everything". And a lot of their work then made it back into augmenting the backend with info to let the generic frontend apply those improved views elsewhere as well.

I have only had a cursory look at FastUI. If they do something similar to that, then great. If they actually try to have the backend generate all or most of the UI and serve that up instead of serving up metadata, then I fully agree with your issues.

Its a shame that RAD on the web is so far behind stuff like Qt

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.

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

https://news.ycombinator.com/item?id=39568486

This. In my experience frontend is not for everybody. There is a reason why FE and BE are often separated - because it makes sense in most non-trivial apps. Related, I never understood the appeal of isomorphic apps either. It's not like the code for UI and data access is very similar.

I love TypeScript, and I think React is mostly very elegant, and I still find front end work to be a real chore. Fucking around with forms and CSS and responsive breakpoints is not my idea of a good time!

I don't think the main problem backend developers have with frontend work is the language. As you say, Typescript is a really good language - in many ways better than Python. I don't think it's even the tooling, although becoming basically competent with two very large tooling stacks is not a trivial matter either.

I think there's a fundamental verbosity to the way most SPAs do data management - I've seen it said elsewhere that when you build a SPA, you basically end up having to reinvent the database, by which it is meant that an inordinate amount of your code is dedicated to extracting data from the backend via an API and then keeping track of that state using mountains of front end code.

At some point, you have to decide - is this really two separate applications (a backend and a frontend), or is it actually just one? If you don't have a need for multiple different clients, and you already have a backend written in Python (or some other backend language, e.g. Elixir, Kotlin), then maybe you can get away with writing a whole lot less code if you can find a framework that fills in that whole in-between layer for you and lets you stick with the language you already have.

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 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’m assuming “Fast” here is the same as in “FastAPI”, meaning fast for developers comfortable with python to build with and not fast in the sense of performance.

It means the UI abstains from eating, not that it works quickly.

Be careful. I made a similar comment and it was flagged.

It's customary to mention when you're promoting your own project.