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

141–150 of 230 posts

Re: FastUI: Build Better UIs Faster

#141

Post by boxed »

sirsinsalot wrote: post #104

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.

Re: FastUI: Build Better UIs Faster

#142

Post by QuadmasterXLII »

slmjkdbtl wrote: post #61

What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?

I recieved a "secure patient portal message" in email from my doctor. Navigating to the actual message took 5 clicks, and each click involved waiting 3 to 12 seconds for pages to load, while all sorts of react-y things happened like hydration, spinning loading icons, placeholders. This is on gigabit internet with 50 ms ping. Shipping javascript to provide snappy UI has utterly failed, please let us go back to 1 round trip to the server for each client interaction.

Re: FastUI: Build Better UIs Faster

#143

Post by account-5 »

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.

Re: FastUI: Build Better UIs Faster

#144

Post by 8n4vidtmkvmk »

elbear wrote: post #76
8n4vidtmkvmk wrote: post #52

Earlier quoted context omitted.

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.

Can you detail your troubles with syncing frontend and backend validation?

Well, for my latest iteration, I'm using Bun+Elysia on the server which uses Typebox for request validation+schema, which is effectively JSON Schema so you could do something similar in other languages. I can pass that schema down to the client/browser, and I could use AJV to run that schema against the request before I send it to the server, but there's a couple tricky parts.

1.Json schema/AJV return not very human friendly results and they're hard to associate with a specific field to display the error nicely 2. If you want to validation as the user is typing to clear errors as they're satisfied, you have to run the entire schema, not just for that one field 3. Any async validations like checking if a username is unique is harder if not impossible with this approach

Re: FastUI: Build Better UIs Faster

#145

Post by 8n4vidtmkvmk »

vidarh wrote: post #89
8n4vidtmkvmk wrote: post #51

Earlier quoted context omitted.

Skip the python and use xml+xslt directly in the browser if you like it

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.

Re: FastUI: Build Better UIs Faster

#146

Post by eropple »

int_19h wrote: post #67
eropple wrote: post #35

Earlier quoted context omitted.

Honestly, if I'm going to nitpick myself , even that isn't a true statement. You might have an integer/float divide for your registers, like amd64 does, but even past that it's squishy and becomes human bookkeeping or compiler magic. Is %rax an 8-byte integer, or is it a pointer? Or is it garbage because you used %eax (the lower 4 bytes of %rax) for storing a 4-byte integer, and the top half is whatever(tm)? Ditto ag…

The problem with Python specifically is that the type system is such a massive bolted-on hack. It has to be, because it's such a dynamic language that all declarations and imports are executable statements - and it's hard to reconcile it with type declarations, which often need to be mutually recursive. TypeScript is much better in that regard, though.

It is kind of hacky for sure, but I've gotten way more productive with it than I've ever been with Python before. Like I went my entire career (and time before that) where the words that came out of my mouth after "Python" were "is bullshit", but this year due to both AI jank and other unrelated tools having no path but Python, I've made my peace with it--and yeah it's spotty, though with Pylance I think it's fine, and it saves me from so many category errors that make old-Python infuriating.

Unfortunately for me, as an unreconstructed Ruby dork, Sorbet does not scratch the same itch. :(

Re: FastUI: Build Better UIs Faster

#147

Post by eropple »

com2kid wrote: post #27
behnamoh wrote: post #21

Earlier quoted context omitted.

[flagged]

It is all an illusion. Unicode, ASCII, base 10 numbers, are all lies. Our CPUs know binary registers of certain sizes, ints and floats, and nothing else. Everything else is a lie that we make work by throwing a lot electricity at a lot of fancy sand and out the other end comes something that looks reasonable. That said, TS has a really nice type system that is absurdly flexible and at times quite fun to use.

I say the phrase "TypeScript crimes" a lot, and it is almost always a positive.

Most programmers I work with and have worked with are not wielding the type system in the same way, and that's usually okay--because I tend to be the one building the libraries they then use, and the compiler keeps folks from doing things with my code that I didn't plan for.

Re: FastUI: Build Better UIs Faster

#148

Post by astrea »

peddling-brink wrote: post #138
pjerem wrote: post #122

Earlier quoted context omitted.

In Jinja, Razor, or Blade, you write, HTML that you enrich. With FastUI, you write Python.

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.

Re: FastUI: Build Better UIs Faster

#149

Post by rolisz »

MyFirstSass wrote: post #140
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'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.

Recently tried Flask for a project started by someone else, made me want to run to FastAPI right away.

Re: FastUI: Build Better UIs Faster

#150

Post by wruza »

AlchemistCamp wrote: post #80
promiseofbeans wrote: post #78

This seems to mainly be useful for spinning up quick and dirty internal tools. But for that use-case, isn't it easier to use something visual and established like Retool ( https://retool.com/ ) or that generates nice react code, like MUI Toolpad ( https://mui.com/toolpad/ )?

React code is basically the opposite of nice. Bad language and horrible ecosystem :D Seriously, I first tried it in 2013, used it for work from 2014-2016 and here and there for odd projects later, and the amount of churn and complexity of the ecosystem has been surprising every time I check back on it. My Obj-C from even longer ago pretty much all runs fine and is fairly understandable even for most iOS devs who star…

Chiming in to not let you feel alone in this. React feels like you're doing low-level assembly in an esoteric functional language that ought to be simulated in javascript, but due to limitations of the latter you have to simulate it by hand, by following the manual. Looks absolutely delusional to everyone who catched peak ui phases like Cocoa and UIKit. I remember writing custom components in Obj-C and never thinking about all the nonexistent issues which React claims to be a perfect solution for every few years.
Post reply on HN