- about HTTP compression (gzip, brotli) - it works on byte/text level and doesn't know about your markup template repetition (where structure is mostly the same but small changes everywhere) so it will be not as efficient as manual template-data separation
- about SPA - in my comment I said no word about SPA, it's a more complex layer on top. I only arguing about template-data separation approach to decrease data duplication and traffic consumption. And no, you don't need to rewrite your app as SPA and no react/preact/javascript frameworks required. You can use your server-side rendering and just change format of what you are sending to user. Instead of sending index.html with repetitive html markup for every list item you can basically send script-tag where you loop over data and build html-markup directly on a client
HTTP compression (gzip, brotli) works on byte/text level and doesn't know about your markup template repetition (where structure is mostly the same but small changes everywhrere) so it will be not as efficient as manual template-data separation. Moreover you can also use gzip, brotli for your template and data so http compression doesn't change the overall picture
No, rendering html server-side is not nice and never was. Why on earth you will send markup template for every list item over and over again instead of sending just data and only one code-template (to render data on a client) ?
Suppose you need to show to user a list of books on your web-page. Server side rendering means you need to send to user a markup consists of html elements for every book
Don't you see something wrong with this? Why you need to duplicate over and over again html template for every list item resulting of significant increase of size of page to download if you can send only one template-component like this
or even in more compact binary-encoded format resulting in more than magnitude size compaction comparing to over-duplication html-approach. More size means more traffic for users to download over network and users which use data-roaming will "thank" you for your hundreds of kilobytes instead of dozens
This is why server-side rendering approach was flawed from the beginning (not because of page reloading but because of data duplication and traffic consumption)
Is there a something similar but uses array of bytes as output to application viewport pixels framebuffer? I think it will be way more interesting, especially pixels rendering part. You need implement vector rasterizer (because after you parse ttf font file glyphs represented as sequence of lineTo(x,y) and quadTo(cx,cy,x,y) instructions). You need to implement proper antialiasing (based on area coverage, not sampling, because it gives 256 shades of color not 16x of something like msaa in games). You need to choose some of rendering approaches - for example rasterizing vector objects one by one with blending to background or do some deferring approach with resolving intersection between objects geometrically (to reduce overdraw) and only then walk over pixels and calculate its colors. You also need to implement some dynamic caching and adaptive streaming because you want to zoom big blobs of text and without caching e.g rendering as vector you will not get 60fps and smooth curves without pixelization or LOD changing artifacts)
Just remembered this interesting provocative video from 2011 - https://youtu.be/00gAbgBu8R4
As I understood right - to achieve something like unlimited detailed geometry we need to store objects in adaptive vector form which is very fast to render in current zoom level and will need a little bit of computation if zoom also changes a little. And what encoding form of models/geometry will be the fatest way for rendering? From 2d/ui engine perspective it's just a pixel cache and we only need to copy pixels to viewport. And there will be max zoom level where it makes no sense to cache pixels for bigger zoom level because of memory overhead and ability to render straight from original vector representation in realtime.
But what is equivalent of pixels caching in 3d world? Due to ability of viewing objects/geometry from different sides/angles (without changing distance from camera to object e.g zoom level) we need to have something like 3d pixel cache which seems like huge memory requirements. Maybe voxels or points/splats? Or maybe just same 2d pixels cache but for each 6 sides of object (like 6 edges of cube) and do some pixel interpolation for intermediate viewing angles?
But don't you think that Dreams engine is the sight of more superior rendering approach than current triangles pipeline and will dominate in the future? Can't we achieve more in terms of performance and flexibility if we skip triangles pipeline and do all rasterization and pixel color calculation in computed shaders? For example you don't need to carefully choose tesselation level (or spend memory for many different zoom level lods and then trying to avoid lods switching artifacts) for models and fases with many smooth curves if you can do resolution independent rasterization straight from sdf/nurbs/b-splines in realtime. And it seems like having much less overhead due to 2*2 pixel overdrawing of many triangles just for visual curve effect.
Why don't use pixels caching solution for dense geometry problem described in the article? For example 2d/ui/gui engines don't render detalized vector shapes (like glyphs) from scratch every frame - glyphs rasterized to pixels, pixels stored to cache and used for subsequent rendering until zoom changes. And if you cache pixels for each 2x zoom level you just need to downsample next zoom level whan user changes zoom or resizes object (which is very fast comparing to rendering from scratch)
- about SPA - in my comment I said no word about SPA, it's a more complex layer on top. I only arguing about template-data separation approach to decrease data duplication and traffic consumption. And no, you don't need to rewrite your app as SPA and no react/preact/javascript frameworks required. You can use your server-side rendering and just change format of what you are sending to user. Instead of sending index.html with repetitive html markup for every list item you can basically send script-tag where you loop over data and build html-markup directly on a client
<doctype html>
<html>
<body>
</html>
Yes, it lacks http streaming but - less repetitive html markup -> smaller size -> less time to download -> http streaming becoming less useful
And again - you can use your favorite http compression (gzip, brotli, etc) on top of this template-data separation approach to compress even more