• Precedence doesn't work as you'd expect (twin.macro and twind solve this)

 const SomeComponent = ({ className }) =>
   <div className={classnames('bg-red', className)} />

 <SomeComponent className="bg-blue"/>

What background color will the component have? The div will end up with class="bg-red bg-blue", so precedence depends on whether the specifiers for .bg-red was generated before or after specifiers for .bg-blue in the css file

• variants conflicting because you have to specify their order globally in the config, not case-by-case - @JonasKuske (twin.macro and twind solve this)
• Unclear how to perform bundle splitting (is this even possible?) (twin.macro and twind solve this)
• Requires purging css as part of build step to strip unused css (of which there is an immense amount) (@tailwindcss/jit, twin.macro and twind solve this))
  • Potential for inconsistencies between dev vs prod due to purging CSS in prod and not during dev
• Since the stripped css file is shared throughout the app, adding or removing a usage will invalidate the css file cache for the whole app (@tailwindcss/jit, twin.macro and twind solve this))
  • after 2+ years of tailwind, the bundle has been invalidated every day
• Uses a DSL that's almost but not exactly inlining CSS
  Need to consult a dictionary to look up what tailwind key maps to what css property
  Inconsistent class naming rules. Possibilities I've encountered:
  • [property-name]-[property-value] (e.g. pointer-events-none for pointer-events: none)
  • just [property-value] ( e.g. flex for display: flex, absolute for position: absolute)
  • a variation of the [property-name] (e.g. border for border-width: 1px;)
  • [first-piece-of-property-name]-[property value] (e.g. justify-center for justify-content: center, flex-col for flex-direction: column)
  • [second-piece-of-property-name]-[property value] ( items-center for align-items: center) This is like performing manual compression on your CSS
• Arbitrary increments of units (0.25rems from 0.5 to 1.5rem, 0.5rems from 1.5 to 3, 1rem from 3 to 6, 2rems from 2 to 16) (solved by @tailwindcss/jit, twin.macro and twind)
• Mental math required to transform designs to tailwinds units.
  Implementing designs consists of
  • get px value from design
  • convert to rems (divide by 16)
  • round to closest tailwind unit
  • (somewhat solved by @tailwindcss/jit by having more units to work with and also being abel to pass arbitrary units)