Replacing Goober with something else #40
Comments
|
Yeah great discussion topic. I did pick Goober on size, and not much else. I'm not so much a CSS in JS person and I was just trying to check the boxes. Definitely interested to hear thoughts. |
|
Streamich, the creator of React-Use (useCss) also the creator of FreeStyler may have created but mentioned CSS in JS Generations, I really like his approach to the situation but I would like to add more to it. I imagine that Solid Styled Components was made to look like React Styled Components, mommy said never judge a book by its cover but I'm doing it now. I was going to do some benchmarking because it is of my interest to really know which CSS in JS Libraries is the best, but just noticed how incorrect the results would turn out. To help a little to the research I've made a list of CSS in JS Libraries (From most star count to less star count), here's the list: Styled Components (37.6k Stars) - 4th Generation My personal recommendations for some libraries would be nano-css, fela and free-styler. Glory has made a benchmark to test CSS in JS libraries, this benchmark shows a lot about Fela's performance over Goober, Emotion and Nano-CSS. There's a lot of differences also in the way the CSS is implemented in the page, some use CSSOM, some use single style tag injections while others use multiple style tag injections (better for 5th gens while worse for 3rd gens). CSS in JS is a whole world where everyone's trying to grab a little of performance in something. The way I do it in my personal projects are to use nano-css or any 5th generation performant library and implement my own theme system on top of it, using styled-system Styled Props, I love them. |
|
That's a lot of great alternatives. Thank you! @phiberber I ran into this amazing thread when realized that |
|
I'm far from understanding the whole landscape of CSS-in-JS, but so far, |
|
There's a problem with zero runtime css-in-js that's it has no runtime at all. Dynamic styling is pretty limited because of that, I would recommend Solid-styled-components to look like and act like styled-components, which has a runtime and allows any kind of dynamic prop. That's why all the recommendations I've made are libraries with runtime. This project probably only exists to extend the Solid ecosystem, that has no problem at all, the problem is making an unpredictable library. Don't get me wrong, Linaria is really good, but it's not a perfect replacement for styled-components nor goober. One thing that I had never seen before was an adapter css-in-js system, where one could use the same API with different libraries, just like deploy adapters, if that were the case, I would agree in supporting Linaria. About the CSS files, it's a big problem that static CSS is generated in runtime when SSRing. I'vent noticed any library yet that allows static css extraction while still running with runtime dynamic styles. Nano-css does have a really good implementation of static vs dynamic styles, but I don't think that would be enough to work with. It has always been a thought of mine of creating such library, which through partial evaluation is able to determine dynamic styles, in-line static styles and extract them to pure css at build time, while then only delivering the JS of the dynamic styles. I've tried to do that once, but the babel's partial evaluation system had some big problems. I would be up to help creating such library, but I don't think that's what @ryansolid is planning to this SSC. That's why I still keep my recommendations. |
|
I would also like to add, Solid Start is implementing the Islands Architecture. In my opinion not only Islands are something hard to achieve with a good level of DX by it own, but implementing CSS-in-JS using Islands always turned out to be a mess (to me). I don't think this project is a serious project. I know it's here to be used, but it has been shown that Ryan is not focusing on SSC. I think SSC exists only because Solid needs ecosystem, Ryan is then trying to deliver that fast, at the cost of using making bad decisions (goober). If this project were to be serious, I would suggest discussing about the following topics:
It's a lot of discussion and it's all related subjects. Should this be all discussed here in this thread? The islands problem does have a big effect in which library to replace Goober with, being like Styled Components too. I'm really unsure about the future of this issue, it can go to amazing places, it can turn into a mess. |
|
It is also good to mention. Solid Styled Components is currently being used along Styled-System by some people. There's even an issue about it solidjs/solid#148. When thinking of a goober alternative, it would be good to check for the compatibility of that x library with Styled-System. I'd also like to know about @ryansolid's opinion on this, it may be too late to change libraries, I'm not in the position to say that though. |
|
The only advantage of goober is it size. Class generation is wrong, it not respecting nesting of class and their relations. This is related to recently opened issues: solidjs/solid-styled-components#7, cristianbote/goober#397 There is very very simple example, where this library totaly fails. It was very hard to debug and to find this. I have spent a lot of time to find the issue in my components styling. And there was no issues, styling was perfect, but goober thinks different and broke everithing. Before you try this example, try to guess the style of all 4 components, on parent element hover. const ChildA = styled("div")``;
const ChildB = styled("div")``;
const ChildC = styled("div")`
color: yellow;
`;
const ChildD = styled(ChildC)``;
const Parent = styled("div")`
&:hover {
${ChildA.class} {
color: red;
}
${ChildB.class} {
color: blue;
}
}
`;
export const App = () => {
return (
<Parent>
<ChildA>ChildA</ChildA>
<ChildB>ChildB</ChildB>
<ChildC>ChildB</ChildC>
<ChildD>ChildB</ChildD>
</Parent>
);
}; |
I think the best option is Linaria or any Zero-runtime library for css-in-js, in fact there is a PR for solid integration in Linaria repo |
|
@azuwo quoting #40 (comment) from above:
|
Like I've said and has been quoted. Solid-Styled-Components should in my strong opinion look and act like Styled-Components. I would recommend a Solid-Styled library to be created to support multiple CSS in JS adapters, which is the idea I've already mentioned here. Then Linaria would really be a good option as an adapter. I agree that the only good factor of Goober is its size. |
|
@ryansolid Can this issue have your attention? It makes no sense using Solid which is one of the fastest frameworks along with Solid-Styled-Components currently. SSC uses Goober which has been shown to have serious performance issues when updating styles (Like changing from Light theme to Dark theme). |
|
@phiberber I made something you can add to your CSS-in-JS tier-list :P |
Cool idea. I see it is in maintenance mode now. Do you have a better alternative? |
I switched to unocss |
As there is no discussion tab in this repo, I think an issue would be appropriate.
Goober may be very small, having CSS in JS in 1kb gzipped is amazing, but it may not be good to use in big projects. In andreipfeiffer's CSS in JS Goober Analysis he mentions how inefficient Goober can be for dynamic styles.
Not only that but Goober does not allow Atomic CSS, when an update is made to the stylesheet, not only it seems to duplicate, but it seems to duplicate the whole rule, even for things that haven't been changed at all. Here is a CodeSandbox sample that demonstrates this behaviour.
The 1kb promise may look good to the eyes, but I think that behind there's a very unoptimized library that in the end, suffers from being optimized as it is only 1kb.
How easy would it be to replace Goober in the internals of Solid-Styled-Components?
Has anyone built something in production with SSC that's scalable?
There's some examples that I can give of alternatives to CSS in JS but I would like to first hear your opinion about it.
The text was updated successfully, but these errors were encountered: