twin.examples VS compiled

Hey, I'm trying (and failing) to put together a codesandbox. I think it's easier to replicate the steps from here: https://github.com/ben-rogerson/twin.examples/tree/master/next-styled-components

well, this is exactly how it's set up in the twin.macro example repo with next.js, and it is working perfectly fine?

You can pretty much follow all the steps from this tutorial, until this point where it tells you to extend JSX with a jsx-pragma in front of every twin.macro import. The documentation underneath says the following:

Alright, I had my tools in place and it was time to start connecting the dots, so to speak. I kicked off a new TSDX project, installed Styled components, and then went on to try and set up twin.macro. However, I hit a snag there... In the Twin example repo, there was no Styled Components + Storybook example, so I configured what seemed to make sense. Then I went on to add some samples, imported them into a new Story, and tried to run Storybook. It didn't work as expected. Some of the code worked and other components that were using the tw syntax didn't:

the biggest would be as a plugin to compile/transpile other language macros for example twin-macro (styled components using tailwind syntax) https://github.com/ben-rogerson/twin.examples/tree/master/component-library-styled-components/packages/components

tags inside SFCs are typically injected as native </code> tags during development to support hot updates. <strong>For production they can be extracted and merged into a single CSS file.</strong></p> </blockquote> <p>There are also 3rd party CSS libs that do the same thing such as <a href="https://linaria.dev/">linaria</a>, <a href="https://vanilla-extract.style/">vanilla-extract</a>, and <a href="https://compiledcssinjs.com/">compiled CSS</a>. Which can be used in the event you're stuck with something that doesn't have baked in support via SFC formats (looking at you React).</p> <p>These are my preferred ways of handing it.</p> <ol> <li>Tailwind</li> </ol> <p>Option 2 is tailwind, which works backwards.</p> <p>That is, instead of the above with extraction where you write the styles, and the framework or libs extract them and replace them with class names, it's the other way around.</p> <p>You're writing class names first (which are essentially aggregated CSS property-values) which then generate and/or reference styles.</p> <p>It has the advantage of being easy to write (assuming you've got editor LSP, linting, etc), but as you've discovered, it's difficult to read / can get really messy really fast.</p> <p>As far as all the other claims on the Tailwind site, it's all marketing, at least 80% bullshit.</p> </div>

Your choice of CSS lib. Bootstrap can still be a valid choice, tho you may want to check the docs of whatever SSR / SSG framework you end up using as they may have better (or worse support). For example if you wanted to do CSS-in-JS (Next) i'd consider Linaria, vanilla-extract, or compiled.

So to be extremely clear, the issue isn't CSS-in-JS per se, it's just that the author only looked at implementations that don't generate create CSS files. He notably mentioned the (apparent) zero-runtime solutions Vanilla Extract and Linaria, only to skip them and complain that Compiled inserts nodes at runtime.

Compiled

Link: https://compiledcssinjs.com/

Compiled (Compile time CSS-in-JS solution from Atlassian)

Stitches Is near zero runtime and vanilla-extract claims it's zero runtime and typed. There's atlassian compiled as well but I never used it.

Author here, I haven't had time to play around with it, but this library[0] from Atlassian looks like a "best of the both worlds" styling approach: CSS-in-JS authorship without the runtime penalty.

[0] https://compiledcssinjs.com/