I'm not a web dev, but I see a conflict between server-side HTML generation and a local-first application. ;)
I think there's 2 distinct use cases here:
a) a classic "web-site" that people "visit", interact with and leave
b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state
Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there.
I'd aim at 100 ms page loading time (without initial network delay).
Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top".
This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps.
And about people re-implementing TCP: I first thought you referred to QUIC.
Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).
I think there's 2 distinct use cases here: a) a classic "web-site" that people "visit", interact with and leave b) an "application" that people (in the past would have installed and then) use over a longer period of time that needs to persist and sync state
Case a) doesn't lend itself to local-first, because it's unpredictable which information the user wants to query (think of Wikipedia – I don't want to download all of Wikipedia before reading an article). Yet, I still find it important that the website renders quickly, which I guess means removing all the layers of JS, as you described, and returning HTML from the server. Or replacing the JS frameworks with something much more light-weight and asking what really needs to be done there. I'd aim at 100 ms page loading time (without initial network delay).
Case b) is the prime case for local-first, which I would phrase as a grumpy old man's "just bring back programs like we had in the past (immediate response, data is local), and add multi-user sync on top". This means reaction times in the ballpark of 16 ms. I'm very happy that the local-first movement brings this experience into web apps.
And about people re-implementing TCP: I first thought you referred to QUIC. Because it's also a non-C implementation – in userspace. It is better in some scenarios, but also much more ineffecient and slower on high-bandwidth links (cf. e.g.: B. Jaeger, J. Zirngibl, M. Kempf, K. Ploch, G. Carle. 2023. QUIC on the Highway: Evaluating Performance on High-rate Links. In Proc. of IFIP Networking Conference (IFIP Networking)).