For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in
Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.
If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.
Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.
I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.
React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.
Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP
https://en.wikipedia.org/wiki/Wireless_Application_Protocol
which had a way to send multipart forms to the client. Something like that designed to work with a software factory
https://www.amazon.com/Software-Factories-Assembling-Applica...
(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)
or a "no-code" app builder could be great.
I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
Rules are applied to a Model to make more rules, rules are again transformed by rules in stages to compile to targets. Declarative schemes arbitrate between rules, select execution modes such as forward or backwards chaining, hybrid execution, memorization, etc.
Much like the vision in
https://www.amazon.com/Software-Factories-Assembling-Applica...
but more aimed at "getting non-professional programmers to be able to do more easily" and less aimed at "helping a team create software product lines".
Roughly this is the direction that OMG is going in.
This book is an attack on the problem from one angle
https://www.amazon.com/Software-Factories-Assembling-Applica...
Note the authors of that book were lead architect's for Microsoft's Team Studio System. It may have been the system that they wanted to build, but we wound up with something that isn't quite as good.
Salesforce.com is a great case study, they executed with great discipline, fot a huge amount of funding in the first year
https://www.crunchbase.com/organization/salesforce/company_f...
and they’re famous for resisting customer demands to change the way they do things. Instead they developed a model for customers to run their own code inside their platform, access it through an API, etc.
There’s another idea which fascinates me that I’ve rarely seen executed well which is to develop something that is a hybrid of custom and prepackaged software. I worked at a place that had developed in the early 2000’s a packaged web site for wineries to sell wine online and when I went driving around the finger lakes (where I live) I would always see the signs of wineries who were our customers. Despite having a few things like that the company struggled financially and collapse under the weight of technical debt. (For one thing they depended on a proprietary language called Tango which let you build web sites with an interface like Scratch. I told them they ought to hire a CS intern to help write their own Tango implementation but they weren’t ready to do so.)
The authors of this book
https://www.amazon.com/Software-Factories-Assembling-Applica...
wanted to make this happen. They were in charge of the enterprise version of Visual Studio and unfortunately it turned out nowhere near as cool as what they speculate about in that book.