It is true that a button's click event can fire before a client re-render. *However* if that event changes state it does have to do a initial VDOM render to make a first frame before a second one to work how to change the actual DOM and the UI. and although that click event does run it needs to be redirected to the actual event handler. That redirect needs to do downloading, parsing and hydration. So "immediately usable" and "super responsive" are a stretch here...
There is a service worker that will prefetch all of the event handlers currently in view. So when the person clicks on the button, the browser will fetch the JS, but the service work short circuits that request and returns the JS instantly. They have plans to make the prefetching even smarter by gathering information on which chunks are most used and prefetch those first.
Ah I didn't realise it did that? The homepage still makes several references to lazily downloading JS?
Eagerly downloading JS is something every framework does though and many only download for the current view through code splitting for the current page. It doesn't fix the later two problems..., struggling to find any benefits above existing techniques here :/
