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

71–80 of 230 posts

Re: FastUI: Build Better UIs Faster

#71

Post by badsectoracula »

int_19h wrote: post #65
nurettin wrote: post #53

Earlier quoted context omitted.

And Qt is leaps and bounds behind Delphi and Lazarus. It is even behind rails g scaffold when it comes to RAD.

The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since. Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked? That was a lovely time to work on any kind of line-of-business app.

> Remember how you could just "add" a database [...] and things just magically worked?

You can do these in both Delphi and Lazarus, except with a much better GUI framework (comparing GUI only here, not everything you'd get with .NET). If anything having worked with Windows Forms for a while i think it was abandoned before it reached even what you could do in the midlate 90s in Delphi.

Re: FastUI: Build Better UIs Faster

#72

Post by LtWorf »

int_19h wrote: post #65
nurettin wrote: post #53

Earlier quoted context omitted.

And Qt is leaps and bounds behind Delphi and Lazarus. It is even behind rails g scaffold when it comes to RAD.

The ultimate RAD was Windows Forms, in my opinion. It's been downhill ever since. Remember how you could just "add" a database connection to your project, plop a data source on a form, then a datagrid or a bunch of text/check/comboboxes and the standard control, wire it all up in a couple clicks, and things just magically worked? That was a lovely time to work on any kind of line-of-business app.

> The ultimate RAD was Windows Forms

Layouts >> fixed size window

Re: FastUI: Build Better UIs Faster

#73

Post by LtWorf »

enoch2090 wrote: post #44
calvinmorrison wrote: post #33

Earlier quoted context omitted.

Its a shame that RAD on the web is so far behind stuff like Qt

Actually, does Qt have something like FastUI? Been looking for one.

You can compile Qt to target the browser instead of native apps. But besides seeing a demo I don't know how good it is with performances, accessibility and so on.

Re: FastUI: Build Better UIs Faster

#74

Post by regularfry »

bornfreddy wrote: post #57
jawns wrote: post #25

> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…

This. In my experience frontend is not for everybody. There is a reason why FE and BE are often separated - because it makes sense in most non-trivial apps. Related, I never understood the appeal of isomorphic apps either. It's not like the code for UI and data access is very similar.

It looks to me like FastUI is literally the BFF pattern with a pre-supplied front-end. If that's true, then complaints about it should be viewed through the lens of who has control over the application, who is gaining control, and who is losing it.

I've had quite vocal arguments from front-end devs which, when we stripped back what they were actually complaining about, came down to the front end being in service of the back end, rather than vice versa as they were used to.

Re: FastUI: Build Better UIs Faster

#75

Post by enoch2090 »

LtWorf wrote: post #73
enoch2090 wrote: post #44

Earlier quoted context omitted.

Actually, does Qt have something like FastUI? Been looking for one.

You can compile Qt to target the browser instead of native apps. But besides seeing a demo I don't know how good it is with performances, accessibility and so on.

I think Qt does have WASM compilation options, but I mean generating interfaces given models like Pydantic/Dataclasses/etc.

Re: FastUI: Build Better UIs Faster

#76

Post by elbear »

8n4vidtmkvmk wrote: post #52
petesergeant wrote: post #26

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.

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

Re: FastUI: Build Better UIs Faster

#77

Post by anonzzzies »

jawns wrote: post #25

> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…

> to build something complex on the frontend

But, unlike frontend devs, designers and product managers believe these complex things are needed, they almost never are and actually bring a lot of issues with them instead. I rarely see a complex component/combination (in a SaaS, let alone on some landing/public page) and think, "well, that adds real value over just a standard component". If you can point some out, please do; there are very obvious cases where something else than standard is needed, but that also depends on your definition of standard; if I can buy complex off the shelve somewhere, you are not building something complex in the frontend and so you can use simple means to hook them up without the complexity.

Re: FastUI: Build Better UIs Faster

#79

Post by spinningslate »

jcheng wrote: post #70
jairuhme wrote: post #30

Earlier quoted context omitted.

The first point you made is what myself and my team have struggled with. We have built simple apps for customers to upload a document to interact with and having the state be accurate to the document that the user uploaded was a major pain. Felt easier at that point to build something from scratch than to keep messing around with streamlit's session states

Would you consider giving Shiny (for Python) a try? https://shiny.posit.co/py/ It's (I hope) pretty close to Streamlit in ease of use for getting started, but reactive programming runs all the way through it. The kind of app you're talking about are extremely natural to write in Shiny, you don't have to keep track of state yourself at all. If you decide to give it a try and have trouble, please email me (email in pro…

Haven't used Shiny on Python yet, but we use the R version a lot. It's been a good experience: solid, reliable framework, good set of widgets, decent styling out the box.

The Python version is a port from its R stablemate (well, maybe more than a port: a re-engineering). If it's as solid as its R parent then it'll be a very useful addition to the Python UI landscape.

Re: FastUI: Build Better UIs Faster

#80

Post by AlchemistCamp »

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 started after Swift was the default.

Post reply on HN