Chat about the future for stitches

[StephenHaney]

Update

We're going to update the Stitches site to say it's no longer maintained so that new folks are aware of the current status. You can read more here.

---

Original post:

Hey y'all, I wanted to chat with everyone on the best route for the future of Stitches.

Obviously, things have been very slow lately. Here's the situation: most of the team that created Stitches is no longer available to work on it. And with React 18, the ecosystem has changed and made the future for runtime injection pretty murky.

If you're currently using stitches for SPAs, the React 18 changes don't really matter to you and you can continue using stitches without making any changes. But looking forward, the best route for the library – as far as I can tell – is to use static extraction. For stitches, that means a major rewrite of the styling engine.

So, given all of that, I think the right thing to do is to open it up to the community to have a chance to drive it forward. I'm chatting with a few very qualified people who have volunteered to take over the reins on Stitches. I'd love to see a great maintainer emerge who can help with the small features and daily triage and also drive toward the next major version for React 18+.

I'd LOVE to see the Stitches API with a static extraction engine. I think there's a huge opportunity here to be the perfect styling lib in the React ecosystem.

Let me know what you think of this path and if you'd like to nominate or volunteer as a lead maintainer. 🖤

[lucastobrazil]

I'm a passionate stitches user/believer/supporter, and would love to help however I can. That said, I'm more of a designer than a OSS maintainer so I'm not sure how I could. I work as a manager so maybe have skills to contribute around planning etc.

Are there any peeps with OSS maintenance experience?

[hennessyevan]

I know https://github.com/Mokshit06 has been working on a project called macaron which is very similar to this stitches static extraction endeavor. I wonder if there's any desire to combine efforts here?

I can also say that I'm happy to take PRs on where I can.

[jd-oconnor]

I know https://github.com/Mokshit06 has been working on a project called macaron which is very similar to this stitches static extraction endeavor. I wonder if there's any desire to combine efforts here?

I can also say that I'm happy to take PRs on where I can.

Macaron is built off of vanilla-extract so they would need to be included in that conversation since it’s their static extraction engine.

[peduarte]

This is really good news 🎉 While I don't have the capacity right now to maintain Stitches again, I'd love to help out with the DX-related work, including the Stitches API. Being one of its creator, I can also contribute to providing historic context where necessary.

If there's a future for Stitches, I'd also love to once again advocate for it.

[ivanbanov]

I gave a try to macaron but it lacks many Stitches features yet, the api is the same which is nice but the types and access to the tokens is still missing, same for responsive variants. I think it's a great start point since Stitches runtime will have to be replaced. I'm wondering if it worth relying on an external tool or better to build it internally.

We use it internally in Miro's design system, and I could absolutely step in to push Stitches forward!

[jpmaga]

I've recently been writing a POC for a stitches like api with static extraction. Bit of a frankenstein, but it's alive!!!

Works more or less like this: I wrote something like cva, then using linaria to create the classes and handle css extraction. Now, linaria has an option that let's you define a preprocessor, using stylis we can add a plugin that adds all the nice stitches stuff like utils, custom theme map, etc, and since this is a build step, stylis is never included in the browser bundle. And by the way, let me take a moment just to mention how great stylis is, like really.

The real challenge was actually to get responsive variants to work. The best solution i could come up with was to create a new option named dynamic variants, the goal is to use them to set css variables. The problem with css variables is that it bleeds to child elements, so using React's useId (and an hash function) it creates a class, and then proceeds to append a style tag right before the component with the media queries, scoped to the created class. Not optimal, but does the job, and works just fine with SSR.

Just throwing some ideas out there, feel free to use and adapt if needs be.

A sample of how it looks like at the moment:

import { css } from "@linaria/core"

const Stack = styled("div", {
  base: css`
    display: flex;
    flex-direction: var(--stack-direction, column);

    & > :not(style) ~ :not(style) {
      margin-top: var(--stack-spacing-column, 0);
      margin-inline: var(--stack-spacing-row, 0) 0;
      margin-bottom: 0;
    }
  `,
  dynamicVariants: {
    spacing: (v: number) => ({ "--stack-spacing": `calc(${v} * 1px)` }),
    direction: (v: "row" | "column") => ({
      "--stack-spacing-row": v === "row" ? "var(--stack-spacing)" : "initial",
      "--stack-spacing-column": v === "column" ? "var(--stack-spacing)" : "initial",
      "--stack-direction": v,
    }),
  },
  defaultVariants: {
    spacing: 16,
    direction: "column",
  },
})

