css-in-js VS ava

As you might have realized by now, the front end ecosystem is saturated with tools, and unsurprisingly, tools have been invented to partially solve some of the problems with writing CSS at scale. "At scale" means that many developers are working on the same large project and touching the same stylesheets. There is no community-agreed approach on writing CSS in JS at the moment, and we are hoping that one day a winner would emerge, just like Redux did, among all the Flux implementations. For now, we are banking on CSS Modules. CSS modules is an improvement over existing CSS that aims to fix the problem of global namespace in CSS; it enables you to write styles that are local by default and encapsulated to your component. This feature is achieved via tooling. With CSS modules, large teams can write modular and reusable CSS without fear of conflict or overriding other parts of the app. However, at the end of the day, CSS modules are still being compiled into normal globally-namespaced CSS that browsers recognize, and it is still important to learn and understand how raw CSS works.

There are a myriad of CSS-in-JS tools, many of which are zero-runtime giving you all the benefits of authoring in a single file without the drawbacks of inline styles. That's how I prefer to do my CSS with React anyway... Vanilla Extract and/or Linaria are my current favorites.

One thing I think you're really missing is what the output is of CSS-in-JS. There are tens of CSS-in-JS frameworks that can output anything from: CSS Module like classes (Linaria, Vanilla Extract), Atomic Classes (StyleX, PreStyle), to the more traditional (Styled Components, Emotion) many with zero runtime cost (ie no JS bloat). That's why I say CSS-in-JS is primarily about developer experience... the output can often be whatever you want it to be.

We use Jest Framework for testing. Jest is not a dogma, and, of course, in its place can be any other test runner, such as Mocha or Ava. Let's focus on tests. I'll provide a short example because I don’t want to waste your time. You can find the full version here. It's crucial to read the comments in the code below. Let's go!

> In the popular jest test runner, each test file is executed in its own child process.

Is that confirmed?

I've been following this issue:

https://github.com/jestjs/jest/issues/6957

And what Jest actually does is still kind of muddy.

In contrast to that, other test runners like AVA have a clear description what happens when:

https://github.com/avajs/ava/blob/main/docs/01-writing-tests...

I've been looking at using japa or ava for web server testing but was curious what others were using and why.

Continued work on the test suite. Implementing AVA, with snapshotting. Making a lot of effort to have the snapshot directory structure match the test262 test directory structure by generating AVA test files.

You might want to give ava a spin:

https://github.com/avajs/ava/

It has a TAP reporter, but more importantly, as opposed to the more popular solutions, like Jest, the way it achieves parallelism is explained in the docs and won't change anytime soon, thus preventing wonky, hard to debug errors which occur when this part is abstracted away.

I switched to ava for that reason and have been very happy with it. But vitest looks nice, too. Thanks for the pointer.

Runs unit tests using AVA.

Last but not least important are ava, uvu and tape; they are a really light and fast test runners.

I've had some good experiences with Ava + Sinon. I've personally disliked Jest because it seemed to do some weird trickery in the background that prevented me from using ES modules.

Ava for a simpler environment than Jest, which I usually use. I need to check how to mock ESM with it, though.