use className instead?

[PeerRich]

this alternative package https://github.com/marklawlor/nativewind

is using className="text-black" instead of style={tw´text-black´}

I like trnc, it seems more comprehensive but i really like the className approach making it easier for learners / and potentially make code copy/pasteable

[jaredh159]

yeah, i agree that it's a very intuitive API to use className instead of style, and that seems like a nice library.

the reason this library doesn't take that approach is that it's heavily oriented towards React Native native projects (as opposed to React Native Web). React Native <View /> components aren't like HTML primitive elements, you can't slap a className attribute on them, they take no such prop.

the way nativewind works is by using a Babel plugin transform to rewrite the calls to className and turn them into style= at build time.

this may be just my personal bias, but i've got some battle scars from libraries implemented on top of babel plugin transforms -- i find that when they work well, they're magical and wonderful, but when they don't, they're super frustrating, hard to debug, and hard to get to play nice with other libraries. as the years pass, i find myself leaning more and more towards thing that are simple, explicit, and not magical, even if the apis are a bit more cumbersome, or they involve some more boilerplate. i'll exchange a bit of boilerplate or a slightly awkward API for simplicity and reliability any day of the week. in particular, a few years ago i did a lot of work with the "styled components" library, which is conceptually very similar to nativewind (it uses a non-standard css prop, and a babel transform), and I had no end of trouble with it.

but none of that is meant as a critique of the library you mention. it seems super great, the author has already posted a super helpful explanation/comparison here in this repo, and you may find it works great for you. especially if you're building a RN web project.

you'll just need analyze the approaches and tradeoffs, and figure out what suits you better. this library is heavily-cached and optimized, but at it's core is conceptually pretty simple -- it parses tailwind utility classes into react native style objects at runtime. nativewind does a ton (all?) of it's work at build time and does a babel transform of className props, turning them into style objects. theoretically, nativewind should be faster -- although i've got apps in production using twrnc and the styling layer is very fast, plenty fast enough for my use case, and probably very low on the list of things i would need to optimize if i were working on app performance.

[PeerRich]

i find that when they work well, they're magical and wonderful, but when they don't, they're super frustrating, hard to debug

I can totally see that yea. most people never wanna touch Babel heeh