I've never wrote a babel or SWC plugin, so my experience with it is not up to par to the needs of stitches. But I'll definitely contribute with a pull request here and there.

@gajus and his company @contra have voiced interest in this here, and I would support them. I've used another package by him (them?) and was really please with it.

[gajus]

@gajus and his company https://github.com/contra have voiced interest in this #1096 (comment), and I would support them. I've used another package by him (them?) and was really please with it.

I had a conversation about it with @StephenHaney, and unfortunately it is no longer an option for me or Contra to become active maintainers of Stitches. We also intentionally do not use SSR (or intend to), so the static extraction is not particularly relevant to our setup.

[jpmaga]

@gajus and his company @contra have voiced interest in this #1096 (comment), and I would support them. I've used another package by him (them?) and was really please with it.

I had a conversation about it with @StephenHaney, and unfortunately it is no longer an option for me or Contra to become active maintainers of Stitches. We also intentionally do not use SSR (or intend to), so the static extraction is not particularly relevant to our setup.

A shame, but totally understandable nonetheless. 👍

[Tahul]

Hey :)

I used @stitches/stringify in https://github.com/Tahul/pinceau to create a static-styling solution for Vue.

I would happily share my insights on the usage and help in achieving the static extraction engine!

Thank you so much for Stitches by the way, it is an amazing project and I hope it continues to make styling so pleasing for everyone!

[joshuaellis]

I've not a great experience in this type of library, but I do have experience in large OSS projects - primarily react-spring but also react-three-fiber / drei & strapi (who I work for).

I've always loved stitches from when I first used it, I use it for my own site and the react-spring docs site and at my previous work used it on several microsites.

I'd be happy to help out with daily triaging and working on smaller features and fixes till I'm up to speed on the landscape of styling solution - I'd understand if I don't quite fit the bill though 💪🏼

[thekidnamedkd]

I don't think I have the capacity to be a lead maintainer, but I'd love to contribute and work with an ad hoc group in the interim. If it feels like there is sufficient energy, maybe it would b worth figuring out a little meetup to get some historical context via @peduarte and start roadmapping?

[heikir]

On the one hand, I am sad to hear that the original team cannot maintain the project anymore, but on the other hand, I am excited to see that the project might have a strong future since also at our team, we decided against adopting using Stitches for our latest product despite this being our favorite styling library.

I am a big fan of Stitches API design and strongly believe this could become the go-to alternative to styled-components for every project that wants to adopt react 18+.

I would be excited to start maintaining the library together with the team at Commonbase, but I would need to have a quick discussion with the team first to see whether we have the bandwidth in the near future to rewrite the style extraction logic.

[PookMook]

Same boat as a lot of people here, love stitches, been using it for quite some time now (since the @christianalfoni experimentation days) and I do have some thoughts on how to keep pushing forward the APIs. But As lot of people, don't have the bandwidth to take on a maintainer role (and it wouldn't help the library to be sometimes available).
Glad to help and contribute as much as I can! If there's an internal demo/code walk through/RFCs, I'd be happy to join!

[natew]

Not to spam but I'd be happy to help Tamagui cover any gaps people see in using it, as currently it's probably the closest to Stitches in terms of API that has a production-ready static extractor (and optimizer!).

I just put out @tamagui/web which is a subset of @tamagui/core that drops the RN-specific APIs and works nicely just for web. But still some work to be done there to support a fuller set of web styles. Also happy to help, the Tamagui compiler has a nice section just for optimizing styled() calls you can crib.

[giuseppeg]

@StephenHaney I am the co-author of styled-jsx, if anybody is willing to fund these efforts I could help

[brijeshb42]

