return to table of content

FastUI: Build Better UIs Faster

jawns
33 replies
1d16h

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 who actually enjoy it. And I know a lot of frontend developers who feel the same way, only from the other side.

The tagline of FastUI is "Build Better UIs Faster," but I think this will likely end up being "Build Passable UIs Faster," 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's doing.

calvinmorrison
14 replies
1d16h

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

nurettin
5 replies
1d12h

And Qt is leaps and bounds behind Delphi and Lazarus.

It is even behind rails g scaffold when it comes to RAD.

int_19h
4 replies
1d10h

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.

nurettin
0 replies
1d8h

Data source on the form idea originated from Borland Delphi. Later, Anders Hejlsberg quit Borland to work at Microsoft, where he implemented the idea of visual and non-visual components and property editors in .net

You would be even more impressed with Delphi, because after connecting your data source, your form fills with data at design-time. Lazarus and Typhon does the same.

dgiovan
0 replies
1d5h

THe ultimate RAD was Delphi.

badsectoracula
0 replies
1d9h

Remember how you could just "add" a database [...] and things just magically worked?

You can do these in both Delphi and Lazarus, except with a much better GUI framework (comparing GUI only here, not everything you'd get with .NET). If anything having worked with Windows Forms for a while i think it was abandoned before it reached even what you could do in the midlate 90s in Delphi.

LtWorf
0 replies
1d9h

The ultimate RAD was Windows Forms

Layouts >> fixed size window

rescbr
3 replies
1d14h

Web development used to have a RAD experience in the ages of PHP 4/ASP Classic and Dreamweaver.

For better or worse, we lost this capability in the path for code purity, RESTful services and SPAs.

g-b-r
2 replies
1d6h

and accessibility, and standards compliance, and maintainable code...

rescbr
1 replies
1d2h

That’s why I said for better or worse :)

In a way I disagree with you.

On accessibility: I see more custom components that nobody cares to make it properly working with keyboard interaction compared to native HTML input components.

On standards - mixed feelings: we had XHTML, now we don’t. We had IE and jQuery to deal with it, now we don’t need it, but I still see many places that have the old “works best with” message, now with Chrome instead.

On maintainable code: it’s a different shit show, we exchanged spaghetti code for billions of npm dependencies that break if you dare to try and upgrade something.

g-b-r
0 replies
1d1h

Yeah you're not wrong, I'd stop half way around 2005, or maybe in the alternate world where the whatwg, Chrome etc never happened ;)

enoch2090
2 replies
1d14h

Actually, does Qt have something like FastUI? Been looking for one.

LtWorf
1 replies
1d9h

You can compile Qt to target the browser instead of native apps. But besides seeing a demo I don't know how good it is with performances, accessibility and so on.

enoch2090
0 replies
1d8h

I think Qt does have WASM compilation options, but I mean generating interfaces given models like Pydantic/Dataclasses/etc.

LoganDark
0 replies
1d15h

What makes Qt special here? Qt has its own issues that make it painful to use.

xtagon
5 replies
1d14h

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.

ipaddr
3 replies
1d13h

The kind of site that gets all of their data stolen. It can be a cool pattern.

vidarh
0 replies
1d7h

If serving up metadata about what the site already makes accessible via the API will get their data stolen, then the actual problem is they're not applying access controls to the data, not the introspection.

lozenge
0 replies
1d7h

In Django I had code in every view ensuring that the user was not accessing another user's data. If I create an abstraction like a utility function or "model manager" to handle this, I have to remember to call it from every view. In Graphene, this logic would be in a resolver which is used across multiple views.

dventimi
0 replies
1d13h

Rubbish

vidarh
0 replies
1d7h

We didn't use GraphQL, but in my last company that was essentially what we did - every API call returned schema information about the parts of the model the current user had access to, with detailed type information and which validations to apply, and metadata that affected presentation, and the frontend built a UI from that.

We then let designers/frontend devs override that on a case by case basis instead of building from scratch, and where possible tried to roll that into the generic UI as components triggered by specific metadata from the backend. It was not entirely agnostic, but it was largely driven by metadata from the backend, so e.g. schema changes rarely needed much, if any, UI work unless they fundamentally changed how the page worked.

