
Chakra UI – Modular and accessible UI components for React apps - jhabdas
https://chakra-ui.com
======
tony
Use it on a few websites
([https://www.hskflashcards.com](https://www.hskflashcards.com),
[https://parataxic.org](https://parataxic.org)). Like it.

\- TypeScript

\- WAI ARIA / a11y for accessibility

\- Passthrough styling props via Styled System: [https://styled-
system.com/](https://styled-system.com/)

\- Passthrough responsive conditional props: [https://chakra-
ui.com/responsive-styles](https://chakra-ui.com/responsive-styles)

\- Light / Dark: [https://chakra-ui.com/color-mode](https://chakra-
ui.com/color-mode) (but it doesn't work on Gatsby: [https://github.com/chakra-
ui/chakra-ui/issues/305](https://github.com/chakra-ui/chakra-ui/issues/305))

\- I eschew some of the helper components like <Flex>. You are fine just using
plain old Box as the shorthand props in Flex component don't add much. You can
just pass display="flex" into a Box.

\- Passing hover/active styling requires using PseudoBox (or a component
deriving from it), so <Box> \- or anything built on top of it - can't have
hover colors directly. This means configuration for some components require
additional wrappers

\- Active! [https://github.com/chakra-ui/chakra-ui](https://github.com/chakra-
ui/chakra-ui)

\- Author is very courteous (if my limited interaction with him on the tracker
is any indicator!) If you use Chakra and like it, you can support the creator
via
[https://www.patreon.com/segunadebayo](https://www.patreon.com/segunadebayo)

~~~
founderling
What does it give you over simple server-side rendered templates?

~~~
tony
Chakra UI is a widget toolkit, so it's not on the same level of comparison.

React will use JSX and can use all the cool new JS stuff, e.g. module imports,
template literals. With webpack there's automated code splitting. The
toolchain is under very active development (from react, to webpack, to babel,
to new dependencies I've never heard of - aside: a downside is the dependency
graph in node can be crazy)

If your site is simple enough, server site templates will do. For anything
non-trivial, where there's a lot of reusability and its very async / API
heavy, the benefits shift dramatically to including a frontend framework.

Regarding server side templates, there's limitations to how far templates
engines (e.g. django templates / jinja2) can take you. Extending templates
works when done carefully, as does overriding blocks. Anything non-trivial
becomes very hard to manage - there's no type safety, setting variables is
burdensome.

On parataxic, there's no server. It's all static files served from cloudfront
via Gatsby (to get an idea of this:
[https://jamstack.org/](https://jamstack.org/))

------
xmorse
I use this library for basically all my projects now, i have tried many
component libraries but this is the one I am most productive with

The idea of using atomic css properties is similar to the tailwind philosophy
but there is no need to purge the css and you get typescript completion and
validation

------
kamranahmed_se
I work with Segun (the creator of Chakra UI), super cool and down to earth
dude. I love that Chakra UI is getting some attention. We have been using it
in all our production applications and couldn't be happier. I also just
finished creating a short project-based video series on Chakra UI and React
yesterday. Have a look if anyone is interested
[https://www.youtube.com/watch?v=NyG7YJWJd6s&list=PLkZYeFmDua...](https://www.youtube.com/watch?v=NyG7YJWJd6s&list=PLkZYeFmDuaN3NDLnBG01-sH2-nwn43mYu)

------
catlifeonmars
I’m not sure exactly what’s going on, but I noticed in iOS Safari (iPhone 11,
iOS 13.5.1), the components get progressively less responsive while browsing
the components. After switching to a few component menus, for example, the
button presses take ~1s to start animating. Reloading the page appears to
reset the responsiveness to normal.

~~~
eis
In my Firefox on a Macbook the animations seem janky. The toast example does
not work at all. When something like the drawer opens, the main content part
of the page jumps and moves to the side a bit only to jump back when the
drawer gets closed. On every page there's an empty light blue box at the top
which just wastes space and makes me scroll.

That being said, many of issues don't seem to be present in the Vue version
linked in another comment. Though even there some animations are not smooth
and for example the up/down arrows on the slider number input just don't work.
And for something that's supposed to provide a unified UI the styles between
React and Vue versions are totally different, even the font size and weight.
That slider number input that I mentioned looks completely different: shapes,
positions, colors etc.

Too many issues for my taste. Unfortunately that seems par for the course with
many frontend frameworks.

------
feross
Really happy that Chakra UI is getting some attention here.

I interviewed the creator, Segun Adebayo, on the JSParty podcast here:
[https://changelog.com/jsparty/125](https://changelog.com/jsparty/125) You
couldn't meet a friendlier maintainer. The fact that he's only been
programming full-time for 6-7 months makes Chakra UI even more impressive.

I used it to build my recent side project, Virus Cafe
([https://virus.cafe](https://virus.cafe)) (Show HN:
[https://news.ycombinator.com/item?id=23408144](https://news.ycombinator.com/item?id=23408144)),
and it's been an absolute joy to work with.

------
thomasfedb
The component I always look for in these libraries is a date picker (and also
a time picker). I've never found one that actually works well on desktop and
mobile and can be used with a keyboard.

~~~
santialbo
I have mixed feelings about more advanced components like datepickers because
they always make quite opinionated choices:

\- do they use moment, date-fns, ?

\- do they favor an easier and rigid API or a more complex but customizable?

\- do they allow custom i18n? Most of the ones you find out there have English
hardcoded in.

All of these reasons usually make me go the route of building my own one.

~~~
chank
Honestly though. Every third party framework or component you use is going to
have an opinion. Your only choice is if that opinion aligns with yours or not.

------
dubcanada
There is also [https://vue.chakra-ui.com/](https://vue.chakra-ui.com/) a Vue
version.

~~~
McPepper
Thank you for noting it out! (a Vue developer)

------
JMTQp8lwXL
What is the threshold for UI component libraries describing themselves as
"accessible"> Is it running through automated tools, such axe, is it an audit
by an independent third-party group, or is it manual testing by actual users
who regularly use screen reader tools?

~~~
snide
I don't work on Chakra, I lead the team that builds Elastic's design
library[0]. We take accessibility pretty seriously. In general this means:

\- We make sure tab order and keyboard control is a equal level citizen.

\- All our colors and palettes are backed by math, both for contrast and for
color blind qualitative comparison.

\- We build using semantic HTML and try to to avoid abstracting things like
input controls and labels with too much magic.

\- We test and build for screen reader support at the component level and then
provide helpers for navigation. Usually, given the complexity, this means a
decent mix of native html, aria, and hidden text to make things read
correctly.

We do have some automated axe testing, but in all honesty, axes only gets the
surface level spec and might cover 30% of what you need. The rest is really
hand touched, backed by pretty strict review.

In general the bigger frameworks like ours are getting better at this stuff,
but it's still fairly poorly considered in the industry overall. The specs are
pretty verbose and poorly standardized against browsers. This make it very
much like building a traditional visual frontend during the browser wars of
the 2000s (I was there!).

Third party audits are normally done on the products themselves (in our case
Kibana), not the framework itself. This ends up being an indirect method of
auditing the framework though.

All our work is open source and documented. If you have any questions, please
ask away. I love this stuff and web UI has been a 20-year passion for me.

[0]: [https://elastic.github.io/eui/#/](https://elastic.github.io/eui/#/)

~~~
cheald
Can you elaborate on the tools you use to do color selection?

~~~
snide
Mostly it's a combination of tools. We write a lot of custom color functions
(using Sass). You can check the src here[0]. A common one we'll use is
makeHighContrastColor(), which given two colors will automatically make the
first one a 4.5 AA accessible contrast by adding tint/shade.

For palette generation, we do a lot of our work with tools like chroma.js[1]
which can help with some colorblind math.

[0]:
[https://github.com/elastic/eui/blob/master/src/global_stylin...](https://github.com/elastic/eui/blob/master/src/global_styling/functions/_colors.scss#L64-L130)

[1]:
[https://gka.github.io/palettes/#/9|s|00429d,96ffea,ffffe0|ff...](https://gka.github.io/palettes/#/9|s|00429d,96ffea,ffffe0|ffffe0,ff005e,93003a|1|1)

~~~
cheald
Beautiful. Thank you so much!

------
apineda
I'd rather just use tailwind or other utility css. Why have another
proprietary abstraction when you can have something concise that maps more
directly to css. You can then build your own local abstractions as needed.
Much leaner, universal and comprehensible imo.

~~~
wokwokwok
CSS frameworks only solve the display side of things.

Behaviour is as important, and it’s not trivial to implement.

You’re writing a button? Well, big dealing you don’t need a component library.

Modals? Menus? Tool tips? Autocomplete? Sliders? Colour pickers?

I think it’s fair to say tailwind is a totally distinct problem domain, and
not really relevant with regard to component frameworks.

~~~
pdxandi
I totally agree with you. I will say though, Tailwind with React hooks and
Zustand is my go to lately. Feels quite trivial and flexible to build the
functionality you mentioned. I've been quite happy with the output.

Chakra UI looks fantastic, however. I am just personally feeling Styled
Component fatigue after a few years of using it. I like being able to create
consistent presentation with just CSS classes and leveraging hooks for
anything more complicated.

------
codebender828
Hello fam! Creator of the Vue version of Chakra UI here!

Chimed in a little late, but I'm grateful for the Chakra UI shoutout!

The React team is currently working on publishing new 1.0 Typescript release
for Chakra UI. Lots of new goodies coming in next major version for React!

I've gained some useful insight while reading some of the comments made about
the libraries. We'll definitely be looking into this in the near future!

The Vue version was recently released a month ago! We're currently improving
the release and coming up with new ideas to make developing accessible Vue
apps with Chakra UI easier and more fun.

If you have any questions about the Vue version (or React) as well, I'm happy
to take them!

We're also very glad to receive contributors to help us improve Chakra UI. If
this sounds like something you're interested in doing, feel free to checkout
the issues:

Vue repo: [https://github.com/chakra-ui/chakra-ui-
vue/issues](https://github.com/chakra-ui/chakra-ui-vue/issues) React repo:
[https://github.com/chakra-ui/chakra-ui/issues](https://github.com/chakra-
ui/chakra-ui/issues)

------
player2121
I am a big fan of styled-system and glad that more frameworks are utilizing
it. This is something that helps a lot when building desktop-alike apps for
the web.

------
McPepper
I really like this style of creating UI. This is awfully similar to Flutter's
style of declarative UI and I do mean it in the most positive way.

------
phist_mcgee
I have just launched a cheap fuel finder (for Australia) application using
chakra.

[https://petrolbuddy.net.au](https://petrolbuddy.net.au)

It's been such a joy to work with, and I have loved the abstractions so far,
especially things like <Flex> and <Box>.

------
nickbauman
Where's the datepicker?

------
agustif
I used to have ant.design as my react frontend first pick.

Then I needed to do responsive, and it was much more fun doing this in chakra
with it's variable sizes for different viewports, etc, which was much nicer
than dabling with ant.design less/css @media queries in my experience.

+1 for Chakra-UI

------
RNCTX
The people who publish this also have a drag and drop interface for assembling
low level components into higher level bundles of components, too.

Seems to be an all-around well designed system to me, I like it!

------
modzu
what advantage does this bring over something like material-ui?

~~~
crubier
Material UI is a nightmare to customize, extend or integrate with third party
react libraries. This on the other hand is fully customizable (through theming
AND the css props) and use emotion, so it plays well with A LOT of libraries
that use emotion too.

~~~
mikewhy
Material UI uses a very similar theming system. The interface of the theme
itself is different, but that seems to be about it there.

Material UI has the exact same Box component, also using styled-system.

They're both libraries of components, so just as much a "nightmare" to extend
or integrate.

Seems the biggest difference is this uses Emotion.

~~~
player2121
> Material UI uses a very similar theming system. The interface of the theme
> itself is different, but that seems to be about it there.

Material UI implements Material UI by default and this is the main reason why
it's hard to customize. Too much to change. I guess this is one of the reasons
why there are not that many custom themes available for this library.

~~~
shripadk
Check this out and see if you find it actually hard to customize:
[https://news.ycombinator.com/item?id=23516513](https://news.ycombinator.com/item?id=23516513)
?

~~~
crubier
I count around 45 LOC just to change the colors of an input box. No changes to
animation, borders focus mode or others. So yes: overly complicated.

~~~
shripadk
Are you serious or are you trolling at this point? Because I just mentioned
that you don't need to use the components Material UI provides and you can
just use the Base components (which is what Chakra provides too or so does any
other UI framework). Styling just those Base components will get it down to 8
or so LOC.

Also, since when does LOC say anything about developer productivity? By using
Material UI you are avoiding a lot of problems that you will face later on
especially if you are building a complex app.

~~~
crubier
Not trolling. But your second example is indeed more meaningful of the way I'd
like to customize styling. And on that aspect, it is -as you mention- exactly
the same as chakra, line to line. Except that Material also has a lot of
additional stuff and opinions that I don't need.

But anyway, it looks like we have had different experiences, maybe due to
different use cases. My experience with Material UI has been the opposite of
yours: It is cool to get a quick project stated, and I would use it again for
small projects. But for a large SaaS application like I do, that includes 3D
views, Openlayers Maps, React Select and others complicated 3rd party
libraries and custom UX patterns, I would NOT use Material UI. Too
opinionated, not flexible enough, and not being based on emotion is a show
stopper for me. So let's agree to disagree maybe on that point.

Regarding the LOC, yes it does indeed say something about developer
productivity, and this does match the contortions I had to do in the past to
make Material UI fit my need. Lot of LOC, lot of time, no-so-cool results. I
want more control, that's all.

------
chris_engel
The initial example immediately drove me away. Attributes for font size,
-weight and the like? There was a reason we stopped using inline styles...

~~~
xmorse
And what is the reason?

So you can have a global css file difficult to maintain and update?

So you can give a stupid class name to every single tag you use in your
markup?

So that every time you include third party css there is the risk of
confilicts?

~~~
saagarjha
> And what is the reason?

So you can use CSS the way it was designed?

> So you can have a global css file difficult to maintain and update?

You know you can have multiple CSS files, right? Plus the code is all in one
place and you can refactor it.

> So you can give a stupid class name to every single tag you use in your
> markup?

No, you give it a _good_ class name. If something is a button, you call it a
button rather "grey-rectangle width-500 clickable"

> So that every time you include third party css there is the risk of
> confilicts?

That's why you name your classes so this doesn't happen?

~~~
player2121
> So you can use CSS the way it was designed?

css was designed to style HTML documents. It was never designed to build rich
and scallable apps thus we have all these libraries which fixes a lot of
underlining problems.

~~~
saagarjha
What problems do they fix? How do they deal with refactoring?

~~~
cutemonster
Refactoring: I suppose one then just refactors js instead of css. And even
simpler/safer? If using typescript to make the js and refactorings type safe

------
player2121
question to the author, why did you switch from styled-components to emotion?

~~~
xmorse
I am not the author but I can say one reason is emotion supports ssr without
injecting styles imperatively

------
hnuser
How is this different from all other UI libraries out there?