Hello Stitches team and fellow collaborators. Since the formal announcement of Stitches being wound down, I (on behalf of the MUI team) started looking into how Stitches can be used as a build time solution with very minimal runtime code. I had already worked with Linaria before and I knew how it works and how it can facilitate using any kind of runtime CSS-in-JS solution to be moved to build-time. So I took that task and within 3 days (and few more for some refinement) I was able to create a POC using Linaria for the build-time evaluation and Stitches as the actual CSS-in-JS library. I call this library no-stitches, mainly because stitches's runtime is not part of the final build output. Please see the relevant links at the bottom. The current POC works well with Vite and could easily be extended to support nextjs.
Due to the build-time nature of css-generation, it is not a 1:1 migration for users of this library, especially when using the css prop on styled components. It supports styled, css, keyframes and globalCss functions from Stitches. There are two significant API changes as far as the user of stitches is concerned -

First Change -

import {theme} from './path-to-local/stitches.config';

const component = styled('div', {
  color: 'red',
  backgroundColor: theme.colors.background.value
})

Here, you can import and use your generated stitches theme from your stitches config path. With build-time, this is not possible as there is no path from where you can import your theme and use that. To overcome this, the styled API is modified to also support callback in the 2nd argument.

const component = styled('div', ({ theme }) => ({
  color: 'red',
  backgroundColor: theme.colors.background.value
}))

Intead of importing, you are passed the theme object as an argument. How is this theme generated you ask. So now, stitches config has moved to being passed through build-time configuration. In case of vite, it'll be created in vite.config.ts which'll be consumed by the no-stitches package and then passed as an argument. You can pass n number of themes through the config and they'll be passed back to you in the 1st argument.

Second Change -

The other major portion that is not easy to port to build-time is the inline css prop mainly because all the values that come through the prop won't be available at build time. So it isn't possible to extract that part during build. So instead what I've come up is the usage of an icss (for inline css) function. Intead of passing a css object to the css prop, you pass the css object like -

<Component
  css={
    count % 2 === 0 ? icss({
      color: 'red'
    }) : icss({
      color: 'blue'
    })
  }
/>

If you want the icss function to generate css with more specificity (in case it is not able to override the original styles), you'll also need to pass the actual styled component as the 2nd argument (icss({color: red}, Component)).
As you'll notice, I wrote icss twice for a ternary condition instead of having that condition in the color property like icss({ color: count%2 === 'red' : 'blue'}). This has the same reason as you'd write full tailwind class string in your code instead of doing something like font-${variableName}. It allows for better/easier build-time evaluation. This essentially generates two class names in the final build like -

<Component css={count % 2 === 0 ? "class-1" : "class-2"} />

.class-1 {
  color: red;
}
.class-2 {
  color: blue;
}

All of this uses the last released version of Stitches and only uses the public Stitches API without any kind of modifications. There is slight modification in the final css that is generated but that is done outside of Stitches.

Why

1. Why we are doing this?
   At MUI, we ourselves are trying to migrate to a zero-runtime solution that'd allow us to still keep most of our APIs while being flexible enough to support build-time evaluations with a way to hook into runtime to set dynamic values. API of Stitches is quite similar to our current code and with first class css variables support in Stitches it becomes a likely candidate for the CSS generation part.

2. Where we are trying to go with this?
   Right now, we are mainly trying to gauge interest from community and if it gets enough traction, we can look into taking this from a POC to a proper project.

Links -

1. no-stitches package code
2. Example usage with Vite. This compares a Slider component. Left one is from @mui/material that uses emotion. Right one uses no-stitches whose code is here.
3. Final runtime code that gets included in the build.
4. Code for the example app. Please ignore the typescript errors as I've not had time to augment the stitches typing to support the callback signature. I also think that due to the build-time configuration, it'll need some sort of generator that would generate a d.ts file using a cli command based on the config provided so that users can get completions for their custom themes/utils.

[yumin-chen]

I really appreciate your great work on this!

The other major portion that is not easy to port to build-time is the inline css prop mainly because all the values that come through the prop won't be available at build time. So it isn't possible to extract that part during build.

For parsing the inline css prop, can we also try instantiating all components found in the project at build time with default initial props, and generate CSS files as per the css prop? Once a component is instantiated, all of its children are also generated with default props too. The idea is that we could easily do something like const app = App() at build time and you can analyze all its app.props.css and write out CSS rules. That way we won't need that icss helper function.