vidarh
3 replies
1d7h

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.

lifeisstillgood
1 replies
1d6h

So, how did the “override” work? What made it easier to replace a part not whole page without understanding how the framework worked?

Agree completely that is the only sane goal - just wondering how you got there?

vidarh
0 replies
1d5h

"The framework" in this case was a very thin layer underneath a bunch of components for which one of the inputs was a prop that included the relevant part of the schema from the server. So at a top level you got everything. The default top-level component knew to look up a view definition, and type, and a function that knew how to render that type, and that was pretty much it.

Then it'd just apply that recursively. For a simple model there'd only be two levels: The view, containing a bunch of columns, and the columns themselves, and the view type knew to iterate over the columns in the view and look up their type and tell them to render themselves. For more complex views frontend devs might e.g. provide a custom view type that'd group columns based on certain attributes, but still delegate to the generic mechanism to render those columns.

So replacing a part just meant writing a component that knew how to render itself from its props, just like any other component. Just that some of those props would be coming from the backend.

We'd generally try to avoid replacing components if the only reason for a component was to override how something was rendered, and to focus on why it should be rendered differently and consider if we could reflect that 'why' in the data, or other ways.

E.g. were certain fields grouped together because they were semantically related? Then reflect that with an attribute in the "meta schema" for those columns, and make the frontend component render related groups according to the type of that group (let's say a bunch of fields reflects a user address). Incidentally this tended to be very simple, as with a relational model when there were groups like that the right thing was often for them to be a separate table/model anyway, and we 'just' needed to distinguish between type handlers for rendering an object 'as the page' vs. 'as a reference' vs. 'as a group within the page', and that was easy enough to distinguish "well enough".

At a top level, we'd look for a registered view-level component (or fall back on the default), within a view if the backend returned the model instance "in-line" we rendered it as a group, and if it returned an id, we'd render it as a reference.

So a "User" object for example would render as a profile view if it was not your user and you went to a page where the associated API call returned the User as the top level model, you personalised profile page w/optional edit view if it was your user, or a "pill" linking to the user profile if it was just a reference.

The idea was that frontend components should focus on how to render specific types of data in a specific context, rather than specifying how specifically to render the page, because it'd make no sense to have the frontend e.g. try to render a field that no longer exists, or try to render a field as a different type it is when the meta data about which fields were available and what type they are was already available.

hakanderyal
0 replies
1d5h

That's the way I've been doing things for a long time as a freelancer also.

Especially for business oriented apps, most of the models only need a list view with a table, and a detail view displaying some properties and related lists of models.

It works wonderfully.

whazor
1 replies
1d10h

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

lozenge
0 replies
1d7h

Django admin is really extensible. I'm not seeing here how to offer multiple forms against the same model. Eg if a user can edit some of their profile but not the subscription plan field, while a sales team can.

https://github.com/pydantic/FastUI/blob/main/demo/forms.py#L...

bornfreddy
1 replies
1d11h

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.

regularfry
0 replies
1d8h

It looks to me like FastUI is literally the BFF pattern with a pre-supplied front-end. If that's true, then complaints about it should be viewed through the lens of who has control over the application, who is gaining control, and who is losing it.

I've had quite vocal arguments from front-end devs which, when we stripped back what they were actually complaining about, came down to the front end being in service of the back end, rather than vice versa as they were used to.

anonzzzies
1 replies
1d8h

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.

ajjenkins
0 replies
1d4h

A lot of custom front end components that I’ve built were more about aesthetics than functionality, so I agree that it’s often unnecessary. In terms of functionality, you can get really far using only native HTML elements.

One common front end component that you can’t build with vanilla HTML is an autocomplete/typeahead input. I’ve had to build a few of these in JavaScript and I do think they’re genuinely helpful. It’s helpful to get suggested options as you’re typing. I also think search results that get filtered in real time as you type are helpful and can’t be accomplished with pure HTML.

manojlds
0 replies
1d10h

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

devjab
0 replies
1d10h

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.

sirsinsalot
20 replies
1d4h

After years of crispy forms and HTML-in-Python hackery, I am firmly on the side that the presentation layer shouldn't be so tightly coupled to the code that renders it.

A template language (that isn't Python) is sufficient. Even better if you can render the templates from different languages.

I'll never be defining web app presentation in Python.

boxed
12 replies
23h29m

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.

mvdtnz
11 replies
22h44m

ORMs are bad and I say that as a veteran of Hibernate, Entity Framework (almost every version, including code-first and db-first), E Bean, NHibernate and, worst of all by far, ActiveRecord.

marcosdumay
3 replies
22h23m

And yeah, you are just reinforcing the GP's point, because all of those are atrocious.

I am at the ORMs are bad club, but if you try any of the systems that encode the logic paradigm into their interface, they are a completely different kind of beast. (MS has brought some of it into C# with linq so you can use with the Entity Framework. It's not a fully logic system, and has so many attrition points with the Entity Framework that it's mostly not useful at all.)

mvdtnz
2 replies
12h30m

I'm very familiar with Linq and Linq to SQL. It's as close as any ORM got to being "good enough" and was abandoned by Microsoft very early in its lifecycle. Linq in Entity Framework is a minefield of N+1's and excessive eager loading.

skyde
0 replies
1h1m

In EF line expression you can easily specify which navigation should be Eager loaded.

var customersWithOrderDetail = context.Customers.Include("Orders").ToList();

Would generate :

SELECT * FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId

boxed
0 replies
9h20m

The N+1 problem is solved in iommi (again, I am one of the authors) by simply:

1. keeping a log of queries per request with stack traces

2. at the end, checking if there are N+1 problems

3. print a big warning with example SQL and stack trace to the console

During dev if I miss a prefetch_related/select_related the console will start to print gigantic stack traces telling me where the problem is. I don't have these problems in production because I get alerted to them in dev.

These are not only solvable problems but EASILY solvable problems!

(Also, in iommi tables, most of the times it can automatically figure out and do the prefetch/select related for you, further diminishing the problem)

animal_spirits
3 replies
16h17m

Django's ORM is beautiful, I can glide through queries using it. It makes SQL a breeze

LtWorf
2 replies
5h46m

But is it fast?

boxed
1 replies
3h41m

Fast to develop with? Yes.

Fast to run? Well.. no.. it's Python.

I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.

LtWorf
0 replies
3h13m

You're doing queries to a db, the fact that it's python is not your bottleneck

bpanon
0 replies
19h7m

AR is fantastic. I never struggled to get what I wanted with AR.

boxed
0 replies
9h24m

And me, who have never used Hibernate, but has spent over a decade in Django thinks ORMs are great. This is exactly my point.

946789987649
0 replies
46m

JOOQ is the only acceptable ORM.

Capricorn2481
6 replies
1d2h

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

pjerem
5 replies
1d

In Jinja, Razor, or Blade, you write, HTML that you enrich.

With FastUI, you write Python.

peddling-brink
3 replies
23h43m

When Python is the hammer you have..

Not every web app needs to survive HN levels of traffic. Empowering the <insert profession here> that already knows Python to make an app to automate their team’s toil is a great thing.

astrea
2 replies
23h2m

Exactly. If your team is fully fluent in Python and has a need for a web UI, easier to adopt something like FastUI than try to quickly upskill in JavaScript for a one-off project.

sirsinsalot
0 replies
17h28m

Perhaps, but it is a false economy. Anyone writing a UI for the web, should be fluent in HTML/CSS and so on. In that case, other templating approaches make more sense.

I say this with absolute conviction; you're just deferring costs, technical debts with compounding interest. When you come to pay it off, it'll bankrupt you.

LtWorf
0 replies
5h38m

They can use markup and a mkdocs

Capricorn2481
0 replies
10h10m

What? How is Razor more of HTML than Jinja? Both are mostly HTML with syntax specific to their languages. They don't even look that different.

Jinja:

{% for item in items %}<br> {{ item }}<br> {% endfor %}

Blade:

@foreach(var item in items)<br> {<br>@item<br> }

madeofpalk
13 replies
1d18h

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

LtWorf
8 replies
1d18h

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

hotfixguru
2 replies
1d2h

Not the first time I see you try to use any thread related to pydantic or fastapi to market your own library, it’s getting boring.

LtWorf
1 replies
15h39m

I'm under the impression that you work for a company that sells services related to FastAPI? https://github.com/Intility/fastapi-azure-auth

I maintain an open source library in my spare time for free, that you are welcome to ignore if you find better alternatives.

hotfixguru
0 replies
3h27m

You’re under the wrong impression, I’m a network engineer who happens to _use_ FastAPI for some projects. The library linked I made at work, but open sourced and wrote docs for in my own time. The other libraries I’ve written are all in my spare time.

My comment is my own opinion, and a quick search for your name and pydantic backs it up. It’s just boring to read the same thing, every time.

manojlds
1 replies
1d10h

Fast for me was about the DX rather than performance.

LtWorf
0 replies
16h30m

What does dx mean?

0cf8612b2e1e
1 replies
1d17h

I am certainly not in love with how the FastAPI team handles comparisons or development. Hiding superior benchmarks. Immediately closing Github issues (they refile as Discussions to keep the issue count low). So on and so forth.

LtWorf
0 replies
1d17h

I suspect that part of the problem is that they got VC money to do the rewrite in rust, and it took very long and the results aren't as amazing as expected.

But that's just my own conspiracy. I have no idea. Perhaps things changed since I last ran the benchmarks.

Benchmarking isn't easy. I know that my software using my library mostly loads Unions, so that's a focus in my benchmarks. However I have absolutely no idea of what the other users are doing with it, and my benchmarks might not be relevant to them.

In the end I wrote them for myself mostly, to check for possible regressions in performances.

erezsh
0 replies
1d

The Pydantic project has a long history of misrepresenting their benchmarks, and ignoring the existence of much faster alternatives. I'm not at all surprised that their supposedly super-fast rewrite isn't really as fast as they made it out to be.

__jonas
1 replies
1d18h

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.

jeremycarter
0 replies
20h2m

Which is a deceptive tactic IMO.

jeremycarter
0 replies
20h3m

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

DonHopkins
0 replies
1d

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

slmjkdbtl
12 replies
1d10h

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?

Culonavirus
4 replies
1d6h

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

jasonjmcghee
2 replies
1d

Have you used FastAPI? Certain functionality like file upload is mind blowingly slow.

FastX is popular these days.

dralley
0 replies
22h42m

Anyone have experience with Django Ninja?

jacobyoder
0 replies
1d2h

Fast to develop, not necessarily as fast as a 'written and optimized by hand' UI.

__jonas
1 replies
1d3h

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?

Capricorn2481
0 replies
1d2h

Yes that's exactly what it does, and it's possible some people don't know that because they haven't had to think about that stuff at work. But I do think the ergonomics of HTMX are better. I would argue that lowers the barrier to doing exactly what you want, which will lead to less over fetching.

williamdclt
0 replies
1d1h

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

shmooper
0 replies
23h56m

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.

jacobyoder
0 replies
1d2h

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.

dgellow
0 replies
1d7h

Internal tooling

QuadmasterXLII
0 replies
23h27m

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.

mikeocool
11 replies
1d

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.

Do the features offered by these really warrant the complexity?

avarun
5 replies
1d

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.

drowsspa
3 replies
22h51m

That's the elevator pitch, but as someone with a middle-tier Android phone and in an area with not that stable mobile connection, those supposely "optimized" pages work much worse than plain old HTML. It's even funny how my phone struggles to even render the home pages of these projects.

Developers always find ways to down-compensate gains due to Moore's law and its infrastructure equivalents.

avarun
2 replies
20h26m

Of course it's slower than plain HTML being delivered from the server. That's not what we're comparing to, and frankly if that approach fits the needs of your project then go ahead and use it.

The real comparison point is client rendered SPAs, which is the status quo in web app development that SSR frameworks are competing with. If that's your starting point, SSR is a strict optimization and a significant improvement for almost all usecases besides internal admin tools that are only meant to be used on desktop.

ezst
1 replies
10h22m

Not OP, but I think the point might be that we get served more and more SPAs weighting millions of lines of JS for anything and everything, because it's trendy in a resumé-driven industry, while overlooking the end-users needs and constraints

avarun
0 replies
7h32m

That's not a relevant or useful point at all. Obviously there will always be people using the wrong solutions for their problems. Doesn't mean that other people don't have perfectly valid problems that need a solution.

cuu508
0 replies
23h50m

What complexity is needed or helpful? Plain HTML is simple and loads quick.

FinalBriefing
2 replies
23h49m

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

smolder
0 replies
22h48m

There's a big difference between serving up static documents (I wouldn't call this "rendering") and dynamic documents. Then there's also a difference between using a templating system for dynamism or a more programmatic and less portable page generation system that's anchored in a specific language like this.

hanniabu
0 replies
22h51m

Served from a server and rendered from a server is completely different.

hanniabu
0 replies
22h52m

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

FireInsight
0 replies
22h22m

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

japhyr
8 replies
1d17h

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.

elijahbenizzy
7 replies
1d16h

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 hacks

3. The control flow of when it’s running/executing makes for clunky interactions

4. Some API decisions are painful. For instance, a block str comment in the file will render as st.write

5. Long running (or even not instant tasks) make for some annoying engineering challenges — the UI is tied to the compute, so you have to be smart about juggling it

6. Caching is not smart — it’s quite useful, but it’s easy to get lost in caching/state

I’ve been dreaming about streamlit but a little more state/function oriented. E.g. react-based. Not far from fastUI

These are both great tools for prototyping, but I’ve found that I’ll pull up tailwind + some UI framework when I want something slick and it’ll take a few times as long.

jairuhme
5 replies
1d16h

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

jcheng
3 replies
1d9h

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

spinningslate
0 replies
1d8h

Haven't used Shiny on Python yet, but we use the R version a lot. It's been a good experience: solid, reliable framework, good set of widgets, decent styling out the box.

The Python version is a port from its R stablemate (well, maybe more than a port: a re-engineering). If it's as solid as its R parent then it'll be a very useful addition to the Python UI landscape.

jairuhme
0 replies
1d4h

Didn't know that there was shiny for python, so I'd definitely be interested in trying it out

elijahbenizzy
0 replies
1d1h

That looks slick! Didn’t have any idea shiny was in python, but IIRC data scientists I’ve worked with in the past love it.

elijahbenizzy
0 replies
1d1h

Yep agreed, I really found it good for the first something — e.g. a more advanced figma. Past that it was a bit of a gamble.

enoch2090
0 replies
1d14h

Streamlit's state management is so painful, feels like constantly writing hacks.

dragosmocrii
0 replies
1d

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

qudat
9 replies
1d18h

It seems the big selling point is building websites without JS.

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

I wrote a post recently about how I feel like this loathing of all things FE/JS is overblown: https://bower.sh/front-end-complexity

petesergeant
6 replies
1d16h

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!

8n4vidtmkvmk
5 replies
1d12h

You shouldn't need breakpoints 98% of the time. Use flex box and grid. Failing that, try container queries.

A really good form is still a PITA. I've been trying to perfect it for years but haven't found anything to sync frontend and backend validation that doesn't suck/involve a lot of boilerplate.

petesergeant
0 replies
15h49m

This looks excellent, thank you. I'm iterating a lot of startups at the moment, and sort of home-growing a framework, but each new product I want to replace bits of it with off-the-shelf tooling, and this is an excellent selection of components.

erhaetherth
0 replies
15h39m

No, hadn't heard of that. Looks like it's doing a bit too much. I'm not sold on ORMs or auto-genned scaffolding apps. The tRPC lib they're using OTOH looks interesting. Kind of. Looks like I'd have to give up my server lib/router for theirs, but then it looks like they botched the client-side error formatting which is the one thing I haven't solved: https://trpc.io/docs/server/error-formatting How is this good UX?

    <pre>Error: {JSON.stringify(mutation.error.data.zodError, null, 2)}</pre>
Formik (https://formik.org/docs/api/errormessage) does OK with the "touched" and "errors" objects, that helps you render out the error messages nicely, next to the inputs, but for my very first use-case I wanted to validate a File input and it seems to struggle with that a bit. Can't do it without suppressing some TS errors but maybe it's an edge case. And it of course doesn't handle the server half of the equation. So.. yeah.

elbear
1 replies
1d8h

Can you detail your troubles with syncing frontend and backend validation?

8n4vidtmkvmk
0 replies
23h19m

Well, for my latest iteration, I'm using Bun+Elysia on the server which uses Typebox for request validation+schema, which is effectively JSON Schema so you could do something similar in other languages. I can pass that schema down to the client/browser, and I could use AJV to run that schema against the request before I send it to the server, but there's a couple tricky parts.

1.Json schema/AJV return not very human friendly results and they're hard to associate with a specific field to display the error nicely 2. If you want to validation as the user is typing to clear errors as they're satisfied, you have to run the entire schema, not just for that one field 3. Any async validations like checking if a username is unique is harder if not impossible with this approach

ledauphin
1 replies
3h13m

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.

qudat
0 replies
2h46m

Ah! A real criticism of FE development, I agree with your problem statement.

When you jump into the world of single-page applications, things get complex pretty quickly, because the use case for needing an SPA pushes the web app into a full desktop application.

Ultimately, for a highly interactive and dynamic "desktop-class" user experience, there is added complexity. I think that's why so much movement within the FE world has moved away from "SPA for everything" and into these mixed dynamic apps. Islands, React Server Components, NextJS, they all help create a middleground between a document-based website with no dynamic elements with a full blown desktop app experience. They all have real tradeoffs, in particular adding an entirely new backend service to serve the front end.

For many projects, react + react-query is probably enough.

Having said that, my argument from https://bower.sh/dogma-of-restful-api still stands: when you build an API that is RESTful (1:1 mapping between endpoint and entity) you are unknowingly pushing the complexity of data synchronization to the FE, which requires a well thought out ETL pipeline.

This probably doesn't help my case but I've been building a simplified middle-layer for react to bridge the gap between react-query and full blown SPA: https://starfx.bower.sh

ic_fly2
9 replies
1d2h

Call me old fashjioned but what is wrong with django and htmx?

Works beautifully and fast, send only rendered code to the front. Have db admin for when you scale

pjerem
5 replies
1d

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.

MyFirstSass
2 replies
23h31m

I've been a Laravel guy mostly, but tried Flask for a project last year, and it was so incredibly easy to get up and running.

Still not really sure how the two compare, but there was just something about the extremely tried and battletested code. Nothing got in my way, the code told you what it did, it was fast etc.

rolisz
0 replies
23h0m

Recently tried Flask for a project started by someone else, made me want to run to FastAPI right away.

marcosdumay
0 replies
22h19m

Flask is the hard one to get up and running alternative, where you must look at every detail, that lets you create an application exactly as weird as you need.

The fact that you found it so simple coming from another framework speaks loudly about your previous one. But they do compare in that Django is the easy one to start where most choices are already done for you.

maronato
0 replies
1d

Django is truly amazing. It’s as you said - you don’t have to think about anything else other than the business problem. Authentication, session, databases, RBAC, everything is handled for you. Unfortunately, if you want to use react, it usually means you’ll write APIs that are consumed by a browser-rendered app.

The holy grail for me would be a Django backend that renders react on the server. A Django nextjs.

AlchemistCamp
0 replies
1d

I don't like Django as much as Phoenix (or Rails for that matter), but I'd take it over a Node-based backend any day of the week.

semiquaver
2 replies
1d

old fashjioned

htmx

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

mock-possum
0 replies
20h27m

It’s a figure of speech. Not literal.

gscho
0 replies
23h39m

The concepts that htmx has been built on have been around forever. Maybe that’s what they meant.

kumarvvr
7 replies
1d15h

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

8n4vidtmkvmk
6 replies
1d12h

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

vidarh
2 replies
1d6h

Try to write a generic data and time formatting template in xslt to let you do basic arithmetic on timestamps of the type you might want in a view.

When you've stopped screaming in horror at what you've suffered, we can discuss whether you still think that's a good idea.

The overall concept is good, but sadly xslt is constrained enough to be massively painful for this kind of thing.

8n4vidtmkvmk
1 replies
23h16m

I tried it for a couple days years ago. I concluded it was not a good idea then

I'm a full stack guy myself, so I'll stick with React.

vidarh
0 replies
21h18m

So a pretty bad faith suggestion then - the way the linked site does things is nothing remotely resembling your "suggestion" to use XSL.

int_19h
2 replies
1d10h

The XML+XSLT equivalent here would be an XSLT stylesheet with a bunch of predefined rich parametrized templates that you can just <xsl:call-template>. Hand-coding XSLT to produce HTML (or whatever) is still rather tedious.

dustrider
1 replies
1d6h

Did this extensively in the mid-naughties. Huge site, lots of data and traffic.

Performance exceeded what was available at the time, scaled super well, but not something I’d ever go back to.

- xslt is not a programming language. As soon as you start using xslt:functions you’re doomed.

- it is not a fit for interactive UIs. It’s good for static content, trying to mix in js goes wrong very quickly.

My opinion is that these days infra is cheap enough that you get all the same benefits by doing standard templating in your language of choice from your data in json or whatever. Which I know is essentially the same thing without the specialist software and dsl. And that’s kind of the point.

vidarh
0 replies
21h19m

Similar story for me. Conceptually I still like the idea, but not with XSL. JS operating on JSON as you say can do the same, but without all the needless pain. Though I'd still love a more declarative option - but I'll sacrifice that before I use XSL again.

appveyor
5 replies
1d2h

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

mleonhard
1 replies
19h46m

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?

appveyor
0 replies
19h27m

Thanks for your notes!

It looks like Flet is for client-side code.

For web you can package Flet app to client-side (with pyodide, all Python logic runs in the browser, see an example here: https://gallery.flet.dev/todo/) and run as a server-side app (or server-driven) with Python logic running on the server (example: https://flet-controls-gallery.fly.dev/layout - notice faster loading compared to client-side one).

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?

That's correct. Any backend service which provides Python API can be used when running Flet app on a mobile: FastAPI, Firebase, Supabase, Pocketbase, etc, but you use Python to call that which is awesome especially for beginner and non-web developers.

FireInsight
1 replies
22h9m

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.

appveyor
0 replies
19h49m

SEO - maybe, but IFAIK accessibility in Flutter web app shouldn't be an issue (I just saw this comment from someone on Flutter team: https://news.ycombinator.com/item?id=24922849). They've been recently doing a great job in terms of performance (compiling app to WebAssembly) and size. I agree that Flutter web is not good for building websites, but for web apps, especially those "internal" apps used by a small group of users, it's a pretty decent solution.

mft_
0 replies
9h28m

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!

IceDane
4 replies
1d16h

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.

wruza
1 replies
1d14h

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.

wiseowise
0 replies
1d10h

I’m not a frontend dev and even I don’t understand why would you use this over vanilla html + css + JS. You don’t need to be a front end dev to do a basic UI like this.

screye
1 replies
1d16h

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.

bormaj
0 replies
1d14h

This is probably the best summarization I've seen that describes this space. Even outside of ML, there's a real use case for building small, contained UIs for non-technical people to use in place of CLI tools.

The focus of these products should be 0 to 1 rather than 1 to Inf.

promiseofbeans
3 replies
1d8h

This seems to mainly be useful for spinning up quick and dirty internal tools.

But for that use-case, isn't it easier to use something visual and established like Retool (https://retool.com/) or that generates nice react code, like MUI Toolpad (https://mui.com/toolpad/)?

AlchemistCamp
2 replies
1d8h

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.

wruza
0 replies
22h57m

Chiming in to not let you feel alone in this. React feels like you're doing low-level assembly in an esoteric functional language that ought to be simulated in javascript, but due to limitations of the latter you have to simulate it by hand, by following the manual. Looks absolutely delusional to everyone who catched peak ui phases like Cocoa and UIKit. I remember writing custom components in Obj-C and never thinking about all the nonexistent issues which React claims to be a perfect solution for every few years.

hu3
0 replies
1d5h

Agreed. And React Components was the final nail in the coffin for me.

Tainting what used to be a lean frontend library with server side concepts [1] was a net negative in my opinion.

[1] https://react.dev/reference/react/use-server

account-5
3 replies
23h25m

I write my side projects in dart/flutter. Least friction, less hassle. If I needed to write a web app and flutter wouldn't cut it, I'd probably go htmx.

EDIT: my main issue is figuring out how to simply deploy a website.

hanniabu
2 replies
22h49m

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.

FireInsight
1 replies
22h17m

I'm just here to fullfill the prediction by someone, I don't remember who, that every time Netlify is mentioned in the future [this thread](https://news.ycombinator.com/item?id=39520776) is mentioned.

Maybe someone will even recommend Cloudflare Pages or a $5 VPS.

pizzafeelsright
0 replies
19h26m

Wow. Keep others updated.

There really should be a max bill on every cloud service. I've accidently ran up a bill with AWS. Alarms aren't enough. Notifications aren't enough.

PufPufPuf
3 replies
1d18h

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.

cyberax
1 replies
1d14h

Is there anything similar for Go?

iamflimflam1
0 replies
1d11h

Maybe this: https://fyne.io/

shmooper
0 replies
1d

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.

pests
2 replies
1d16h

How does this compare to React Server Components?

Which are basically just server side routes / rendering + optional pre-rendering ala static site generators using simplified react components?

internetter
0 replies
1d15h

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.

halfcat
0 replies
1d11h

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

/s (but only half)

boxed
2 replies
1d18h

This seems way slower (in dev time) and more verbose than iommi https://docs.iommi.rocks/

manfre
1 replies
1d14h

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

boxed
0 replies
9h19m

My bad. I usually do, but I missed it this time.

yakkomajuri
1 replies
22h27m

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 "hey, you're a backend dev and can just quickly generate a UI in your own language" 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.

I'm far from being one of those people that's like all in on AI, but I've definitely been super impressed with its abilities to generate basic boilerplate code when you're working on project from scratch.

mleonhard
0 replies
20h8m

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.

TheCapeGreek
1 replies
1d6h

The stated goal/outcome seems pretty good. Glad to see more of this in Python in particular.

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's plenty of indie hackers out there proving that you don't need an immaculate UI to get customers anyway. Use it for what it is good for.

We need more tools like this, because it cuts the development effort in half when it hits its stride. That's very valuable for internal tools especially, where you need something functional first and pretty second.

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's Livewire based instead of React/Vue/etc and so firmly within the Laravel ecosystem, if that bothers you. https://filamentphp.com/

lowercased
0 replies
23h44m

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.

CyberDildonics
1 replies
1d18h

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.

I don't know why someone would say "Build UIs" and not mention html, it seems pretty myopic to think a UI automatically means a web page.

LtWorf
0 replies
1d18h

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.

webprofusion
0 replies
1d14h

It doesn't seem better or faster but apart from that, great!

no_wizard
0 replies
23h58m

If you're a frontend developer — you can concentrate on building magical components that are truly reusable, no copy-pasting components for each view.

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.

If this is common in 2024 I have lots of questions

nextworddev
0 replies
1d14h

This is a better retool alternative

mleonhard
0 replies
1d8h

Beyond Python and React ... Implementing frontends for other platforms like mobile ...

I'm building something like this for mobile: https://www.applin.dev

la_fayette
0 replies
1d9h

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.

kapilvt
0 replies
1d6h

I was looking at this space and nicegui seemed like the best ootb experience.

https://nicegui.io/

Fastui seems prettty barebones mostly a form adapter to pydantic models that I can see.

gar1t
0 replies
1d9h

Gradio does a pretty good job here.

cheptsov
0 replies
1d11h

Sounds promising! Gonna check it out.

betimsl
0 replies
1d3h

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

CrzyLngPwd
0 replies
1d

...and yet, it is slow.