[HN Gopher] Goodbye CSS Modules, Hello TailwindCSS
___________________________________________________________________
Goodbye CSS Modules, Hello TailwindCSS
Author : 01brett
Score : 112 points
Date : 2021-11-04 17:15 UTC (5 hours ago)
(HTM) web link (www.polytomic.com)
(TXT) w3m dump (www.polytomic.com)
| wccrawford wrote:
| I notice in the config you specify "colors" and "fonts" but also
| "fontFamily", not plural. Ugh. I _hate_ inconsitancies like this.
| They make it a lot harder to predict how to specify what you
| want, and it 's likely that someone in the future will "fix" it
| and you'll end up with deprecation warnings all over the place.
|
| No thanks.
| SarfasCodes wrote:
| That's because fonts is a collection of the singular font.
| Colors, the same for color. fontFamily is precisely what is
| says; a font family. It's a singular unit. There is no
| inconsistency here.
| ysavir wrote:
| When configuring the settings, it uses `fontFamily`,
| singular, to set up multiple font family options (eg. options
| for "heading" and "body" in their example). `colors`,
| however, is plural here.
|
| When applying them later in the code, they're both singular
| since they're specifying a specific family/color.
|
| I agree with GP that this inconsistency shakes my confidence
| in the package.
| m8s wrote:
| Tailwind is free and open source. If it really shakes your
| confidence with the entire system, you could certainly
| consider opening a discussion or PR. I've been using
| Tailwind in production and I never even really thought
| about it. It just seems out of place that of all the
| incredible work Tailwind is doing, this potentially minor
| issue is enough to say "well then nevermind".
| adamwathan wrote:
| Creator of Tailwind here -- what you're seeing here actually is
| a best effort attempt to be consistent and predictable.
|
| Keys in the config file generally correspond with the CSS
| property they refer to, and we use the singular form to make it
| match the CSS property.
|
| There are 3 exceptions, which are "colors", "spacing", and
| "screens", and these are sort of special keys that don't map to
| anything in CSS. The "colors" and "spacing" keys are more like
| reusable variables that are consumed by the property-specific
| keys like "backgroundColor", "fill", and "borderColor" in the
| case of "colors", and "width", "height", "gap", and others in
| the case of "spacing".
|
| The "screens" key is a list of breakpoints for your project,
| which also doesn't map to an underlying CSS property.
|
| Originally we tried to keep things really abstract and group
| things together under concepts like "spacing", "typography",
| whatever, but ultimately found it was more flexible and
| predictable to make it possible to customize every CSS property
| using the exact property name, while only providing a couple
| high-level things like "spacing" and "colors" that you can use
| to update other dependent keys at once.
|
| Getting complex config files right is unfortunately hard and
| it's not perfect for sure. At this stage in the project it's a
| delicate balance between improving things and maintaining
| backwards compatibility. Totally appreciate what you're saying,
| just wanted to do my best to clarify though as I'm equally
| picky about this sort of consistency.
| 01brett wrote:
| Author here, I will add my kudos for the Tailwind API. The
| more I've used it and internalized its structure, the more I
| appreciate the care and effort of its API.
| earthboundkid wrote:
| Tailwind is mostly consistent, but I do sort of wish it were
| color-gray-500 instead of text-gray-500, and I think some of
| the sizes are a bit confusing in terms of when you can use
| what.
|
| What would you do if backwards compatibility were out the
| window?
| donatj wrote:
| I've always been of the mind that if you like tailwind, you'll
| love the flexibility inline css gives you, and without the need
| for interim tools!
| Vinnl wrote:
| Except you'd be missing out on Tailwind's constraints, which
| prevent someone like me (with not as much of an eye for design)
| from accidentally sneaking in little inconsistencies that make
| a design seem off.
|
| (Like in another comment here, I'm rehashing a more extensive
| blog post [1] of mine here.)
|
| [1] https://vincenttunru.com/why-tailwind/#constraints-set-
| you-f...
| SavantIdiot wrote:
| Why do people prefer Tailwind to Bootstrap (css only)? THey
| both seem really similar but I've been using Bootstrap so long
| that I haven't had the impetus to change.
| thomasfortes wrote:
| Bootstrap is a fully opinionated framework, tailwind is far
| more versatile, it has his opinions, but they aren't set in
| stone in the way that bootstrap is.
|
| You can build bootstrap in tailwind, but you can't build
| tailwind with bootstrap.
|
| Both are tools to help you design something, but the
| tradeoffs of each one are quite different.
| grayrest wrote:
| The restrictions are a feature, not a bug.
| adamwathan wrote:
| The biggest issue with inline styles is you can't use media
| queries or pseudo-classes like hover, focus, etc, which
| effectively means you can't build anything of substance with
| them.
|
| Agree that if inline styles offered all of the features you get
| when writing your CSS in a stylesheet that it would be a
| compelling option because of the simplicity, even though the
| verbosity would be a big knock against.
| codyogden wrote:
| I know you're the creator of Tailwind. However, using
| emotion's css() from @emotion/react feels like the best of
| both worlds. Essentially, writing inline styles but with the
| ability to do media queries, pseudo classes, and conditional
| styling based on state. I didn't like CSS modules, I never
| quite "got" Tailwind's functional take on CSS which left me
| feeling inflexible, but I found something great with emotion
| and it works wonderfully.
| omnimus wrote:
| Might be best of both worlds if you write JS apps. Not if
| you write html :)
| teitoklien wrote:
| Um you can in tailwind
|
| Its like
|
| md:p-2 which is for m devices , make padding as 2 Or xl:p-4 ,
| which is for xl devices , make padding as 4
|
| Similarly for hover or focus in tailwind its
|
| bg-white hover:bg-black focus:bg-red Which says , by default
| keep background of this element white , when you hover over
| it keep it black and when you focus on it , keep it red
|
| Works just fine, Give it a try and go through the docs of
| tailwind, navigating it using algolia, is a joy :D
| Kiro wrote:
| In case the other comment isn't clear: you're replying to
| the creator of Tailwind.
| hanspagel wrote:
| I think Adam knows what's possible with Tailwind CSS [1],
| but wanted to point out that it's not possible with just a
| style attribute. :-)
|
| [1] https://github.com/tailwindlabs/tailwindcss/graphs/cont
| ribut...
| adamwathan wrote:
| Haha correct, I was just explaining why inline styles
| aren't a suitable alternative to Tailwind. Tailwind can
| definitely do all that stuff!
| [deleted]
| [deleted]
| Vanderson wrote:
| I found using inline CSS variables and clever use of
| selectors allows for both media queries and inline to work in
| harmony.
| johnnypangs wrote:
| I had always heard inline styles were slower and not
| recommended by browsers. Here is a blog post looking into
| that:
|
| https://simonadcock.com/are-inline-styles-faster-than-
| atomic...
|
| In reality the difference wasn't so big but inline styles
| might not scale well. (I also realize the original poster
| might have been sarcastic but it's a fun to look into even
| the non serious ideas).
| elefantastisch wrote:
| Tailwind also offers curated (and curatable) styles instead
| of a free-for-all. You can set up Tailwind to exactly provide
| the levels of spacing, colors, fonts, etc. that you want for
| your design system. Tailwind is in some ways like inline CSS,
| but enhanced inline CSS that you can customize the options of
| precisely for your project/team/company. You don't have to
| use text-xs, text-sm, text-lg. You can use text-fineprint,
| text-prose, text-inyourface and configure them to be exactly
| the size you want. And then of course, you can change the
| definition of those styles in one place and have it propagate
| throughout your project. This is where Tailwind starts to
| move well beyond inline CSS.
| earthboundkid wrote:
| Haha, good one, never heard it before. Did you think of it
| yourself or was it a collaboration?
| toomanydoubts wrote:
| Can we all finally agree then that this is not an issue with
| modern frontend technology which allows you to componentize
| your stuff? Yeah, it was bad when you had a hundred HTML files
| with repeated elements across them. Updating the style on one
| such element meant going through all these 100 files. Nowadays,
| if you want to change your button background color or your
| container width size, you should be able to change a single
| component and have that updated for your whole website. For me,
| that kinda fix the main issue people had when they started
| saying "do css, not inline styles".
| crisnoble wrote:
| Probably would actually be a valid way to go if you could do
| media queries and didn't need vendor prefixes.
| 01brett wrote:
| Author here, most of the non-Tailwind CSS I write is browser-
| specific tweaks or hacks, and mostly for Safari.
| rapind wrote:
| I think a big problem with CSS is the assumed best practice of
| starting with the abstraction / module (stylesheet) instead of
| starting inline and refactoring out like you'd do when coding
| in any other language.
|
| It creates paralysis and feels like an upfront chore/ cost.
| Then naturally it's hard to maintain because you didn't know
| what the right abstraction was yet. You literally end up with
| everything modular (css files) even if it's only used once.
|
| I'm really enjoying elm-ui and the principles behind it.
| sodapopcan wrote:
| This is exactly what I tell people when explaining why I like
| tailwind. It's very freeing. I mean, I tell them other good
| things too, but this one is big.
| CuriouslyC wrote:
| Inline css is very powerful, but tailwind gives you the vast
| majority of that power with a much smaller learning surface,
| and with the ability make sweeping style changes without having
| to update the css in every single component.
| kmeisthax wrote:
| I don't get why you wouldn't use LESS mixins or SASS class
| extensions (or whatever the modern equivalent of that is) instead
| of inlining each utility class directly into each div.
|
| Having a name for each element in your markup is really powerful
| and useful, and it seems like the Tailwind approach exists
| _specifically_ to avoid having to name things.
| nightski wrote:
| I think the thought process is that if you are using Tailwind
| it's probably with a component based system like React. So you
| don't need a button "name" because you have a button component.
| You re-use components instead of classes.
|
| This makes it so you don't have to remember all the names
| specific to the project (or learn an existing projects css
| names).
|
| I've never used Tailwind myself so I am not advocating it per
| say, just explaining how I understand it.
| tchvil wrote:
| After 20+ years of HTML, CSS I started to use Tailwind for a
| new project. Using web components (disabling the shadow dom
| unfortunately).
|
| You guessed it right. There is no need for named selectors
| anymore.
|
| And you get the advantages of standardisation. People can
| share snippets of code you can reuse as is.
|
| And when you have a problem, you are probably not the first
| to have it, and can quickly find a solution on youtube, stack
| overflow, etc.
| abledon wrote:
| the code-reuse is such a boon
| Vinnl wrote:
| Exactly. When using something like React, the abstraction of
| using classes to create reusable components is redundant with
| the framework's, and thus no longer carries its weight.
| Especially considering how, in practice, that abstraction
| isn't that effective in the first place: it's rare that a
| layout change involves _just_ a CSS change. (I 'm somewhat
| rehashing from a blog post of mine [1] here - if anyone wants
| this more extensively argued they can read that.)
|
| [1] https://vincenttunru.com/why-tailwind/#the-right-
| abstraction
| z3t4 wrote:
| Also you avoid writing CSS and designing like before CSS
| existed. Its more messy but a bit easier to learn then CSS.
| CSS is simply too advanced and powerful it takes years to
| master. Ohh and you can copy/paste components into your
| spaghetti code.
| jarek83 wrote:
| So you're using Tailwind fine, but find CSS too advanced?
| But you gotta master CSS to know what Tailwind is doing.
|
| Otherwise, you're just improvising.
| 01brett wrote:
| Author here, I have a few custom classes that look like more
| traditional CSS. Tailwind gives an example[0] of how to do this
| in their docs. I have about 15 of these extracted classes. I
| use them for common styling patterns, such as transforming
| "flex items-center justify-center" to "flex-center," or to
| unify styling on components I haven't abstracted into a styled
| version, such as "listbox-option" or "flyout."
|
| [0] https://tailwindcss.com/docs/extracting-
| components#extractin...
| danielvaughn wrote:
| I've been considering an approach like this, but I don't want
| to risk going back down the path of "having to name things".
| wjakub wrote:
| I've recently discovered Tailwind, and after a day or two of
| getting used to it, not only does it 'feel' more natural when
| styling than what I've used recently, it also opens up a lot of
| doors for performance. Speaking from a traditional business
| website stack perspective (non react).
| TurningCanadian wrote:
| Looks like CSS variables in CSS Modules would've achieved the
| same thing but is more verbose.
| 01brett wrote:
| Author here, CSS variables change the landscape in terms of
| what is possible. I think Theme UI (CSS-in-JS) uses them
| heavily under the hood. I can't think of the name, but I saw a
| CSS framework on HN some months back that is almost exclusively
| CSS variables. Plenty of unexplored territory there.
| jarek83 wrote:
| Was it Pollen? I really love that concept million times more
| over Tailwind.
| SavantIdiot wrote:
| I still don't get CSS in javascript. Why blow up the size of the
| payload when linking to a compiled style sheet is sufficient?
| Yes, I realize some components are one-offs, but I think the
| discpline required to keep CSS clean is a small price to pay for
| mitigating bloat.
| aidos wrote:
| Tailwind isn't css in js. It's just css. They've built endless
| css mini classes that effectively give you enhanced inline
| styles. So stuff like hover variations are possible by adding
| the class directly to your element.
|
| You can use the just in time compiler to generate the classes
| on the fly rather than importing millions of them in as a style
| sheet. That's js, but really it's just a regex that scrapes
| things that look like tailwind class names from your html and
| generates those classes for you.
| SavantIdiot wrote:
| Yes, I know that, but in the article the OP is loading CSS
| via JS.
| lancemurdock wrote:
| personally I find tailwind to be atrocious looking and can't
| understand anyone preferring it to styled-components
| Vinnl wrote:
| The tooling is much less intertwined with other tooling and
| therefore less likely to cause problems, and the runtime
| performance impact is less. That's pretty neat.
| VWWHFSfQ wrote:
| agree. I don't understand this fad at all.
| lancemurdock wrote:
| the syntax of styled-components plays so nicely with actual
| reusable components. A mesh of tailwind syntax with reusable
| components feels weird. But mostly, a div with 10 classes
| each doing one small thing is so unreadable
| reidjs wrote:
| In our codebase when it starts getting out of hand like
| that, we refactor using @apply
| https://tailwindcss.com/docs/extracting-components
| neurotrace wrote:
| If you're using `apply`, you might as well have just
| written the CSS normally, imo
| 01brett wrote:
| Author here, I haven't had time to play around with it, but
| this library[0] from Atlassian looks like a "best of the both
| worlds" styling approach: CSS-in-JS authorship without the
| runtime penalty.
|
| [0] https://compiledcssinjs.com/
| [deleted]
| lycalopex wrote:
| As someone still sometimes building brochure-style sites, I do
| wish it were easier to componentize things without unnecessarily
| turning every site into an SPA with React et al.
| tmitchel2 wrote:
| Very well written post tbh
| hbn wrote:
| I get why people are skeptical of Tailwind, and I was too when I
| started a job at a new place that used it for their frontend, but
| now I'm totally onboard and use it for all my personal projects.
| Incidentally I'm wearing my TailwindCSS shirt today!
|
| It really fixed a whole slew of my biggest pain-points with CSS.
| The biggest one being that you have to jump between files when
| modifying a single UI. Which isn't just annoying while
| developing, but it's also even more frustrating when refactoring
| and you have to come back to some files you haven't touched in a
| long time, trying to cross-reference ID names and styles between
| the template and the CSS.
|
| It's also just way more concise than typing CSS which helps with
| the fast iteration. e.g. jumping to a different file and typing
|
| #id-name { margin: auto; }
|
| vs just being in the tag and typing
|
| `class="m-auto"`
|
| Maybe it doesn't seem like that huge of a difference, but I find
| it saves me so much mental overhead when I'm in the flow of
| putting together a UI, and I work way faster now. It's also
| really not that difficult to learn the syntax, which stays pretty
| consistent throughout all the different CSS properties you can
| apply. Also the responsive syntax is so much nicer than the
| typical "@media screen blah blah" syntax is vanilla CSS
|
| On top of this, it's not even just a different way of writing CSS
| - you inherently end up working in a built-in design system that
| you can tweak to your liking. For example, the margins go up in
| units of 0.25rem, it comes with a pretty good built-in color
| palette (that you can add to/modify in the config), etc. Which
| keeps you on something of a consistent grid, and is really good
| for teams where you don't want some new guy coming in using weird
| sizings or units.
|
| If you don't like the idea, I'd urge you to give it a real shot,
| even on a small application. Try converting styles on a page to
| Tailwind. I think it's worth it in the long run.
| abledon wrote:
| can i get another 2-3 paragraphs expounding on this... the way
| you wrote that i just levelled up like 3x on my inner-tailwind-
| foo comprehension.
| amjnsx wrote:
| On conciseness (and possibly scale), isn't the css "bloat" just
| being shifted to the html file instead? Has there been
| sufficient studies in comparing tailwind to say something like:
|
| .MyHeading {color: red; font-weight: bold} // Left container
| <h1 class="MyHeading"... // Right container <h1
| class="MyHeading"...
| mimsee wrote:
| > The biggest one being that you have to jump between files
| when modifying a single UI.
|
| This is why I still like Vue files over React ones. Vue files
| can have a <template> tag containing the HTML structure of the
| component, a <script> tag containing the functionality, and a
| <style> tag containing the CSS.
| antihero wrote:
| I avoided web react like the plague (always veered towards React
| Native projects) until I found TailwindCSS. Now I enjoy web
| again.
|
| The wonderful thing that it gives you is some natural feeling
| constraints.
| dwmbt wrote:
| despite a lot of the backlash i've seen around the web
| concerning tailwind, bootstrapping projects is easier when all*
| the work is done for you. i also found that the consistency and
| familiarity you gain is just... nice? i've learned a lot about
| css through the tailwind documentation, and it's impacted the
| way i look at and implement my own css outside of using it. i
| even practiced learning css by creating my own design system /
| atomic css framework by mimicking tailwind. not sure if you've
| checked this out but windicss[0] is an awesome implementation
| of tailwind.
|
| *mostly
|
| [0] https://windicss.org/
| LAC-Tech wrote:
| I still prefer one big file called "style.css". So much easier
| than any of the "modern" solutions I've seen.
| 01brett wrote:
| Author here, I just looked at our frontend build and Create
| React App bundles our CSS into one big {webpack-hash}.css. It
| scales well for us because the frontend is a single page app.
| dwmbt wrote:
| i mentioned this in another comment but one takeaway i got from
| using tailwind is that it changed the way i look at css. i use
| it as a learning tool as well, which is something i rarely ever
| get out of solutions that try to do most of the heavy lifting
| in a project.
|
| consider this comment an open-invitation for other good css
| references!
| paulgb wrote:
| > consider this comment an open-invitation for other good css
| references!
|
| I'll take you up on that! Any good resources for learning
| tailwind that jibe particularly well with your "learning
| tool" approach?
| dwmbt wrote:
| i would say the tailwind docs themselves and looking at the
| examples were a big help. for instance, the way they
| visualize their flex elements was enlightening. also,
| learning about how atomic css is a useful paradigm was the
| biggest motivator for writing more meaningful and
| expressive css. i'll list some things i've bookmarked:
|
| [0] https://css-tricks.com/lets-define-exactly-atomic-css/
| [1] https://adamwathan.me/css-utility-classes-and-
| separation-of-... [2] https://acss.io/thinking-in-
| atomic.html
|
| and finally, it's always useful to read critiques. the
| following article is well written, in my opinion:
| https://www.browserlondon.com/blog/2019/06/10/functional-
| css.... through that i learned that tailwind has a useful
| feature: @apply, which you can use in conjunction with a
| standard css class approach. i.e container { @apply color-
| grey-100; box-sizing: border-box; }
| econnors wrote:
| this doesn't scale to any reasonably sized project or company
| LAC-Tech wrote:
| It scales further than you think if your html is clean.
| ravenstine wrote:
| Respectfully, in most cases, this is nonsense.
|
| Not everyone is working at even 1/10th Google scale. Most
| aren't working at that scale. The vast majority of sites and
| web apps can get away with a relatively minimal amount of CSS
| and modern CSS features in a one or a few concatenated files.
| For the rest of us, tools like Tailwind, SCSS, etc., are best
| treated as tools to help us be more efficient, and they are
| not necessities.
|
| If basic CSS doesn't "scale", then it's time to stop and
| think about whether one is doing the right thing.
| 1_player wrote:
| CSS stops being scalable much earlier than 1/10th Google's
| scale. Without rigorous practice, CSS' idiosyncrasies start
| getting in the way after 50 lines of it.
| pyentropy wrote:
| I honestly thought Tailwind is a sarcastic project mocking bad
| css class names until I found the Windi.css fork which has now
| inspired Tailwind JIT and it 'clicked'.
|
| Writing class="<md:content-center sans font-normal hover:font-
| semibold pt-[7px]" and having a media query for phones, proper
| flexbox centering, font face and weight stuff autogenerated
| without copy pasting and googling snippets is amazing.
|
| And you can reuse the same thing in any project without setting
| up imports and build steps and being constrained to a specific
| component framework. No selector specificity/namespace conflicts,
| just pure WYSIWYG.
| jarek83 wrote:
| For me it looks like all terrible concepts in one place. Please
| learn CSS, you'll see how fluid and easy it can be, and how many
| problems Tailwind introduces.
|
| I recommend going with Pollen if you really need some kind of
| framework for CSS. I believe that's the way to really help with
| CSS development without the burden of learning yet another layer
| of abstraction over simple CSS.
| stevebmark wrote:
| I don't get it. CSS Modules are designed to be combined with
| global utility classes. Using mainly utility classes is some
| OOCSS shenanigans we stopped doing literally decades ago. And
| CSS-in-JS has worse performance because styles aren't compiled to
| sytlesheets like they're supposed to be, they're applied at
| runtime. Downloading JS > parsing JS > executing JS > generating
| stylesheets > injecting stylesheets in to the DOM dynamically >
| repaint + reflows is how you get poor performance.
|
| CSS is a solved problem and that solution is CSS modules with
| global utility classes compiled to static stylesheets.
| jakelazaroff wrote:
| _> And CSS-in-JS has worse performance because styles aren 't
| compiled to sytlesheets like they're supposed to be, they're
| applied at runtime._
|
| That depends on the tool. Libraries like Linaria [1] ("zero-
| runtime" CSS-in-JS) do generate CSS files.
|
| [1] https://linaria.dev
| DigitalSea wrote:
| I've been using CSS Modules as well as Shadow DOM for styling for
| about 2 years now after ditching SCSS. I've switched over to
| using Shadow DOM and things like Constructable Stylesheets, but
| CSS Modules is still one of the best options for compatibility
| and ease of use (no boundary restrictions being the main one).
|
| I've tried to like TailwindCSS. I tried to use it on a project
| and I just found it so complicated and messy. People are quick to
| say, "Oh, give it time, eventually you don't need to consult the
| documentation as much" which is a strange thing to me, because
| for normal CSS it's rare I do have to consult MDN to know
| something (unless it's CSS Grid syntax). If you're new to
| Tailwind be prepared to waste hours just consulting documentation
| until "it clicks". You're basically learning a new language on
| top of CSS. And then the resulting markup in some Tailwind apps
| I've seen isn't easy to read, it ends up being no different than
| the randomised classes that CSS Modules gives you.
|
| CSS Modules work perfectly with design systems and other CSS
| additions. I even use CSS Modules with Bootstrap 5, it works
| well.
|
| I'm not saying Tailwind is bad, but there is a curve when you use
| it and given the amount of work I have on my plate, I would
| rather stick with my current approach than lose hours in
| productivity because I want to change how I write my CSS.
| oDot wrote:
| Tailwind's JIT is a joy to use
| 01brett wrote:
| Author here, Agreed. It feels like as big of a revelation as
| the original execution of Tailwind.
| gwn7 wrote:
| > The biggest drawback to CSS Modules is the lack of design
| system utilities.
|
| There is nothing preventing anybody from using design systems
| with CSS Modules.
|
| The author makes it sound like you need stuff like Tailwind in
| order to leverage design systems. This is completely misleading.
|
| > I have used Tailwind UI as a starting point and inspiration for
| my own components.
|
| There are loads of UI libraries you can use as a starting point &
| inspiration with CSS modules as well.
|
| The concept of a design system is orthogonal from one's styling
| solution of choice (CSS modules, Tailwind, CSS-in-JS).
|
| The author certainly knows how to write a blog post and does a
| good job at selling Tailwind. But in my opinion he doesn't have
| enough experience to give this kind of opinionated advice to
| others yet.
| vbo wrote:
| I wanted to like tailwind, but the html/tsx became so bloated and
| unreadable that I actually begun appreciating scss modules more.
| Separation of concerns and all that jazz.
| sodapopcan wrote:
| People often tout "separation of concerns" but it really
| doesn't apply here.
|
| The important concerns to separate are business/application
| concerns. Putting your JS in .js files, your CSS in .css files,
| and HTML in .html, it's separation of languages. You could
| argue that the three languages solve different problems but
| this isn't true. We have JS writing DOM nodes which HTML does
| intrinsically, we have CSS and JS doing animations, we have CSS
| that does styling but also CSS that does layout, HTML nodes
| that are sometimes there specifically for design or layout
| concerns. We should be focused on components here, which use
| the three technologies to solve one business/application
| problem.
|
| Tailwind can get a little ugly, but you are supposed to use it
| in conjunction with components. Personally, I don't find 10
| inline classes that much harder to read than 10 style rules on
| 10 lines.
|
| To each their own, of course!
| abledon wrote:
| you we're using @apply to extract into classes?
| chiefalchemist wrote:
| A Design System makes sense. It's the UI SME if you will.
|
| That said, in that context, I don't see the appropriateness (?)
| of something such as:
|
| .rounded-lg{ border-radius: .5rem }
|
| It's not abstract enough (for me). That is, if the design system
| evolves that shouldn't become a code issue (e.g., remove
| .rounded-lg and replace it with something else). To me all that
| should be via CSS and only CSS. There sould be -as much as
| possible - a layer of abstraction between the code and the design
| system.
|
| Is it just me? What am I mis-thinking? Or does CSS in JS all but
| eliminate such a possibility? But isn't that what a design system
| helps to resolve?
|
| Help?? :)
| nsonha wrote:
| functional css is basically anti design system. Some will deny
| it and claim that they do have a design system implemented in
| functional css, but really all they do is adding a redundant
| layer between css and their design system.
| diab0lic wrote:
| > It's a choice that--in hindsight--I would make again.
|
| It is always truly satisfying when you land in this spot on past
| technical decisions.
| endisneigh wrote:
| It's kind of funny how things go. I've been using Tachyons since
| 2015 (before tailwind existed) - it was (and currently still is)
| very niche.
|
| tailwind comes along and surges in popularity. it really goes to
| show you that marketing makes a difference!
|
| for what it's worth I prefer tachyons because it's much simpler.
| robmerki wrote:
| It's because Tailwind looks good. It has well designed defaults
| & the documentation makes it look beautiful. I've used Tachyons
| before & enjoyed it, but it looks ugly in comparison.
|
| If you're picking a framework that will eventually be used by
| developers who might not have any design skills, which would
| you prefer?
|
| Tachyons shadows: https://tachyons.io/docs/themes/box-shadow/
|
| Tailwind shadows: https://tailwindcss.com/docs/box-shadow
|
| Tachyons colors: http://tachyons.io/docs/themes/skins/
|
| Tailwind colors: https://tailwindcss.com/docs/customizing-
| colors
|
| Even something like floats look better in Tailwind
| documentation despite being the same one line of CSS.
|
| Tachyons floats: http://tachyons.io/docs/layout/floats/
|
| Tailwind floats: https://tailwindcss.com/docs/float
|
| Part of it is marketing and part of it is the novelty of using
| inline utility classes, but none of this explosive growth
| happens without a deep focus on design at every stage.
|
| Documentation, defaults, examples, and color palettes all
| matter.
|
| This is somewhat apples to oranges, but look at Bootstraps'
| navbar example page versus Tailwind's (paid) examples. One is a
| cluttered mess, the other is a carefully designed list.
|
| Bootstrap 5 navbars:
| https://getbootstrap.com/docs/5.1/examples/headers/
|
| TailwindUI navbars:
| https://tailwindui.com/components/application-ui/navigation/...
| omnimus wrote:
| TailwindUI is not great comparison. Its a commercial product
| - bunch of snippets. You could build pretty similar thing
| with tachyons by replacing the class names to tachyons
| version.
|
| I like tachyons looks more than tailwind but you can change
| tailwind using config to look exactly like tachyons but you
| cant turn tachyons into looking like tailwind.
|
| So i use tailwind.
| bryanrasmussen wrote:
| based on just opening the first two links - if I was picking
| a framework that will eventually have to handle accessibility
| issues like wcag contrast rules I think I might say take that
| tachyons stuff.
|
| although probably making a decision like that based on how
| the documentation for the framework looks isn't actually
| reasonable.
| ilrwbwrkhv wrote:
| I think this hits the nail on the head. Tachyons out of the
| box looks really ugly whereas Tailwind out of the box looks
| far cooler.
| arawde wrote:
| tachyons is excellent, nice to have a small library and build
| from there
| 01brett wrote:
| Author here, I am a big fan of Tachyons, too. It was my first
| introduction to utility-class CSS as a styling philosophy.
| bryik wrote:
| Also a Tachyons fan. I looked at TailwindCSS, but stopped at
| the installation section. The recommended path to get it
| working with Create-React-App is to install a bunch of JS
| packages (PostCSS, autoprefixer) and to layer on another tool
| over CRA (craco)? No thanks, I'd rather just <link>
| tachyons.min.css and move on.
| SquareWheel wrote:
| Wouldn't that be necessary for tree shaking? Including the
| entire stylesheet would add considerable overhead to your
| production site.
| brightball wrote:
| As much as I hate JS packages, when I read why Tailwind is
| built the way it is...it made a lot more sense.
|
| You basically generate the kitchen sink in dev and then rip
| out everything you're not using when it's deployed so the
| actual package size is really tiny.
| 01brett wrote:
| Author here, while it's not the default, newer versions of
| Tailwind have an experimental Just In Time mode, which
| inverts the approach to generate styles as you type them
| rather than upfront. Using JIT has greatly sped up my
| development workflow. Changing the config is significantly
| faster than in normal mode.
| omnimus wrote:
| It might be partially marketing but there is one crutial
| difference between the two. I like default tachyons style a lot
| better than tailwind but tacyons cannot be customized (atleast
| it couldnt when ive tried it). Tailwind is essentialy postcss
| functional css system generator. I suspect most companies are
| going for specific colors/typography/spacing that fits their
| designs but follows tailwind naming. So that puts tachyons out
| of it.
|
| I couldnt use tachyons in type of work i do but i can tailwind.
| at-fates-hands wrote:
| Not sure why, but I thought Tachyons CSS was kind of the first to
| take this approach, but Tailwind certainly caught on much faster
| event though they came on the scene over a year after Tachyons:
|
| _Tailwind has amassed 21.8k stars on GitHub and it is being used
| by 38,749 repositories and has over a 100 contributors, it also
| has 73,791 weekly downloads on NPM._
|
| _Tachyons has 9.7k stars on GitHub, has 64 contributors, and has
| 26,384 weekly downloads on NPM._
| nsonha wrote:
| what about bootstrap or whatever came even before that? all
| these libaries do is adding more to that fundamental idea,
| nothing is conceptually new here.
___________________________________________________________________
(page generated 2021-11-04 23:00 UTC)