There are folks who want you to believe it isn't a problem that "modern" frontend starts with 35KiB of JS and scales obscenely from there. The mobile web ecosystem is collapsing because of JS emissions. We can't afford denial any more.https://twitter.com/FronteersConf/status/1185099012128595970 …
-
Show this thread
-
Replying to @slightlylate
The web cannot compete with native if websites are unable to run even a fraction of the code native apps can. Browsers (and also websites/frameworks) need to change in order to enabling running more client side, but this needs to be collaborative.
1 reply 1 retweet 3 likes -
Replying to @n8Schloss
Absolutely agree on collaboration! The way I decompose the problem is to focus on "how much work are we doing per interaction?" You see this here: https://github.com/slightlyoff/never_slow_mode … If you think about this as "what is the price of tapping on a button?", we get closer.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @n8Schloss
So, can we afford 1MiB of JS loaded and running on the main thread per tap if it has to come over a slow network? Clearly not. But we can afford that much over time, amortized across multiple interactions.
2 replies 1 retweet 0 likes -
Replying to @slightlylate @n8Schloss
And the default way today's popular tools manage this is to treat page load as the *only* moment. We need a much more sophisticated approach if we're going to lean into JS-first.
1 reply 0 retweets 3 likes -
Replying to @slightlylate @n8Schloss
dynamic imports solve this problem pretty elegantly, no?
1 reply 0 retweets 1 like -
Replying to @lastmjs @n8Schloss
They can! As can preloading JS into caches w/ <link rel="preload"> or prefetch and Service Worker pre-fetch or H/2 push. The PRPL pattern the Polymers worked up serveral years ago nailed a lot of this: https://polymer-library.polymer-project.org/2.0/docs/apps/prpl …
2 replies 0 retweets 2 likes -
Replying to @slightlylate @lastmjs
Yep! At Facebook we've been using this pattern since 2010 via bigpipe and carried it over into the new Facebook as well. (https://www.youtube.com/watch?v=WxPtYJRjLL0 …) But when we display things we still need JS to ensure that it's interactive enough to show something basic while the next view load.
2 replies 0 retweets 5 likes
Yep! But the cost of that abstraction, today, shouldn't be 35KiB; certainly not for most users who have access to modern JS/DOM. Getting to a reasonable per-interaction cost means economising at every level.
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.