Convopage
See the entire conversation
Next.js 2.2.0
◆ 1-line CDN support
◆ React `prop-types`
◆ Socket.IO, Firebase, Semantic UI, Material UI examples
zeit/next.js
next.js - Framework for server-rendered React apps
github.com
41 replies and sub-replies as of Apr 23 2017
+ all these changes!
Thanks to the 14 contributors that have helped us since 2.1.1!
Particularly excited about built-in ETag support for server-rendered pages
i.e.: clients won't download the same (dynamic!) content twice ⚡️
That's really slick! Ya'll are doing some great work over there.
thank you!
These changes rock! Can't wait to check out this latest version!!
Do you buffer whole response to generate etag or do you have a different strategy (trailing header?)?
We don't support streaming yet, so we have to get the entire HTML tree from React first.
Ick. Better than no SSR, I guess. At least with fastish backends.
Not sure you get much with streaming if you're pre-rendering "above the fold" (or close) content, or fast backend.
If you expect your backend to be slow, it's best to pre-render the layout, and have the client display its data cache, lazily invalidate it
Flushing before body-open is almost always worth it. "above the fold" rendering with manual selection of the fast backends works, of course.
Yeah, getting the <head> out fast is important. We'll be able to do that fairly soon, with automatic rel=preload tags for page's scripts
I was advocating for trailing http status codes. Pains not to be able to flush a script tag before the database answers that resource exists
Streaming wins come only if you are careful about what tags you are shipping ..a single non defer/async script will ruin it.
Streaming wins come often from early resource discovery where that doesn't matter.
Depends :) Lotta complexity around network priority hueristics for resource discovery
In my testing I have found the wins for streaming html resource discovery to be difficult to quantify on real pages
This is actually a big concern. Our early tests showed conflicting results w/ early discovery on slow download
Yes this.
Preload is stupid hard to get right and keep right
Flushing early for critical resources wins by definition. No measurement necessary.
For non-critical resources it depends, but putting bytes on the network instead of idling is a good default.
Funny you bring up flushing. I discovered a hack technique of inserting an empty script tag in my document to force the browser to paint
So if you have a large document and you know where you want to cause a layout paint operation to force a render. an empty script tag will do
are we having fun yet?
May not be deterministic and may just be chrome (or different across browsers). Parser will yield before a script tag...
*****hack****** 🤣😅😅😅😱
Oh yeah. Totally. I'd use hack to describe the chrome logic for it too (I added it)
Ah, I accidentally hit this for Google's SSR component renderer by emitting data via a script tag for each component.
If the script tags are near each other shouldn't be an issue. Spread through the document would yield a lot but also not always bad
Heuristics in general are hard and full of edge cases that fail hard. Would love to expose explicit dev control
confirm('click to render')
Only if it has processed a bunch of other tokens but doesn't force a layout/paint. Just gives them a chance to happen.
Paint driven off vsync makes it racy. I'd like to make it deterministic but hard to do without slowing down parsing with a RAF delay
Any links to learn more about how to do streaming like this? First I've heard of it, but sounds interesting!
In node it's trivial, just write to your response stream with some html :)
Oh I see - so streaming HTML to the client as it's rendered rather than waiting for rendering to finish before sending first byte.
bingo :) There can be wins in there, but 99.98% of sites out there have MUCH lower hanging perf wins to do before this. 🤣
Sadly no browsers support trailers despite me asking for it since 1979
😂 lol I was 1 day too early for the CDN stuff! Y'all are on 🔥🔥🔥
GG WP 👌