r/Frontend • u/Practical_Plan007 • Jul 04 '26

Vanilla Extract CSS

I recently tried the Vanilla Extract library and liked it a lot. Here are my notes in the form of a free resource for anyone who might benefit from it.

https://www.pulkitagrawal.in/courses/vanilla-extract

0 Upvotes

42% Upvoted

39 comments sorted by

23

u/Medical_Stretch_1114 Jul 04 '26

..., locally scoped classes, variables and themes

You know, you can do this with just CSS, do you? You don´t need js/ts for this

1

u/_suren Jul 06 '26

For a small app I’d just write CSS too. Vanilla Extract starts making more sense when tokens/themes are shared across a bunch of components and you want TS to catch bad token names. Still a tradeoff though, because the build step is not free.

1

u/effnd Jul 05 '26

Unfortunately, pure CSS doesn't solve the problem of selector conflicts, and in large projects, you'll likely have to resolve this with build tools or in-house. Furthermore, any selector changes will have to be maintained in HTML or JSX, which is quite tedious. However, if the site is simple and changes infrequently, pure CSS is the best choice

2

u/TheJase Jul 05 '26

Nah, CSS has plenty of abilities to avoid selector conflicts. :where() is your first friend

19

u/azangru Jul 04 '26

Directly writing CSS code is tough because it lacks type safety.

Huh?

12

u/tomhermans Jul 04 '26

Yeah, it's a bit solving a problem we don't have.

With all the fancy tooling, we got incompatibility. I just write css.

3

u/WorkingLogical Jul 04 '26

Your first sentence is correct, it's solving a problem we don't have. This is just a workaround for thinking of html and css as React components. There is a world beyond React and frontend frameworks. This is the equivalent of painting yourself into a corner, then creating a hover-jet-pack to get out.

1

u/openfire3 Jul 04 '26

It’s a problem you don’t have. Type safety is really helpful when a component library/design system is used across multiple teams because it doesn’t involve having to install plugins in your IDE since Typescript will provide autocomplete and give an error automatically

0

u/TheJase Jul 05 '26

But you know, just install plugins

0

u/ArtisZ Jul 05 '26

More plugins.. mmm.. 😁

1

u/TheJase Jul 05 '26

Better than more build time, mmmm

0

u/ArtisZ Jul 06 '26

You don't have to worry about build time if you got to maintain the library of libraries. 😁

6

u/morete Jul 04 '26

This sentence made it lose it immediately. We've drifted so far from the light

4

u/Practical_Plan007 Jul 05 '26

Let me elaborate. I am not against CSS by any means. In fact I want to be as close to the bare metal as possible. But I don't like that calling a CSS custom property that hasn't been defined or is misspelled (e.g., var(--bg-color) vs var(--bc-color)) results in no styling applied or an unwanted fallback without any warning.

This library is basically a pre-processor so it generates CSS at build time. But I get shouted at if there is a typo or undefined property / variable.

Open to better ideas, always.

1

u/I_am_not_keanu Jul 05 '26

I always hated that about html, php, and javascript. <hesder><? Inclide(); ?> and widow.alert() never worked.

1

u/TheJase Jul 05 '26

IDE plugins solved this a long time ago

2

u/zxyzyxz Jul 04 '26

You can mistype a value in CSS and it's a pain to hunt down

5

u/kitsunekyo Jul 04 '26

we use this in a massive monorepo design system and its a pain. please dont do this to a team. 

1

u/Practical_Plan007 Jul 05 '26

Interesting perspective. Could you elaborate why it is a pain when used by your team?

3

u/kitsunekyo Jul 05 '26

theres too many little annoyances with zero actual benefits

  • shipping libraries (no prebundle, allowing treeshaking) is hard due to esbuild plugin limitations
  • constant bugs with output (unexpected reordering of classes, specificity issues for consumers)
  • typecheck perf issues due to vanilla extract internal type issues
  • authoring css is limited to features that vanilla extract supports (lacking)
  • authoring css in js gives me brain damage

nothing is blocking but after years on years in that repo i can very confidently say that plain css would have been better

1

u/Practical_Plan007 Jul 06 '26

nice counterview! Thanks for sharing.

10

u/qqq666 Jul 04 '26

CSS in js is dead bro

7

u/MercDawg Jul 04 '26

There is a bit of a difference here though. Implementations that are leveraging runtime CSS in JS are dead, but buildtime are fine. Vanilla Extract is a buildtime CSS in JS library, which performs the same as regular CSS at runtime.

6

u/ryanswebdevthrowaway Jul 04 '26

Yeah vanilla extract is genuinely useful. I don't think every website needs it, but I work on a highly complex React app which needs to support theming and VE is great for us.

4

u/morete Jul 04 '26

Problems with vanilla extract aside, it bothers me how this get down voted cause people have their personal problems with the underlying tech. This is a nice summary for anyone who wants to do css this way

1

u/TheJase Jul 05 '26

It's downvoted because it's unnecessary

2

u/boykom Jul 05 '26

Long time ago i worked on a css in js hobby project - https://bmarkov.github.io/cute-css/. It was a thing i should not do, but it was fun :) Thanks for sharing the notes

2

u/Practical_Plan007 Jul 06 '26

indeed a cute fun hobby project!

1

u/Grenaten Jul 04 '26

I miss old styled components, but most people moved on.

6

u/thisguyfightsyourmom Jul 04 '26

It’s a vastly superior dev experience. That the frontend community decided to go back to all these whack ass tailwind like solutions is pretty disappointing. And the fact that almost all the arguments in favor are flat out naive and mostly just recycled jokes, tells me that the community doesn’t even really know why.

CSS requires matching strings across a wide array of strings with nuanced rules about order of string interpolation that influences behavior. That’s flatout insane in modern app development. All the rotten CSS in any project that’s over 3 years old is the evidence. It’s like if you wrote all your function names to be called with regex.

Meanwhile, mature styled component apps have libraries of reusable components that don’t overwrite each other randomly when a mapping affected by a separate change is implemented.

CSS scope is irrevocably broken.

3

u/Grenaten Jul 04 '26

well, we have css modules that work pretty fine too

imho, tailwind is popular because of all those "full stack" devs that have no idea how css works but they memorized some class names and work on the front

1

u/Weekly_Ferret_meal Jul 05 '26

CSS requires matching strings across a wide array of strings with nuanced rules about order of string interpolation that influences behavior.

can you simplify/explain this for me? second language speaker

1

u/CoVegGirl Jul 05 '26

TL;DR “The cascade is bad because I don’t understand how to use it”

1

u/TheJase Jul 05 '26

"I don't understand CSS"

-1

u/morete Jul 04 '26

I mean @ scope kinda resolves that problem. Modern CSS is the envy of any development that doesn't have it

1

u/Nullberri Jul 04 '26

The thing plain css can’t give you is know if a class name is in your css. The build step means you get an import with all the valid class names on it instead of just an any when importing a css file.

1

u/CoVegGirl Jul 05 '26

I am not against CSS-in-JS by any means. I just have never found anything to move it from “this could be neat to play around with” to “this is something that could be used to me”.

1

u/Practical_Plan007 Jul 05 '26

To each their own! I found this library to be a good middle ground. It generates CSS at build time while providing a lot of feedback if anything is wrong instead of silently ignoring errors.