Thoughts?

[brijeshb42]

In that case, what if the css prop object had some kind of usage from the component's props object. That would most likely throw an error. That's why the escape hatch of icss. That way, the actual props usage would lie outside of the icss function making the css evaluatable at build.

You'd still be able to access the theme object as callback arg icss(({theme}) => ({ color: theme.colors.blue500.value }) if required. For dynamism, you could set custom css variables with values at runtime and those variables can be referenced through the styled definition.

[yumin-chen]

In that case, what if the css prop object had some kind of usage from the component's props object.

For building the static CSS for the initial paint, it shouldn't matter even if the css prop is dynamically accessing the components props. As long as we initialize the entire App's virtual DOM tree, it should be able to generate the entire initial CSS according to the default props, but any change to the prop at a later state might require a different CSS rule and those won't be generated.

Your work is great. However, I don't like the idea of having to wrap a icss helper function around my css code. It kind of defeats the purpose of keeping our APIs.

I've been working on a POC that parses inline css props at build time using PandaCSS, and it's able to parse all inline css props at build time with near-zero touch to code written for Emotion.js. Feel free to take a look at Radipan if interested.

[wbobeirne]

Personally very sad to see Stitches get left behind as a result of where the broader React ecosystem is going. For the projects I'm currently working on that use Stitches, I personally get no benefit from RSC / SSR and don't have a need for static extraction. Stitches is great for me as-is, but I'd love to see some improvements around small stuff like supporting container queries, deterministic style ordering etc.

Is there a path forward where work on Stitches is limited to improvements on what it's already good at, and out of scope improvements that would require a significant rework of the styling engine are rejected as out of scope?

We've had a few good chats with volunteers but so far no one has been able to take things on.

I haven't been a contributor to Stitches in the past, but I really enjoy using it and would be happy to help in grooming the issue queue to keep it to a limited scope of improvements, and review existing PRs and make contributions just to keep it up to date with basic CSS features. I've been somewhat active in the Discord where I assumed these conversations would take place, but it looks like that all happened somewhere else. Not sure if this reduced scope vision aligns with anyone else, but maybe that would make it less daunting of a project to maintain.

[hennessyevan]

I'm open to help contribute to that vision

[Pearce-Ropion]

I am in exactly the same boat. My company's application isn't interested in SSR or static style extraction at this time. We've committed to Stitches as it provides everything we need with a simple, clean API.

