rtsao's comments

I actually wrote a separate benchmark suite [1] that uses Paul Irish's pwmetrics [2], so using real Chrome to check render performance. From those numbers, Styletron performed really well in terms of time to first paint and time to first meaningful paint. But I didn't include it in the blog post because I wasn't sure how best to separate the transfer time factor (pwmetrics is set up to throttle network speed) since Styletron critical CSS was so much smaller.

[1] https://github.com/rtsao/styletron/tree/master/packages/benc...

[2] https://github.com/paulirish/pwmetrics

I think the argument is that separation of UI components is a more true "separation of concerns" than separating CSS, JS, and HTML.

The implementation of a UI widget is ultimately a combination of CSS, HTML, and JS which are coupled to some degree, so by colocating them together, the component is easier to manage. But to do this effectively, you need some way to get around the global nature of CSS. CSS modules and CSS-in-JS are means of achieving this.

A good blog post about this topic is: https://medium.com/seek-developers/the-end-of-global-css-90d...

Lerna [1] is very cool. I was firmly against monorepos, but the ability to easily manage and coordinate between individually versioned packages in a single repo is awesome. You get the benefits of a monorepo but also the benefits of small modules so it's the best of both worlds.

[1]: https://github.com/lerna/lerna

CSJS author here, thanks for the plug! I think CSJS fairly unique in comparison to the numerous alternatives in that it:

1) Can be used without any tooling whatsoever. It's just plain JS.

2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds.

I loved the ideas behind CSS Modules but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?