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

81–90 of 230 posts

Re: FastUI: Build Better UIs Faster

#81

Post by nurettin »

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.

Data source on the form idea originated from Borland Delphi. Later, Anders Hejlsberg quit Borland to work at Microsoft, where he implemented the idea of visual and non-visual components and property editors in .net

You would be even more impressed with Delphi, because after connecting your data source, your form fills with data at design-time. Lazarus and Typhon does the same.

Re: FastUI: Build Better UIs Faster

#83

Post by lozenge »

whazor wrote: post #63
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…

You would be surprised how far a company can get with a Django admin for customer service or sales teams.

Django admin is really extensible. I'm not seeing here how to offer multiple forms against the same model. Eg if a user can edit some of their profile but not the subscription plan field, while a sales team can.

https://github.com/pydantic/FastUI/blob/main/demo/forms.py#L...

Re: FastUI: Build Better UIs Faster

#84

Post by lozenge »

ipaddr wrote: post #49
xtagon wrote: post #39

Earlier quoted context omitted.

Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.

The kind of site that gets all of their data stolen. It can be a cool pattern.

In Django I had code in every view ensuring that the user was not accessing another user's data. If I create an abstraction like a utility function or "model manager" to handle this, I have to remember to call it from every view. In Graphene, this logic would be in a resolver which is used across multiple views.

Re: FastUI: Build Better UIs Faster

#85

Post by vidarh »

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…

My approach to what they are doing in my last job was to augment our models with more fine-grained information than what the database schema held, as well as with metadata about which views made sense or were needed, and then output schema information in our API. The raw base case was generated directly from the live database schema, so even without a line of code you had something once you'd enabled it (default off for anyone but people with devops level admin rights because giving a default on view of a raw table is a recipe for leaking data), and most of what the models provided were just more structured forms of what the models already needed, such as validations.

Then we built a set of generic frontend components for that in React once.

And we then had an instant UI for 50+ models, but the frontend devs could trivially selectively override both the whole page for models where the default was too simplistic, or how to render specific types of fields or for specific fields of specific models.

The "instant UI" was flexible enough that for most "backend" views we never customised it on the frontend. But being able to have the frontend devs customise the user visible things was essential, and thanks to having the ability to replace things bit by bit they could focus on the things that didn't look or work right, instead of "everything". And a lot of their work then made it back into augmenting the backend with info to let the generic frontend apply those improved views elsewhere as well.

I have only had a cursory look at FastUI. If they do something similar to that, then great. If they actually try to have the backend generate all or most of the UI and serve that up instead of serving up metadata, then I fully agree with your issues.

Re: FastUI: Build Better UIs Faster

#87

Post by vidarh »

xtagon wrote: post #39
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…

Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.

We didn't use GraphQL, but in my last company that was essentially what we did - every API call returned schema information about the parts of the model the current user had access to, with detailed type information and which validations to apply, and metadata that affected presentation, and the frontend built a UI from that.

We then let designers/frontend devs override that on a case by case basis instead of building from scratch, and where possible tried to roll that into the generic UI as components triggered by specific metadata from the backend. It was not entirely agnostic, but it was largely driven by metadata from the backend, so e.g. schema changes rarely needed much, if any, UI work unless they fundamentally changed how the page worked.

Re: FastUI: Build Better UIs Faster

#88

Post by vidarh »

ipaddr wrote: post #49
xtagon wrote: post #39

Earlier quoted context omitted.

Interestingly, you could accomplish a similar thing with GraphQL if the frontend uses the type introspection GraphQL provides and the backend graphql schema implements HATEOAS-like principles to let the frontend become a UI that's agnostic to different backends. That might not be how most GraphQL implementations are used, but it's kind of a cool pattern.

The kind of site that gets all of their data stolen. It can be a cool pattern.

If serving up metadata about what the site already makes accessible via the API will get their data stolen, then the actual problem is they're not applying access controls to the data, not the introspection.

Re: FastUI: Build Better UIs Faster

#89

Post by vidarh »

8n4vidtmkvmk wrote: post #51
kumarvvr wrote: post #36

Is this a good way to build UI? The syntax looks very awkward. IMV, XML is the best format for any Declarative UI. Tools to generate that XML (or HTML) are better value than these systems. I would love to see an XML based UI generator in Python.

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.

Re: FastUI: Build Better UIs Faster

#90

Post by lifeisstillgood »

vidarh wrote: post #85
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…

My approach to what they are doing in my last job was to augment our models with more fine-grained information than what the database schema held, as well as with metadata about which views made sense or were needed, and then output schema information in our API. The raw base case was generated directly from the live database schema, so even without a line of code you had something once you'd enabled it (default off…

So, how did the “override” work? What made it easier to replace a part not whole page without understanding how the framework worked?

Agree completely that is the only sane goal - just wondering how you got there?

Post reply on HN