Server side rendering with renderToNodeStream

[Jafar Rezaei]

Does this plugin supports server side rendering with renderToNodeStream and if yes , how?
is there a sample explanation about how? cuz used-styles is a module like critters but if works with SSR stream..

[Jason Miller]

The architecture Critters uses is quite different from used-styles, and can't be done in a streaming manner. used-styles does a loose analysis of your code (with specific workarounds for things like React components) to make an educated guess at which styles are used by a set of files. Critters does an analysis of an HTML document in order to determine with 100% certainty which styles are used by that document.

In a theoretical React-style streaming SSR setup, there is no reliable way to analyze generated HTML as a document until renderToNodeStream completes. Critters could potentially use the unfinished buffered HTML output to begin downloading resources, but this is not natively supported by JSDOM - we'd essentially be implementing the browser's preload scanner, which is a rather complex thing to do. It requires detecting URLs in a mixture of HTML, CSS and JS, but also obtaining enough context during scanning to determine whether a given URL is actually a stylesheet or not.

Also, this is a bit off-topic, but FWIW it's extraordinarily unlikely that streaming SSR offers performance benefits. The outcome is generally a stream with a single utf8-encoded chunk due to the default high watermark for HTTP in Node being 16kb, which means the only difference between streaming and non-streaming is that streaming incurs buffering and book-keeping overhead. I covered this issue in a talk last year.

Finally, my guess is that this question is perhaps related to performance. Streaming is one potential way to spread work out over time (of debatable benefit given the above), but I think Critters' implementation could be made considerably faster without requiring an interface change. Currently it creates new JSDOM document instances for every instantiation, and does not memoize or optimize selector execution at all. Both of these things end up consuming more time than they should. They're also both things that were introduced after the original release, which used a much faster purpose-built DOM implementation and a faster CSS selector engine. Perhaps performance improvements would be reason enough to consider moving back to something more minimal like that.