I wish there was a mode that gave me everything <i>except</i> lazy load.<p>I like the idea, though I do fear the level of complexity (while necessary for the problems it's trying to solve) will further push away non-web developers from the web space.<p>But my concern is that if I'm on spotty wifi, and I click a button or scroll the page, the actual behaviors of that button or the components scrolling into view may not function for a solid 5-10 seconds while my phone attempts to establish a connection. I love that the framework's demos make it really easy to see what's going on - for example, under the "Simple useWatch()" demo, you can see that the JS file that actually updates the page when the "+" button is clicked, does not get loaded from the server until the first time you click the button. Similarly with the "Below the fold Clock" button, that clock will be rendered correctly for some specific time (default to 10:20:30 in the example code) when you initially scroll down, but won't actually update to the current time until a network connection has been established, javascript downloaded, parsed, and executed - none of which kicks off until you scroll the clock into view, meaning you may be staring at a non-functional clock for 1-5 seconds until it snaps into reality.<p>It seems to me that there would be no downside to having these JS files preloaded in the background after the initial page load finishes. Curious why they went with the completely lazy loading strategy.<p>As an aside, it seems these JS files are loaded from a service worker. I have no idea why that would be remotely necessary, but it prevents me from playing around with this idea using the chrome devtools, as the service worker doesn't seem to be subjected to the network tab's "ignore cache" or internet throttling simulation (for example, returning the .js file in 2ms despite throttling being set to simulate a network latency of 300ms).