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 -
We also need JS to ensure that the basics (like showing new messages) work, even if we don't load all the messaging code right away. No matter what we do this will take some amount of JS.
1 reply 0 retweets 1 like -
I really think that there has to be something better we can do here vs just tell devs to not write JS. As it stands you cannot make something interactive without some amount of code, the real question I think is how can we make running it cheaper.
3 replies 0 retweets 2 likes
I'm not asking devs not to write JS; I'm asking for it to be cheaper by default and loaded on a per-interaction basis. FB is far ahead here, but doesn't document or externalize this knowledge for most React users.
-
-
Replying to @slightlylate @lastmjs
Totally, but I think that we (as an industry) can do more. Waiting for interactions to load is a painful experience but loading it upfront absolutely slows things down. isInputPending + scheduling helps, so we can preload things when nothing is going on, but that's not free.
0 replies 0 retweets 1 likeThanks. 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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.