Explain the table a bit more

[natew]

Explain the table a bit more

[oliviertassinari]

First of all, I have added some notes on each table cell in the source code.
I don't go into details but that can give some ideas.

Unbiased

Unbiased. What makes it biased?

In case you missed the README. I'm digging a bit more into the sections:

Unbiased. The less coupled with a solution we are the better. We also want to make sure the solution we are going to use reach a broad audience. E.g. LESS is used by the Angular and React community. That's increasing odds of success.
Are we coupled to React?
Are we coupled to Webpack?

From my perspective, Aphrodite was designed to be used with React. However, I feel like it could be used with any other view libraries. So Aphrodite and JSS don't differ much in that dimension.

Server-side rendering

SSR. How is it worse for SSR?

I'm gonna use the README again:

Server Rendering. Server side rendering a page drastically improve perceived performance for a user first visit (for repetitive one, Service Worker are even more efficient). Material-UI can't be taken seriously without a strong answer to this point.
Can requests be parallelized? I.e, not using a singleton, that's also bad for security.
Is the API allowing streaming the response?

Let's have a look at the Aphrodite docs:

To perform server-side rendering, make a call to StyleSheetServer.renderStatic, which takes a callback. Do your rendering inside of the callback and return the generated HTML. All of the calls to CSS() inside of the callback will be collected and the generated CSS, as well as the generated HTML, will be returned.

import { StyleSheetServer } from 'aphrodite';

// Contains the generated html, as well as the generated css and some
// rehydration data.
var {html, css} = StyleSheetServer.renderStatic(() => {
    return ReactDOMServer.renderToString(<App/>);
});

The Aphrodite API is using a singleton to collect the styles. Requests can't be rendered in parallel nor asynchronously. It's working with ReactDOMServer.renderToString because is a synchronous call. What's gonna happen with a stream like https://github.com/aickin/react-dom-stream?

On the other hand, with JSS you instantiate a style collector at each request.

First Paint

From the README:

Time to first paint. We have a legacy of poor performance with our inline-style implementation (lake of caching). Reducing the delay between an interaction and something on the screen is quite critical for us. I have run a simple benchmark on a modified version of CSS-in-JS There is quite some factor than can make a difference. I have noticed a factor x2 of difference between the fastest solution (CSS modules) and the slowest one (styled-components).

• Is the style pre-processed at runtime of build time?
• Is the style injected as class names used or upfront during the bootstrap?
• How are the classNames generated? E.g. computing a hash of the rule object could be expensive

For that dimension, you really need to benchmark how it perform on your page with and e2e metrics.
I just had some intuition on how it behave at large scale. I have only measured things on a low scale project.

• prefix: Aphrodite prefixes for all the user agent while JSS only prefix the current one. I believe the second one is less intensive.

To conclude,

Aphrodite and JSS are close on those dimensions, for Material-UI, the key differentiator for using JSS over Aphrodite was the access to lower level API needed for a custom theme solution.