Live data from Hacker News

FastUI: Build Better UIs Faster

github.com

151–160 of 230 posts

Re: FastUI: Build Better UIs Faster

#151

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?

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

Re: FastUI: Build Better UIs Faster

#152

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?

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

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

Re: FastUI: Build Better UIs Faster

#153
post #132

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?

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.

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.

Re: FastUI: Build Better UIs Faster

#154

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.

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.

Re: FastUI: Build Better UIs Faster

#155

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?

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

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.

Re: FastUI: Build Better UIs Faster

#156
post #141

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.

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.

Re: FastUI: Build Better UIs Faster

#157

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.

Anyone have experience with Django Ninja?

Re: FastUI: Build Better UIs Faster

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

Re: FastUI: Build Better UIs Faster

#159
post #156
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 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.)

Re: FastUI: Build Better UIs Faster

#160

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?

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

Post reply on HN