OK. There is a lot of stuff here, and I will have to study carefully again about things like EM/REM, that I thought I had already understood.
I will be short and reply now, only to part of your text.
Now I understand your mention on parallelism: it is about fetching files, not processor work (I had misunderstood).
A clarification is needed: please don't take my medium article demos as reference to the webpages that WebAsYouWish is going to output. OK? They are worlds apart.
---
Besides what I have presented before, about the demos:
I was inspired by C header files: github.com/nothings/stb and github.com/floooh/sokol . I know they are not webpages, but the easy of handling is very important to me. I really hated wasting time when I hosted a blog, managing manually file by file in the VPS. Thank God, Medium exists!
Now the demos live in a bucket of Google App Engine, and I can move them anywhere without care about broken links of resources. There is an issue about "/images/x.png" versus "images/x.png": what works for VPS is bad for cloud bucket and vice-versa (at least I had problems with that, and I don't want to have again).
They have *very* few accesses: preparing it for caching is not worth it, mostly no twice visits.
In the specific case of the MosaicApp: I had to ship a library (that I don't use, because I have practice with the canvas, but others would need) for running a small app. The result is 108k (excluding embedded images) not minified JS for an app that doesn't do much, if you think on creating a mosaic. But the creating the mosaic is not the purpose. The purpose is showing the construction and functioning of the widgets (buttons, sliders, panels).
If the argument above is not enough, let's consider BobSprite, a complete app with only 419k of not minified JS, with many remarks. But the JS is a separated file, cacheable ;). Now, the relation utility/size must be good!
For prudence, I warned that the MosaicApp is not for smartphone. But it worked on all smartphones that I tested, except for one that had an eventual and bizarre bug: sometimes it paints a gadget, sometimes doesn't. I really don't get it, because it has only one canvas that is fully painted when updated. Anyway, I suppose my readers are developers and developers have computers. I bet that who created React, Svelt or Vue, is not ashamed of demanding computers.
Therefore, no luxury for the demos! If people (the half dozen that play the demo) will think I am not skilled enough... Amen!
By the way, after relaunching WAYW and spreading the word on Medium, I will stop writing articles; the relation readers/effort
is very low.
---
About caching WAYW webpages (*NOT* that sad, lonely demos):
1. no JS content anywhere
2. no embedded images (except small icons *maybe*)
3. expected HTML file size (CSS embedded) less than 20k (if the text is not big)
I have just entered your webpage in Medium and opened the top article ("Poor man's... part 3"). Then I downloaded the top image (blue gloves, white fabric). It is a JPG file that weights 34K.
You see... just the top image weights 34k.
Now, I am working on EASY and FAST construction of webpages that weight half of that image...
That's how I see this subject (need for caching).
---
As I said before, I need time to study everything else that you have expressed (it is not about building a correct webpage, it is about building a tool that builds correct webpages which I have no idea about them).
Thanks for your efforts to enlighten me ;)
