This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Chat about the future for stitches #1144
Comments
|
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? |
|
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. |
|
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. |
|
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! |
|
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 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. |
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. 👍 |
|
Hey :) I used 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! |
|
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 💪🏼 |
|
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? |
|
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. |
|
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). |
|
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 |
|
@StephenHaney I am the co-author of styled-jsx, if anybody is willing to fund these efforts I could help |
|
FWIW I made box-extractor that could (also) help on the static extraction part using the first example (a bit reduced to avoid spamming too much) in the docs import { styled } from '@stitches/react';
const Button = styled('button', {
backgroundColor: 'gainsboro',
fontSize: '13px',
'&:hover': {
backgroundColor: 'lightgray',
},
});here's what the output would look like [
{
"name": "styled",
"box": {
"stack": [
"CallExpression"
],
"type": "list",
"node": "CallExpression",
"value": [
{
"stack": [
"CallExpression",
"StringLiteral"
],
"type": "literal",
"node": "StringLiteral",
"value": "button",
"kind": "string"
},
{
"stack": [
"CallExpression",
"ObjectLiteralExpression"
],
"type": "map",
"node": "CallExpression",
"value": {
"backgroundColor": {
"stack": [
"CallExpression",
"ObjectLiteralExpression",
"PropertyAssignment",
"StringLiteral"
],
"type": "literal",
"node": "StringLiteral",
"value": "gainsboro",
"kind": "string"
},
"fontSize": {
"stack": [
"CallExpression",
"ObjectLiteralExpression",
"PropertyAssignment",
"StringLiteral"
],
"type": "literal",
"node": "StringLiteral",
"value": "13px",
"kind": "string"
},
"&:hover": {
"stack": [
"CallExpression",
"ObjectLiteralExpression",
"PropertyAssignment",
"ObjectLiteralExpression"
],
"type": "map",
"node": "ObjectLiteralExpression",
"value": {
"backgroundColor": {
"stack": [
"CallExpression",
"ObjectLiteralExpression",
"PropertyAssignment",
"ObjectLiteralExpression",
"PropertyAssignment",
"StringLiteral"
],
"type": "literal",
"node": "StringLiteral",
"value": "lightgray",
"kind": "string"
}
}
}
}
}
]
},
"unboxed": [
"button",
{
"backgroundColor": "gainsboro",
"fontSize": "13px",
"&:hover": {
"backgroundColor": "lightgray"
}
}
]
}
]it basically wraps ts-morph and extract only the relevant part, while keeping track of the ts-morph's can extract both jsx components & functions calls, just need to pass the names |
|
I don't want to spam but saw macaron mentioned here — I am the author of Macaron, a zero-runtime css-in-js library highly inspired by Stitches, with a very similar API. I would be happy to share my insights and contribute to this to some extent. |
|
@Mokshit06 I think that the work done in Macaron would be a good way to start adjusting Stitches for CSS extraction, vanilla-extract sprinklers may fit the purpose of variant props, I'd expect Stitches to work as the connector to the design definitions and pass it to extractors that would allow not only css but different usages of those styles. For instance I would love to make stitches available in canvas. I'd be more than happy to team up and bring it to Stitches, what do you think? |
|
One thing I noticed with macaron is that you need that |
I actually appreciate the clear separation of concerns. However, since I am dealing with strings on my makeshift solution, what i did is that the second argument of Hey, @Mokshit06, since you are here, how does Macaron handle responsive variants? |
|
Hey, @StephenHaney I am Stitches library believer and supporter, I have also introduced stitches in my organization and they loved the variants API specifically. I have a background in static analysis in JavaScript while working on a static analysis engine from scratch. I am not sure where I can help but I would love to work with you all. |
|
@ivanbanov Macaron already has variants, so can you explain what do you mean by "variant props"? sprinkles is a very different approach than stitches and macaron, but yeah making a lower-level static extractor that can be shared by these does sound like a good idea. @lucastobrazil The main reason for that is that base styles allow to set pre-existing classes as base styles: const Button = styled("button", {
base: "my-button",
variants: { ... }
})I don't think this is possible if this is just a flat object, but I am open to allowing both @jpmaga Macaron doesn't handle responsive variants currently, but if I understand correctly, the reason they were causing to be an issue was that they were explosive in size and created too many unused styles. I think it would be possible to keep responsive variants while not generating unused styles if we use @astahmer's box-extractor inside macaron though |
that's pretty much the main goal of box-extractor 😄 if you consider it as a potential solution, I recommend looking at the tests since there's no docs atm, I'd also be happy to help if you have any questions |
Haven't looked into the implementation properly, but does it replace the node as well or just provide the ast for the node with all the references etc? eg Macaron extracts the definition to a virtual file and replaces the declarations with an import to the virtual file. Then this virtual file is evaluated at build time |
|
then there's |
|
A few quick updates:
|
|
Seeing if I can lend my design skills here... How about we continue the discussion by fleshing out what we know of the problem(s) to solve? I'll start:
I'm sure I've missed a lot here - either in the detail or other problems to solve, it maybe this is a starting point! Feel free to copy / extend upon what I've got here everyone - and remember - no need to start taking about solutions just yet - let's be sure we're all on the same page about the core problems to solve first :-) |
|
Thanks for organizing Lucas!
One thing that'd be useful, if someone has time, is to actually confirm that injection order really does break when using Streaming SSR. My understanding theoretically is that streaming could inject styles in the wrong order but I haven't actually seen it happen (@hadihallak do you have any insight?) |
Related issues |
|
FWIW, we do not have a huge issue with SSR streaming, when we just extract the styles, however, the biggest problem with streaming is with dynamic However, the problem is here, that in the future (or even currently transitioning) the Next.js compiler is being used (swc) and we might need to add a babel plugin, and a swc plugin. Am I seeing something wrong here? |
|
@StephenHaney I haven't personally used Stitches with React 18 so I can't speak precisely on how frequent these injection issues are going to be but in theory I believe that Stitches will be more susceptible to injection issues because it tries to optimize the css output and needs to control the injection order more than other libraries. |
|
Hope everyone's having a great week! Any ideas on how we might move this discussion forward? Do we need any POC work or anyone putting their hand up to shed light on the React 18 injection stuff? |
|
And out of curiosity - is there any particular file or function in stitches source code that the overall issue is centred around? Like I'm wondering how much of the peripheral code / dx related stuff is actually affected by whatever we'd need to change, or if it's more a matter of just "swapping out" a portion of stitches. |
|
Is this scheduler helpful? Perhaps we could define an agenda ahead of time, but even meeting casually could precipitate a more nuanced working group. |
|
After this conversation sparked, I've been paying attention to all the alternatives that were mentioned, and https://tamagui.dev/ stood out as near identical replacement to Stitches in terms of the API while already achieving everything that is being discussed here. Other mentioned libraries have similar APIs as well. Is there even a need to continue the efforts of maintaining Stitches when the vast majority of users (it seems) would benefit from switching to one of the alternatives? I fully get that it is less than ideal outcome, esp for the original maintainers of the project. Stitches impact on the ecosystem cannot be overstated – it is clearly visible in all of the mentioned projects. However, duplicating efforts is not going to benefit the community overall. |
I've never heard of I've stumbled upon this codepen that apparently uses SWR and async/dynamic imports to curb that. Which makes me think that we could come up with at least a "workaround" for SSR-streaming so that we don't have to migrate to other frameworks, resort to CSS/SASS modules & Would be nice to keep using I guess the "ability to write plain CSS (or even atomic) that can be used without |
I agree, I first learned about tamagui yesterday from that comment, went to site and became so obsessed with how good it seemed to be that I read the entire documentation. However, when I then tried to setup I could not manage to get a basic client only version of it working, at least on nextjs 13. It's not clear at all when to use tamagui, @tamagui/core, or @tamagui/web. I didn't want any of that react native stuff but it keep throwing errors requiring react-native dependency. Stitches, by comparison, is much easier to setup and reason about. The api of tamagui seems superior with variants, functions, and a stronger type system, but its harder to setup. I think the continuation of stitches would be a net benefit for the community. |
|
Just want to say I didn’t mean for all the Tamagui talk to happen here (nor encourage it), I actually think Stitches focusing on the web has some big advantages for web only use cases and it’s inherent beauty and design and ecosystem means it’s clearly worth continuing to build! @55Cancri I think you popped into the discord. Sorry to hear about some of your troubles. I’ll keep working with you there to fix them. |
|
Quick update: I've had chats with a few people who are interested in taking the reins but nothing has firmed up yet. Just speaking for myself, React 18 and Next 13 feels like a new moment of change in the ecosystem. If the ultimate answer is that a new library emerges to take advantage of static extraction and SSR streaming use cases – and Stitches helped to move the API design forward – I'd count that as a good thing. |
|
Thanks for the update @StephenHaney ! So where does that put us now? Ie should we wait to hear how thing "firm up" before moving forward on any of the thinking above? Having a committed maintainer / leading voice in this is gonna be pretty crucial / impactful so I guess it's worth the wait if things might come to fruition in your chats with these people :) |
|
Hard to say, but I think we should keep any positive momentum up. If someone emerges, that'd be great, but I don't think we should plan for it (it's been about 3 weeks since this post went up). |
|
Hi! Coming at this from a completely different use case. We have slowly adapted Stitches in a new internal designsystem. We use native web components without shadow dom (because stitches doesn't support it), rendered on server or in client. We have only been using Stitches Core (and Stringify). We are not interested in React 18/NextJS 13 support nor static extraction (the stringify package is pretty much enough). Would love to work more on the core package though, but it might take it in a completely different direction to what is envisioned for React 18/NextJS 13 support. |
|
Just asking here: Where do we see the major pain points? I mean, static extraction could be done "easily" with the help of the If we would get together a task/painpoint list, it would be awesome I think. At least me (for @fintory) would be interested in tackling some points and contributing onto the switch to something for server rendering for stitches. |
|
@StephenHaney Would you mind transforming this issue into a discussion, so we could better "reply" to others? (Edit: Perhaps also pinning this issue/discussion would be helpful I think). |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
and others
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. 🖤
The text was updated successfully, but these errors were encountered: