So, HTTP servers serve up strings, parsing of the many layers of which the kernel is a webpage.
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.
Although I agree with many of your points, the reality is that a whole class of desktop apps - call them 'business productivity' apps - has been replaced (for better or worse) by the SaaS model of web apps (Software as a Service).
I used to believe that some types of desktop software (e.g. graphics, video editing, animation, 3D etc) could never work as web apps unless extremely limited in scope. But I was wrong.
Compare the Figma UI with Sketch. Both apps share core UI design tools.
Figma is delivered to a browser as a binary blob using Web Assembly.
Sketch is a Mac-only native desktop app with all the speed and functionality advantage of a native app. Despite that, it is 'cloud-based' Figma which is now a serious rival to Sketch. The Sketch team even wrote a blog post extolling the virtues of native apps - no doubt with a nod to their cloud rival. [1]
Sketch is also hampered by the fact that sharing designs or collaborating with others is harder than Figma. Sketch was designed in an era of single-user desktop app use, not the multi-user (cross-platform) scenario common today. This is a problem for some desktop apps.
SaaS is a juggernaut that shows no sign of slowing down and is eating the desktop model. Whether that is a good thing or not is a question for another debate.
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.