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

201–210 of 230 posts

Re: FastUI: Build Better UIs Faster

#201

Post by 946789987649 »

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.

JOOQ is the only acceptable ORM.

Re: FastUI: Build Better UIs Faster

#202

Post by hansvm »

LtWorf wrote: post #197
boxed wrote: post #194

Earlier quoted context omitted.

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.

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

That's mostly false for a nontrivial fraction of queries in most bigger projects. If your queries are doing sane things (not regularly full table scanning for each customer, ...), little things like datetime conversions as the rows are instantiated in Python easily dwarf the cost of the database (depending on your networking setup and exact queries, perhaps just in throughput instead of latency, but Python will the still at least be the "cost" bottleneck for your app).

Re: FastUI: Build Better UIs Faster

#203

Post by paradox460 »

shmooper wrote: post #131
PufPufPuf wrote: post #4

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.

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.

Phoenix LiveView works this way

Re: FastUI: Build Better UIs Faster

#204

Post by pjerem »

maronato wrote: post #128
pjerem wrote: post #125

Earlier quoted context omitted.

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

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.

There is Django Unicorn. Never used it so I don’t know what it’s worth.

Re: FastUI: Build Better UIs Faster

#205

Post by pjerem »

AlchemistCamp wrote: post #127
pjerem wrote: post #125

Earlier quoted context omitted.

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

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.

Phoenix looks really cool too but I’d have to learn Elixir and while that’s something I want to do (already started some years ago), my main prerequisite for this project was not to struggle and going comfy. Building something out of my hand with no roadblocks was more important to me than to learn something new.

Re: FastUI: Build Better UIs Faster

#206

Post by LtWorf »

hansvm wrote: post #202
LtWorf wrote: post #197

Earlier quoted context omitted.

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

That's mostly false for a nontrivial fraction of queries in most bigger projects. If your queries are doing sane things (not regularly full table scanning for each customer, ...), little things like datetime conversions as the rows are instantiated in Python easily dwarf the cost of the database (depending on your networking setup and exact queries, perhaps just in throughput instead of latency, but Python will the s…

To convert some dates? Really?

Have you benchmarked this?

Re: FastUI: Build Better UIs Faster

#207

Post by hk1337 »

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.

ORMs are bad at some things and good at others. Some people are stubborn and feel like if they’re using an ORM then everything has to go through the ORM, for example.

Re: FastUI: Build Better UIs Faster

#208

Post by staticautomatic »

sirsinsalot wrote: post #178
astrea wrote: post #148

Earlier quoted context omitted.

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.

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.

I'm not the least bit ashamed to say that I can't grok CSS today any better than I could when I first tried to learn it about 20 years ago. Whether or not alternative abstractions are "bad" or "wrong" or whatever is entirely irrelevant to me. The worst case scenario is that I end up finding them as painful as CSS.

Re: FastUI: Build Better UIs Faster

#209

Post by jasonjmcghee »

duckmysick wrote: post #196
jasonjmcghee wrote: post #124

Earlier quoted context omitted.

Have you used FastAPI? Certain functionality like file upload is mind blowingly slow. FastX is popular these days.

I have trouble finding the FastX project you mentioned. Can you tell me its website? The top results I get are for the Fast and Furious movie. After specifying the context ("API", "web", "framework") I get hits for remote desktop software which also has API: https://www.starnet.com/fastx/ https://www.starnet.com/help/fastx-v3-api/ And "fastx python" returns a module for parsing FASTA files https://pypi.org/project/py…

Sorry for the confusion. I just meant, naming something "Fast" and then a descriptor, has become very popular.

FastHTTP, FastGPT, FastChat, FastAI, FastLED, FastText, FastClick, FastHub, FastSAM

Most of these have 10s of thousands of stars on github.

https://github.com/search?q=fast&type=repositories

Re: FastUI: Build Better UIs Faster

#210

Post by Timwi »

boxed wrote: post #189
mvdtnz wrote: post #184

Earlier quoted context omitted.

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

Can you explain what an N+1 problem is?
Post reply on HN