One of the lead devs on Panda also did Chakra (the React UI component lib). For me, Panda has been great, it's a very nice library to work with, with compiled CSS you get best of both worlds. Type safety and expressiveness of typescript and a clean way to define CSS styles for your components. I believe it works with any JS lib too. There's also a port for the shadcn UI library for Panda: https://shadow-panda.dev/
TIL, thanks for the source! I really liked chakra and used it as influence when writing my own UI library - funny seeing that typo in the readme!
Seems like ‘fannypack’ went to ‘bum-bag’ as its successor. I wonder how much naming has to do with popularity of libraries, and if chakra took off because it was more appealing to larger tech companies. Satirical names never seem to get too big from what I’ve seen.
Seems just like a survivorship/small sample bias to me, I'm sure I've had the thought that it's funny X is used at such and such places with a name like that before.
But such naming is niche, and a new project making it big like that is too. I'm sure it would make for an awkward conversation getting it approved, but ultimately it doesn't really matter does it. Funding/sponsorship on the other hand, I can definitely see it being a consideration.
So not sure what controversy you're trying to stir. Fannypack didn't have dark mode, Accordions, Alerts, Breadcrumbs, responsive containers, and a whole slew of components that Chakra had.
In fact if you look at the Avatar component from Chakra 5 yrs ago vs the Fannypack Avatar you'll see the code is completely different.
Not trying to stir anything. Just posting receipts. The creators of Chakra have a well-documented history of jacking people's stuff without crediting them.
This is definitely a bad look for the Chakra team, but at most it proves that they need to hire a copywriter. I'm not sure I would extrapolate from this that they're stealing code.
Is it actually a fork, or did the creators just copy some of the documentation?
I always thought the biggest influence on Chakra was actually Styled System. I really doubt there's anything nefarious happening here given that the Panda docs have a whole acknowledgement section that lists the projects that influenced it: https://panda-css.com/docs/overview/getting-started#acknowle...
Most of these React styling libraries were influenced by their predecessors. Emotion essentially copied styled components entire api: https://emotion.sh/docs/styled
One thing that bugs me about this (and Tailwind) is the number of dependencies they pull in. Panda has 152 nodes (239, if you count their dev-dependencies)[0].
Tailwind has 98 (594 if you count their dev-dependencies).
I know they're only dev-dependencies, but still... I've got all of that code running on my machine, just to process CSS. I really don't love it.
I don't disagree with the main point here, but the dev-dependencies won't be installed or run on your machine unless you're building Tailwind or Panda itself. They're not necessary for processing the CSS.
None of Tailwind's dependencies ship to your production app. Tailwind is a CSS build system (mostly) so when you build for prod, the only thing that ships to prod is a CSS file.
Is there a way to install only your own dev dependencies?
As far as I can tell installing a package will also pull down all of its dev dependencies. This unfortunately leads to many typescript related annoyances such as jest typescript global types being pulled in despite not needing them.
Panda seems really nice. As someone who does a lot of "creative" CSS work, writing styles quickly is important to me. I find writing styles as Javascript objects kinda cumbersome. I wish there was a way to use Imba's CSS system within a React or other Javascript app. https://imba.io/docs/css/syntax
Imba allows you to write CSS anywhere in a component definition using CSS-like syntax (rather than Javascript object syntax).
The syntax for adding a quick inline style is so simple:
<div [width:20px]>
You can even do hover states in an inline style:
<div [color:red @hover:blue]>
And interpolation is easy too:
<div [width:{someValue}px]>
Putting a CSS block at any level of your tag hierarchy scopes it to that tag.
<div.foo>
<div.bar>
css color:red # this applies to div.bar
em color:blue # this applies to div.bar em
"hello"
<em> "world"
CSS blocks declared in a component definition but outside of the markup, apply to the whole tag. CSS declared in a file, outside of a component definition, apply to all components defined in that file. There is also a global keyword to apply styles globally.
and there's a whole range of other useful features, a favorite of mind is the shorthand syntax for things like this:
c:red # same as color:red
d:vtc # same as display:flex flex-direction:column justify-content:center
x:10px rotate:30deg # same as transform:translateX(10px), rotate(30deg)
I sometimes feel like the one weirdo using jsxstyle (originally by Pete Hunt of React 1.0), but it's been great for me. It's a really simple concept - exposing CSS keys as props:
Works in both React and Preact. It's designed to support generating styles at build time, but I've never bothered. For the sorts of things I work on, being able to quickly bang out a component is more important than golfing the bundle size or maintaining a design system.
jsxstyle feels like I can sculpt in code. It's really satisfying to hammer out some props and see a component come to life, especially when you've got hot module replacement working.
Based on a quick perusal of linked page, Panda seems like perhaps a more mature version of jsxstyle, but also more fidgety. As an army of one, I'm happy to optimize for iteration speed, but if I needed to maintain a system, maybe I'd consider switching to Panda.
It sounds silly, but it feels much nicer to skip the `style = {{}}`.
Plus, they all get their own class names, so it's a bit more efficient than the naked style prop, and if you edit one in DevTools, all its siblings are updated to match.
I've been doing front for 18 years and I've sill not figure out how to maintain code with the HTML dom structure and CSS rules coupling.
Touch either side, you have to understand the entire codependencies, inheritance rules and edges cases to make any predictions on what will actually happen.
You always can do edit/fix fast cycles, but it always ends up complicating initial code while eroding overall quality.
Good practices to make to whole thing predictable generally fails on edges cases.
Long story short, having each attributes defined, used and moved around independently really really simplify the whole experience, without leaving much things to regret.
I have the opposite question: If you are already using templating/components, why would you want to use something like CSS in the first place? I do not find it to be an effective tool, at all. It is an optimization on dimensions that do not really matter to me, and a pessimization on the dimensions that do matter, a lot.
You’re going to use CSS anyway because that’s how things are styled
Essentially the discussion is around how should you use it
- define it as inline attributes on individual elements
- use some thing like Andy Bell’s CUBE approach to define styles for layout and components
With something like Andy’s approach you’ll end up with far less CSS, it’ll adapt to devices and you won’t actually have to write much CSS for new components
> You’re going to use CSS anyway because that’s how things are styled
I am speaking in principle. Im am not even sure if inline styles are correctly referred to as CSS, as there is no cascading and no sheet. Aren’t they just styles?
With templates/components, I do not find myself writing a lot of style code at all, plus they remain more composable. The segregation into CSS, despite its inevitable coupling to the structure of the document, has no value to me.
I also do not buy the adaptation argument. I can adapt in code just fine, in fact it is necessary because proper adaptation needs more than just styling.
There's definitely a subjective element to authoring CSS, so I'm glad people have options.
That being said, one of the things Tailwind got right is that it's even faster to type out than normal CSS _or_ JS objects.
When you know what you want from Tailwind you write it and see it very quickly. Subjectively, there would have to be some very strong benefits to get me to go back to writing plain CSS rather than a bunch of class names.
This take varies greatly depending on the user's experience.
I can knock out a responsive grid layout taking advantage of pseudo elements and :is() selectors quickly with CSS. Doing so with Tailwind is a nightmare for me, I end up searching docs for classes for every style I want and combinatorial classes for pseudo selectors will never click for me...why bother when simple things like spaces before a :has() selector or `margin-block` isn't even available?
This is a… super niche case but if you insist, you can use the @apply syntax to use tailwind inside a css file to save time and typing. Then they have an extension for vscode that does autocomplete and shows you the css of each shortcut.
It may just be how I structure layouts, but in 10+ Tailwind projects I've worked on I've never been able to avoid escaping TW at times and using @apply or directly styling with CSS selectors.
Some things just don't work well or at all in a class-based utility system. There's nothing wrong with that, but personally I'd rather stay with one styling paradigm and avoid having to decide when to break out of the "do everything in utility classes" model. The context switching isn't worth it for me and I still lose the benefit of colocation.
Agreed that grid styling works better in plain CSS, but that's often only a small amount of the CSS a site needs in my experience. You can write grid in a normal class and then write all your other styles inline via classes.
I get that react didn't really have a clean answer for styling, but that's more a reason to not use react than a reason to invent a new DSL for styles on the web.
In my experience most don't though, I usually see importing a plain .css file traded as a code smell. That may very well be a limitation of the projects I've worked on, but they have all ended up using Tailwind or a build-time tool for CSS-in-JS or CSS modules.
That's where it may get a little too pedantic, but I'll try. I do consider CSS modules using CSS as a DSL, but I don't consider it as using CSS the browser spec.
CSS modules still run through a build and bundling step which, in my opinion, kicks it out of the "I'm just using CSS" camp.
React has so many solutions for this- I wonder, is there anything that works similarly to Vue scoped styles? I always struggled with styling React but it's like a completely solved problem in Vue imo. You're welcome to use Tailwind of course but the scoped styles per-component work so well I rarely find myself missing it.
Then again I'm one of those few engineers who actually enjoys CSS so my opinion may not be representative.
And it's not hard to get them working in Webpack...if you're like me.. maintaining the same app for 10 years and see no reason to switch to the new hotness.
Css modules would be great, except there’s bad tooling in VSCode. Autocomplete through Typescript is the killer feature of Panda / Vanilla extract, not that you can style.
For a long time React was advertised and regarded as "just a UI library", so not having anything bundled with it was a conscious design decision.
End result is that you have an average of three popular solutions for stuff that's normally already included in other frameworks and no two React projects are the same.
React is a small general-purpose reactive rendering library. Everything else is outside of its scope, including anything pertaining to DOM, CSS, and so on.
If you want something less flexible, more opinionated, restricted to rendering in DOM but with more respective batteries included (such as styling, etc.), you should look at a framework instead. Some popular examples are Gatsby, Next, Docusaurus, etc. (Non-React alternatives in the same category include Vue and Svelte.)
The front end went into shit when we started shoving html+js in one file, now it will be worse having all three in one.. I don’t understand why is it too hard to keep these three files separated?! Look at the example code, total junk!
Web development has a long history of cargo culting “best practices”. IMHO separating markup from code is a holdover from progressive enhancement. That ship has sailed in most web apps.
This looks very similar to Vanilla Extract, the API of Panda is exactly the same DX I had using it with React, but I still ended up jumping on the Tailwind bandwagon because I find it just gives me a slight extra boost in productivity and speed, especially when prototyping.
The site is trying to load a script that is failing: https://plausible.io/js/script.js
Maybe it’s related… training contents (page Learn) do not seem to work.
That's a tracking script, might be failing due to your adblocker or other privacy tool.
Learn page appears to work fine for me, while blocking plausible.
It’s like tailwind except that you get type definitions and don’t need to memorize a bunch of random Tailwind specific shorthands. I particularly like it since I can compose styles robustly while not losing the visibility of what the actual HTML is in our UIs since we don’t need to make wrapper components. It’s agnostic to the underlying framework, is built at compile time meaning very light runtime JS impact, and basically the best solution I’ve found.
I lean towards simple stylesheets. Plain. Classic. No preprocessor required. No build. Something like Tachyons, Bootstrap, W3CSS, Foundation you name it.
One less architectural component to maintain, update, upgrade, migrate etc.
We continue to over engineer solutions around a key/value struct to make a div blue.
Modern frontend is increasingly depressing. Don't get me wrong, there are lots of great things that solve real engineering problems, then there are things that really don't solve a real problem.
but there are real problems with vanilla css. Tipically as a project grows in size you want to be able to abstract something, and avoid a random selector causing havoc in an unrelated part of the application.
ah, another attempt of how to make something simple, easy and elegant like css and turn it into a convoluted mess that will evolve into maintenance hell real quick. I can see the good intentions, and it will work initially, but I wouldn't want to be involved in something mature that uses this (or other similar) tooling.
Pendulum seems to be approaching max displacement position with this weird ass convoluted mess - probably sooner or later we'll start to spot sites with names like you-actually-dont-need-css-in-js.com akin to their js-related counterparts.
For anyone who is looking for UI library that's compatible with Panda, I highly recommend https://park-ui.com/ By far the most polished and actively developed. I am building a second project using it.
67 comments
[ 2.9 ms ] story [ 135 ms ] threadSource: https://github.com/segunadebayo/chakra-ui/blob/master/README...
[1]: https://github.com/jxom/fannypack/blob/c7046c5f58cc68ee756be...
Seems like ‘fannypack’ went to ‘bum-bag’ as its successor. I wonder how much naming has to do with popularity of libraries, and if chakra took off because it was more appealing to larger tech companies. Satirical names never seem to get too big from what I’ve seen.
But such naming is niche, and a new project making it big like that is too. I'm sure it would make for an awkward conversation getting it approved, but ultimately it doesn't really matter does it. Funding/sponsorship on the other hand, I can definitely see it being a consideration.
See top of readme: https://github.com/jxom/bumbag-ui
So not sure what controversy you're trying to stir. Fannypack didn't have dark mode, Accordions, Alerts, Breadcrumbs, responsive containers, and a whole slew of components that Chakra had.
In fact if you look at the Avatar component from Chakra 5 yrs ago vs the Fannypack Avatar you'll see the code is completely different.
https://github.com/segunadebayo/chakra-ui/blob/master/src/Av...
https://github.com/jxom/fannypack/blob/c7046c5f58cc68ee756be...
The most likely story is he was just using Fannypack's docs as a reference for how to format his own.
"Build your next idea even faster."
https://tailwindui.com https://pro.chakra-ui.com
I always thought the biggest influence on Chakra was actually Styled System. I really doubt there's anything nefarious happening here given that the Panda docs have a whole acknowledgement section that lists the projects that influenced it: https://panda-css.com/docs/overview/getting-started#acknowle...
Most of these React styling libraries were influenced by their predecessors. Emotion essentially copied styled components entire api: https://emotion.sh/docs/styled
One thing that bugs me about this (and Tailwind) is the number of dependencies they pull in. Panda has 152 nodes (239, if you count their dev-dependencies)[0].
Tailwind has 98 (594 if you count their dev-dependencies).
I know they're only dev-dependencies, but still... I've got all of that code running on my machine, just to process CSS. I really don't love it.
[0] https://npmgraph.js.org/?q=%40pandacss%2Fdev
I am not arguing for using sass, et al, but CSS preprocessors still have their place for those who wish to utilize them.
How much do they care about simplicity, bloat, efficiency, security? The number of dependencies is a signal. Maybe not an important one, though.
As far as I can tell installing a package will also pull down all of its dev dependencies. This unfortunately leads to many typescript related annoyances such as jest typescript global types being pulled in despite not needing them.
Imba allows you to write CSS anywhere in a component definition using CSS-like syntax (rather than Javascript object syntax).
The syntax for adding a quick inline style is so simple:
You can even do hover states in an inline style: And interpolation is easy too: Putting a CSS block at any level of your tag hierarchy scopes it to that tag. CSS blocks declared in a component definition but outside of the markup, apply to the whole tag. CSS declared in a file, outside of a component definition, apply to all components defined in that file. There is also a global keyword to apply styles globally.and there's a whole range of other useful features, a favorite of mind is the shorthand syntax for things like this:
I've considered porting it to JS into a Vite plugin so the same syntax can be used anywhere else. I would have done it already if I had the time.
jsxstyle feels like I can sculpt in code. It's really satisfying to hammer out some props and see a component come to life, especially when you've got hot module replacement working.
Based on a quick perusal of linked page, Panda seems like perhaps a more mature version of jsxstyle, but also more fidgety. As an army of one, I'm happy to optimize for iteration speed, but if I needed to maintain a system, maybe I'd consider switching to Panda.
https://www.npmjs.com/package/jsxstyle
Can you just use inline style in this case ?
Plus, they all get their own class names, so it's a bit more efficient than the naked style prop, and if you edit one in DevTools, all its siblings are updated to match.
Better off learning CSS and using it more effectively rather than single attributes
Touch either side, you have to understand the entire codependencies, inheritance rules and edges cases to make any predictions on what will actually happen.
You always can do edit/fix fast cycles, but it always ends up complicating initial code while eroding overall quality.
Good practices to make to whole thing predictable generally fails on edges cases.
Long story short, having each attributes defined, used and moved around independently really really simplify the whole experience, without leaving much things to regret.
Essentially the discussion is around how should you use it
- define it as inline attributes on individual elements - use some thing like Andy Bell’s CUBE approach to define styles for layout and components
With something like Andy’s approach you’ll end up with far less CSS, it’ll adapt to devices and you won’t actually have to write much CSS for new components
I am speaking in principle. Im am not even sure if inline styles are correctly referred to as CSS, as there is no cascading and no sheet. Aren’t they just styles?
With templates/components, I do not find myself writing a lot of style code at all, plus they remain more composable. The segregation into CSS, despite its inevitable coupling to the structure of the document, has no value to me.
I also do not buy the adaptation argument. I can adapt in code just fine, in fact it is necessary because proper adaptation needs more than just styling.
but since using tailwind, i far prefer this
class="bg-red-500 hover:bg-blue-500 mx-4 my-12 p-4"
That being said, one of the things Tailwind got right is that it's even faster to type out than normal CSS _or_ JS objects.
When you know what you want from Tailwind you write it and see it very quickly. Subjectively, there would have to be some very strong benefits to get me to go back to writing plain CSS rather than a bunch of class names.
I can knock out a responsive grid layout taking advantage of pseudo elements and :is() selectors quickly with CSS. Doing so with Tailwind is a nightmare for me, I end up searching docs for classes for every style I want and combinatorial classes for pseudo selectors will never click for me...why bother when simple things like spaces before a :has() selector or `margin-block` isn't even available?
Some things just don't work well or at all in a class-based utility system. There's nothing wrong with that, but personally I'd rather stay with one styling paradigm and avoid having to decide when to break out of the "do everything in utility classes" model. The context switching isn't worth it for me and I still lose the benefit of colocation.
Best of both worlds IMO.
I get that react didn't really have a clean answer for styling, but that's more a reason to not use react than a reason to invent a new DSL for styles on the web.
CSS modules still run through a build and bundling step which, in my opinion, kicks it out of the "I'm just using CSS" camp.
Then again I'm one of those few engineers who actually enjoys CSS so my opinion may not be representative.
And it's not hard to get them working in Webpack...if you're like me.. maintaining the same app for 10 years and see no reason to switch to the new hotness.
Why does react makes this the developer’s problem to figure out? It feels a bit like a missed opportunity.
For a long time React was advertised and regarded as "just a UI library", so not having anything bundled with it was a conscious design decision.
End result is that you have an average of three popular solutions for stuff that's normally already included in other frameworks and no two React projects are the same.
If you want something less flexible, more opinionated, restricted to rendering in DOM but with more respective batteries included (such as styling, etc.), you should look at a framework instead. Some popular examples are Gatsby, Next, Docusaurus, etc. (Non-React alternatives in the same category include Vue and Svelte.)
Modern frontend is increasingly depressing. Don't get me wrong, there are lots of great things that solve real engineering problems, then there are things that really don't solve a real problem.
CSS is neither of these.