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?
FastUI: Build Better UIs Faster
151–160 of 230 posts
Re: FastUI: Build Better UIs Faster
#152It’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.
Re: FastUI: Build Better UIs Faster
#153It’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.
Developers always find ways to down-compensate gains due to Moore's law and its infrastructure equivalents.
Re: FastUI: Build Better UIs Faster
#154I 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.
Re: FastUI: Build Better UIs Faster
#155It’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.
Re: FastUI: Build Better UIs Faster
#156After 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.
Re: FastUI: Build Better UIs Faster
#157Re: FastUI: Build Better UIs Faster
#158I'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
#159Earlier 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.
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
#160It’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
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...