We are already using a private fork of Stitches (although we haven't actually committed anything yet) and have a few ideas of things we want to add including dynamic variants and the ability to extend a stitches config/stylesheet.

I would be open to contributing toward stitches going forward. I haven't contributed publicly on Stitches but I have a very good grasp on Stitches' internals having had to do a deep dive to get config extension working.

[OnkelTem]

A slightly belated response.

I can't agree more. Honestly, I don't quite understand this trend that has become widespread, the eagerness to render everything on the server. I can be wrong and missing some important points, but let me share my current view please.

Before, SSR was the main concern of SEO because search bots couldn't run JS. Since then they have learned to deal with JS websites, so let them do their job, no? Ok, there are probably other good reasons for SSR, but don't tell me you really need SSR in a web app, web game or an intranet website.

When you make an npm package, you get a bunch of reusable js-files, that you distribute. Now with the new CSS-in-JS it's simply over. You cannot continue using tsc for building nice and clean TypeScript ESMs (that are also friendly to tree-shaking), because you should also care about CSS extraction: https://panda-css.com/docs/guides/component-library and produce a bunch of style information (that is already a part of your code!).

My current impression:
It forces us to abandon convenient technologies in favor of some vague advantages that we can't even evaluate.

P.S. Sorry for this outburst, I feel like I no longer have the strength to put up with all this mad tech-zoo. I haven't seen any innovation in this for a long time, it's a pity that human resources are being wasted on all this nonsense. I want to retire.

[thiagoarantes]

I can definitely contribute with manpower to make Stitches thrive. Let me know!

[Pearce-Ropion]

@thiagoarantes @hennessyevan @wbobeirne @StephenHaney
All of you have expressed interest in supporting the existing Stitches API into the future. I'd like to hopefully get started on some serious plans to restart the maintenance of Stitches. I don't have a preference on communication method but my discord is xorcinuss if you want to get started there. Feel free to reach out and we can start making some plans.

[wbobeirne]

I don't see you in the Radix / Stitches discord, but that would probably be a good place to spark up the discussion as I assume the maintainers keep an eye in there as well.

[IlirEdis]

Please make stitches alive again to save me from tailwind 😬

[shadymoses]

Panda is a step backwards for my use case. I'm building an internal design system package used by multiple teams which all have major variations in build tools.

The major selling point of stitches for me is that it's self-contained. No consumer of our package needs to install stitches, add a theme provider, or otherwise switch their styling solution to get going. Stitches is an implementation detail that's nearly invisible in our setup.

Panda is build-time, which means every consumer of our package would need to install panda and configure it for their app to be able to use our package. That is a good amount of friction that's currently a deal breaker. No other solution I've used in the past or looked into recently can provide what I'm getting from stitches.

[astahmer]

Panda is build-time, which means every consumer of our package would need to install panda and configure it for their app to be able to use our package.

Panda extracts your style usage from your source files and generates a static CSS file using atomic classes, that's it, you can use it anywhere and that also means you can distribute it to anyone (even non-Panda users)

---

we do have presets if you want to share some utilities/recipes/etc to your Panda users, but that's completely optional

[natew]

@shadymoses Tamagui has a super close API to stitches, fully type safe, and works compile time and runtime so it fits your use case.

[mustafa519]

@shadymoses I totally feel you and have the same exact problem. People still try to not understand that stitches has the most fixable API with its pure vision.

Oh yeah, finally someone mentions annoying ThemeProviders that we cannot integrate for external usage without forcing people to add the provider.

Well, I extracted stitches from the source and integrated our own internal structure already. It had seemed like the only solution at that time, so it seems now as well.

In 2024 there are still no frameworks what stitches brought us. No matter how many different packages appeared.

Sad, good luck people.

[lucastobrazil]

Panda is a step backwards for my use case. I'm building an internal design system package used by multiple teams which all have major variations in build tools.

The major selling point of stitches for me is that it's self-contained. No consumer of our package needs to install stitches, add a theme provider, or otherwise switch their styling solution to get going. Stitches is an implementation detail that's nearly invisible in our setup.

Panda is build-time, which means every consumer of our package would need to install panda and configure it for their app to be able to use our package. That is a good amount of friction that's currently a deal breaker. No other solution I've used in the past or looked into recently can provide what I'm getting from stitches.

I totally agree. Stitches is just so "plug and play" which is exactly what we need for our design system too.

I'm sure the problem is not a simple solution, but honestly, I still don't really understand what it is about stitches technically that prevents it from overcoming this server side rendering issue. I mean, is there just something under the hood in some kind of "engine" that needs to be altered? Can't we just maintain everything else that is very very stitches oriented and change only the bits that need changing?

I've been following this thread for ages, and seen so many people put up their hands to try to nail this problem, but every time there seems to be a bit of momentum, and it's time to get hands-on, it just falls by the wayside. I'm more of a designer who codes so feel I cannot help much but maybe there's a way to try use some problem solving methods to fix the issue?

As always, big love for the Modulz crew and all of the stitches community

[mstade]

@StephenHaney would it be possible for you to open up this repo for commit access by people here who've expressed interest in moving it forward, and just let them work on it? I see some interesting and concrete developments by @brijeshb42 for example, but I doubt initiatives like that will gain any reasonable traction as a fork. Even if Stitches has a runtime and despite the whims of the React team, there are plenty of people who'd probably benefit from further development, regardless of direction.

If you're not going to be stewards then consider just handing it over to anyone saying they're willing to work on it. What's the worst that could happen? This is version controlled software, after all.

[jeffscottward]

I have been in the ThemeUI ecosystem this whole time, specifically Dripsy because I can cross compile to React Native which is massive win for me.

Wondering if this same issue applies to ThemeUI wrt static extraction. I have no issues about rewinding shorthand's from m to margin, but at a minimum I don't want to change my inline authoring style (saves so many headaches), and keep responsive design arrays.

I suppose I could just never use RSC's if ThemeUI isn't static. There will be way more CSS written for sure.

[natew]

@jeffscottward check out Tamagui, which does this including an optimizing compiler. The creator of Drispy is migrating to Tamagui actually with their startups app and has high praise for it over a year since their migration.

[jeffscottward]

@jeffscottward check out Tamagui, which does this including an optimizing compiler. The creator of Drispy is migrating to Tamagui actually with their startups app and has high praise for it over a year since their migration.

Very cool!

Yea he mentioned it in my tweet to him, just hadn't looked yet. Looks like PandaCSS

https://x.com/fernandotherojo/status/1710689378991821048?s=46&t=zsjvsRFuxqFkYW8y9jxV1A

[natew]

Yep, PandaCSS came after Tamagui ;) but many of these libraries are similar.

