91–100 of 230 posts
Earlier quoted context omitted.
Its a shame that RAD on the web is so far behind stuff like Qt
Web development used to have a RAD experience in the ages of PHP 4/ASP Classic and Dreamweaver. For better or worse, we lost this capability in the path for code purity, RESTful services and SPAs.
Earlier quoted context omitted.
Skip the python and use xml+xslt directly in the browser if you like it
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.
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 these days infra is cheap enough that you get all the same benefits by doing standard templating in your language of choice from your data in json or whatever. Which I know is essentially the same thing without the specialist software and dsl. And that’s kind of the point.
Fastui seems prettty barebones mostly a form adapter to pydantic models that I can see.
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?
To those dissing it for production use case over a hand build frontend by a frontend dev: yeah, no shit. But not everything needs such work put in. This is perfect for internal tools, and there's plenty of indie hackers out there proving that you don't need an immaculate UI to get customers anyway. Use it for what it is good for.
We need more tools like this, because it cuts the development effort in half when it hits its stride. That's very valuable for internal tools especially, where you need something functional first and pretty second.
That being said, as a biased Laravel developer, I can highly recommend Filament both as an admin panel builder and declarative UI component kit like FastUI. It's Livewire based instead of React/Vue/etc and so firmly within the Laravel ecosystem, if that bothers you. https://filamentphp.com/
> 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…
Especially for business oriented apps, most of the models only need a list view with a table, and a detail view displaying some properties and related lists of models.
It works wonderfully.
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…
Tainting what used to be a lean frontend library with server side concepts [1] was a net negative in my opinion.
Earlier quoted context omitted.
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?
Then it'd just apply that recursively. For a simple model there'd only be two levels: The view, containing a bunch of columns, and the columns themselves, and the view type knew to iterate over the columns in the view and look up their type and tell them to render themselves. For more complex views frontend devs might e.g. provide a custom view type that'd group columns based on certain attributes, but still delegate to the generic mechanism to render those columns.
So replacing a part just meant writing a component that knew how to render itself from its props, just like any other component. Just that some of those props would be coming from the backend.
We'd generally try to avoid replacing components if the only reason for a component was to override how something was rendered, and to focus on why it should be rendered differently and consider if we could reflect that 'why' in the data, or other ways.
E.g. were certain fields grouped together because they were semantically related? Then reflect that with an attribute in the "meta schema" for those columns, and make the frontend component render related groups according to the type of that group (let's say a bunch of fields reflects a user address). Incidentally this tended to be very simple, as with a relational model when there were groups like that the right thing was often for them to be a separate table/model anyway, and we 'just' needed to distinguish between type handlers for rendering an object 'as the page' vs. 'as a reference' vs. 'as a group within the page', and that was easy enough to distinguish "well enough".
At a top level, we'd look for a registered view-level component (or fall back on the default), within a view if the backend returned the model instance "in-line" we rendered it as a group, and if it returned an id, we'd render it as a reference.
So a "User" object for example would render as a profile view if it was not your user and you went to a page where the associated API call returned the User as the top level model, you personalised profile page w/optional edit view if it was your user, or a "pill" linking to the user profile if it was just a reference.
The idea was that frontend components should focus on how to render specific types of data in a specific context, rather than specifying how specifically to render the page, because it'd make no sense to have the frontend e.g. try to render a field that no longer exists, or try to render a field as a different type it is when the meta data about which fields were available and what type they are was already available.
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.