[aphexairlines]

You still need postcss or something like it to use css modules. The alternative of CSS-in-JS requires a build step to extract either a CSS file or inline critical styles for server rendering. The browser-native alternative of CSS Module Scripts doesn't work in Safari.

You still need babel, tsc, or swc to transform typescript to JS.

And then there are imports of files that aren't JS (images, fonts, stylesheets, etc).

[Joeri]

The best approach for a no build CSS approach I've found is using BEM notation to scope the CSS of each component, and then @import'ing the separate CSS files into a master stylesheet. When hosted over HTTP/2 those @imports are downloaded pretty efficiently. However, when doing that the lighthouse score is impacted and it doesn't scale for large websites.

Typescript is indeed a given. There's no good way to do that without build tools. The question is whether typescript's benefits are worth the overhead of the build tooling. I tend to prefer it for libraries with strict API's, but I don't experience as much of a benefit for web applications. I think libraries also benefit a lot from bundling/minifying, so there I would choose a full build tools approach. For small web applications the overhead of the build tooling is not worth the benefit IMHO.

And then when it comes to direct imports of images, fonts, svg, I don't think people should do that at all, even when using heavy build tools. YMMV.

[youngtaff]

@imports are invisible to the browser's preparser as the stylesheet that contains them must be downloaded and parses before the browser can discover them

This will lead to slower FCP etc times particularly if the stylesheets aren't in cache