[Mistsuu]

Hi, sorry if this came out to be a huge misunderstanding as English is my 2nd language, and I'm not technically a dev so I'm not really familiar with the lingo and where to put a comment :-)

While there seems to be no way to do static extraction, I've been using this component as a way to include the CSS to the static website built.

import React from "react";
import { styled } from "@/lib/styles/stiches.config";
import { HtmlConst } from "@/lib/consts";
import type { CSS } from "@stitches/react";
import type { PropsWithChildren, ForwardedRef } from "react";
import type { NextNode } from "@/types/next.d";

// * TODO: This is where if somehow, in the future,
// *      if stitches.dev work more on Static Extraction,
// *      then we might consider changing this.
type StyleProps = PropsWithChildren<{
  // Default style
  style?: CSS,

  // CSS overwrite!
  css?: CSS,

  // Inline style to children
  as?: NextNode,

  // Customize element name
  elementName?: typeof HtmlConst[keyof (typeof HtmlConst)],

  // Other props
  [x: string]: any,
}>;

const StyleWithRef = ({
    style={}, 
    children, 
    elementName=HtmlConst.DIV, 
    ...otherProps
  }: StyleProps, 
  
  ref: ForwardedRef<HTMLElement>
) => {
  // Somehow, wrap an element like this will cause 
  // serverside rendering to include all CSS styles
  // of the generated class during page load in <head/>.
  let CSSWrapper = styled(elementName, style);
  return (
    <CSSWrapper ref={ref} {...otherProps}>
      {children}
    </CSSWrapper>
  )
}

const Style = React.forwardRef<HTMLElement, StyleProps>(StyleWithRef);

export default Style;

Usage:

// ...
const Footer = ({children, ...otherProps}: FooterProps) => {
  return (
    <Style style={FooterStyles} {...otherProps}>
      {AppConfig.DESCRIPTIONS.FOOTER}
    </Style>
  )
}
// ...

I hope this provide as a workaround to someone who wants to build a static website using Stitches.

If you're curious more about this, you can check for more code at: https://github.com/Cryptsu/Cryptsu.github.io, where I generate my static website using this way.

If I understand the situation wrong, please just leave me here :-) Thank you.

[viniarruda]

Interesting think to implement to use jsx with next 13+: https://nextjs.org/docs/app/building-your-application/styling/css-in-js#configuring-css-in-js-in-app

[hennessyevan]

Interesting. I don't know the first thing about this but I'd be down to jump into the styled components implementation for example and see what would be required of stitches here. This is certainly a promising path forward but we still need a maintainer.

[artmsilva]

We have a working example in our project here if anyone wants to take a look https://github.com/washingtonpost/wpds-ui-kit/blob/v2/apps/nextjs14-approuter/src/app/registry.js.

[hennessyevan]

Oh dang, that's great! I'll try that out in our project

nvm... we're using remix 🙈

[colliejs]

I write a css static extract library with stitches like syntax. please take a look. https://github.com/colliejs/colliejs

[berkaytheunicorn]

