> Why Isn't the Construction of CRUD Web UI's 90% Automated?
My guess is because web coders have very, very short memory and couldn't be
bothered with learning whatever programmers were doing in '90s and '00, both
on server side and on desktop side.
> There have of course been hundreds of UI builders. Why aren't they used?
There was this Borland Delphi thing, and these different GUI toolkits like
Motif, Tk, Qt, GTK+, wxWidgets, or Java Swing, but then desktop software
became mostly irrelevant, replaced with web. Somehow very few people cared to
port good ideas from desktops.
> Behavior should be mostly auto generated config from a standardized format such as json schema or a db schema.
There you go with learning history. There were attempts on desktops at doing
such things, but they died off. They weren't that good of idea.
Although I never got deeply into the field, I think the UI builders also had the problem that web frameworks do: which is though they make it easy to do the easy stuff, they eventually make everything harder.
That isn't supposed matter because most real-world customers only have simple needs, so you want to bang out the apps quickly. But in practice I have never seen a use case that was really as simple as it was supposed to be -- they all end up in the "too hard for the framework" bucket.
I programmed in a DOS tool called 'Magic'. It basically was a screen designer which could work on tables. All code was held in the database, all screens were datadriven (declarative). It ran on the Novell Btrieve database. It was from an Israelian company.
It worked perfectly. Even my brother, who wasn't a programmer at all, was able to write his business software with it. It was reasonably fast. Downsides: theming wasn't possible so all applications looked the same, and Btrieve wasn't as reliable as it needed to be.
But otherwise it was great. I never understood why such a program doesn't exist these days. Tempted to write one myself....
I've been down this path before. There is R:Base (incredibly hard to Google http://www.rbase.com), which is basically the same. Another one is Wavemaker, for the web.
The difference is that if you're a small shop, the licensing costs will kill you (although Magic was a $2000 product, which is around $3,700 adjusted for inflation. R:Base and Magic cost around the same.
I've love to see more character cell intefaces. Not everyone wants to run a web/GUI stack for a simple CRUD form. TUIs are often fast, and low requirements. I've considered the same myself, as no modern languages include a real TUI library (no, curses support != a TUI).
I think that's what the web community misses. We have 50 years of Moore's Law to benefit from, yet we are making slower applications than ever. The larger these codebases, the more complex they are to maintain, secure, and debug. They need larger hardware to provide the same relative performance.
I want to see more lean, tiny, fast applications. Low TOC, low investment because they aren't complex. Low end hardware that can be made reliable, small, and maintainable.
I think it's hideous that most business applications I see (CRUD interfaces) are 90+% text, and yet they are built on layer and layers of GUI and web interfaces.
Your Raspberry Pi example would be lean and easy to maintain. No virus scanners, no 20GB OS footprint to maintain. No worries about your user visiting Facebook all day instead of working with your business application.
I want applications that are so incredibly dull that they will be taken for granted as much as office telephone.
My guess is because web coders have very, very short memory and couldn't be bothered with learning whatever programmers were doing in '90s and '00, both on server side and on desktop side.
> There have of course been hundreds of UI builders. Why aren't they used?
There was this Borland Delphi thing, and these different GUI toolkits like Motif, Tk, Qt, GTK+, wxWidgets, or Java Swing, but then desktop software became mostly irrelevant, replaced with web. Somehow very few people cared to port good ideas from desktops.
> Behavior should be mostly auto generated config from a standardized format such as json schema or a db schema.
There you go with learning history. There were attempts on desktops at doing such things, but they died off. They weren't that good of idea.