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

191–200 of 230 posts

Re: FastUI: Build Better UIs Faster

#191

Post by avarun »

ezst wrote: post #185
avarun wrote: post #168

Earlier quoted context omitted.

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

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.

Re: FastUI: Build Better UIs Faster

#192

Post by LtWorf »

animal_spirits wrote: post #180
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.

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

But is it fast?

Re: FastUI: Build Better UIs Faster

#193

Post by LtWorf »

astrea wrote: post #148
peddling-brink wrote: post #138

Earlier quoted context omitted.

When Python is the hammer you have.. Not every web app needs to survive HN levels of traffic. Empowering the that already knows Python to make an app to automate their team’s toil is a great thing.

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.

They can use markup and a mkdocs

Re: FastUI: Build Better UIs Faster

#194

Post by boxed »

LtWorf wrote: post #192
animal_spirits wrote: post #180

Earlier quoted context omitted.

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

But is it fast?

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.

Re: FastUI: Build Better UIs Faster

#195

Post by hotfixguru »

LtWorf wrote: post #182
hotfixguru wrote: post #113

Earlier quoted context omitted.

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.

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.

Re: FastUI: Build Better UIs Faster

#196

Post by duckmysick »

jasonjmcghee wrote: post #124
Culonavirus wrote: post #94

Earlier quoted context omitted.

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

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/pyfastx/

Re: FastUI: Build Better UIs Faster

#197

Post by LtWorf »

boxed wrote: post #194
LtWorf wrote: post #192

Earlier quoted context omitted.

But is it fast?

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

Re: FastUI: Build Better UIs Faster

#198

Post by ledauphin »

qudat wrote: post #10

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

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.

Re: FastUI: Build Better UIs Faster

#199

Post by qudat »

ledauphin wrote: post #198
qudat wrote: post #10

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

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

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

Re: FastUI: Build Better UIs Faster

#200

Post by skyde »

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.

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

Post reply on HN