Hm that doesn't seem like a useful SSR solution. The point of user facing SSR is to get them Googlable content fast.
-
-
Replying to @wycats @jlongster and
Googlebot runs JS; so that works fine. Anyway, we agree that SSR should not delay TTFB = )
3 replies 0 retweets 1 like -
Replying to @slightlylate @wycats and
The broader point about delay loading JS is that it really has to be small chunks to avoid locking up the main thread.
1 reply 0 retweets 1 like -
Replying to @slightlylate @wycats and
So I can imagine many ways to make it work (chunked <script> blocks, e.g.), but haven't seen good solutions in the wild yet.
2 replies 0 retweets 1 like -
Replying to @slightlylate @wycats and
The best architectures I'm seeing right now in traces just run a LOT LESS JS; exotic strategies not required when you do less work = )
1 reply 0 retweets 3 likes -
Replying to @slightlylate @jlongster and
Yep. But "do less work" only gets you so far. App code ends up dominating, not framework code. Strategies needed there.
2 replies 0 retweets 6 likes -
Replying to @wycats @slightlylate and
Right - which use cases am I supposed to not support for my paying customers in order to "do less work?"
1 reply 0 retweets 1 like -
Replying to @AdamRackis @wycats and
Adam, I know you like inserting your app into these conversations but in general we're not talking about desktop-centric, closed-loop apps
1 reply 0 retweets 1 like -
Replying to @slightlylate @wycats and
*any* app. Are developers just implementing use cases *their* users don't care about?
1 reply 0 retweets 1 like -
Replying to @AdamRackis @wycats and
Many developers are carrying around infrastructure their users don't need (legacy, polyfills, etc.) or loading too much up front.
4 replies 0 retweets 2 likes
I know of at least one major app that still has a globals.js they <script> in sync before they even boot the ember 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.