And by headless I mean something which builds on what the web provides like buttons but adds a whole lot more of components which are used but are unstyled.
Second, the graphical niceties of these platforms often run "in-process", and save what is basically code in the same database as content. This will anger most Smalltalk fans, but I think this style of development is a bad idea. I want to know that some folder full of source code is the program, and some other folder is the data, and that if I back up one or the other, it will be independently usable.
I'm not saying 90s IDEs were perfect, but I don't think there's been any successful successor to their style of development. Graphical GUI builders exist, but they usually don't support making web apps, and after working with modern JS GUI frameworks, manually syncing GUI state with app state seems antiquated and needlessly bug-prone. I suppose QML with Qt Creator comes closest.
You probably don’t want to know how Electron works then!
That would be completely ordinary with Smalltalk.
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
1984 Smalltalk-80 The Interactive Programming Environment page 46
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
I wrote one in PHP and 3 devs were able to build and maintain a 800 page CRUD system with it (still going strong, makes a ton of money). It has complex business logic, is fully unit testable and allows for escape hatches when needed.
I'm in the process of rebuilding the DSL in C# with the lessons learned (because Entity Framework is awesome). And might open source.
About the framework, I just read in a comment below about Java's Vaadin framework and it looks very similar to what I made in PHP. It's code that generate UI.
See https://vaadin.com/docs/latest/components/crud
Please check my profile in a month. I'll publish contact info.
Solving this “problem” just doesn’t seem like a good use of a time. There are now 4738484 different viable ways to build a website, adding another way is just a waste of everyone’s time
The problem is the amount of boilerplate and tool complexity involved. In a large project, the boilerplate can become a small fraction of total work put in (hopefully), with most to the work spent expressing the logic of the application.
In smaller projects, the boilerplate can be the vast majority of the work. Building a backend, a frontend, and a communication protocol between them (that includes reactivity). On the backend you need to learn HTTP/Websockets and a backend framework. On the frontend you need node, nvm, npm, yarn, React/Svelte/Vue. To do it right you need to implement automatic reconnect/resubscribe on reconnect, etc.
Several projects try to reduce this complexity in various ways, but they all have trade-offs and I don't think we've found a sweet spot. Drag and drop tools like Squarespace and Retool are heavily biased toward expressing UI and integrate clunkily with backend logic. Backend-based tools like Streamlit and Pynecone (Reflex) get closer to a sweet spot IMO but are either severely limited in what you can do (Streamlit) or ultimately expose you to the full complexity of the frontend (Pynecone).
I think further work in this space is warranted.
I have a good example of a small-scale problem that's a b** to solve with web technology.
In a nutshell, I have an application which sends batches of data to a remote client. On the far end, I want a little web app that pays attention to the incoming queue of batches, display that list of batches in a browser, each batch with a progress bar, and be able to click on a batch to start the next stage of processing it when the batch is ready.
making real-timeish display updates should be a canned function but there is a lot of frontend/backend stuff going on to make it work.
> I think further work in this space is warranted.
what he said.
These two solutions can address all of these examples I can think of for a "simple" site:
- static blog site
- interaction with a database
- interaction with external APIs
- simple games (Django is based in Python)
- more complicated interactivity (pick a language that's compatible with Wasm)