6 ms·
I'm not super up to date with frontend development trends, but when I used it recently it really went against everything I've ever been taught about separation
by adwww 4y ago
I'm not super up to date with frontend development trends, but when I used it recently it really went against everything I've ever been taught about separation of concerns.
Like, I thought we were supposed to keep our content and styles separate, not mismatch them all together with a thousand utility class imports.
- deleted 4y ago[deleted]
- naasking 4y agoConsider whether those lessons were actually informed by evidence. Tailwind is not like inline CSS, the latter has a number of downsides because it doesn't permit you to access all of CSS, where Tailwind does.
- atsjie 4y agoThis has changed a number of years ago. Basically it's a component-mindset; create some file with everything in it so that in the rest of the app you can just use `<MyButton>...</MyButton>`. The `<MyButton />` file takes responsibility for everything it does (logic, handlers, markup, style). However; this does not mean these files should grow large. Instead when things become too big (say over 250 LoC) you split up responsibilities by sub-components. It's basically dividing problems in ever-smaller problems, but NOT by separating by technology (html/css/js). Separation of concerns is horizontal slicing of the app architecture, components however slice the architecture vertically.