Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FastUI: Build Better UIs Faster

github.com

Post reply on HN
Print view View original

181–190 of 230 posts

Re: FastUI: Build Better UIs Faster

#181

Post by petesergeant »

cjr wrote: post #164
8n4vidtmkvmk wrote: post #52

Earlier quoted context omitted.

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.

Have you checked out https://kirimase.dev ?

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.

Re: FastUI: Build Better UIs Faster

#182

Post by LtWorf »

hotfixguru wrote: post #113
LtWorf wrote: post #12

Earlier quoted context omitted.

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 overwhelm…

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.

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.

Re: FastUI: Build Better UIs Faster

#183

Post by erhaetherth »

cjr wrote: post #164
8n4vidtmkvmk wrote: post #52

Earlier quoted context omitted.

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.

Have you checked out https://kirimase.dev ?

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?

    
Error: {JSON.stringify(mutation.error.data.zodError, null, 2)}
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.

Re: FastUI: Build Better UIs Faster

#184

Post by mvdtnz »

marcosdumay wrote: post #159
mvdtnz wrote: post #156

Earlier quoted context omitted.

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.

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 F…

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.

Re: FastUI: Build Better UIs Faster

#185

Post by ezst »

avarun wrote: post #168
drowsspa wrote: post #153

Earlier quoted context omitted.

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.

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…

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

Re: FastUI: Build Better UIs Faster

#186

Post by Capricorn2481 »

pjerem wrote: post #122
Capricorn2481 wrote: post #111

Earlier quoted context omitted.

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

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

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 %}
{{ item }}
{% endfor %}

Blade:

@foreach(var item in items)
{
@item
}

Re: FastUI: Build Better UIs Faster

#187

Post by mft_ »

appveyor wrote: post #115

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.

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!

Re: FastUI: Build Better UIs Faster

#188

Post by boxed »

mvdtnz wrote: post #156
boxed wrote: post #141

Earlier quoted context omitted.

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.

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.

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

Re: FastUI: Build Better UIs Faster

#189

Post by boxed »

mvdtnz wrote: post #184
marcosdumay wrote: post #159

Earlier quoted context omitted.

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 F…

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.

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)

Post reply on HN