As a purely native desktop application developer, whenever I read about these frameworks, they seem to contain almost no trace of any of the programming models/designs/lessons that were learned between (say) 1980 and 2005 in the domain of native GUI toolkits (both platform-specific and cross-platform). There's almost no trace of any of the vocabulary, but also very little sign of any of the fundamental concepts (widgets, "classic" MVC, etc.)
So I'm asking without (much) predjudice: what's so different about UI/UX in web-dev that justifies throwing away all these design lessons? Or are they really still in modern web frameworks and I'm just not seeing them?
but popular web frameworks have their own more webful lexicon/definitions.
imo few native frameworks really use the old lexicon heavily either. even in legendarily ancient realms like objective-c, there's persistient ideas, but the classic ui construction paradigms dont rule, arent the guiding star; there are still different & newer patterns & systems & words for using the available standard libraries.
The whole thing was just supposed to be a glorified network file browser with optional index pages to explain or introduce the resources there.
The main issue seems to be folks trying to avoid the page reloading. HTTP is stateless itself, so your form submission will need to engage server code blocks that then spit back an appropriate response, “hey that username exists already” amd HTTP could care less about the content of the response, let alone it’s meaning, it’s just a string. It’s no problem if the code that responds to the form submission can render a templated response as a string and the browser gets a page and parses and displays it.
There is a no standardized means of maintaining a stateful webpage across page reloads, or even at all. It’s execution context is a remote client that is making HTTP requests and you have to wait for one and the only ways of even knowing the identity of the requester across requests, stateless protocol on purpose designed for scalability, are hacks of some kind, assuming IP addresses remain constant, or embedding à browser cookie that the browser then attaches to a future requests etc.
Remember, the payload is a string, it has to get parsed into html elements that you could call the intended widgets of the web world. The web widget creation committee (paraphrasing) effectively never got off the ground so we never got more browser native elements.
So, then you basically have everything being implemented ad hoc with Javascript and CSS, since then. React and its ilk are just ways of using JavaScript to create and append and remove elements to the tree, the DOM, dynamically without a page load. The whole thing works fine out of the box if you let the server update the state of a browsers view as was intended, but then you get a page reload, which is less than groovy if you are adjusting a virtual dial, for example.
The web being cross platform only 24-7-365, it’s been particularly vulnerable to the politics of the tech industries in a way that low level code is not. If WPF is missing a crucial widget, you can code one and build it into your product.
This is a good juncture point to bring up the incredible waste of electricity and computing power trying to create what behave like GUI applications on top of these massive virtual machines that only a handful of money pits can afford to try to build and maintain.
I would say that trust is the primary obstacle to making a truly efficient binary remote blob deployment and activation infrastructure to replace the web, even if it still just piggybacks on port 80.
IMO, the essence of the endless complication in the field of web development lies in the difference between what the web was architected to be and what we want to use it for.
I do not think it’s wise to build a universal app platform on strings. Castle made of sand.