Totally agree about this. Some bad stuff you can get into, and we should make JS-powered sites more bulletproof by default.
-
-
Replying to @jlongster @wycats and
Honestly, I'd love to see "SSR"d sites simply not ship JS on first load and only pull in JS when served from SW.
3 replies 0 retweets 5 likes -
Replying to @slightlylate @jlongster and
That'd make the TTFB hit you usually pay for "SSR" more reasonable and prevent invisible breakage.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @jlongster and
What's the problem with background loading JS? Why does it affect TTFB?
1 reply 0 retweets 1 like -
Replying to @wycats @slightlylate and
Honestly, nobody should use SSR if it makes TTFI worse. TTFB also shouldn't be worse but if worse TTFB improves TTFI, seems ok?
1 reply 1 retweet 0 likes -
Replying to @wycats @jlongster and
Most SSR solutions I've traced do not flush() early, delaying delivery of markup to request critical resources; critical path pushed out.
2 replies 0 retweets 1 like -
Replying to @slightlylate @wycats and
This seems particularly framework-centric. Excited to see streaming pulled into this discussion to avoid the TTFB delays.
2 replies 0 retweets 1 like -
Replying to @slightlylate @jlongster and
The work I've been doing with
@tomdale on glimmer SSR assumes flushing (& avoiding blocking scripts b4 content) is key part of the solution.1 reply 0 retweets 1 like -
-
Replying to @slightlylate @jlongster and
Honestly part of the story is that there are very few solutions that help you build the HTML for your app.
1 reply 0 retweets 0 likes
In most frameworks that's "too coupled" and left as an exercise for the reader. We decoupled in Glimmer but still default to whole-app
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.