: what I'm seeing is that the build/module/runtime systems of frameworks cause far too much code to be included up-front
-
-
Replying to @slightlylate @youyuxi
: I covered this here: https://www.youtube.com/watch?v=a5X_Ot-R6lo …
1 reply 0 retweets 6 likes -
Replying to @slightlylate @youyuxi
: baaaaascially current build/module/load systems & framework integrations don't load granularly enough, nor cache enough
1 reply 0 retweets 2 likes -
Replying to @slightlylate @youyuxi
: the interplay of these things takes a long time to tease out; most frameworks don't own all parts. Farming bits out.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @youyuxi
: but when I sit down to trace, e.g., a frameworky app these days, I know what I'm gonna see most times...
1 reply 0 retweets 0 likes -
Replying to @slightlylate @youyuxi
: maybe some "server-rendered" early UI, but almost always a big bundle of script that pegs mobile CPU for seconds
3 replies 0 retweets 2 likes -
Replying to @slightlylate @aerotwist
WC alone is close to raw DOM, but I doubt FWs being re-built on WC solves that. e.g. Polymer ain’t fastest
1 reply 0 retweets 0 likes -
Replying to @youyuxi
: go take a trace of http://shop.polymer-project.org on a real phone on a real network. Srsly, do it.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @youyuxi
: ...what you'll see is that even if Polymer "isn't the fastest", it sure gets interactive components on screen fast
1 reply 0 retweets 0 likes -
Replying to @slightlylate @youyuxi
: and that's not about Polymer, it's about how Polymer is using selective Custom Elements ugprade
2 replies 0 retweets 0 likes
: ...+ granular HTMLImports to keep code loading in chunks that don't disrutpt interaction.
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.