I've been toying with building a GUI-as-a-DB kind of engine where consumers run a server process that listens for commands that tell it to create/update a window & its elements. You would interact with a DOM-like structure that maps to the various native UIs. (there is also a "guidb-lite" for including with your binary)
The general idea is; you issue nosql-like commands to this service to interact with the non-web DOM you create. e.g.
// POST localhost:3344
{
action: 'create-window',
settings: { title: "Hello World" },
content: [{ tag: "Text", value: "Hello World" }]
}
// returns 200 { id: "xxx", "auth": "xxx" }
// POST localhost:3344
{
action: 'update-window',
id: "xxx", auth: "xxx",
exec: { content: {
$findOneAndUpdate: { query: { tag: "Text" }, set: { value: "updated"}}}
}
}
(I tried SQL but dealing with children nodes doesn't work out well)This means your application can be written in whatever language you want. "Frameworks" (like React) would be written on top of this as language-specific implementations - allowing the GUI-DB to focus on only mapping the API to the various native GUI UIs.
I can imagine there would be limitations I am naive to and I'm generally not smart enough to see this through, but it is the change I would like to see in the world.