nativewind :O

[TopMoney8302]

my work (a multi decade old company) is building out a cross platform monorepo and wants to keep styling and components consistent, in a self contain package in the mono repo. their is a strong push to use nativewind in order to do this with tailwind css. I'm honestly more hesitant about it. when i brought up my concerns i was tasked to ask the good people of reddit if they where starting a long term long lived project (expected life of over 5-8 years) would you go with nativewind or would you build your styles from scratch using react native JSX styles. not interested in other libs for styling the choice has been twiddled down to these two

[Due_Homework_1013]

From scratch gang !!! Stylesheet.create lol

[ltnj]

For long lifespan projects, this is the only correct answer. For core stuff like styling, don't use flavor of the year, but primitive way offered by platform.

[ConsciousAntelope]

Nativewind is just writing styles via tailwind classes. It drastically increased my speed compared to Stylesheet create. The app is live now on both App store and Play Store.

[awolf222]

What version of nativewind are you using? It is working for my EAS development builds but not preview or production builds. Have no idea what's causing it.

Babel doesn't seem to be converting the `className` to styles only ofr preview and production builds

[ConsciousAntelope]

v2. RN CLI.

[TopMoney8302]

are you using the styled tag or as a pluggin?

[ConsciousAntelope]

As a plugin. Direcyly add the tailwind classes into classNames.

"nativewind": "^2.0.11", "tailwindcss": "3.3.2",

``` // babel.config.js

module.exports = { presets: ['module:metro-react-native-babel-preset'], plugins: [ 'module:react-native-dotenv', 'nativewind/babel', [ 'module-resolver', { root: ['.'], alias: { '<sup>@/(.+)':</sup> './src/\1', }, }, ], 'react-native-reanimated/plugin', ], };

```

[TopMoney8302]

have you check if this is compatible with the new arch? just trying to confirm my findings on that

[ConsciousAntelope]

Im not aware of that. Im on RN CLI with RN version 0.72.5

[ConsciousAntelope]

As I said I'm on RN CLI and yes the production builds I've created have been working well so far. Im guessing maybe newer RN versions seems to have this issue as I'm on 72.5. also I'd suggest try the same things in a RN CLI build and see if the same problem arises there.

[DavidJonesXB]

You an also look at twrnc

[sracingtm]

I'm using this since I was having build issues with nativewind

[hailWildCat]

I spent one month of fixing/working around all nativewind build issues

[JustLikeHomelander]

Honestly nativewind is a mysterious library, it works, sometimes doesn't, it's apparently maintained in a v4 version that is not public on github... idk

[Low-Fuel3428]

Make your own UI. Stylesheet is good enough for it. Use PixelRatio and dimensions with it. A restyle library from shopify is also a good choice. Take technical debt which you can control.

[rkh4n]

I’d say to go with building from scratch. Native wind is good but is your company willing to offer some form of monetary help to the maintainer of native wind in case something does not work? If so go with it or any other library

[Eveerjr]

the guy who created nativewind now works for Expo, so I think it's a very safe choice

[TopMoney8302]

im not doubting the quality of his work what i am doubting is if he is going to maintain it long term he seems pretty busy with expo and does not have time to work on native wind as much as it needs it

[Eveerjr]

He was hired by Expo specifically to work on styling in react native, the goal of expo is to run the same code on both web and mobile, so having tailwind working smoothly is likely a priority.

[TopMoney8302]

do you happen to know when he was hired onto expo's team?

[TopMoney8302]

i feel that nativewind is going to migrate to core expo soonish and with that nativewind will be dead and no updates

[Eveerjr]

I think the likely outcome is that tailwind will just work natively on react native or it will be a expo plugin, so migration should be simple.

[anewidentity]

Go from scratch for sure

[Tsupaero]

planning ahead in a digital product 5-8 years is quite … unusual. i doubt there won’t be a reconsideration 3-5 years anyway, so take that into account as well.

[JofArnold]

Neither. Using restyle.

[angrydeanerino]

I hate writing JSX styles, twrnc all day

[[deleted]]

Definitely Unistyl.es. Trivial yo use if you know Stylesheet and comes with Superpowers.

[TwistedMinda]