Arriving a bit late to the party, I've been utilizing Stitches for production apps for a few years now. For me, this has been the best API and the most dev-friendly experience among CSS-in-JS packages (I was using styled-components before). Despite many inquiries, I couldn't find a clear answer: should we continue using this package or not? I'm on the verge of creating a relatively large UI kit in Stitches as always, but this unresolved discussion led me to explore other alternatives like yamagui, unocss, stylex, and panda CSS. My entire day was spent testing, and the result is that "Stitches" still stands out as the best one. At some point, I attempted to create a basic version on my own, only to realize that I ended up using many Stitches features – essentially, there was too much to replicate. Please, let anyone willing maintain it, so we can continue enjoying this amazing invention :)

[wbobeirne]

should we continue using this package or not?

The only person who can decide that is you. There's no inherent reason to stop using a package just because it's not updated or maintained, it's only a problem if it has a bug, library incompatiibility, or a missing feature that inhibits you from what you're trying to do.

Just keep in mind that with the current statements from the maintainers, you shouldn't expect any security vulnerabilities, breaking React changes, new CSS features, or bugs you run into to be addressed in future versions. It's unclear if an API-compatible alternative will come from the community, or if the maintainers will decide to pass it on to a volunteer, so you should make your decision of what to use with that risk in mind.

[feledori]

IMO as long as you don't need server components and keep your app client side there is no real need to change. If you want to keep up with the react ecosystem changes it would be a good decision to search for an alternative.

[sohcfst]

Hi! I'm just a product engineer, but I still believe stitches has the best in class styling API. Where do I start to learn how to write static extraction?

[sohcfst]

or even, how does one even write a styling library? I really want stitches to serve the future but I'm not sure where exactly to begin

[PookMook]

I'm currently building a stitches-style API for static extraction, it's too early to share code but looking promising.
For the static extraction part, I can see 3 viable paths for the moment:

• choose one framework (like nextjs or so) and leverage the static build steps to inject css in (this is what I currently have working after a WE of work, you can see my first working page here https://juchereau-com-git-arthur-movetoapprouter-arthurj.vercel.app/ , still some font flicker but it looks like it's on vercel's side)
• create the bundles with bun and leverage the macro feature https://bun.sh/docs/bundler/macros, it's potentially doable but now you force your users to use the bun bundler, though ask
• inspire yourself from styleX or vanilla-extract plugin systems. This is the most amount of work as you need to create a plugin for every bundler/pre-processor (webpack/vite/etc) but probably the best outcome for a library: https://github.com/facebook/stylex/tree/main/packages

[natew]

@PookMook what would you think is missing from tamagui as a stitches replacement? It does the third option already and has a very close API.

[PookMook]

tamagui is utility class based if I read it correctly.
This is not a question of better or missing, I just think there's value in having the choice to write like a boomer if you choose so (with all the trade-offs that are associated with it)

[sohcfst]

@PookMook thank you so much! i think i have an idea of where to start. i hope all the work we do can lead to the best in class styling solution for react. cheers!

[kijv]

I developed https://github.com/jujitsustudio/sutairu in a short amount of time, which includes the stitches API (with some updates) and static extraction. There is working proof of concept, although some plugins can be buggy. Feel free to take inspiration or even fork it for yourself!

[nixjs]

After searching for other libraries to replace stitches, I found that there is still nothing that can replace it.

[drianoaz]

I have been using https://www.tailwind-variants.org/ and it has served me well. I have no major complaints

[PookMook]

No promises but I have a working prototype of static extraction + something close to stitches (a bit more TS strict oriented). Writing documentation at the moment before pushing.

…

On Sat, Apr 20, 2024, 9:25 AM Nghi Nguyen ***@***.***> wrote: After searching for other libraries to replace stitches, I found that there is still nothing that can replace it. — Reply to this email directly, view it on GitHub <#1149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADMQUH42XJOPXGRIT5RWCGDY6JUGLAVCNFSM6AAAAAAWFXK27GVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNZUGMZTM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[thekidnamedkd]

@PookMook How can I help? 🤩

[gajus]

What's missing in panda css ? It does all of it without any tradeoffs known to me

[paul-sachs]

The limitations on conditional variants is the thing that currently prevents me from migrating to panda-css. Specifically, not being able to use compound variants along with conditional variants.