I have a server-side rendering approach that can get instantaneous paint of arbitrarily-complex views after pulling down index.html and exchanging a single pair of websocket messages. Once the initial page is loaded, redraws are as fast as you can get packets between the machines plus 2-3ms for decoding. It involves some very unorthodox methodologies and has latency constraints (similar to Google Stadia hosting model), but there are serious upsides. Including completely untouchable load & response times.
I strongly believe we are stuck in a Malthusian Trap regarding the use of HTML/iOS/UWP/Android for clients and then an entirely separate stack of things for the server - Go/.NET/Rust/Python/C++/etc. This separation adds such a huge burden to the development and maintenance of any application. I argue that if we must have some division between client & server, lets move as much of the complexity to the server as we possibly can. It's so much more manageable when you have all of your state in 1 domain like that. If the client doesn't have to track state or reason about its views, the application implementation for each device can be trivial.
I don't think that HTML/JS/CSS/JSON APIs represent a good boundary layer. I think final rasterized views, viewport dimensions and client events do. JPEG/MPEG can be decoded incredibly quickly on most mobile client devices due to availability of hardware acceleration. You will never be able to write a website in the traditional sense that can outperform the speed at which you could decode a full-screen JPEG image and display it. Server hardware is also getting insanely powerful with the new generations of AMD CPUs rolling out. Encoding JPEGs using something like LibJpegTurbo on TR/Epyc is ridiculously fast. This is also a type of application that does trivially parallelize across many cores. As bandwidth becomes ever more ubiquitous, and services more geographically-distributed, there is a good chance something like this could become practical in the general case.
For now, this is all just a crazy experimental thing that only works for a narrow range of applications. But, I would strongly encourage other developers to start thinking outside of the box. As networks get faster and latency gets lower, we will begin to encounter new "step function" opportunities that fundamentally shift how we do business.
I strongly believe we are stuck in a Malthusian Trap regarding the use of HTML/iOS/UWP/Android for clients and then an entirely separate stack of things for the server - Go/.NET/Rust/Python/C++/etc. This separation adds such a huge burden to the development and maintenance of any application. I argue that if we must have some division between client & server, lets move as much of the complexity to the server as we possibly can. It's so much more manageable when you have all of your state in 1 domain like that. If the client doesn't have to track state or reason about its views, the application implementation for each device can be trivial.
I don't think that HTML/JS/CSS/JSON APIs represent a good boundary layer. I think final rasterized views, viewport dimensions and client events do. JPEG/MPEG can be decoded incredibly quickly on most mobile client devices due to availability of hardware acceleration. You will never be able to write a website in the traditional sense that can outperform the speed at which you could decode a full-screen JPEG image and display it. Server hardware is also getting insanely powerful with the new generations of AMD CPUs rolling out. Encoding JPEGs using something like LibJpegTurbo on TR/Epyc is ridiculously fast. This is also a type of application that does trivially parallelize across many cores. As bandwidth becomes ever more ubiquitous, and services more geographically-distributed, there is a good chance something like this could become practical in the general case.
For now, this is all just a crazy experimental thing that only works for a narrow range of applications. But, I would strongly encourage other developers to start thinking outside of the box. As networks get faster and latency gets lower, we will begin to encounter new "step function" opportunities that fundamentally shift how we do business.