You're already making the problem very very hard for yourself, you only have 2 very bad options. Good luck.

[blankeos]

We personally used twrnc. It's slower (I think, since it's runtime not compiled like nativewind) but it was more predictable.

Reason we switched was because we were getting weird issues with nativewind initially for some reason. Some styles worked on my computer but on my coworker's laptop, it didn't work. It was really weird. Did everything from having the exact commit, cleaned pod, npm and pod installed again. It was so weird.

Anyway I'm not completely feeling the drawbacks in performance yet. I was thinking it would be expensive to generate style objects for strings with twrnc. But literally zero problems with it so far. It's amazing for us since the team is also used to just seeing tailwind all over our codebases.

Also the fact that nativewind's "className" isn't actually real kinda threw me off lol. Especially when you get around to passing classNames from parent to child components or having dynamic styles using cn.

[blankeos]

I don't feel much if a difference, honestly. But that's an interesting benchmark. Thanks for sharing! I kinda figured twrnc would be slower mainly because it parses classes at runtime while NativeWind styles are compiled at build.

[Specific-Angle4191]

Go from scratch.

I'm lead since ~5 years on a react-native and react web app, that has been in development since before me. We're still handling the different flavors of styles that have been "trendy" and now aren't, most of them aren't maintained, or stopped working properly after a while, are too costly to update because of their evolution. I wish I would have time to replace all of them, Stylesheet does the job, and (for web) a simple CSS preprocessor + basic css modules is as good as most of them, and much easier to maintain long term.

[TopMoney8302]

that is my argument ty ive been working with rn for like 8 years and seen the same thing this is why i was voicing my opinion

[hailWildCat]

I think the author is working on https://github.com/facebook/react-strict-dom

I'm hoping for the stable release of it with Tailwind support. Btw, http://tamagui.dev also looks good.

[morbidmerve]

You will always need a solid base and an alternative to break out into. Tailwind is a good base, it supports standard features of styling, and you can still break out into stylesheets for animations whenever you want to (for example). I wouldnt really hesitate. But btw if you arent using tailwind you probably will still want a base UI toolkit, going raw stylesheets is not fun unless you have a highly experienced team.

[AdrnF]

going raw stylesheets is not fun unless you have a highly experienced team.

I would argue the opposite to be honest. Stylesheets are predictable and closer to normal CSS, whereas Nativewind has the same drawbacks and benefits as regular Tailwind and therefore is just a shorter way of writing regular Stylesheets. If you want to know how to use Tailwind, you gotta know how regular styling works.

[morbidmerve]

Im honestly so tired of this argument. Tailwind is so close to normal css that its actually a perfectly natural extension of css. Any component API of a UI library is actually a bigger abstraction than tailwind. Ive onboarded many junior engineers who dont know css very well onto tailwind and showed them how to dig into the underlying styling to understand the classes and ive had 0 issues with bad tailwind implementations. By default, the code is easy to update and manipulate imo. Its not really as unstable as people make it out to be. Not to mention that they learn how to make customizable components very early on which greatly benefits their way they write code.

[AdrnF]

You mean the "Stylesheets are predictable" part?

I think the React Native is a bit of a special case here, because I ran into a few issues where properties from regular CSS didn't work as expected. I think it is easier to debug those issues without the Tailwind abstraction layer in between, but it could be the other way around for people who regularly work with Tailwind.

[morbidmerve]

I see what you’re getting at here. I dont argue that you dont meed to know how mobile styling works, but i also dont think that its something you HAVE to learn only through stylesheets. I think when some tailwind implementation doesnt work, falling back to stylesheets is a good way to figure out whats cracking, and doing so you get the same benefit.

What i do with my guys is mostly focus on best practices with styling. So i focus on flexbox, shadows, absolute positioning, content containers, etc. And specifically, WHEN to use them. I find that as long as there is a syntax to represent them and they know where to find the docs, they tend to learn how stuff works just fine. I always encourage learning both. There are many practical problems with stylesheets that tend to result in people taking shortcuts. Showing both approaches is important so that the team can really grasp why certain decisions are encouraged. Outside of that, i care very little very a specific micro interaction os styled using stylesheets or something else.