Last evening I saw a demo of a SSR @angular app that had partial client-side component hydration triggered only by a mutating user action.
This meant that not only was there 0 JS overhead to render the app, but that users only paid the runtime cost for what they interacted with
-
Show this thread
-
I'm happy to see route splitting becoming the norm, but the demo I saw was next level... Ignore routes, think component level code splitting and component hydration on demand. Not only is the framework compiled away, the delivery of the app is sparsed down the the smallest unit.
4 replies 7 retweets 91 likesShow this thread -
The implications of this approach are immense. One's time to interaction would be 0, and your users would only pay the parse/compile/runtime overhead as they used the application instead of being bound to initial boot cost.
5 replies 2 retweets 60 likesShow this thread -
Replying to @samccone
I'd love to see this pattern paired with low-priority prefetching JS needed for the interaction so minimize perceived latency. Is this demo up somewhere? :)
2 replies 0 retweets 15 likes -
<link rel=prefetch>'d JS is fetched with low-priority and kept in cache for 5m (until the resource is consumed/cache rules apply). There isn't parse/compile done until script consumption (e.g. until script src=foo.js).
@mathias may know if background parse/compile changes this.2 replies 0 retweets 17 likes
I had the same understanding. I’m not sure if background parse/compile kicks in for preloaded scripts, though. I’ll ask domain experts @camillobruni and @tverwaes about it next week!
-
-
Thanks, Mathias!
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.