Live data from Hacker News

FastUI: Build Better UIs Faster

github.com

161–170 of 230 posts

Re: FastUI: Build Better UIs Faster

#161
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've been a Laravel guy mostly, but tried Flask for a project last year, and it was so incredibly easy to get up and running. Still not really sure how the two compare, but there was just something about the extremely tried and battletested code. Nothing got in my way, the code told you what it did, it was fast etc.

Flask is the hard one to get up and running alternative, where you must look at every detail, that lets you create an application exactly as weird as you need.

The fact that you found it so simple coming from another framework speaks loudly about your previous one. But they do compare in that Django is the easy one to start where most choices are already done for you.

Re: FastUI: Build Better UIs Faster

#162

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.

I'm just here to fullfill the prediction by someone, I don't remember who, that every time Netlify is mentioned in the future [this thread](https://news.ycombinator.com/item?id=39520776) is mentioned.

Maybe someone will even recommend Cloudflare Pages or a $5 VPS.

Re: FastUI: Build Better UIs Faster

#163

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.

Unfortunately Flutter (which seems to be the backend for Flet), is IIRC rendered in a HTML5 canvas, which yields bad accessibility and is overall a pretty bad way to build web apps.

It's kind of unbalanced, as web tech, on the other hand, is pretty good at building desktop apps.

Re: FastUI: Build Better UIs Faster

#164

Earlier quoted context omitted.

I love TypeScript, and I think React is mostly very elegant, and I still find front end work to be a real chore. Fucking around with forms and CSS and responsive breakpoints is not my idea of a good time!

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?

Re: FastUI: Build Better UIs Faster

#165
post #66

Earlier quoted context omitted.

The XML+XSLT equivalent here would be an XSLT stylesheet with a bunch of predefined rich parametrized templates that you can just . Hand-coding XSLT to produce HTML (or whatever) is still rather tedious.

Did this extensively in the mid-naughties. Huge site, lots of data and traffic. Performance exceeded what was available at the time, scaled super well, but not something I’d ever go back to. - xslt is not a programming language. As soon as you start using xslt:functions you’re doomed. - it is not a fit for interactive UIs. It’s good for static content, trying to mix in js goes wrong very quickly. My opinion is that t…

Similar story for me. Conceptually I still like the idea, but not with XSL. JS operating on JSON as you say can do the same, but without all the needless pain. Though I'd still love a more declarative option - but I'll sacrifice that before I use XSL again.

Re: FastUI: Build Better UIs Faster

#166
post #89

Earlier quoted context omitted.

Try to write a generic data and time formatting template in xslt to let you do basic arithmetic on timestamps of the type you might want in a view. When you've stopped screaming in horror at what you've suffered, we can discuss whether you still think that's a good idea. The overall concept is good, but sadly xslt is constrained enough to be massively painful for this kind of thing.

I tried it for a couple days years ago. I concluded it was not a good idea then I'm a full stack guy myself, so I'll stick with React.

So a pretty bad faith suggestion then - the way the linked site does things is nothing remotely resembling your "suggestion" to use XSL.

Re: FastUI: Build Better UIs Faster

#167

Call me old fashjioned but what is wrong with django and htmx? Works beautifully and fast, send only rendered code to the front. Have db admin for when you scale

> old fashjioned > htmx Htmx went 1.0 a little over three years ago. Is it really something you can call old fashioned?

It’s a figure of speech. Not literal.

Re: FastUI: Build Better UIs Faster

#168
post #132

Earlier quoted context omitted.

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.

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 for almost all usecases besides internal admin tools that are only meant to be used on desktop.

Re: FastUI: Build Better UIs Faster

#169

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…

Most of the cost of a software project is from ongoing maintenance. When we make it easy to write the first version and make maintenance harder, the total cost of the project goes up.

Projects like FastUI allow maintenance of a project with fewer skills, directly reducing the cost of maintenance: owning teams spend less time learning and maintaining their skills and there are fewer bugs due to engineers making mistakes because of low skill-level in a technology.

Also, projects like FastUI make the project's tech stack much simpler. Simplicity helps reliability, incident resolution, security, testing, adding features, removing dead code, refactoring, etc. Highly-productive teams apply these ideas and keep their systems as simple as possible. As tools like FastUI mature, they will become standard in healthy engineering orgs.

Post reply on HN