First, a primer on React Native Web (RNW), for those unfamiliar. RNW is taking the high-level API of React Native, onto the Web. "Why not just use React?", you say. RNW is all about using specifically tailored native cross-platform components (that primarily render onto a native Screen view) and also rendering them on the web (to the DOM). Which is possible because RN/RNW uses higher-level abstractions (
<View>and<Text>instead of<div>and<span>, etc.). (RNW should have been called "React Platform", really.)
If you want to use React Native or React Native Web (RNW) and want to use a component library similar to Chakra UI (which doesn't support RN yet, and likely won't support RNW), then you have two good alternatives, to my knowledge. Especially if you want to use NextJS to do Server-Side Rendering (SSR) of the webapp/PWA.
Here is a brief comparison of Magnus UI vs Dripsy:
Both:
- React Native support
- Themed
- Inspired by Chakra UI and Theme UI
- Use
StyleSheet.createunder the hood
The differences:
Magnus UI
- Utility first / atomic design methodology. "Almost all Magnus components have support for utilities like spacing, border-radius, font sizes, shadows, etc". Example code. Can remind of TailwindCSS. Meaning that all styles are direct style props on components. (This is likely not future-proof with RNW which supposes to own the top-level styling API, and has deprecated several other props like
classNamein favour of having all styles passed as an object to thestyleprop). - Has a component library: "Magnus UI comes with a set of 25+ polished React Native components that just works out of the box." magnus-ui.com
- Not yet responsive, but planned responsive with react-native-media-queries, which makes pure CSS media queries also run on native (with device orientation). Since Magnus UI generates pure CSS media queries when run on web. They consider it more performant than using Fresnel. But the jury is out... Alternatively, it might be that Magnus UI will use react-native-extended-stylesheet as a drop-in replacement for the StyleSheet in React Native which also supports media queries on native.
- Supports SSR on web via something like NextJS.
Dripsy
- Started in [Jun 2020] likely since Magnus UI didn't support responsivity through CSS media query breakpoints.
- Primarily a design system. Relies on you combining it with other React Native component libraries, or build your own on top. nandorojo/dripsy#why. "Dripsy is an almost-drop-in replacement for React Native's UI components." from the Readme.
- Uses the Dimensions API on Android, iOS and Web. Whether you use Dripsy with RN or with RNW.
- Dripsy is very declarative: it allows you to provide object and array values to add mobile-first responsive styles. Instead of manually using the Dimension API (on native), and adding media queries and nested styles throughout your code (on web), Dripsy will do it for you. This API is very inspired by Chakra UI's array syntax for declaring responsiveness.
- All styles declared inside an object. Either the
styleobject familiar from React Native, or a singlesxprop. Inspired by Theme UI's sx prop. "Rather than have just direct style props for components, theme-ui has an sx object prop. - Does NOT currently support SSR. Even though it still works with NextJS for other reasons such as code splitting and navigation, and SSG.
These are the most important differences.
Conclusion, my advice would be:
- If you use RNW, go with Dripsy. You get responsivity (using JS, not CSS media queries), at the price of SSR.
- If you need SSR and like the utility-first approach (similar to Tailwind), go with Magnus. You get SSR, at the price of responsivity and RNW. I'm not quite sure Magnus UI works with RNW today, but it's utility-first design is a risk that it will be less future-proof with RNW, as mentioned.
- If you want both SSR and RNW, then you are not so lucky. But you can read my research of the options you have, in this discussion: How to combine React Native Web (RNW) + Responsive styles (media queries) + NextJS Server-Side Rendering (SSR), to get SEO on the web. If you don't want to make a compromise like the current options, there is a library called Fresnel, which has some promise to afford this combination. But it is not quite there yet. So please consider contributing to Fresnel in the RNW+NextJS compatibility issue or the useMedia() hook issue, so that Dripsy could be upgraded to use Fresnel again to support SSR.
The problem of SSR + Responsivity
Read on, if you are interested in how Dripsy worked before it dropped SSR:
Dripsy used media queries and the SSR library Fresnel to accomplish Responsivity with SSR. Now it uses Dimensions API which determines responsive layouts in JS instead of with media queries in CSS on the web. This is to stay close to the API of RNW, which presumes you determine window dimensions in JS, which entails Client-Side Rendering (CSR), since window in JS is only available on the client. In short.
Before, Dripsy used a library called Fresnel to achieve achieve Responsivity with CSS media queries. CSS breakpoints on web will rely on the mobile device's user agent for most cases. But since this can be inaccurate, Fresnel also uses pre-emptive server-side breakpoint generation. Basically, if the mobile user-agent cannot be accurately detected (if you combine Fresnel with its sister library, detect-responsive-traits), then Fresnel will render all media query breakpoints on the server (a bit of extra work for the server, since it might lead to rendering more components). So the client's browser will receive all breakpoints on first render and can immediately start rendering according to the correct ones. Instead of waiting for React to rehydrate before only then running the media queries with CSS-in-JS, which would have given latency and potentially unwanted visual side-effects. This becomes most acute when you are using SSR, and thus don't want to wait for rehydration on the client to start showing the responsively laid out content.
"Basically, it comes down to this: when using server-side rendering, every component's props on the first render on the client side must be the exact same as their props on the server's render. Since we use the screen size to determine which style to apply, and this is done using JS, it's possible that the props on the server and client won't match. This happens because the server doesn't know what the screen size will be on the client." - Fernando Rojo of Dripsy
So if you want a design system / component library for React Native, then either of Magnus UI or Dripsy seems the way to go, instead of using Chakra UI, currently.
But you have some other options if you are determined to use Chakra UI on mobile, and are willing to sacrifice using RN/RNW.
Top comments (13)
NativeBase is worth checking out: "Mobile-first, accessible components for React Native & Web".
It works with RNW, and it looks like you can get SSR with it (without an utility-first approach, but more like Dripsy, since "NativeBase V3 allows you to provide object and array values to add responsive styles."):
github.com/GeekyAnts/NativeBase/pu...
But maybe not, since compatibility with NextJS is still questionable:
github.com/GeekyAnts/NativeBase/is...
Even though NativeBase has docs for NextJS:
docs.nativebase.io/install-next
NB: Many people are reporting performance issues at scale with NativeBase. Heard in various Discord channels, and also here: github.com/GeekyAnts/NativeBase/is...
Chakra UI vs. Nativebase code comparison (usage, functions, components): nativebase.io/blogs/nativebase-cha...
NativeBase doesn't seem to have the same polished aesthetics as Chakra UI.
But you could potentially use Chakra UI's theme with NativeBase's unstyled components: github.com/chakra-ui/chakra-ui/iss...
See also the successor to Nativebase, made by the same team, called Gluestack UI ui.gluestack.io/ which can be used with the accompanying dank.style style library. It is part of the overarching suite they call Gluestack.io
Nativebase is discontinued for performance reasons: github.com/GeekyAnts/NativeBase/is...
SnackUI is another alternative.
SnackUI's name has been changed to Tamagui (tamagui.dev)
Tamagui looks like a worthy competitor to Dripsy and Magnus UI!
Update: Yeah, I would definitely use Tamagui over Dripsy and MagnusUI, and even over NativeBase (due to its performance issues).
You sure? Seems like different maintainers…
I think so
yeah, the old links to @natebirdman’s (aka. @natew) SnackUI repo now route to the Tamagui repo. Plus it seems like it from what the tamagui.dev author @natebirdman said on twitter.
But I’m still puzzled by the different repo contributors, and the existence of this repo by @nzbin :
github.com/snack-ui/snack
Maybe it is a completely different SnackUI than the one that @natebirdman made. Maybe the duplicate names was the reason for the name change to Tamagui?
I think it's completely different repo from different authors. It can be a possibility for the name change to Tamagui...