[HN Gopher] Tailwind CSS v3.0
___________________________________________________________________
Tailwind CSS v3.0
Author : pspeter3
Score : 790 points
Date : 2021-12-09 18:33 UTC (1 days ago)
(HTM) web link (tailwindcss.com)
(TXT) w3m dump (tailwindcss.com)
| yewenjie wrote:
| Seems surprising that no one has mentioned UnoCSS - the big
| umbrella of atomic CSS frameworks yet.
|
| https://github.com/antfu/unocss
| joshlemer wrote:
| I took a stab at using Tailwind a while back but I'm embarrassed
| to admit it didn't make much sense to me as someone with only the
| most basic CSS skills. And for some reason CSS to me has been
| something really hard to get any kind of foothold in and I've
| always ended up just resorting to big UI component libraries like
| Bootstrap. Any recommendations on skilling up in CSS for your
| average back end dev? Manning's "CSS In Depth" maybe
| https://www.manning.com/books/css-in-depth
| 1_player wrote:
| Before you ask, as it happens in every Tailwind post, what is the
| point of this when CSS "promotes" reuse and separation of
| concerns, have a look at @ 5e92cb50239222b comment:
| https://news.ycombinator.com/item?id=29501650
|
| And let me repeat what every Tailwind fanboy (like me) states
| every time this project is on HN: don't knock it till you've
| tried it. Look at the animated example in the front page. You'll
| never be able to iterate that quickly with CSS.
| LouisSayers wrote:
| Hmmm... as a non-tailwind user I just took a look.
|
| Maybe this shows my age, but it kinda looks like an extension
| of <b></b> <i></i> - you know, that stuff that we moved away
| from a long time ago...
|
| Isn't this losing the point of CSS - that our "content is
| separate from its styling"?
|
| I know I know, we often have to adapt our HTML to allow the
| styling to work properly, but this is only really true for
| layouts, not for colors / padding / margin / fonts etc.
|
| I understand that we now have people writing React apps and
| componentising everything, but if you litter your code with
| styles such as "font-semibold" and "font-sans", isn't that just
| going to mean you have a million places to change next time a
| designer decides to give your webapp a makeover?
| topspin wrote:
| > if you litter your code with styles such as "font-semibold"
| and "font-sans", isn't that just going to mean you have a
| million places to change
|
| If, instead, you litter your code with my-brilliant-semantic-
| class you create a different kind of problem. Requirements
| change and my-brilliant-semantic-class won't be sufficient.
| Now the choice is; alter my-brilliant-semantic-class and
| suffer all of the unintended side effects or abandon reuse
| and make another-brilliant-semantic-class.
|
| The likely choice is the latter and so applications become
| masses of ad-hoc, partially finished, inherently flawed
| styling abstractions scattered hither and yon among
| directories full of redundant styling artifacts, half of it
| long dead. How is that a benefit to some future re-designer?
|
| > next time a designer decides to give your webapp a
| makeover?
|
| I figure the odds of one approach vs the other being the
| greatest benefit to some future re-designer are about even,
| and my guess is as good as yours.
| 1_player wrote:
| One underrated problem with semantic naming and classic CSS
| is having to repeatedly do one of the two hardest problems
| in computing, that is naming things, 5 times per minute
| while you're trying to be creative. You constantly have to
| context switch between "design/creativity" and
| "logic/pragmatism" mental modes. It's awful, exhausting and
| doesn't enable any state of flow. The productivity loss is
| enormous.
| LouisSayers wrote:
| I think you're discounting the value of naming though.
|
| You don't refer to bananas as "the curved sweet yellow
| food that grows on trees", you simply refer to a banana
| as a banana.
|
| Sure, for one off items it might not make sense to name
| it but when you create design patterns then it's
| incredibly useful to be able to name things.
|
| Yes it may be hard and require you to think, but just
| because that is so does not make it bad necessarily.
| deergomoo wrote:
| In my experience the "one-off items" are far more common,
| simply because every one thing I _do_ reuse will
| typically have several child elements. Why am I naming
| the styles that represent the title of a contact card if
| I never use it outside of the contact card--which itself
| is probably included by referencing a file called
| "ContactCard.html" or whathaveyou.
|
| Of course, there's no right or wrong answer here, and I
| suspect it very much depends on what type of web systems
| you are building. I feel the entire debate is basically a
| special case of the question "do you make websites or web
| apps".
| hbn wrote:
| You can still call it a banana in Tailwind, but you'd do
| it with a component in your framework rather than a class
| name.
|
| If you plan on using bananas multiple times throughout
| your app, aren't you going to be pulling that out into a
| component anyway? So define that it's curved and sweet
| and yellow in that one place, and then insert an instance
| of it wherever necessary.
| topspin wrote:
| > "the curved sweet yellow food that grows on trees"
|
| You have (some variety of) cavendish bananas in mind.
| There are red, pink and blue bananas. They're not all
| sweet. The plants they grow in are not always "trees" but
| rather large fern like plants.
|
| And then that day arrives when you are required to style
| some variant of 'banana' you are forced to decide: do I
| break the world by messing with banana or do I make new-
| banana?
| LouisSayers wrote:
| I'm definitely going to have to do some research on
| bananas after this lol.
|
| In CSS land however you wouldn't break the world for a
| different banana, you'd simply add another class for the
| variant and style appropriately.
|
| .banana { // generic banana styles }
|
| .banana.musa-velutina { color: pink; }
|
| Of course not all decisions are going to be as
| straightforward, but I do think that there's a lot of
| value in keeping a website's items consistent.
|
| The work upfront to name things and build out concepts
| will pay its dividends as you extend a site or build out
| new ones.
| KarlKemp wrote:
| Nobody said that it's a bad experience to use. People say that
| it's _evil_.
|
| And, also, that it is made by and for the JS crowd that doesn't
| understand CSS nor the document hierarchy it depends on, while
| simultaneously considering it unworthy of any learning efforts
| since it's a girly making-it-pretty addition to a markup
| language, not a real professional STEM-grad-grade programming
| language.
| handrous wrote:
| As much fondness as I have for the pure separation-of-
| concerns CSS Zen Garden style, I have to admit I've yet to
| actually see it leveraged on a real project. In 20 years of
| working on the Web. I'm not sure I've ever seen a significant
| re-working of CSS to re-theme a site without also changing
| the markup substantially.
|
| In practice, maybe coupling the two doesn't actually do much
| harm, provided _consistency of approach_ is maintained and it
| doesn 't go quite as far as inlining CSS all over the place.
| lghh wrote:
| Why do you have the exact same tone and wording as this
| comment from a different user above?
|
| https://news.ycombinator.com/item?id=29502044
| lhorie wrote:
| Some technical thoughts as someone who could care less about
| fanboyism:
|
| - One point where atomic CSS frameworks are supposed to shine
| over conventional CSS is bundle size, since they (at least the
| good ones) compile to only a single rule for any used value,
| rather than potentially repeating rules for semantically
| different classes.
|
| - Another point where atomic CSS frameworks shine is just sheer
| volume of banging code out. When the bulk of your output is
| visual, mastering tools based on shorthands like tailwind,
| emmet, etc can feel very productive.
|
| - Purely atomic CSS frameworks can make some workflows more
| difficult, e.g. by having too granular call sites and not
| allowing "let's see what happens to the overall theme if I do
| this design change" iterative style of work, or because
| workflows that edit CSS on the fly via browser devtools can no
| longer be used to limit impact within semantic lines (e.g. "I
| want to change padding only on buttons, without breaking
| everything else that happens to depend on the same padding
| value"). There are both design-oriented and debugging-oriented
| workflows that are affected in similar ways.
|
| - You generally don't get visual regressions at a distance w/
| atomic CSS. This matters at organizations where desire for
| pixel precision and simultaneously fickle design teams are the
| norm. But conversely, "can we just change the font size to be a
| bit bigger across the site" can often run into issues of missed
| spots. On a similar note, designs may become inconsistent
| across a site over time due to the hyper local nature of atomic
| CSS oriented development.
|
| - Custom rules may as well be written in APL[0]; they usually
| aren't documented and it takes a "you-gotta-know-them-to-know-
| them" sort of familiarity to be able to work with them (or get
| back to them after a while).
|
| - There are some tools that mix and match atomic CSS with other
| paradigms. For example, styletron[1] can output atomic CSS for
| the bundling benefits, but looks like React styled components
| from a devexp perspective, and has rendering modes that output
| traditional-looking debug classes for chrome devtool oriented
| workflows.
|
| The main theme to be aware of: proponents of atomic CSS rarely
| talk of maintenance, so beware of honeymoon effect. Detractors
| often omit that traditional CSS (especially at scale) also
| requires a lot of diligence to maintain. So think about
| maintenance and how AOP[2] vs hyperlocal development workflows
| interact with your organization's design culture.
|
| [0] https://en.wikipedia.org/wiki/APL_(programming_language)
|
| [1] https://www.styletron.org/
|
| [2] https://en.wikipedia.org/wiki/Aspect-oriented_programming
| recursive wrote:
| What animated example? You mean the youtube video? I didn't see
| anything compelling in it over CSS. Stuff like "You can now
| style print media!". The only reason you wouldn't have been
| able to is because you were using tailwind. This new release is
| probably an improvement over tailwind v2, but I don't see any
| improvements over CSS.
|
| It's true that I haven't tried it. And I probably wouldn't, at
| least until someone can formulate at least a hypothetical
| advantage.
| arcdigital wrote:
| I don't think there's a youtube video embedded anywhere on
| the homepage, the animation under the get started button is
| not a video.
| recursive wrote:
| With the new understanding that the linked page is not "the
| homepage", I can see that now.
|
| However, there's definitely a very prominent youtube video
| on the linked page.
| https://tailwindcss.com/blog/tailwindcss-v3 That's the one
| I was talking about.
| cercatrova wrote:
| > animated example in the front page
|
| Not the blog post, the main landing page, ie
| https://tailwindcss.com/
| zodiakzz wrote:
| If you have a hammer... I am able to iterate orders of
| magnitude faster in Adobe Photoshop. Back and forth feedback
| with the customer and then the end result gets coded in non-
| spaghetti reusable, themeable HTML/CSS. Seems you're iterating
| at the wrong phase.
| crate_barre wrote:
| Depends. I've never used Tailwind, so I'll entertain your
| aside. If you are mostly doing flat design, truthfully you
| should be designing in HTML/CSS/JS. This is a failure of
| setting expectations for designers. If you can get developers
| to learn Leetcode, get designers to code their designs.
|
| Design in the browser with browser technology, it's just
| boxes, gradients and shadows for industrial level web design
| at the moment. You really shouldn't even be designing in a
| tool like Photoshop or Figma given the current design
| paradigms.
|
| You will not iterate faster than what I am suggesting.
|
| Edit:
|
| The reason why we are here, why something like Tailwind and
| MUI exist, is mostly because we need an abstraction layer to
| do what a designer does on a whim. You can flick a shadow on
| and off on a Photoshop layer and mess with the subtlety of a
| drop shadow with a slider. If a designer makes a fickle
| change, the developer needs this abstraction to make the
| fickle change as fickle as the thought that made it. That's
| why you have all these quick utility methods. The designer is
| one layer (no pun intended) removed.
|
| In 2021 (2022 really), it's shocking the amount of latitude
| we give designers to still not be able to do CSS. A half
| competent designer could have a modest style sheet that
| mostly captures their design instincts, yet here we are,
| unable to capture their whims and must now have an albatross
| utility library to have manual laborers capture the
| translation - all because ... they still won't learn basic
| shit.
|
| And for what ultimately? These aren't baroque art pieces, it
| is ultimately boxes with an aesthetic applied, all very
| describable with semantic HTML and CSS. But alas, our
| brilliant artists can't be bothered. Here, send me your
| masterpiece so I can transform it for you.
|
| Take the bootcamp on web dev. You are literally the people I
| want going there. Not the Classics major that needs money
| because they picked a stupid major. It's you guys that need
| it, and deserve it.
| robertoandred wrote:
| Nah, don't need designers passing along broken, useless CSS
| that has to be redone anyway.
|
| Let designers focus on designing, developers on developing.
| crate_barre wrote:
| Lol, bro, making their typography and layout changes is
| not really development. I'd much rather they just pick
| that up already.
| handrous wrote:
| > Design in the browser with browser technology, it's just
| boxes, gradients and shadows for industrial level web
| design at the moment. You really shouldn't even be
| designing in a tool like Photoshop or Figma given the
| current design paradigms.
|
| This is why all but the very best flat designs (which does
| _not_ always correlate positively with the size or
| reputation of the firm turning them out--looking at you,
| Google) look to me like something I 'd have turned out for
| a quick feature demo circa '05, with everyone at the table
| agreeing that, however nice the feature, a designer
| _definitely_ needed to take a pass at it before it was
| released.
| Griffinsauce wrote:
| > non-spaghetti reusable, themeable HTML/CSS
|
| The words of an open mind.
|
| Each of those adjectives are _very_ open to disagreement.
| zodiakzz wrote:
| Perhaps. But hard coded colors, hard coded layout (flexbox
| etc), hard coded margins, paddings hard coded everything
| right in the markup. Tailwind and those adjectives are
| mutually exclusive.
|
| Does nobody remember themeing forums software like
| vbulletin? Designers weren't allowed to touch the markup in
| the slightest and yet so many amazing themes were made.
| Why? Styling wasn't hard-coded in the markup. Hell,
| remember the insanely customized old.reddit subreddits?
| jf22 wrote:
| We should be comparing Tailwind to modern alternatives,
| not vBulletin CSS from 2004.
|
| FYI I'm a recent Tailwind convert so I agree that
| Tailwind is good, but your comment is like saying Tesla
| cars are great because they aren't horses.
| zodiakzz wrote:
| Whoosh. Well I prefer my "modern" alternatives to be
| superior than the legacy ones, not the other way around.
| jagger27 wrote:
| All of the things you mention, including colours, are
| configurable or at least overridable at compile time.
| It's just not swapping a CSS file like the good ol' days.
|
| I won't argue if one is better than the other.
| [deleted]
| lijogdfljk wrote:
| Any thoughts as to how Tailwind can handle dynamic plugins
| using Tailwind? Ie it seems Tailwind relies on tree shaking to
| produce sanely sized CSS. But if you have plugins which rely on
| Tailwind, you'd have to either ship the full sized Tailwind CSS
| _or_ they 'd have to duplicate CSS and ship with it.
|
| So far with this plugin/extension design i've not found a way
| to use Tailwind and also retain nicely sized CSS.
| aniforprez wrote:
| > it seems Tailwind relies on tree shaking to produce sanely
| sized CSS
|
| This 3.0 release has its biggest feature be JIT. If you read
| the linked blog post, CSS is no longer purged but generated
| dynamically by reading your source files and generating the
| TW classes you use. It's not tree shooken anymore
| lijogdfljk wrote:
| Appreciate the info! I'll have to figure out how the hell
| this works though lol, i watched the video and am still a
| bit perplexed, since i'm not using JavaScript. I'll be
| curious to see how i can hook into it
| hbn wrote:
| As far as I understand, the build system just scans for
| whatever Tailwind class names you use, and then generates
| them into CSS. Which is why you can't dynamically compose
| Tailwind class names and insert them into your markup,
| cause it wouldn't be picked up.
|
| Whether or not you're using Javascript doesn't matter (I
| guess unless you use the new CDN script which I haven't
| tried), but it does need to be run in a build system.
| lijogdfljk wrote:
| If it just uses regex over source material i guess it
| would be fine, though seems like it might hit a fair
| number of false positives if it's too loose. Too rigid
| and it might not work if you don't write your css vars in
| something that looks html-like.
|
| Will be interesting!
| hbn wrote:
| I've never looked into how accurate it is, but even if
| you get a few false positives, I'm not too concerned
| about a few extra characters being transferred in the
| grand scheme of things.
|
| The creator of Tailwind posted a comment in this thread
| that the Tailwind website itself, which uses way more
| Tailwind classes than a normal size would use (for
| demoing everything), only spits out 36.9kB of CSS.
|
| https://news.ycombinator.com/item?id=29503769
| droptablemain wrote:
| Any general advice for incorporating Tailwind into a massive
| legacy project with awful CSS architecture?
| marc_io wrote:
| This: https://youtu.be/oG6XPy1t1KA
|
| And/or this: https://youtu.be/cZc4Jn5nK3k
| cuddlecake wrote:
| > Modern aspect ratio API -- no more padding hacks, well unless
| you need to support Safari 14, which you probably do, but still.
|
| This is what makes me cry at night.
| stevebmark wrote:
| I'm not sure I get Tailwind still. Doing everything with utility
| classes and OOCSS / BEM are things we stopped doing literally
| decades ago. CSS modules still seem to solve every problem
| Tailwind solves, and better. CSS modules combine the power of
| global utility classes with locally styled components/locally
| scoped classes, and compile to static stylesheets, a requirement
| for performance. I'm not sure how Tailwind works, but any CSS
| that's built at runtime and JS and inserted into the DOM
| dynamically should be avoided, and is an example of favoring
| developer experience over end user experience. It's always
| surprising to me when the build process isn't front and center of
| any CSS framework, since that's the most important performance
| aspect. I'm not concerned about Tailwinds verbose CSS use since
| that's gzipped away, but the static stylesheet compilation aspect
| worries me if it's not front and center of the framework.
|
| CSS modules let you use the full power and control of vanilla
| CSS, without having to worry about styles bleeding across
| components. Sprinkle in your global utility classes for your
| design system and you're good to go. Or sometimes even better,
| abstract design into components like `<grid>` `<column>` etc and
| not even worry about the classname implementation.
|
| I know I'm missing part of the picture, because of the hype and
| joy that people report from Tailwind. What part(s) am I missing
| that move folks from the power, beauty, and simplicity of CSS
| modules, to all-utility-classes-all-the-time Tailwind?
| freeopinion wrote:
| I build tailwind exactly once and it gives me a static css file
| with utility classes. I get local scoping from scope classes
| ala Svelte.
| slantyyz wrote:
| With Svelte, I just maintain a small reset file and maintain
| a list of native CSS variables that I can use from my Svelte
| components.
|
| I have not personally found the need to use Tailwind because
| of that.
| [deleted]
| wwweston wrote:
| > CSS modules still seem to solve every problem Tailwind
| solves, and better.
|
| I agree with most of what you're writing, but in arguing this
| out with people who seem to be enthusiasts, what I think I've
| discovered is that while there are existing (hell,
| longstanding) unbundled _technical_ solutions fully capable of
| solving the problems Tailwind does... they don 't solve the
| practical problems of channeling a group into a good-enough
| design system, and in fact many people who've been doing CSS
| have never actually really used a design system (especially if
| their experience is solely recent, and _definitely_ if their
| experience is only incidental in the sense that they 're
| application devs first). And many organizations don't have
| roles where someone can focus on solving this problem.
|
| Just-add-Tailwind _may_ hit an interesting pit-of-success spot
| for a lot of people in this position, where TW provides the
| atoms of the design system to scatter in a just-in-time manner.
| Sure, not elegantly, but practically.
|
| Personally, I'd prefer to work with people/orgs that don't see
| this is an optimum, but I might accept it as a situational
| local optimum.
| reaperducer wrote:
| I think this is not well understood.
|
| Tailwind is great if you're a startup, or someone who is a
| webdev and also has to be the designer. But in a large
| organization, with a company-wide style book, and a design
| department, it's not a good fit.
|
| Tailwind works for "I see this control in my head, and I'm
| going to code like this to make it happen." It's not really a
| good match for "I see this control from the design
| department, and I'm going to make it fit into the rest of the
| site codebase like this."
| tomnipotent wrote:
| > Sure, not elegantly, but practically
|
| Let's be honest, there isn't much elegance to the non-
| Tailwind solutions either. At the end of the day it's text
| input used by a rendering engine to style layout, it and your
| customers don't care how it got there.
| zachrip wrote:
| Based on what you've said, you're right, you don't understand
| it...the things you're comparing it to don't really make sense.
| Bem doesn't make sense to compare and neither do css modules.
| Tailwind is a stylesheet with css classes that do atomic things
| like changing border radius. It gives you a set of classes that
| allow you to build just about anything you need with just
| classes. When you compile an app that uses tailwind, it takes
| just the styles you use and puts them into a single stylesheet.
| So all of the things you claim to be wrong with tailwind aren't
| true. Tailwind is very performant because you only use the
| styles you need. It uses css variables for theming so there's
| no need to implement it in userland. It also uses css variables
| to do transforms which is very important because transforms are
| not additive in css yet. Even if you don't end up liking
| tailwind, the thing is executed really really well from the
| ground up.
| andrei_says_ wrote:
| I (not OP) get all of these, incl. the relief of not naming
| things.
|
| But I still prefer naming things to the class soup and the
| excessive repetition.
|
| ITCSS (Inverted triangle CSS) works with the cascade and
| results in clean, minimalistic CSS files.
|
| I do not build SPAs though and do get that quick styling
| works really well for that scenario.
|
| I do import Tailwind colors, spacing and sizes in SCSS maps
| for easy access and do like the standardized approach.
| colourgarden wrote:
| > ITCSS (Inverted triangle CSS) works with the cascade and
| results in clean, minimalistic CSS files.
|
| The real Tailwind lightbulb for me was understanding that
| the cascade and actual CSS files don't matter anymore - you
| don't need them. No more inheritance, no more naming, no
| context switching.
|
| I'm a big fan of ITCSS and was using Harry's methods before
| he coined the name but we don't need to fight the cascade
| any longer.
|
| > I do not build SPAs though and do get that quick styling
| works really well for that scenario.
|
| Admittedly, if you're not breaking down your UI into small
| components then Tailwind will get real messy, real fast.
| docmars wrote:
| Using Tailwind @apply to compose utilities into classes is
| a wonderful feature and gets you the best of both worlds!
| :)
| ksubedi wrote:
| Seems like you are basing your opinions on some misconceptions.
| Let me try to clear that for you.
|
| "CSS modules still seem to solve every problem Tailwind solves,
| and better."
|
| - Not necessarily true. Unlike css modules, tailwind removes
| the whole "think about a name for your class" mindset, reducing
| friction from the development process. It also unifies some
| base level design decisions like spacing and colors, which
| developers would have to rely on "best practices" otherwise,
| which don't necessarily get strictly enforced.
|
| "I'm not sure how Tailwind works, but any CSS that's built at
| runtime and JS and inserted into the DOM dynamically should be
| avoided, and is an example of favoring developer experience
| over end user experience."
|
| - You are right, looks like you are not sure how Tailwind
| works. Tailwind does not build anything at runtime, it all
| happens at build time. Tailwind will compile only the things
| you need (using the new JIT mode) into a css stylesheet which
| is sent to the frontend. Not much different from how sass or
| scss works.
|
| "CSS modules let you use the full power and control of vanilla
| CSS, without having to worry about styles bleeding across
| components."
|
| - Tailwind does not stop you from using vanilla css, but in
| most cases you do not need to. As per their website, you can
| think of it as an API to use parts of CSS, instead of CSS
| replacement. I think you are confusing Tailwind as a
| replacement for something like CSS Modules, but those two are
| completely unrelated. You can still use CSS Modules while using
| Tailwind. Think of it as an api to your design sytem just like
| you could think of an ORM as an API to your database.
| iruoy wrote:
| JIT mode basically means it recompiles your styles before you
| can press reload on your browser.
|
| Before they didn't have all colors enabled by default,
| because generating classes like `bg-blue-500`, `text-
| blue-500`, `border-blue-500`, etc. for all colors would
| increase the resulting CSS way too much. They did the same
| thing with variants.
|
| With the JIT none of that is necessary anymore. Plus you can
| use arbitrary values because it's being compiled now.
| aidos wrote:
| And even that is less magic than it sounds. Unless it's
| changed in v3, there's just a regex matching stuff that
| could be a class name and building a rule for it.
| /[^<>"'`\s]*[^<>"'`\s:]/g
| BatteryMountain wrote:
| The other thing is, building css the traditional way, after
| refactoring and renaming things a bit, I usually end up with
| something that looks very similar to tailwind syntax anyway.
| So might as well have a flavour of that we can all refer to
| and agree on than each person having their own set of
| utilities and naming conventions. That way I don't have to
| explain or write elaborate comments - I can just point the
| person to the tailwind docs. So it solves that kind of
| problem for me.
| colourgarden wrote:
| > You can still use CSS Modules while using Tailwind
|
| Recommended even. I use Tailwind with CSS Modules as a
| fallback when there's simply no way to achieve the result
| using Tailwind (rare) or it's prohibitively
| complicated/messy.
|
| Also for CSS hacks if you need to support an older browser.
| robertwt7 wrote:
| Aside from all of this. Try to use tailwind for 1 side
| project. You'll see the difference of productivity when you
| remember most of the tailwind classes as opposed to having to
| open another css file, create a class, then reimport them.
|
| I just can't go back without tailwind.
| danielvaughn wrote:
| I used Emotion for a few years (CSS-in-JS). I was so in
| love with it that I never thought I'd change to something
| else. But Tailwind converted me. I can't go back either,
| it's too powerful.
| docmars wrote:
| You can use both and gain the benefits of Tailwind-in-JS
| to dynamically apply utilities and arrays/objects of
| utilities composed together, all using a nifty wrapper
| library called "twin.macro".
|
| It sits on top of Styled Components or Emotion (your
| choice), and uses your project's Tailwind config
| faithfully, minus a few of the plugin features.
|
| It eliminates the need for JIT or PurgeCSS because it
| compiles Tailwind's utils with a drop-in Babel macro,
| eliminating the need for PostCSS.
|
| As a lover of vanilla Tailwind in Vue and Svelte
| projects, Twin Macro has made using it in React 10x
| better and I haven't looked back! :)
| ereveles wrote:
| +1, tried Tailwind and liked it, but when I found I was
| able to use CSS-in-JS with it with twin.macro i was
| amazed. Now is used on all my side projects.
| danielvaughn wrote:
| Just checked it out, looks nice. What I'd really like is
| a more concise way to apply tw classes in jsx. Something
| like this: <Button h5 w6
| bgBlue500 textWhite hidden={props.hide}
| />
| azangru wrote:
| > CSS modules still seem to solve every problem Tailwind
| solves, and better.
|
| I don't understand Tailwind either; but I find myself
| struggling with CSS modules when I need to override a CSS rule
| of a child from a parent. Like, say, my button should always be
| green, except in this context I want it to be purple, its font-
| size larger and its padding a bit different. With CSS modules,
| the parent component is unaware of the class name of the child
| component; so it cannot target that. Perhaps this should all be
| done with CSS variables; but then hell, how many CSS variables
| should my components expose? and besides, I am not even sure
| even they will completely solve this.
| mixedCase wrote:
| .button is the default .button-context is the context version
|
| className={isContext ? ".button--context" : ".button"}
|
| ----
|
| alternatively if you want many unrelated base rules that
| aren't color/padding as a baseline:
|
| .button contains base rules .button--default default
| color/padding .button--context contextful color/padding
|
| className={`.button ${isContext ? ".button--context" :
| ".button--default"}`}
| azangru wrote:
| Yeah, sounds sensible. What I've been doing so far was
| attempting to extend the base class like so:
| import classNames from 'classnames'; ...
| className = classNames(styles.buttton, props.className);
|
| But this leaves me at the mercy of the order in which
| webpack builds stylesheets (sometimes props.className will
| be defined after styles.button and my plan would work;
| other times it will get defined before styles.button, and
| styles.button will override the CSS rules of
| props.className).
|
| Really wanted the extension of the base rules to work out;
| but I guess you are right: the className from the props
| should override entirely one of the classNames of the
| component.
| docmars wrote:
| Use Twin Macro for Tailwind-in-JS -- you won't regret it!
| tshaddox wrote:
| I think Tailwind is multiple very different ideas in one
| library. One thing that Tailwind is is a set of primitives and
| design tokens that's just slightly higher level than CSS, but
| still lower level than a component library. I think it's pretty
| good at this.
|
| Another thing that Tailwind is is an opinionated delivery
| mechanism for your styles, in this case, as utility classes
| that can go straight into your HTML. This is probably a big
| cause of Tailwind's popularity, not because any one person
| necessarily loves using classes, but because it makes it
| extremely easy for _everyone_ to start using Tailwind in nearly
| any imaginable web project starting at plain static HTML files
| and going up from there. This aspect of Tailwind is something
| I'm not a huge fan of. To me it feels like a step back from a
| lot of higher-level CSS tools (like many CSS-in-JS libraries)
| to just go back to concatenating magic string literals into my
| UI code. All the official Tailwind tooling (AFAIK) either just
| watches your codebase looking for these magic string and
| generating the appropriate raw CSS, or doing it in real-time
| with their new JIT compiler (which I admittedly haven't
| investigated yet).
| laskdqflaksqdf wrote:
| I agree with this. I think the "set of primitives" part is an
| interesting, perhaps great, idea. Makes it easy to enforce
| consistency across your codebase. But I don't like the
| delivery mechanism--chucking all the styles in with the
| markup feels like it makes everything hard to read: the
| HTML/component declarations are harder to read both in code
| and in the browser, the individual classnames are hard to
| read (both because the names chosen are often gibberish and
| because parsing a dozen of them in a row is difficult), and
| the styles are annoying to debug in the browser (now you have
| to scroll through a dozen different utility classes to figure
| out what's going on).
|
| Personally I feel like a better approach is taking that same
| philosophy of design system primitives and executing it via
| something like SASS mixins, paired with single-file
| components a la Vue or Svelte. Then you can use better names
| (no need for brevity now), keep the styling separate from the
| markup (but still paired with it), and have a better
| experience debugging in the browser.
| dmitriid wrote:
| what do you think "high level" css-in-js libraries do if bot
| string concatenation, just watching your codebase with magic
| strings and generally ng raw CSS?
| tshaddox wrote:
| Plenty of CSS-in-JS libraries let you define design tokens
| somewhere and import them or access them on some theme
| object.
| dmitriid wrote:
| This doesn't answer my question.
|
| CSS-in-JS libraries are not magic that summons CSS out of
| thin air. They basically do the same thing Tailwind does:
| they watch your code for changes, they re-build/re-create
| raw CSS by, yes, often using string concatenation etc.
| irrational wrote:
| > Doing everything with utility classes and OOCSS / BEM are
| things we stopped doing literally decades ago.
|
| I don't understand what you mean by this. Literally decades ago
| would take us back to at least 2001. OOCSS, BEM, etc. were all
| created after that year. Wouldn't it be correct to say "Doing
| everything with utility classes and OOCSS / BEM are things we
| hadn't even started doing literally decades ago."?
| [deleted]
| Klonoar wrote:
| I don't personally care for Tailwind, but I get the reasoning
| why people gravitate towards it: just as modern JS moved away
| from inheritance to composition, so is CSS.
|
| There's a fundamental argument that inheritance is a mirage and
| things in large projects become much simpler with composition-
| based approaches. You don't really need to grok the inheritance
| chain with Tailwind in the same way you do typical CSS.
|
| For my personal projects I'd continue writing my own CSS... but
| for teams, I'd go to Tailwind without a second thought.
| Vinnl wrote:
| There's three things:
|
| 1. It removes a layer of abstraction that's redundant if you
| use a component-based UI framework.
|
| 2. It provides constraints that act as guardrails against
| introducing inconsistencies into a design.
|
| 3. Its tooling is not magic and does not have runtime impact.
|
| More detail at https://vincenttunru.com/why-tailwind/
| m0ngr31 wrote:
| I'm in the same boat. Started using Vanilla Extract
| (https://vanilla-extract.style) earlier this year and it's the
| best CSS setup I've ever worked with.
| aidos wrote:
| Tailwind is global utility classes too. There's no runtime
| aspect. It's literally just css classes. The nicest thing is
| that all your variations exist, so you can do things like
| hover:font-bold. So you can see the rules immediately like with
| inline styles, but they're more flexible.
| toastal wrote:
| Side note, most of the time you don't want to make a font
| bold on hover as most fonts this will increase its length to
| account for increased stroke width. It doesn't transition
| well either.
| stefan_ wrote:
| At least finally someone using the dirty word "inline
| styles". It's like all the other comments here stepped right
| over that point from the grandparent. Only it's not inline
| styles, it's inline styles and you are Dennis fucking Ritchie
| in 1970 and your fingers hurt from the teletype so you are
| making up crude abbreviations for everything.
| docmars wrote:
| As an engineer in his 30's, I've been quite vocal about how
| much my fingers hurt after coding professionally for almost
| 15 years.
|
| Tailwind is a f*king godsend XD
| arjunbajaj wrote:
| If you want to jump into learning and using Tailwind quickly, I
| highly recommend their official playlist:
|
| https://www.youtube.com/playlist?list=PL5f_mz_zU5eXWYDXHUDOL...
|
| It helped me a lot!
| plesiv wrote:
| With no disrespect to anyone, I think it'd be useful if people
| bashing Tailwind would briefly list what their day to day
| programming consists of.
|
| My impression is that most of the negative comments are coming
| from people that don't code for Web often (I could be wrong). To
| those folks: I'm not saying you don't know your stuff or that you
| argue badly - since I was on that side myself a few months back.
|
| What I am saying is that the elegance and pragmatism of Tailwind
| might not be easy to intuit just by reading about it. Try to
| implement a simple landing page using Tailwind+TailwindUI and see
| if any lightbulbs gets lit.
| neurotrace wrote:
| I've been a web dev for about 10 years. My day to day now
| involves building out React-based applications dealing with
| both the backend and frontend. I put in the work and built a
| real side project using Tailwind and it was so annoying.
|
| When you write anything substantial you end up with class name
| soup. The answer to this is to use `@apply` which is literally
| just a normal CSS class with extra steps.
|
| The new vernacular just means that users have to learn Tailwind
| language rather than proper CSS.
|
| CSS modules solve the main problems that Tailwind attempts to
| solve. The other things are solved with use of CSS variables.
|
| The only thing that I find useful in Tailwind is the responsive
| design classes. Being able to do `md:<some other style here>`
| is pretty cool.
|
| To me, Tailwind seems valuable to newer engineers because they
| feel like they don't have to learn CSS. They learn "Tailwind."
| It's like all those people who would say "I don't know
| JavaScript, I know jQuery." Like jQuery, there are benefits in
| having a unified language especially when you're newer. I
| believe that a better solution to styling is inevitable (my
| latest favorite heavily uses CSS variables). I do not believe
| Tailwind is the best way forward.
| azangru wrote:
| Sure. Frontend development, mostly on a single React-based
| project, for which we receive mockups from a dedicated
| designer. Using CSS modules, with SCSS (not sure we even needed
| the SCSS; we do sometimes use its nesting and ampersands; but I
| think we could have just as well written vanilla CSS syntax).
|
| Other times, I would write web components with lit. With shadow
| dom, web components would have their own little bits of CSS,
| which provides sufficient amount of encapsulation that neither
| CSS modules nor SCSS are really necessary.
|
| I don't have any problems with importing CSS from (S)CSS files
| or writing it inside of a LitElement-based web component. I
| don't have any problem with writing CSS by hand either. I find
| it strange that people would want to learn another domain-
| specific language for CSS, in addition to the CSS itself and
| DOM's camel-cased style dialect.
| gedy wrote:
| I really like Tailwind, and was excited to use it for a new
| application at our company. However, I find the lack of standard
| component classes (modal, card, button, wherever) pretty
| limiting.
|
| This makes it difficult to have open source Tailwind components
| that can be imported and themed differently for your apps. Even
| after buying Tailwind UI, they are basically just code samples
| that we'd have to copy into our own libraries and maintain.
|
| Again it's a really cool library, but feel the approach is
| probably better for smaller apps and teams.
|
| Daisy UI might help with this, but seems pretty small at the
| moment. https://daisyui.com/
| nomdep wrote:
| There is a headless (meaning unstyled) set of components from
| the same authors: https://headlessui.dev/
| gedy wrote:
| Thanks, yes but so few components compared to other solutions
| laacz wrote:
| I am the one who always has had issues with TailwindCSS. But now
| I know why. It's not because it's polluting HTML. It's because I
| am not one of those, who can whip up some cute buttons on the
| fly. I have no idea how to apply padding, chose fonts, colors or
| combine shadows. I'm better off with CSS frameworks which provide
| me with these things out of the box. TailwindCSS ir just a method
| for rapid designing, which I am totally incapable of.
| ggregoire wrote:
| As always when anything about Tailwind gets posted on HN... 200
| comments so far and (almost) not a single one about the actual
| blog post.
|
| Looking at the new features, I wondered why they went with a
| major version bump, but seems like it's because the Just-in-Time
| engine released in Mars as a feature flag is now the default
| engine, which is a pretty big change by itself.
| 946789987649 wrote:
| I don't think this is a tailwind specific thing. I see this
| happen with almost every framework/language update. There's
| more people who know about a language than people who know the
| language. So it will obviously deviate more to them.
| nickjj wrote:
| If anyone is interested I just updated a bunch of my example
| Docker apps to use TailwindCSS v3. That includes examples for
| Flask, Django, Phoenix, Rails, Node and Play.
|
| Here's a link to the repos:
| https://github.com/nickjj?tab=repositories&q=docker-*-exampl...
|
| It took longer to rebuild the Docker images than making the v2 to
| v3 Tailwind specific changes. In my case it came down to deleting
| and renaming a single property in my Tailwind config file.
| aruanavekar wrote:
| https://www.youtube.com/watch?v=gg43E_AOQko
| hsbauauvhabzb wrote:
| I like the idea of tailwind, I've dealt with raw css and
| bootstrap before but I'm certainly no frontend developer.
|
| How can I learn tailwind enough to become proficient? Most of the
| documentation I looked at seemed to lack any tutorial on how to
| locate the correct classes I need, or any other sharp edges that
| might exist,
| Kaze404 wrote:
| My process of learning Tailwind involved nothing but going to
| https://tailwindcss.com/docs, pressing Ctrl+K to bring up the
| search, and typing the class I'd use in "regular" CSS. Their
| search is great at picking these up.
| JasonCannon wrote:
| Agreed. My team is doing this very process. If we run into
| not knowing what class to use, we just look it up on the
| docs. VSCode also has a great intellisense plugin for
| tailwind as well (https://marketplace.visualstudio.com/items?
| itemName=bradlc.v...). For the first day or two we used the
| docs pretty heavily. Now, we just make a best guess,
| intellisense generally tells us what the class name actually
| is, and if we can't figure it out then we go to the docs.
| fadikhadra wrote:
| Congrats on the release, keep up the great work!
| jlelse wrote:
| Is it possible to use the JIT feature with Golang template files?
| francislavoie wrote:
| Yes, just make sure the `content` config will read your files:
| https://tailwindcss.com/docs/configuration
| jlelse wrote:
| Which template languages are supported? I wasn't able to find
| any information about that.
| francislavoie wrote:
| It's just regexes basically. All languages should be
| supported. If something that looks like a tailwind class is
| found, it'll add it to the list of ones it'll generate.
| aej wrote:
| Tailwind feels like the correct abstraction on-top-of css which
| works for 90% of use-cases.
|
| I struggled with css for many years but Tailwind has actually
| helped me improve my css - when I'm forced to write plain old
| css, my mental model of how everything works is much better. The
| fact that Tailwind has become so popular is a smell that css is
| slightly too low-level for most developers.
| alberth wrote:
| I inherently from a coworker who was terminated, a web app built
| with Tailwind.
|
| The tailwind.config.js is missing.
|
| I can't even begin to describe all of the reverse engineering
| I've tried to regenerate the config file with no luck and we're
| royally screwed.
|
| Make sure you don't lose that file!
| [deleted]
| Yabood wrote:
| Unless your coworker configured some plugins or extended some
| classes, a vanilla tailwind config with JIT-enabled should be
| all you need.
| alberth wrote:
| We have a customized theme (colors, fonts, etc), hence the
| issue.
| Yabood wrote:
| We've been using Tailwind for over a year now. We use it with
| Angular for our web application and with Gatsbyjs/React for our
| production website. I have nothing but love for Tailwind.
| lewantmontreal wrote:
| Has there ever been a front-end library/product so polished? The
| landing page and even this announcement and the video is just
| wow.
| notahacker wrote:
| Ironically, I had the opposite opinion on clicking the link to
| the blog.
|
| Sure, a Galaxy Fold is a pretty niche user device, but its
| genuinely the worst first impression of a mobile website I've
| ever seen, with everything weirdly scaled to sit in a narrow
| portion of my screen (other dimensions linked to px values on
| the video embeds maybe?). Had to load the link a few times to
| confirm I hadn't just accidentally zoomed out, since if I do
| zoom in it looks like a normal mobile stylesheet
| https://pasteboard.co/V0Cy3etIngpY.jpg
| 5cott0 wrote:
| Been a fan since V1 and to this day all I ever use are @apply and
| utility classes.
| nauticacom wrote:
| I find it funny whenever Tailwind people tout that you "don't
| have to name things." You still have to name your JS-framework-
| of-choice components, _and_ you still have names for each of the
| parts of a single component that get smattered with class names;
| it 's just that the name is implicit in your head now instead of
| explicit in the CSS
| ablekh wrote:
| If you would decide or have to use Vue for a complex project
| today, would you use Tailwind with Vue? If yes, why? If no, why
| not? Would your answer and rationale change in cases, when you
| decide or have to use a Web application framework like Nuxt or a
| UI component library like Vuetify and PrimeVue?
| ___q wrote:
| Arbitrary Properties (inline styles) can now use constraints (css
| vars), media queries, and hover/focus states, the reasons
| Tailwind said you should use their utility classes instead of
| inline styles in the first place :)
|
| https://tailwindcss.com/docs/utility-first#why-not-just-use-...
|
| https://tailwindcss.com/docs/adding-custom-styles#arbitrary-...
| asimpletune wrote:
| Is there a link showing the delta between v2 and v3?
| asimpletune wrote:
| From reading the blog post, it looks like they took most of the
| things that were experimental or first class plugins and
| graduated then into being native.
| yurishimo wrote:
| Here is the Upgrade Guide[0] and the Changelog[1]
|
| 0: https://tailwindcss.com/docs/upgrade-guide
|
| 1:
| https://github.com/tailwindlabs/tailwindcss/blob/master/CHAN...
| Accacin wrote:
| I tried Tailwind not long ago and really liked it, but setting it
| up with Create React App seemed a bit of a hassle as I couldn't
| do it without replacing the build, run, and watch scripts with
| something else I'd forgot the name of.
| hiimshort wrote:
| I tried Tailwind (and a similar project Windi) on a few projects
| now and have some findings.
|
| Tailwind aggressively speeds up development time of components by
| allowing me to stay in the same cobtext when styling things. The
| brevity of class names also dramatically shortens the time spent
| writing styles. While working on the projects I'd setup with
| Tailwind, I felt far more productive.
|
| However, those were new projects. After completing them and
| needing to go back and modify or maintain them, the experience
| has been horrible. The resulting style declarations (as class
| names) are completely unreadable and unmaintainable. I've tried
| organizing them and splitting class names onto multiple lines,
| but it has only cluttered things.
|
| In my experience, Tailwind (and similar projects) produce styles
| that are effectively read only. They are superb when writing a
| new component and styling things from scratch, but maintenance is
| nonexistent.
|
| Because of this, I've now switched to using a CSS-in-JS solution
| to gain the benefits of in-context styling and still have the
| ability to write CSS declarations in a structured and
| maintainable way.
| docmars wrote:
| Why not use both? twin.macro is an excellent library that
| compiles Tailwind (and adds additional, useful variants) in
| systems like Styled Components and Emotion, so you gain the
| benefits of quick component creation, but the same pleasant
| maintenance of colocating utilities and styles/classes/objects
| composed of these utilities with your components.
|
| It's been an absolute dream in a decent-sized project so far,
| and even with some refactors.
|
| Regardless, it's not everyone's cup of tea, but depending on
| the UI framework of choice and the flavor of CSS you use, YMMV
| when it comes to dev experience.
|
| In Vue or Svelte, I wouldn't even use a CSS-in-JS solution
| because vanilla Tailwind to compose utilities into localized
| classes is a straightforward approach.
| slantyyz wrote:
| If you're using Svelte, you don't really need Tailwind (but
| are obviously free to use it), especially if you're using
| your own components.
|
| Svelte's styling is already pretty atomic as it is.
|
| With Svelte, I use a small global reset, and a global file
| containing native CSS variables (which I reuse across
| multiple projects).
|
| Most of my Svelte CSS is component specific (and in most
| cases, no classes are even necessary) and they can be themed
| by simply referring to the CSS variables in my global
| variable file.
| jarek83 wrote:
| The only thing I appreciate Tailwind for is that I started to
| dig deeper just to have even stronger hesitation against it, so
| I believe I've saved a lot of hours in my projects just by not
| using it. But it also got me stumbling upon solutions based on
| the CSS global variables and that's what I think is the CSS
| next big thing. They allow to stay with CSS within CSS layer so
| no leakage to HTML or JS.
| tomduncalf wrote:
| I found exactly the same with my brief experience with
| Tailwind. Great fun to write, couldn't make head nor tail of it
| when I came back a few weeks later. Perhaps this changes if you
| use Tailwind day in day out though!
|
| I've stuck with styled-components for now, though I confess
| that I've started to wonder if the the verbosity of creating a
| (styled) component for everything, passing props, etc. is a bit
| excessive since trying Tailwind.
| hajile wrote:
| I'm very surprised that people actually like tailwinds.
|
| I wrote HTML in a time when you used inline HTML attributes for
| styling. Changing one bit of the style meant visiting every
| single page to update everything (then making sure to test
| because you definitely forgot at least one place).
|
| CSS was an amazing idea for making just one place to put all
| your styling. You could now change one style and everything
| else would automatically update.
|
| Tailwinds feels like it's just a trip right back to the old
| inline styling right down to searching bunches of pages if
| you're making a styling update.
| kfajdsl wrote:
| Tailwind is best used with components. If you're repeating
| yourself, it should probably be a component.
| hbn wrote:
| We use Tailwind at my work and I personally find hopping into
| the template of a file I've never been in before super easy
| with it. With normal CSS I've usually got an HTML file and a
| CSS file side-by-side in my IDE, and I'm cross-referencing
| awkwardly-named classes in the template with a stylesheet.
| Sometimes these styles might be coming from a local, dedicated
| stylesheet, sometimes they might be coming from a global
| stylesheet that I might end up needing to grep through the
| project for in order to find where these styles are coming
| from.
|
| With Tailwind, I see a <div>, and I see all the styles on it,
| right within the template. I don't need to follow class names,
| or cross-reference between files, it's just there, where I'm
| already looking.
| proxyon wrote:
| we use tailwind along with a component system. works great.
| kumarvvr wrote:
| Tailwind works wonders in a component based system, but
| component styling ought to be very fine grained to ensure
| maintainability.
|
| I have created React components with TW, where the components
| are complex and large.
|
| However, breaking them down into tiny functional blocks,
| maintenance is easier.
| mythz wrote:
| Tailwind has to have the gold standard of library docs -
| impeccably well thought out with the fastest & relevant quick
| search UX.
|
| The invaluable utility of which ultimately convinced us to
| implement real-time search into our docs as well.
| nfRfqX5n wrote:
| congrats to the team, they've been moving at a solid pace while
| keeping the quality high. funny that this also continues to be
| one of the most controversial topics on HN
| d--b wrote:
| Geez, every time I see stuff from Tailwind I get so jealous...
|
| Tailwind is fine, but how they pulled off making tons of people
| pay for a css framework just blows my mind.
|
| I remember reading the "UI for developers" articles, and saw how
| they built up the hype. This was so well done...
| hbn wrote:
| You don't pay for the framework though?
|
| If you're thinking of TailwindUI, that's a separate product
| that's just a bunch of premade components built with Tailwind.
| You don't have to pay anything if you're just using Tailwind to
| write CSS, which is all I want it for.
| commanderkeen08 wrote:
| Every time Tailwind does something great and gets posted here,
| the conversation devolves into the same arguments: "I don't get
| it. It's just inline styles."
|
| What is it about CSS that gets people so offended and
| opinionated? If it were a new JS framework, few people would be
| saying "I just don't get XYZ. Use React". Is it because Tailwind
| is so drastically different and breaks people's core ideas about
| separation of concerns? Maybe it's because we all learned CSS
| very early and were told to do it XYZ and now challenging that is
| painful.
|
| If you honestly want to "get" Tailwind, go use it in a project.
| If you don't like it, don't use it. Nobody is going to change
| your mind in a comment and you'll never convince anyone to stop
| using it.
|
| Idk. CSS is what I least care about. It's a thing. I use it to do
| a thing. And I move on. I used SASS. Now I don't.
| jastr wrote:
| When you first hear Tailwind's concepts, they seem to
| contradict everything you know about good software design. When
| you try it out and begin to remember some of the class names,
| you get into a great state of flow - it's the high developers
| are always chasing.
|
| I can't help but feel that Tailwind detractors have never
| actually tried Tailwind or are too square to give it a chance.
| alphabet9000 wrote:
| regarding 'contraditing everything you know about good
| design' i feel this way about designing webpages using
| <table> elements. the constraint really forces you to be
| creative with using image elements to make everything fit on
| the page just right. styling with tables used to be popular,
| but then it went out of fashion, unfortunately. i'd like to
| see it make a comeback. i'm not being sarcastic either.
| wohfab wrote:
| It was "popular", because there was no good option to do
| stuff. Now there are plenty options. Tables are for tabular
| content. Using it anywhere else is a spit in the face of
| accessibility.
| alphabet9000 wrote:
| https://news.ycombinator.com uses <table> for the site
| layout, and it works great.
| winstonewert wrote:
| For me, the situation is: I gave tailwind a try. I hated it. I
| spent a lot of effort of ripping every last tailwind class out
| of my project.
|
| And yet, a lot of people swear by it and think its great. This
| really confuses me, and I'd kind of like to understand: how can
| other people like this thing that I think is terrible?
| aniforprez wrote:
| > how can other people like this thing that I think is
| terrible
|
| Cause it works for them? You cannot be the arbiter of what
| other people like or don't
|
| I hate CSS and I find the TW classes being right there with
| the HTML more helpful than class-hunting through a bunch of
| CSS files. React solves that somewhat with styled components
| now. I like having design guidelines set loosely about things
| rather than writing reams of CSS myself. I like having media
| queries defined right there in the HTML. I LOVE the
| flexibility it offers me and how quickly I can iterate
| through concepts and styles
| CRConrad wrote:
| > You cannot be the arbiter of what other people like or
| don't
|
| That's not necessarily what the GP said. The charitable
| reading is that they're genuinely, open-mindedly, asking
| what they're missing that's so great about it, so they too
| might get to love it.
|
| Hey, maybe your explanation above does the trick.
| johnfn wrote:
| Yeah, it flies in the face of conventional wisdom and I think
| that bothers a lot of people. It'd be like if a new JS library
| came out that said you should make every variable a global.
|
| And just for the record I like Tailwind :)
| [deleted]
| zackbloom wrote:
| Having used it pre-release, the JIT compiler is really
| incredible. It makes Tailwind a sea-change when compared to
| Bootstrap and the other, similar, CSS toolkits.
| bamboozled wrote:
| Coming from someone who mostly does platform / service work and
| usually avoids "the frontend", tailwind helped me to actually
| understand CSS, it made sense to me and has saved me a lot of
| time. The site I built looked professional very quickly and
| without much effort.
|
| Thank you to the team and I look forward to using it more in the
| future.
| tomcooks wrote:
| Why have very spurious html, intertwined with the presentation
| layer?
|
| Are you going to update all your HTML in a year when a fresh new
| hip library lands on your HN homepage?
| seanwilson wrote:
| I used the JIT version recently on a new landing page with code
| completion for class names in my IDE and found it great. The
| distance between what I'm picturing in my head and what I have to
| type to see that on the screen felt so much shorter and less
| fatiguing than the standard CSS approach.
|
| With the regular way, to style something that's probably not
| going to appear elsewhere, I'm having to: come up with class
| names, annotate the HTML with them, repeat some of this
| annotating in a CSS file, jump back and forth between files to
| tweak the styles, use the web inspector to figure out which CSS
| class is overriding another then jump to the right CSS file to
| fix it etc.
|
| Tailwind classes are also faster to type and flip between when
| you're experimenting (e.g. editing "mt-5" to "pb-3" vs "margin-
| top: 4.25em" to "padding-bottom: 2.75em") and you get less
| distracted because it has sensible defaults and helpful
| guardrails (you rarely need all the possible attributes and range
| of parameter values CSS has available).
|
| I also rarely had the super irritating and common CSS scenario
| where you edit a style and it doesn't change and you have to go
| investigate to find out why e.g. something is overriding
| something, your selector is wrong, and even after all that maybe
| you undo the edit because it doesn't look good. Plus you no
| longer have the fear that tweaking a shared class to going to
| break some completely different page.
|
| I feel that beyond some building blocks, trying to create
| reusable CSS classes with cascading styles has similarities to
| using excessive abstraction and deep OOP class hierarchies in
| regular programming languages to avoid a little duplication.
|
| I also don't have a problem with styling stuff appearing in my
| HTML files either as long as the right HTML tags are used around
| the data. HTML files are already full of class annotations and
| divs that are only there for styling yet this doesn't cause a
| problem to e.g. browsers, screen readers or crawlers.
| z3t4 wrote:
| The trick with CSS is to write semantic HTML and avoid div,
| span and css classes. You can of course inline css too (used
| mostly for optimization to prevent layout shift, but is also
| fine for elements/classes that are not repeated, such as the
| top menu, top banner/intro and header/footer)
| nsonha wrote:
| what does semantic html has anything to do with css. Doesn't
| this make the look and feel of the page easily break on any
| change on the markup structure and content?
|
| Also does this comment even has a point? Like if we do what
| you suggest then no need of tailwind?
| seanwilson wrote:
| > The trick with CSS is to write semantic HTML and avoid div,
| span and css classes
|
| This experiment has failed though. CSS isn't powerful enough
| to style HTML however you want without having to add a soup
| of extra divs and classes that are only there for styling. No
| large website today works otherwise.
|
| HTML is still semantic when it contains styling markup (in
| the sense that a computer can read and understand the
| structured data from it) so I'm unclear what benefit is being
| missed out on. Whether you call a class "home-cta-subheading"
| or "text-center" so you can apply some styles doesn't make a
| difference to screen readers, browsers or search crawlers
| either.
| z3t4 wrote:
| The example on the Tailwind front page is pretty good
| semantic wise. Here's my version:
| <figure> <img src="/sarah-dayan.jpg">
| <blockquote>"Tailwind CSS is the only framework that I've
| seen scale on large teams. It's easy to
| customize, adapts to any design, and the build
| size is tiny."</blockquote>
| <figcaption><b>Sarah Dayan</b>Staff Engineer,
| Algolia</figcaption> </figure>
| seanwilson wrote:
| Now without modifying the HTML, how would I get the
| author's name only to appear on the right of the author
| image with the other text underneath? And add a line
| break before the company name? And make the word "tiny"
| use a small font?
|
| And if you need to modify the HTML, were the extra tags
| added 100% only for semantic reasons and not for
| presentation reasons?
| Yzupnick wrote:
| I often have trouble writing CSS. Here is how I
| approached this challenge. https://jsfiddle.net/mwabc719/
|
| Anyone have good advice on a better way?
| chrisseaton wrote:
| > without modifying the HTML
|
| > Here is how I approached this challenge
|
| ...but you modified the HTML?
| dragonwriter wrote:
| > ...but you modified the HTML?
|
| The original challenge includes questions that apply only
| if the resolution involves HTML modifications, which
| (contrary to the earlier text viewed in isolation)
| indicates that such modifications are not invalid in
| response to the challenge.
| Yzupnick wrote:
| Yah, maybe I should have been explicit, but I think my
| HTML change as semantically important. (My interpretation
| of the last line of the challenge.)
| mgkimsal wrote:
| You modified the HTML. And... I didn't see the output
| described in the parent in your fiddle. ?
| Kerrick wrote:
| It's possible if you substitute "without modifying the
| HTML" with "without modifying the HTML for styling
| purposes." That's because the HTML is adversely and
| unnecessarily bare-bones, missing semantic markup that
| the CSS could hook into if needed. Specifically:
|
| - There must be a logical reason for wanting to make the
| word "tiny" use a small font, so that word is missing a
| tag that represents that prosaic intent. I've used
| <small>, but depending on how you'd verbalize the word
| "tiny" (which is what you're representing both with
| making it use a smaller font and with wrapping it in a
| semantic tag), you might also wish to use <em> or another
| tag.
|
| - Similarly, there is missing semantic markup inside the
| <figcaption> for the person's name, job title and
| company. Those are semantically separate concepts for
| each other, but for some reason the example HTML was
| written without semantically differentiating them. This
| is much like trying to represent two paragraphs of prose
| with just a couple newlines, rather than actually
| wrapping each in a <p> tag. To fix this error, I've added
| tags as necessary to implement the semantic hCard
| microformat -- independently of styling.
|
| - I've also added the recommended attributes to the image
| tag, because it was missing. (And for the sake of the
| Codepen, I replaced the image's src with a placeholder so
| as not to hotlink from tailwind's site.)
|
| Given those improvements to the semantic structure of the
| HTML, here's how you can make the author's name appear on
| the right, with the quote underneath, with a line break
| before the company name, and "tiny" in a small font:
| https://codepen.io/Kerrick/pen/KKXgPYw
| seanwilson wrote:
| > There must be a logical reason for wanting to make the
| word "tiny" use a small font
|
| > - Similarly, there is missing semantic markup inside
| the <figcaption> for the person's name, job title and
| company. Those are semantically separate concepts for
| each other, but for some reason the example HTML was
| written without semantically differentiating them.
|
| Presentation/visuals aren't always tied so closely with
| logic though. "To make it look nice" is a valid reason.
| As I said, this experiment has failed. All modern website
| designs use divs + classes everywhere for styling. I
| agree extra semantic tags would be useful but at some
| stage you're going to be forcing yourself to come up with
| semantic reasons to add a tag when there isn't one.
|
| > I've also added the recommended attributes to the image
| tag, because it was missing.
|
| Related: alt="" is best practice for when an image tag is
| for presentation purposes only because images don't have
| to be there for semantic reasons.
| BurningPenguin wrote:
| I tried it just for the lolz and without changing a
| single bit of HTML. It's absolutely disgusting and nobody
| in their right mind should do this EVER! Only tested in
| Chrome, it might fail in other browsers. And on mobile it
| will very likely break.
|
| https://codepen.io/BlindPenguin/pen/GRMjjvq
|
| I'm off scrubbing my hands with a wire brush and abrasive
| cleaner.
| jolux wrote:
| I believe there are accessibility problems with using divs
| and spans where a more semantic element would suffice.
| seanwilson wrote:
| Yes, you should always be using the elements/tags with
| the most semantic meaning you can. When you need to add
| divs, spans and classes for styling reasons though,
| they're going to be ignored by screen readers so there's
| no problem here.
| jolux wrote:
| Yeah, I guess my concern is that a lot of developers
| don't really seem to understand the difference between
| semantics and style.
| meerita wrote:
| Exactly. Also you rely on the development criteria and
| developers switch jobs and they have different mindsets for
| architecture. The CSS ends with a soap of architectures and
| technical debt.
| Toutouxc wrote:
| > CSS isn't powerful enough to style HTML however you want
| without having to add a soup of extra divs and classes that
| are only there for styling
|
| Totally this. We say we've come a long way from using
| tables for layout, but for example you still can't use
| Flexbox without at least some non-semantic .stuff-container
| and .radio-with-label junk. Decoupled HTML and CSS have
| failed in the real world, outside of pet projects.
| nsonha wrote:
| I think grid is that powerful
| freebreakfast wrote:
| > CSS isn't powerful enough to style HTML however you want
| without having to add a soup of extra divs and classes that
| are only there for styling.
|
| Can you provide an example? I've never found this to be the
| case, particularly with modern CSS. Happy to be wrong
| though.
| andkon wrote:
| You've never put a number of elements together in a div,
| and added a class and styles to that div rather than each
| individual element? You should try it out.
| freebreakfast wrote:
| I do so for semantics. I don't do it for style.
| danielvaughn wrote:
| Just open up the inspector on any major website like
| Facebook, Twitter, Github, etc. How complex is the UI you
| typically work with? Once you get to a certain level of
| complexity, it's literally not possible to not end up
| with the div soup.
| freebreakfast wrote:
| It's definitely possible, but it's not done.
|
| And it's hard to take Facebook serious as an example.
| They're known to engage in HTML obfuscation on purpose.
|
| https://dev.to/ganderzz/how-facebook-avoids-ad-
| blockers-4mdc
| seanwilson wrote:
| Take a look at the https://tailwindcss.com/ page and
| search for "div". Can you replace them all with more
| semantic tags? If not, can you remove them and still
| style it the same way?
|
| You need divs all the time for layout (e.g. to group
| parents/children in the right way for flexbox), to target
| content for styling (e.g. putting a div around the name
| of the author to make it blue when you otherwise wouldn't
| tag it) and to get around CSS quirks (search for "wrapper
| div" for examples).
| freebreakfast wrote:
| This is a quick and dirty example.
|
| https://jsfiddle.net/gx4hk358/
| freebreakfast wrote:
| The discussion is not about the semantic expressiveness
| of HTML. There are certainly limitations, but these are
| limitations of HTML. The discussion is about whether or
| not "tag soup" (excessive HTML elements) is necessary for
| styling with modern CSS. I cannot think of an example of
| where it is.
|
| > Can you replace them all with more semantic tags? If
| not, can you remove them and still style it the same way?
|
| I looked at on the first four examples, but my responses
| are yes and yes.
|
| Take the figure example. The first div, which groups
| blockquote and figcaption, is extraneous and unnecessary
| for the end styling result. The second div is not
| extraneous because it exists for a purpose. The purpose
| of the second div is to place emphasis on the name or
| make it stand out. Thus, it should be changed to em. The
| third div is extraneous. With the HTML in place, grid it
| up.
|
| You have the container (figure) with two columns and two
| rows. The image sits in the first column spanning both
| rows. The blockquote sits in the second column on the
| first row. The figcaption sits in the bottom right-hand
| corner. Then tweak to get your img and other parts as
| desired (e.g., width, spacing, font-size, etc.).
|
| > You need divs all the time for layout (e.g. to group
| parents/children in the right way for flexbox) ... to get
| around CSS quirks (search for "wrapper div" for
| examples).
|
| Sometimes flexbox is the wrong tool. Sometimes floats are
| better. Sometimes grid is better. If you find yourself
| reaching for extra HTML elements first, you should stop
| and re-evaluate whether your approach to achieving that
| layout is appropriate.
|
| On quirks, my experience is that "quirks" are rarely
| actual quirks. They are usually a limited understanding
| of HTML and CSS.
| seanwilson wrote:
| Can you link to any complex designs you've worked on that
| only use semantic HTML elements and minimal divs/spans?
| Are you saying that any modern website that uses wrapper
| divs is from lack of expertise?
| tomcooks wrote:
| Not eparating concerns also fails VERY hard, but that bites
| you in the arse when you least expect or want it (unlike
| writing good CSS which takes only patience and studying).
|
| There's a reason why inline styles and important! were to
| be avoided
| rendall wrote:
| > _" CSS isn't powerful enough to style HTML however you
| want without having to add a soup of extra divs..._"
|
| This is untrue by any measure.
|
| This might have been true in the days before flex or grid,
| but with those additions, there is no need for extraneous
| styling divs.
|
| > _"...and classes that are only there for styling. "_
|
| That part is confusing. Classes? As in CSS classes? CSS has
| no other purpose than styling.
| LAC-Tech wrote:
| I agree. I think the real crux of the issue is that people
| find CSS hard, and are embarrassed about finding something
| that's "just a style sheet" hard, so they flock to more
| complicated alternatives.
|
| I'm really glad I just powered through that point and let
| myself feel dumb.
| lhorie wrote:
| > I used the JIT version recently on a new landing page
|
| Yeah, that's kinda the poster child use case for Tailwind and
| similar frameworks. Landing pages are all about being jazzy and
| unique and eye catching, and not so much about code
| reusability/composability.
|
| Where it gets less fun is when you want widget consistency
| across multiple areas of a site and across design tweaks over
| time, since now you have to deal with several `class="..."`
| strings across multiple files, possibly with class names in
| arbitrary order, possibly mixed with logic from other
| templating languages (be it from Django or JSX or whatever). So
| you can't just grep to achieve the objective of changing styles
| in one place to affect all instances of some semantic group.
|
| Personally I think comparing Tailwind directly against
| traditional CSS as a whole is painting in too broad strokes.
| There's a lot of CSS methodologies and also a lot of bad
| practices (e.g. using SASS indentation as namespacing mechanism
| and then running into the old problem of specificity), and
| comparatively, there's a lot more than Tailwind in the atomic
| CSS space, and more broadly, in the compiled CSS space.
|
| Utilities like Bootstrap (e.g. `class="btn btn-primary"`) for
| example share many benefits of both atomic CSS and "good"
| subsets of traditional CSS practices (namely, you get memorable
| short class names, which are also organizable along semantic
| lines). So there's definitely more shades of gray than just
| "atomic-css-is-the-best-thing-since-sliced-bread" vs "looks-
| like-lazy-style-attributes-lol".
| jeppester wrote:
| We recently started using a combination of tailwind and BEM
| instead of bootstrap.
|
| It means that we can have our own custom "button button--sm"
| classes - a single place to change general styling - and on
| top of that get all flexibility of the tailwind utils for
| edge cases.
|
| I don't think it's perfect, but it's so far much more
| flexible than bootstrap, and we don't need to duplicate loads
| of classes for each similar component.
| meerita wrote:
| Why would you need a button class when you can have that
| button in a component?
| meerita wrote:
| > Yeah, that's kinda the poster child use case for Tailwind
| and similar frameworks. Landing pages are all about being
| jazzy and unique and eye catching, and not so much about code
| reusability/composability.
|
| It doesn't matter, you can have an entire newspaper and
| perfectly done in functional css with incredible results
| without having to mastermind any architecture.
|
| http://minid.net/2019/08/12/in-defense-of-functional-css/
| dqv wrote:
| Looks like Tailwind has an answer to this: @apply.
| https://tailwindcss.com/docs/reusing-styles
|
| I am going to give it a try. The argument against using it is
| that it defeats the purpose of Tailwind, but I think its
| useful to start by spraying classes until things work and
| then moving those classes into e.g. btn-primary once the
| styles become stable and need universality.
| lhorie wrote:
| Yes, @apply exists, but is generally discouraged (and the
| rationales are given right on that page)
|
| > If you start using @apply for everything, you are
| basically just writing CSS again and throwing away all of
| the workflow and maintainability advantages Tailwind gives
| you
|
| Approaching it with moderation is probably worth trying
| though
| lewispollard wrote:
| It's the same as any DRY or optimised code: taking time
| and effort to make things overly DRY or optimised up
| front is a waste, building stuff out and then refactoring
| when you realise it's going to be repeated is a better
| workflow. With tailwind, that's simple because you take
| your string of class names, slap an @apply on it, and
| then use the new classname instead. No, it's not
| significantly different from just writing CSS then, but
| it's the workflow that's changed that reduces the
| friction between prototyping and then refactoring into a
| reusable design that makes Tailwind nice to work with in
| my experience (and I'm using it for a large-scale
| commercial project, not a landing page or static site).
| hbn wrote:
| I'm pretty sure the creator's intention is that you
| basically don't use @apply at all, except maybe edge-
| cases where Tailwind simply can't be used (for example, I
| think before v3.0 you couldn't set print styles, i.e.
| @media print)
|
| The intended method of not repeating yourself in Tailwind
| is using a framework, and writing the styles in the
| template of the component.
| 14u2c wrote:
| In the context of component based development, react etc., I
| believe what you describe is actually very beneficial. Think
| about a case where instead of doing something <button
| class="btn btn-primary"> you write an atomic component
| <MyButton> which uses tailwind internally.
|
| With this workflow:
|
| * There are no global styles that can have an unknown or
| unexpected impact on the application when modified.
|
| * The component's style is completely encapsulated. It can be
| placed anywhere in the application without worrying about
| inherited styles causing problems.
|
| edit: formatting
| have_faith wrote:
| Those benefits seem the same as the benefits of styled
| components or css modules?
| lhorie wrote:
| I mentioned downthread about a project called Styletron,
| which has styled-components-like devexp, but compiles to
| atomic CSS for the bundle size benefits.
|
| Another variation I've seen is a combination of atomic CSS
| and Mithril.js' hyperscript selector syntax, which lets you
| do stuff like this: const Button =
| 'button.bg-gray-900.px-6.text-white'; // JSX
| return <Button>Click me</Button>
|
| There definitely are interesting ways of applying atomic
| CSS beyond basic Tailwind usage.
| aaronbrethorst wrote:
| I use Tailwind utility classes extensively to create
| reusable components in a Rails app using GitHub's
| ViewComponent gem (https://viewcomponent.org)
|
| Occasionally, I'll use @apply directives to DRY up
| something that isn't easy to encapsulate at the component
| level, but 95% of the time, I can easily get by with
| utility classes.
|
| I try to avoid using hyperbolic-sounding language like
| 'revolutionized,' but Tailwind + ViewComponent has
| basically revolutionized the way I build user interfaces in
| Rails.
| zomgwat wrote:
| My experience with Tailwind + ViewComponent has been
| great as well. I've also had a lot of success with adding
| Sorbet typing to the view components. I often use Sorbet
| enums as view component options. The extra type safety in
| the view layer is very helpful.
| aaronbrethorst wrote:
| I hadn't thought about this. That's a really good idea.
| Thanks for sharing!
| stanislavb wrote:
| Thanks mate! I've been considering this path and may give
| it a go.
|
| Although, I'm still a bit nervous spitting utility
| classes all around. That sounds almost like inline CSS
| and almost unmaintainable.
| ratww wrote:
| The usage of utility classes only become an issue if you
| have unnecessary duplication of components. Say, two
| buttons that should be the same but are implemented in
| different places.
|
| IMO one of the interesting parts of functional CSS is
| that we can apply the same tactics we use for organising
| code to organising the styling.
|
| Also, with separated CSS, and especially with semantic
| CSS, there is often a fair amount of duplication that
| happens in the CSS code itself, which we programmers tend
| to be very forgiving of. Giving Tailwind more scrutiny
| than we do for our CSS ends up making our code more
| consistent, less duplicated and better in general.
| aaronbrethorst wrote:
| I had the same concern at first. I remained skeptical
| during my first couple days working with Tailwind, but
| came around pretty soon thereafter.
|
| I realized that all of my semantic CSS classes might as
| well have been inline CSS for all the good they were
| doing me on reusability. Utility classes are faster to
| work with, and, as long as you're componentizing
| everything, still going to give you consistent styles
| across your product.
| edwnj wrote:
| lol Its funny how this thread just turned into a review of
| tailwind.
|
| IMO Tailwind is awesome (and cant wait to try out v3). It took me
| a second to warm up to it but now it makes so much sense.
|
| You deal with a lot of minutia writing your own classes and since
| css is designed to be put in classes, it looks ugly when you add
| it to elements.
|
| Minifying the styles into structured classes makes life so much
| easier. Once you map out like 5% of the lingo, you can instantly
| play with it like lego blocks.
|
| I literally get the same feeling I had when I was first messing
| around with frontend. That feeling of
| power/possibilities/excitement when you can tweak a few words and
| shit changes on the screen.
| awestroke wrote:
| Since I learned to write semantic class names, and to compose
| using scss or react components, Tailwind feels like it would be a
| big step back. I get that it would be kind of nice to prototype
| in, but is anybody here using it for complex apps or UIs?
| yurishimo wrote:
| Funnily, I've experienced something of the same, but inverted.
| I was all in on semantic class names for years, then moved over
| to Tailwind for a few work projects and couple of years.
|
| Now I'm back working on a project with a team that is staunchly
| against TW and I'm having a hell of time getting back into the
| rhythm of naming things. Everything just kinda looks like a box
| so I'm having to go back to the the designer or team to pull
| out names for things.
|
| Definitely looking forward to when I can go back to using
| Tailwind at work and on personal stuff. The cognitive overhead
| is real.
| Griffinsauce wrote:
| On the contrary, semantic classnames feel like an enormous drag
| to me.
|
| Components are a better way to segment semantic pieces of
| layout. Styling is lower level and having to name each atom of
| it is an enormous PITA.
| pineconewarrior wrote:
| Netflix.
|
| Also, you can prototype your stuff and then use the "extract"
| functionality to create components with nice shiny class names.
| 5e92cb50239222b wrote:
| It's been discussed to death in the past.
|
| https://news.ycombinator.com/item?id=22422873
|
| https://news.ycombinator.com/item?id=28004515
|
| https://news.ycombinator.com/item?id=18084013
|
| https://news.ycombinator.com/item?id=26422286
|
| https://news.ycombinator.com/item?id=25332101
|
| From reading the previous threads, large projects are where it
| (apparently) really shines. Personally I didn't find it useful
| at all, but obviously YMMV.
| cschmidt wrote:
| If you're using components, then it works great. The css is
| local to each component, and you only have to make changes in a
| single place. I'm just doing a fairly simple app, but I can see
| it scaling well to larger projects.
| mixedCase wrote:
| Where's the benefit over something like deduped CSS/Sass
| modules?
| dkryptr wrote:
| I work on a large Next.js project that has at least 100 custom
| made components all using Tailwind CSS. It is, without a doubt,
| the best way to iterate and make changes. I will _never_ go
| back to manual stylesheets. Having a separate CSS stylesheet
| feels like context switching and breaks the flow of development
| in my opinion.
| autonomousErwin wrote:
| Super bizarre - I've found the opposite. I really like
| Tailwinds, it's great for getting up and running quickly if
| you're a one-person-team but as our team's grown, readability
| becomes quite a big issue (it's just not as clear as pure
| CSS/SCSS I find)
| gherkinnn wrote:
| It feels strange at first but then it's a bit like flying.
| [deleted]
| Mizza wrote:
| I've been a Bootstrap user for a long time, but I recently made
| the jump to Tailwind. It's not the revolutionary upgrade I was
| hoping for, but it's nice evolutionary step in the right
| direction. It's quite intuitive, but it doesn't get rid of most
| of the frustrations that come from doing layouts, as those come
| from the design of CSS itself. `@apply` makes the upgrade worth
| it though, it's easy to make custom classes from the Tailwind
| elements.
|
| The one thing I don't like is that the culture around Tailwind
| seems a lot more proprietary, like you're getting three quarters
| of a product that you need to buy the rest of, whereas Bootstrap
| felt like you got everything you could ever need for free.
| staunch wrote:
| It seems proprietary because there are ad links disguised as
| documentation links. You can't click "Components" anywhere on
| TailwindCSS.com or you'll end up on TailwindUI.com pricing
| page.
|
| It's fine that they want to make money but it's very confusing
| for a new user. Ultimately, they might make more money by
| dropping the shady links if it's turning away enough new users.
| s/Components/Tailwind UI/g
|
| across their site would be a big improvement.
| yurishimo wrote:
| I can maybe see how that could potentially be confusing to a
| brand new visitor, but how is it shady? It's a clearly
| labeled link that does take you to components made with
| tailwind. Are they supposed to link to all the freeware out
| there first?
| dcre wrote:
| If you're talking about Tailwind UI[1] -- I use Tailwind
| extensively and have basically never looked at Tailwind UI.
| It's just useful snippets of HTML styled with Tailwind. It is
| by no means required to get value out of Tailwind.
|
| I'm not sure what you mean by proprietary culture! Based on the
| fact that I've pretty much never seen anyone talk about it, I
| would guess (total guess, no real knowledge) that no more than
| 1% of Tailwind users have paid for Tailwind UI.
|
| [1] https://tailwindui.com/
| scubadude wrote:
| You have to do literally everything from scratch with
| Tailwind though, for example I never realised how much work
| is involved in a simple avatar dropdown / logout component
| (hidden full-screen button). Tailwind is much closer to raw
| CSS than Bootstrap. That's not a criticism, it's just a
| different value proposition.
| drusepth wrote:
| My favorite thing about Tailwind is all the sites that
| offer copy-and-paste components, ready to use (since you
| already have all the CSS, you just copy HTML-and-classes
| and it looks exactly how you'd expect). Sure, you can pay
| for TailwindUI, but you can also just browse (free)
| components from e.g.
|
| * https://tailblocks.cc
|
| * https://blocks.wickedtemplates.com
|
| * https://tailwindcomponents.com/
|
| * https://merakiui.com/
|
| * https://www.tailwind-kit.com/
|
| * https://www.tailwindtoolbox.com/
|
| Most of the sites I put together this year used an
| amalgamation of components from those sites for basic
| structure, and then just get customized to the brand and
| site function. I hate writing raw CSS and I would also hate
| writing raw Tailwind.
| hbn wrote:
| That's a bit of an odd criticism. I wouldn't expect any
| library/framework to offer copy-paste-able usage of itself
| as a feature.
|
| Tailwind is just a different way of writing CSS styles. Not
| a bunch of premade UI templates.
| Mizza wrote:
| That's what I mean, though. $250 for some styled HTML! I
| think that's crazy. Compare with Bootstrap, which has
| basically just as many snippets simply as part of the
| documentation.
| dcre wrote:
| I'm saying you don't need that and almost nobody uses it.
| There are tons of snippets in the Tailwind documentation. I
| just scrolled down the side nav and clicked a page at
| random:
|
| https://tailwindcss.com/docs/divide-width#add-borders-
| betwee...
| dcre wrote:
| Ok, I can see how if you're used to relying on the
| Bootstrap examples[1] you would experience the lack of
| such examples as a big hole in the TW docs. I guess I
| would argue that those examples don't go very far at all
| in a real-world application.
|
| [1] https://getbootstrap.com/docs/5.1/examples/
| randito wrote:
| I don't think it's crazy. It's a good business model for
| them and a way to monetize their work on Tailwind.
|
| Spending $250 in order to get a well implemented and well
| designed HTML and CSS framework for your app sounds like
| money well spent to me, depending on the circumstance.
|
| If you're an expert or pro at CSS, then yes, that's
| expensive. But if you have a little budget and need to make
| some quick progress on a new site, it's a great deal.
| Hiring someone who can recreate these designs and give you
| exactly what you want is probably going to cost more than
| $250.
| lghh wrote:
| I think $250 is perfectly reasonable. If it saves you a few
| hours, it's already paid for itself.
| imilk wrote:
| I paid the $250 and it's an incredible time saver for
| prototyping & making decent looking, fully responsive
| internal apps for clients. Based on the number of billable
| hours saved, it's paid for itself many many many times
| over.
| ipaddr wrote:
| Just started with tailwinds and similiar thoughts. A framework
| like this without components.
|
| Try daisyui as a tailwinds plugin. It comes with the missing
| components. It also allows you to replace your 80 character
| style for buttons with btn btn-primary.
| marstall wrote:
| just got parachuted into a tailwind project. have to say I don't
| fully get it.
|
| the major stumbling block has been how tailwind is mostly just
| css translated into its own hard-to-memorize lingo.
|
| For example, say I want to do something basic like "display:flex;
| justify-content: start".
|
| In tailwind you would type "flex justify-start" instead.
|
| Which doesn't really follow any rules as far as how to get from A
| to B, so it's just a matter of having to look the magic word up
| in their docs each time until you memorize. And there are a _lot_
| of keywords (many modifiable according to n-dimensional
| properties) to memorize.
|
| I know there are handy slugs like "w-1/3" that encapsulate a best
| practice - but I'm a person who'd rather master the underlying
| mechanics of that best practice and be able to deploy, tweak and
| debug it myself.
| ponyous wrote:
| Yeah that's my issue as well and so much divitis and
| unnecessary nesting...
| aidos wrote:
| Can you explain what you mean by this? You're still applying
| css to html elements, it's nothing different, right?
| psygn wrote:
| I hear you. I don't understand the reasoning behind frameworks
| propensity to abbreviate things, especially at "atomic"/utility
| levels. I think it partially stems from wanting to prevent
| ignorant knee-jerk reactions like "hurr durr why not just write
| inline styles".
|
| I wish framework devs would just hyphenate (or even colon-ize)
| the CSS property names fully like "display-flex justify-
| content-start". I think Bootstrap does their own pattern like
| "d-flex", but all that does is require one to visit the docs to
| view some less common properties. Autocompletion pretty much
| makes typing these a breeze, and having less opinionated
| patterns for property names will make it less painful
| transitioning between frameworks.
| aidos wrote:
| I think that's a little uncharitable.
|
| One thing to consider is that being a bit more terse in
| tailwind is good because you effectively end up with media
| queries, dark mode, hover states etc all placed together.
| papertokyo wrote:
| You have to learn the more verbose CSS properties in the first
| place, and the vast majority of tailwind's class names include
| the unique keywords of those anyway.
| docmars wrote:
| Try using an IDE extension for autocompleting Tailwind's
| utilities based on your tailwind.config.js.
|
| Twin Macro is a great wrapper library for Tailwind-in-JS with
| strong IDE support and it autocompletes all my utilities. I
| barely have to type anything to style everything in my project.
|
| I can even hover over utilities to peek at its raw CSS.
|
| https://marketplace.visualstudio.com/items?itemName=lightyen...
| the__alchemist wrote:
| Spot on. Whenever you add a DSL like this, you need to
| carefully weigh costs and benefits. A hidden downside is that
| every new person who views your code base (And you in the
| future!) has to become proficient with the DSL. The base tech
| it wraps (HTML + CSS) is more fundamental; less overhead.
|
| Another way of saying this, is that Tailwind adds cognitive
| overhead.
| jesusthatsgreat wrote:
| The beauty of it comes when you're working in a team of say 5
| other front end devs of varying skill levels. There tends to be
| a large amount of duplication & overlap, people have different
| ways of doing things and achieving certain looks. If everyone
| agrees to use tailwind, you stop people from writing custom
| code which is ultimately a good thing because custom code
| requires custom comments and custom documentation etc which
| let's face it - nobody does or wants to do and even if they do,
| it's not maintained to the sort of standard tailwind docs are.
| aidos wrote:
| Not to mention, if your css isn't scoped (and let's face it,
| this is one thing traditional css sucks at) you just never
| quite know what rule some developer has put in somewhere at
| what else it effects.
| BoorishBears wrote:
| I don't do frontend except when I have to and "flex justify-
| start" is way easier for me to learn and explore with than
| "display:flex; justify-content: start"
|
| And the keywords all seem to make sense to me? It's
| "n-dimensional properties" but the dimensions are pretty
| consistent...
| seanwilson wrote:
| > the major stumbling block has been how tailwind is mostly
| just css translated into its own hard-to-memorize lingo.
|
| Autocompletion in your IDE makes this easy (the class names are
| similar to the CSS attributes, even in your examples, so you
| can usually guess them) and you use the same classes over and
| over again so you learn them quick. I barely spent 10 minutes
| in the Tailwind documentation the first few days because of the
| VSCode extension.
| marstall wrote:
| ah yes - that would be a big help. alas I am not a vscode
| user. I use webstorm and haven't been able to figure out how
| to get tailwind autocomplete to work with it.
| superfad wrote:
| Other than autocomplete, I would also suggest using this
| cheat sheet to help you: https://nerdcave.com/tailwind-
| cheat-sheet
| jpbow wrote:
| There's a plugin that you have to install to get it going
| https://www.jetbrains.com/help/webstorm/tailwind-css.html
| marstall wrote:
| oh I forgot to mention. ember. it's an ember project.
| something about handlebars not being supported yet.
| skipants wrote:
| In my experience it's because any web app with complicated
| styling rules tends towards this anyways, except all the CSS
| names are custom, undocumented, and duplicated. The main
| tradeoff is that the CSS names are not domain specific, but
| honestly that's worked fine for me.
| BadCookie wrote:
| Consider using this handy Tailwind cheat sheet:
| https://nerdcave.com/tailwind-cheat-sheet
|
| I have it open in a browser tab almost constantly.
| docmars wrote:
| This is wonderful, thanks for sharing!
| meerita wrote:
| > the major stumbling block has been how tailwind is mostly
| just css translated into its own hard-to-memorize lingo.
|
| This is the only problem of tailwind, it relies on its own
| lingo, as all the OOCSS/BEM projects. When you involve
| semantics, you will always bring these kind of problems.
|
| I covered this problem and I solved it with this approach
| http://minid.net/2019/04/07/the-css-utilitarian-methodology/
| dcre wrote:
| The difference is you type that lingo inline into the HTML
| instead of in separate files and you don't have to come up with
| any class names.
| animal_spirits wrote:
| Coming up with variable/class names is one of the most
| annoying aspects of programming, so any way we can eliminate
| that task I think is always going to be a productivity boom
| jeremyjh wrote:
| Yes, communicating intent to other programmers and our
| future selves is hard, so let's not do it.
| seph-reed wrote:
| So strange. Using good variable names is even better than
| docs in my experience. And having HTML where every div is
| named helps a ton. It blows my mind how different people's
| preferences can be on these things.
| cwaffles wrote:
| Memorizing and looking up names has significant impact on
| my productivity, especially on codebases that I do not
| touch frequently. I often losing my train of thought or
| momentum because of too much abstraction
| d3ckard wrote:
| Most people suck at naming things. Also, most companies
| don't have a strong culture for choosing names carefully.
|
| Honestly, I agree with you on the good variable names,
| but in average team setting I prefer no names than bad
| ones.
| matijs wrote:
| Those files (and components) still need sensible names (that
| would make very nice class names).
| tlamponi wrote:
| Sounds a bit like a glorified <el
| style="display:flex;justify-content: start;">... ?
| montroser wrote:
| Yes, or now with Tailwind v3.0 you can write that as
| <el class="[display: flex] [justify-content: start]">...
|
| I wish I were being hyperbolic, but alas, no:
| https://tailwindcss.com/blog/tailwindcss-v3#arbitrary-
| proper...
| drusepth wrote:
| To be fair, one of the big perks of Tailwind (IMO) is not
| having to have a big ol' folder of CSS that you have to
| figure out what applies where in HTML, but rather just
| having all your styling inline (while still staying
| consistent, which is the usual downside of inlining
| styles manually). Having to have a tailwind-addons.css
| when you needed random bits of CSS they didn't have
| classes for kind of sucked; this looks like a nice QOL
| that would get me back to the original goal of uniting
| structure-and-style into singular files.
|
| FWIW, I also hated using header files in C++ and also
| wrote a Ruby library for inlining all my tests
| immediately following the functions they test. I like
| having more context when looking at code without having
| to flip around from file to file to piece a bigger
| picture together.
| docmars wrote:
| The same reason Vue introduced single-file components!
|
| If you haven't tried Vue yet, I strongly recommend it
| based on what you said.
| drusepth wrote:
| Thanks for the recommendation! I've mostly been thrust
| into React, which works for what I need but I definitely
| don't _enjoy_ it. I 'll give Vue a shot!
| akvadrako wrote:
| Svelte also has single file components.
|
| It seems the biggest advantage most people find in
| tailwind is working around a react limitation.
| keyle wrote:
| Excuse my dad joke "There is a lot of wind at the end of
| that tail"!
| docmars wrote:
| This seems silly, but even this has benefits over online
| styles: it generates a scoped classname that wouldn't
| interfere with others, and you can use this syntax with
| JS conditionals to dynamically apply CSS with values
| interpolated if you need.
|
| Not much different than injecting an object in a `style`
| attribute in practice, but there's a lot of creative
| firepower in the arbitrary styles API.
| Tade0 wrote:
| Essentially.
|
| https://mobile.twitter.com/samthor/status/14028256680611307
| 5...
| moritzwarhier wrote:
| The differences are:
|
| * media queries
|
| * @apply
|
| * low specificity (tailwind doesn't do !important)
|
| EDIT: It "does" important, but only when instructed so, in
| 1.x it was a global switch, apparently since 2.x its
| available as a per-class modifier. Thanks dcre
|
| * the theming abstraction
|
| * brevity
| [deleted]
| nightpool wrote:
| In this scenario, "@apply" is just "a css class", so i
| don't think it's appropriate to list that as a benefit
| tailwind has over inline styles. In both cases you'd be
| defining the styles somewhere else.
|
| Media queries are a good call out, they're definitely a
| benefit tailwind's approach has to the built-in browser
| support for inline styles. Another benefit is hover and
| focus states, which are very difficult to apply with
| inline styles.
| dcre wrote:
| Tailwind does have important, it was added with JIT.
|
| https://tailwindcss.com/docs/just-in-time-mode#built-in-
| impo...
| aidos wrote:
| Oh, nice, I think that's a new 3.0 thing, not a JIT
| thing.
| dcre wrote:
| Looks like TW 2.2 from June. It wasn't in the initial JIT
| release in 2.1.
|
| https://github.com/tailwindlabs/tailwindcss/releases/tag/
| v2....
| aidos wrote:
| I'm...not sure how I missed that, because I did look for
| it. Thanks for the heads up!
| dcre wrote:
| Absolutely. But that's not a downside, that's exactly what
| I want.
| nightpool wrote:
| Then why not just type that, instead of having to learn a
| completely separate set of concepts to map to the
| underlying CSS properties & values? I program with inline
| CSS styles all the time when I'm prototyping something or
| building a page quickly.
| aidos wrote:
| Because inline styles aren't flexible enough to be used
| for everything, so you need to go out to external css
| eventually.
|
| With tailwind you can do "block md:flex hover:font-bold"
| and you've covered pseudo class cases and media queries
| very succinctly.
| psygn wrote:
| See https://news.ycombinator.com/item?id=29502652
| dcre wrote:
| It's much more concise than inline styles, variants and
| configuration give you a lot more power, and it's not a
| separate set of concepts. It's a subset of the same set
| of concepts.
| mixmastamyk wrote:
| It's like radio presets instead of the full dial. Dial is
| still available, but a great majority of the time you use
| the presets.
| marstall wrote:
| that gets long - especially if they are rendered inline, hard
| to scan through.
|
| I'm often in a cycle where I am tweaking a complex class with
| 10-20 properties including flex, transforms, animations, etc.
| - and having them each be on their own line (and the class
| being in a separate file along with its parents, siblings and
| children, frankly) is key for readability to me.
|
| I guess in the end I have come to have enormous respect for
| CSS as a powerful, mature language and I'm not looking to be
| buffered from it.
| dcre wrote:
| I don't think of it as an alternative to CSS. I think of it
| as a way of writing CSS.
|
| It can get long. I certainly have parts of my app where I
| break out into plain CSS because it's easier to understand.
| docmars wrote:
| I put most of my Tailwind utilities on their own line in
| my HTML, and for elements that need more than 3 or 5, I
| do the same but in classes or styled components where I'm
| listing them off instead.
|
| Keeps everything clean and readable!
| bamboozled wrote:
| This, I've used it only for about a week, there's no way I
| could go back now.
| matijs wrote:
| You're not wrong. Once it's in there, it's not easy to
| remove/replace again.
| agumonkey wrote:
| For toying / prototyping it's way nicer than I'd ever expect.
| Seriously fun. I now inject tailwing anywhere possible.
| mcgingras wrote:
| I don't have the energy to explain to the naysayers why I love
| tailwind so much but I do have the energy to log back into HN
| just to comment that I absolutely love tailwind. Give it a try
| and maybe it'll stick!
| ahallock wrote:
| I've been working with CSS for over twenty years, and Tailwind is
| the way forward for me. Some of the big benefits are:
|
| * No more worrying about naming class selectors. This frees up so
| much cognitive space. The less you have to worry about naming the
| better. I used the SUIT CSS naming convention before, which
| allows a mix, and that just creates friction. You need the same
| level of abstraction all the way through.
|
| * No more flipping between files. You edit your styles directly
| in the HTML. You will need to consult the TW docs, of course, but
| they're easy to navigate.
|
| * Tailwind is more than just inline styles. It provides a nice
| syntax for targeting breakpoints and little utilities for
| conveying more abstract styles/stacking rules.
|
| * TailwindUI is a great way to jumpstart a project and looks way
| better (IMO) than Bootstrap's components.
|
| * JIT is awesome
|
| I'd be remiss if I didn't mention some cons:
|
| * Looking at a bunch of class names in your HTML is at
| overwhelming at first. It's hard to delineate the structure.
| Using proper HTML elements, roles, etc. helps.
|
| * You will need to DRY up your repetitive styles by moving things
| to templates/components. So you still have to name things, but
| just keep it generic (alert, dropdown, badge, etc)
|
| * Sometimes you'll have to create class selectors when working
| with web frameworks and JS libs that require a single class
| selector option.
| jbergens wrote:
| I can just add that WindiCss is worth testing. In my small
| trials it worked a lot better than Tailwind with jit. Windi
| with Vite gives me a really fast dev experience.
|
| We'll see if UnoCss takes over.
| osener wrote:
| I am currently using Tailwind JIT and so far it has worked
| well. What does WindiCss or UnoCss offer over it in your
| experience?
| savanaly wrote:
| For those that don't know, the laundry list of new stuff is
| probably all enabled by the first item in the list, just-in-time
| compilation. This means anything they can dream up can be
| included as a utility class, without bloating the compile time of
| the 99% of projects that will never use the feature (also without
| bloating the css package size, but that's not new since shaking
| out dead classes for prod has been a thing since forever).
| brightball wrote:
| I'm so grateful that Tailwind has removed any analysis paralysis
| that I've had in the past on which CSS framework to invest my
| time in learning.
| manishsharan wrote:
| I used to use Zurb Foundation or Bootstrap for my personal
| projects but I found these two frameworks required me to use
| their javascript and their JS does not play nice always. So I
| moved to Bulma and that has served me well so far. I like not
| having to worry about CSS (it drives me nuts) and I would like to
| just focus on building components and functionality.
|
| Is TailwindUI an alternate to Bulma ?
| spiffytech wrote:
| > Is TailwindUI an alternate to Bulma ?
|
| Kind-of. People usually pick one or the other, but they're not
| alternatives in the same sense as Bulma vs. Bootstrap vs. Zurb
| Foundation.
|
| Bulma has opinions about structure and style, and its value
| proposition is providing out-of-the-box components so you can
| skip spending brain cycles on that design work. At a high
| level, Bulma believes projects reuse a lot of design patterns,
| and those shouldn't have to be rethought each time you need
| them.
|
| Tailwind doesn't care what you want your project to look like,
| or how it's structured. Tailwind's value proposition is
| streamlining you choosing your own design, and removing
| footguns from that process. At a high level, Tailwind believes
| cookie-cutter styles are typically less reusable than you hope,
| that you should instead optimize for tailoring design patterns
| to each place they're used, and that style reuse is better
| implemented by e.g., React components than a CSS framework.
| Tajnymag wrote:
| Bulma operates at a bit higher level of abstraction than
| tailwind.
| jerrygoyal wrote:
| TIL about css columns (a replacement of flex if you're not
| building responsive design) https://developer.mozilla.org/en-
| US/docs/Web/CSS/columns
| marstall wrote:
| got excited for a sec - very cool! then tried on Safari (v14) -
| no love.
| dorianmariefr wrote:
| You can have responsive columns, e.g. columns-sm
| bschne wrote:
| For those wondering "but separation of concerns!" or "but code
| reuse!", the dev behind Tailwind wrote a post about his thinking
| around this, which IMO makes quite a lot of sense, a while back:
|
| https://adamwathan.me/css-utility-classes-and-separation-of-...
| 734129837261 wrote:
| The problems he's tackling weren't problems, and his solutions
| are a bombardment of utility class names in your HTML,
| rendering it extremely and unnecessarily verbose. It makes the
| HTML less intuitive to read, too. A `<div
| class="user_profile">` is clearly a container for a user
| profile, a `<div class="here comes a shitload of tailwind class
| names because inline styles are now apparently cool again">`
| tells you absolutely nothing about what the hell is going on.
|
| I fucking LOVE CSS and Tailwind is an insult to the craft.
|
| Those who love Tailwind tend to not understand CSS beyond the
| basics, is what I've learned. Those who hate Tailwind know CSS
| inside and out.
|
| To each their own, but this example from their own homepage
| makes me want to vomit: <button
| class="flex-none flex items-center justify-center w-9 h-9
| rounded-md text-gray-300 border border-gray-200" type="button"
| aria-label="Like">
|
| Like what the actual flying fuck. This is inline CSS, period.
| And that's wrong, always. Tailwind makes me mad and angry
| because I love front-end development, I love CSS, and
| everything about this feels like a mentally challenged person
| spitting me in my face. Nothing I can do about it, they are
| challenged after all, but damnit it's annoying.
| hbn wrote:
| > A `<div class="user_profile">` is clearly a container for a
| user profile, a `<div class="here comes a shitload of
| tailwind class names because inline styles are now apparently
| cool again">` tells you absolutely nothing about what the
| hell is going on.
|
| You know what's going on if you're in a component called
| user-profile.component.html
|
| How often are you writing something like a user profile
| component in the context of something much larger? Also, what
| styles would the class "user_profile" even have? You say the
| second one "tells you nothing about what's going on," but I'd
| say it's the opposite. If you actually put real tailwind
| classes in the second one, I'd know exactly how that div is
| styled whereas the first one requires cross-referencing
| another file.
|
| "user_profile" probably has CSS implementation that have
| almost nothing to do with a user profile. It's probably a
| container that has maybe a margin, a max-width? The important
| styling details all come from the inner HTML and stylings on
| those things. So your "user_profile" class is mostly just
| another generic wrapper that you had to come up with a name
| for.
| seanwilson wrote:
| As an example, I'd say this isn't semantic HTML:
| <div>heading</div><div>bob is a person</div>
|
| This is better: <h1>heading</h1><p>bob is
| a person</div>
|
| This is less clean but has the same level of semantic
| detail in the HTML: <div
| class="container"><h1 class="home-heading text-
| center">heading</h1><div class="m-10"><p class="home-body
| color-blue"><div class="first-name">bob</div> is a
| person</div></div>
|
| Am I missing something?
|
| I think people conflate semantic class names (read by
| programmers and maybe ad-hoc web scrapers) with semantic
| HTML (read by screen readers, SEO bots). Semantic HTML is
| HTML that uses the appropriate semantic HTML tags, but
| including wrapper divs and CSS class names on top of this
| doesn't make it less semantic to a machine.
|
| For styling, when a utility class is all you need to style
| a particular tag and it's obvious from context what that
| tag is being used for, I don't see to reason to spend time
| trying to come up with a semantic name e.g. `home-hero-
| wrapper-inner`.
|
| To me, this is people dogmatically sticking to a "best
| practice" without thinking about the pros/cons and reason
| behind it. This is also related to the pipedream that HTML
| is for data only with nothing about presentation and CSS
| should be able to style the HTML without you editing the
| HTML.
| hbn wrote:
| > This is also related to the pipedream that HTML is for
| data only with nothing about presentation and CSS should
| be able to style the HTML without you editing the HTML.
|
| Which I also think is weird, because the hierarchy of
| HTML is inherently styling/presentation. If HTML was
| truly decoupled from styling, you'd just throw all the
| tags that you want into an HTML file and then arrange
| them around with CSS.
|
| That's why when you're using child selectors in CSS (or
| the nesting in SCSS that's transpiled to child
| selectors), you're forced to keep two hierarchies in
| sync, which makes it a huge PITA to refactor.
| seanwilson wrote:
| > That's why when you're using child selectors in CSS (or
| the nesting in SCSS that's transpiled to child
| selectors), you're forced to keep two hierarchies in
| sync, which makes it a huge PITA to refactor.
|
| Yep, trying to keep data and presentation separated like
| this comes with a lot of pain. Why bother? I don't see
| the practical benefits in real-life projects as long as
| you're still using semantic HTML tags.
|
| There's this other pipedream that the HTML is
| generated/written by people that aren't concerned with
| the presentation and then the CSS can be swapped in to
| style it however you want. You can and should do this in
| a sense that you keep your data/articles/posts in
| Markdown, SQL databases, behind APIs etc. - I think
| trying to split this further at the HTML/CSS level isn't
| gaining anything.
| danbruder wrote:
| we love to see it
| yasserkaddour wrote:
| I love Tailwind! It elegantly solves most pain points in writing
| CSS. However, it does this at the cost of readability, and you
| can easily end up with HTML that looks like this:
| <div class="w-16 h-16 px-2 py-1 m-1 text-sm text-white bg-black
| rounded md:w-32 md:h-32 md:rounded-md md:text-base lg:w-48
| lg:h-48 lg:rounded-lg lg:text-lg focus:bg-red-400 focus:rounded-
| md hover:bg-yellow-200 hover:rounded-t-md md:focus:rounded-xl
| md:focus:text-lg lg:focus:rounded-xl lg:focus:text-xl
| md:hover:rounded-xl lg:hover:rounded-xl">Yikes!</div>
|
| I would love to have a transpiler that produces the line above
| from a code like this: <div class="w-16
| h-16 px-2 py-1 m-1 text-sm text-white bg-black rounded"
| md="w-32 h-32 rounded-md text-base hover:rounded-xl" md-
| focus="rounded-xl text-lg" lg="w-48 h-48 rounded-lg text-
| lg hover:rounded-xl" lg-focus="rounded-xl text-xl"
| focus="bg-red-400 rounded-md" hover="bg-yellow-200
| rounded-t-md">Yeah!</div>
| cush wrote:
| Even spread out in attributes it's hard to read
| happytiger wrote:
| I moved to tailwind a month ago and it's become incredibly
| easy to read and work with very quickly. It's one of those
| frameworks that just clicks when people start using it,
| though I think a lot of people don't feel that way until they
| put the time in to get familiar.
| yasserkaddour wrote:
| Exactly! My example fit a just seven lines colocated with
| your HTML, in CSS you would need to read a full page in a
| different file.
| 65 wrote:
| What about a helper function for that? Something like this:
| const md = styles => styles.split(' ').map(style => 'md:' +
| style).join(' ')
|
| Then const styles = [ 'w-16 h-16
| px-2 py-1 m-1 text-sm text-white bg-black rounded',
| md('w-32 h-32 rounded-md text-base hover:rounded-xl')
| ].join(' ');
|
| Then <div className={styles}>Hello</div>
|
| I haven't actually tried this approach but it might clean some
| things up.
| hbbio wrote:
| https://windicss.org/ does it
|
| It also seems that the major speed improvement in Tailwind is
| inspired by windi
| yasserkaddour wrote:
| I looked into windicss before and didn't see the attributify
| mode https://windicss.org/features/attributify.html
|
| It's exactly what I was looking for, Thanks!
| pdxandi wrote:
| Oh wow, that's pretty handy. I hadn't seen that before,
| either.
| loeg wrote:
| (Formerly: dupe of https://news.ycombinator.com/item?id=29501125
| . The comments have now been merged.)
| gnabgib wrote:
| Other one is actually the dupe (posted slightly later, and a
| poor URL choice), but has gained more traction
| burlesona wrote:
| I'm ambivalent about Tailwind, but I've used it a lot. I will say
| the hypothetical advantages are mostly the following:
|
| 1. It's a step function over CSS units. This is the biggest
| strength, just standardizing that your design uses padding of 2,
| 4, 8px, but not 1px, 3px, or 1.23123em :). It provides more steps
| than you need, but still it's good that the core of Tailwind is a
| design system with defined unit and color variables.
|
| 2. _Some_ of the utility classes are very helpful. Even as
| someone who likes writing CSS, it 's nice to not need to give
| something a custom classname just because I want to put margin-
| top on it. class="mt-4", done.
|
| I think the problem is Tailwind goes too far and tries to replace
| EVERYTHING with a stack of utility classes.
|
| This works okay in extremely componentized web apps. It's a
| nightmare if your UI isn't highly componentized. I've seen
| projects where you make a button by copy pasting this ~80
| character string of tailwind classes all over the place, and then
| changing the color names if you need to. Good luck fixing that
| when the designer decides that we don't want any buttons to have
| rounded corners anymore.
|
| Personally I think the best parts of Tailwind are captured in
| Pollen[1], but I do wish it came with a subset of utility classes
| for colors, font sizes, margin, padding, and text alignment. I
| think the hard part is defining which subset is the right
| subset... I doubt you could find strong agreement from a large
| majority of developers on that.
|
| 1. https://www.pollen.style
| sibit wrote:
| I agree. I used Tailwind for roughly six months on a few
| projects before I noticed that I was only using the basic
| utility classes. I didn't like all the screen sizes and state
| "bloat" classes so I decided to take the best parts (margins,
| padding, background, font, text alignment) and create a simple
| CSS framework.
|
| For anyone interested, you can find it at: https://brixi.dev/
| JasonCannon wrote:
| >This works okay in extremely componentized web apps. It's a
| nightmare if your UI isn't highly componentized. I've seen
| projects where you make a button by copy pasting this ~80
| character string of tailwind classes all over the place, and
| then changing the color names if you need to. Good luck fixing
| that when the designer decides that we don't want any buttons
| to have rounded corners anymore.
|
| That app is done wrong. If you are using the same styles to
| represent a button you should use postcss and do
|
| .myButtonClass { @extend: (80 tailwind classes here) }
| jeremyjh wrote:
| Yes, there is a right way to do it. But in the code I've seen
| in the wild, people are often not doing it right and those 80
| char strings of utility classes are on the low side compared
| to some of what I've seen. I'm skeptical of Tailwind not for
| its own sake but because a lot of (most?) shops do not have
| the discipline to use it effectively. And what you are
| arguing here is basically a no true Scotsman defense.
| rattray wrote:
| I wonder if there's an ESLint rule out there to limit how
| many tailwind classes you throw onto one thing...
| markdown wrote:
| So now we have to add this new postcss thing. Modern web dev
| is bandaids all the way down.
| JasonCannon wrote:
| postcss is literally how tailwind works. If you are using
| tailwind, you already have postcss. I get it, you don't
| like modern frameworks. Don't use it.
| pier25 wrote:
| Doesn't that negate most of the benefits of using Tailwind in
| the first place?
| JasonCannon wrote:
| Not at all. You design and iterate on the button using the
| individual classes, then you swap them out for a concise
| class once you are done. It's how tailwind is designed to
| be used.
|
| https://tailwindcss.com/docs/reusing-styles
|
| Although I realize in looking this up in the documentation
| to show you, it's actually @apply and not @extend you are
| supposed to use.
| Toine wrote:
| Using @apply is the ultimate last resort though.
| ggregoire wrote:
| Or make a Button component in your framework of choice.
| function Button = ({ children }) => <button className={80
| tailwind classes here}>{children}</button>
| <Button>Create</Button> <Button>Edit</Button> // Same
| style <Button>Delete</Button> // Same style
| JasonCannon wrote:
| Even then, I would still recommend using the postcss extend
| tag. Much easier to read that way. Also, postcss doesn't
| require any frameworks, you can still do everything with
| plain ol' html and javascript.
| montroser wrote:
| No, we don't want all of the buttons to look identical.
|
| Some are big and some are small; some are bold and primary
| and some are muted and secondary; some have icons; some
| have shadows; some are disabled, etc, etc.
|
| It's easy to make them identical. The challenge is to be as
| flexible as necessary in a mature application, while
| minimizing verbosity and complexity.
|
| In my experience Tailwind hurts more than it helps here. It
| forces you to use your component system to abstract things
| which otherwise wouldn't warrant the extra level of
| indirection.
| jbergens wrote:
| If you a 100 different types of buttons I can see your
| problem, if it is more like 5 then you just create them
| first and then makes the code more DRY.
|
| For example when using React you can create 5 button
| components first and the refactor your code to make the 5
| buttons use/call a generic button. Or have 2 generic
| buttons if the combinations are hard to handle. The thing
| with atomic CSS like Tailwind is that it very easy to
| quickly create a few different buttons.
| Adrig wrote:
| You should look more into design systems. It's not only
| for Figma files but can structure your whole frontend. To
| extend on the example above, you can do something like :
| <Button variation="primary" size="large">Primary
| Button</Button> <Button variation="secondary"
| size="medium">Medium</Button> <Button
| variation="tertiary" size="small">Small</Button>
| reactor wrote:
| How would you have done it without TailWind? You'd still
| have to create classes for each of them in plain css
| anyway, except it would probably be in a different .css
| file. The inherent complexity pertaining to your app is
| not taken away, it just moved the places.
| montroser wrote:
| My point is that plain CSS is already good at this. So
| then you don't need to make more components with their
| own interface to learn. <button
| class="btn large shadow">Edit</button> .btn
| { ...default button styles }
| .btn.large { font-size: larger; }
| .btn.shadow { box-shadow: 0 0 8px #0004;
| }
| rgbrgb wrote:
| Tailwind always looks like a cool evolution of Tachyons [0] to me
| (with a build step). On the other hand, tachyons is really
| simple, you just drop it into your project with no build required
| (or drop the sass in), and I've never really felt like it was
| missing any features I wanted.
|
| Has anyone used both seriously who can compare?
|
| [0]: https://tachyons.io/
| 1_player wrote:
| I wanted to love tachyons before Tailwind was a thing. I jumped
| to Tailwind as soon as it released because it was configurable.
| The tachyons way of changing the defaults, such as colours or
| breakpoints, last I checked years ago, was using search/replace
| or forking the repo and adding your changes. Eh, no thanks.
|
| Tailwind is better in every way, and JIT is a killer feature.
| porker wrote:
| > Tailwind is better in every way, and JIT is a killer
| feature.
|
| I dunno, the smaller dev build from JIT is great, but it
| breaks my in-browser design workflow. Only the CSS styles
| needed are generated, so I can't make in-browser tweaks to
| see what a different padding/margin/other-property looks
| like.
| monkey_monkey wrote:
| Tailwind 3.0 has a JIT/CDN thing that allows prototyping in
| the browser.
| yurishimo wrote:
| I don't know that this solves their problem though. Even
| with the in-browser JIT, there is no class for the
| browser to autocomplete. One nice benefit of the old
| compiler, was every single class was available with
| autocomplete in devtools. Granted, if you already know
| the class you want to tweak and can guess the next
| correct step in the scale, it's fine, but for new code
| you're writing for the first time, I can see their
| argument.
| rgbrgb wrote:
| For customizing it, we copy the sass files and replace
| variables for colors and breakpoints. It's not what you
| usually do with a dependency, but Tachyons is feature
| complete and has very few (read: human patchable) updates.
| It's an easy way to have a custom style-guide in sass within
| a few tweaks.
|
| It's a pretty small and readable codebase, so while there's a
| downside that you can't upgrade it by incrementing a version,
| the upside is that you don't have an opaque upstream
| dependency and you can cut any fluff you don't need (though
| there isn't much).
| edmcnulty101 wrote:
| Hey great question! I was wondering that as well! They're both
| considered 'functional CSS' libraries. I used Tachyons after
| spending 5 minutes trying to figure out the build process for
| Tailwind and Tachyons worked great for the single site I used
| it on.
| sebmellen wrote:
| Tailwind is more like an editorialized version of all the
| features available in "vanilla CSS" than it is a UI library.
| Tachyons is a small, tiny UI library that enforces _(ugly)_
| standard defaults.
|
| Also, the naming of classes in Tailwind feels much more natural
| -- the tachyons naming is condensed to the point of being
| abstruse.
| gregsadetsky wrote:
| I've had the feeling that Tachyons is a bit abandoned, no? The
| album component/example [0] has been showing 404 images for a
| while. The last release on GitHub is from 2018.
|
| CSS frameworks don't ... need? to be state-of-the-art/updated
| all of the time (I get that), but at the same time, like
| anything else, once a component/css/etc. library falls behind,
| it (can) become harder to make it work with other tools.
|
| i.e. it's hard to abandon the bandwagon of constant new
| releases, as the second that you do, "stuff" sometimes starts
| breaking. This is of course a very general observation that
| doesn't apply to everything.
|
| [0]
| https://tachyons.io/components/collections/albums/index.html
| endisneigh wrote:
| Tachyons has been stated to be feature complete by its
| authors many, many times.
| chrysoprace wrote:
| I've always been a bit apprehensive of Tailwind but with the
| latest JIT compiler it actually seems usable. I'm happy to see it
| getting more use for mainstream applications but I wish it wasn't
| the "default" for a lot of open source projects.
|
| For example, several of the next.js examples[1] use tailwind
| without explicitly stating so, because I guess it's just become a
| ubiquitous as css stylesheets or modules for some people. The
| problem I find is that it adds opinion and mental overhead for
| people learning related technologies or trying to get a head
| start without an opinionated styling solution. In order to use
| something like the blog-starter example for next.js I have to go
| and learn tailwind and then come back before I can use their blog
| starter, where as CSS is universal. CSS works with every project,
| without depending on Tailwind.
|
| Anyway, looking forward to seeing newer improvements to Tailwind,
| but I hope that people will consider it an alternative to
| something like Bootstrap instead of an alternative to CSS.
|
| [1]
| https://github.com/vercel/next.js/tree/canary/examples/blog-...
| dstroot wrote:
| > For example, several of the next.js examples[1] use tailwind
| without explicitly stating so, because I guess it's just become
| a ubiquitous as css stylesheets or modules for some people
|
| I used Bootstrap for years and give MDO major props. I learned
| Tailwindcss actually because it was starting to show up
| everywhere and many of the Next.js examples were using it. Now
| that I have used it I would say it changes how you think about
| css and styling - it gives you more power and more guardrails
| and it also then ships a smaller css load to the client. It was
| always a struggle to carve away the parts of Bootstrap you
| weren't using.
| chrysoprace wrote:
| I'm sure it's very nice to use (I've been learning it in the
| past week), and I think it's a great alternative to
| Bootstrap. Personally, I'm not fully sold on it as a 100%
| alternative to styling with css (not least because you can't
| do pseudo element styling and have to add another node to the
| DOM). As someone who knows CSS, when I look at a template
| which uses tailwind I get overwhelmed because I have to
| mentally process what the 20 classes per node do in
| combination, where as I can look at a CSS module and
| (usually) instantly understand what's going on. Sure, once
| you've done a few tutorials and installed the VSCode
| extension you'll be able to find out what they do, but the
| code becomes almost unreadable for people not familiar with
| Tailwind.
| keewee7 wrote:
| The thing that made Bootstrap click for me years ago as a backend
| developer were these complete example layouts:
|
| https://getbootstrap.com/docs/5.1/examples/
|
| Is there anything similar for Tailwind CSS?
| kemyd wrote:
| I'm the founder of Shuffle, and Tailwind CSS is one of the
| technologies we support:
|
| 1. https://shuffle.dev/editor
|
| 2. https://shuffle.dev/components/tailwind
|
| 3. https://shuffle.dev/setup
|
| The tool is paid, but we have many free components/layouts more
| than Bootstrap docs.
| 0des wrote:
| Paying customer of Shuffle here, this is an answer to a
| different question. This is not what was asked.
| hipertracker wrote:
| Check
|
| https://daisyui.com/
|
| https://windicss.org/
| belter wrote:
| Not exactly the same but close? https://tailwindui.com/
| fgblanch wrote:
| What about tailwind UI components?
| https://tailwindui.com/#components
| keewee7 wrote:
| Tailwind UI looks like a proprietary product by the creators
| of Tailwind CSS.
| 1_player wrote:
| Define proprietary. You pay, they provide full HTML (with
| Tailwind styles) for all of their controls, that's the
| point. Worth the money IMO.
| elliottkember wrote:
| It's more like a series of templates. You copy them into
| your project and customize them. I used them for a big
| project and found them to be absolutely fantastic. It's a
| lifetime license for unlimited projects - the time I saved
| was very quickly worth the cost.
| reducesuffering wrote:
| All the free components with source code available are here:
| https://tailwindui.com/preview
|
| Rest cost $
| T3RMINATED wrote:
| https://dev.to/brianboyko/tailwindcss-adds-complexity-does-n...
|
| If you work in the front-end, you've probably heard a lot about
| TailwindCSS, a CSS library, much like Bootstrap. Much unlike
| Bootstrap, however, Tailwind takes a different approach - it is
| all "utility classes".
|
| And I am not a fan. I got a whiff of it and quickly learned the
| name is appropos: it was as welcome and useful as passed gas.
| acro5piano wrote:
| I love it
| ipaddr wrote:
| I just started using tailwinds. I found the daisyui plug-in to
| simplify the classes required and they add in the missing
| components.
| travisd wrote:
| I wonder what the future of code-splitting with Tailwind will be.
| With JIT and a large web app, it's easy to ship a massive CSS
| file even if 90% of the rules are unused on 90% of the pages.
| adamwathan wrote:
| Tailwind author here! Do you have an example of a site using
| the new engine that is shipping a massive CSS file where most
| of the styles are unused on most pages?
|
| The Tailwind website is only 36.9kB of CSS and it likely
| includes more classes than any other Tailwind site on the
| internet by virtue of the fact that it has to provide visual
| demos for so many of the classes. I don't think 36.9kB is
| massive personally, it's much smaller than the CSS of almost
| every website I've checked.
| [deleted]
| dorianmariefr wrote:
| And the usual release video:
|
| What's new in Tailwind CSS v3.0?
|
| https://www.youtube.com/watch?v=mSC6GwizOag
| drusepth wrote:
| I finally got into Tailwind a few months ago after originally
| HATING the paradigm shift, but it's started to grow on me --
| especially since most of the modern "material design" CSS
| libraries are starting to show their age and Tailwind fills a
| similar throw-together-something-beautiful-fast niche.
|
| This comes at particularly nice timing with Rails 7 releasing at
| the end of the month. I can't wait to pair the two and see how
| well the new features of each work together.
| Ataraxy wrote:
| The waterfall columns layout is really nice.
| kumarvvr wrote:
| _By far_ Tailwind has been _the_ fastest way for me to prototype
| UI.
|
| I am a developer nerd and have a good taste for design. However,
| during actual development, I do not have the ability to visualize
| what I want in the _first attempt_.
|
| So, I have to tweak the look and bring out the beauty I want
| through a 1000 cuts. TW makes that process extremely easy. Like,
| mindbogglingly easy.
|
| However, I have learnt to be careful with my code, and I often
| limit the styles by splitting them off into sub-components.
| weakwire wrote:
| Great! but the docs are on the offensive side: - "Yes, send me
| all your stupid updates" - "The new print modifier lets you style
| how your site should look when _animals_ (in strikethrough)
| people print it."
| skellera wrote:
| When did playful become offensive?
| weakwire wrote:
| Because by definition offensive has to do with how people
| receive something. I love the library, will continue using
| and donate, I would prefer the docs not to assume that people
| that print papers are animals. That's all! Take it or leave
| it.
| CRConrad wrote:
| But people _are_ animals. Apes, to be specific.
| greenie_beans wrote:
| i read that as sarcasm delivering a subtle critique on
| digital consumption in 2021 and how print has been killed
| by digital media (for most folks). obviously they
| acknowledge that people still want to read in print,
| otherwise, why would they bother to add this feature?
|
| maybe i'm reading into it too much, but i don't think they
| think print readers are inferior.
| [deleted]
| kevin_thibedeau wrote:
| They are.
| ___q wrote:
| Well it's not like they're expecting people to pay for...oh
| $279 for the UI kit eh?
| gjvc wrote:
| I want something like this which includes a few ExtJS-like grid
| (as in data table) and treelist classes for "enterprise" CRUD
| want-to-be-spreadsheets-when-they-grow-up apps. (point being,
| everything in a single toolkit)
|
| So much of enterprise IT is little more than glorified form fill-
| in, and yet so few CSS/JS libraries solidly cover these use
| cases.
| peterkelly wrote:
| I've never used Tailwind CSS. I watched the video "Just-In-Time:
| The Next Generation of Tailwind CSS" and all of it seems like
| they're solving problems that are entirely of their own creation,
| and doing so in an impressively complex way.
|
| The use case demonstrated was suppose you have a twitter button
| on your site, and it has to have a background color of #1da1f2
| because that is Twitter's brand color. Instead of writing
| style="background-color: #1da1f2" like a normal person they have
| a class name called bg-[#1da1f2], and their "JIT compiler"
| generates a named class with that property.
|
| In another part of the video, they use className="font-bold"
| instead of style="font-weight: bold". Apparently the advancement
| in this version is that instead of having all of those pre-
| defined classes they only generate the ones you actually use. The
| feature list for 3.0 includes the ability to use any color you
| want, and even arbitrary CSS properties that the framework
| doesn't explicitly know about.
|
| Is this progress? I could use the style attribute in 1999.
| [deleted]
| shepherdjerred wrote:
| I like Tailwind, but I felt the same thing.
|
| Tailwind definitely solves a problem for me. I don't like
| writing CSS, and Tailwind serves a (very) thin abstraction
| layer. I don't have to worry about reusing CSS, figuring out
| how to name my classes, or what CSS selector I need.
|
| I guess these features are helpful, but they're hilarious to
| read. "Arbitrary color support" is a release note you'd see in
| the 90's
| mping wrote:
| You miss the point. Using the style attribute everywhere causes
| duplication; using css classes can quickly lead to bloat where
| you have lots of unused classes.
|
| This is a way of paying only for what you actually use.
| jeremydw wrote:
| I don't think this is quite right.
|
| I'm not a tailwind user but I think the following:
|
| ``` <div class="flex">Foo</div> <div class="flex">Bar</div>
| <div class="flex">Baz</div> ```
|
| gets generated to:
|
| ```html <div class="flex">Foo</div> <div
| class="flex">Bar</div> <div class="flex">Baz</div> ```
|
| ```css .flex { display: flex; } ```
|
| If we replaced this with `style` attribute usage, you'd get:
|
| ``` <div style="display: flex">Foo</div> <div style="display:
| flex">Bar</div> <div style="display: flex">Baz</div> ```
|
| Assuming the content is gzipped when transferred (a good
| assumption), the non-Tailwind version's payload is smaller
| because there are no separate CSS definitions.
|
| Your statement is true in the general sense (a page can
| easily load unused CSS with other CSS/styling approaches) but
| I don't think it's correct to say that using Tailwind results
| in smaller payloads vs. using style attributes.
| bcrosby95 wrote:
| So the benefit of tailwind is not having to write
| "background-color". Got it. I don't know if its worth
| learning yet another framework for that.
| jeremydw wrote:
| Someone should make a compiler that converts inline styles
| to Tailwind so then you don't have to learn Tailwind but
| can still use Tailwind.
|
| For example it can convert `<div style="background-color:
| white">` to `<div class="bg-white">`. Perfect! (Yes, "bg-
| white" is the Tailwind way to make the background color
| white.)
| toomanydoubts wrote:
| Yet again, inline css has no support for media-queries,
| pseudo elements, states(hover, visited, active). Tailwind
| does. Tailwind also works as a design system, limiting you
| to a predefined font-sizes, spacing, etc. generating a
| consistent look-and-feel that requires discipline to do
| with inline styles.
| jbergens wrote:
| I think this video talks a bit about how Tailwind can be used
| efficiently.
|
| https://youtu.be/nqNIy8HkEQ8
| sbergot wrote:
| In case you haven't seen it this is an explanation that is
| worth reading: https://adamwathan.me/css-utility-classes-and-
| separation-of-...
| luisrudge wrote:
| Alright. Now add a media query to change the button size based
| on the device size. Or maybe use a different color on hover.
| You can't do that with inline styles.
| jacquesm wrote:
| You shouldn't need to do any of this in the first place if
| you followed the original recommendations for the WWW.
| papertokyo wrote:
| Use cases and expectations have changed somewhat in the
| last few decades.
| tekkk wrote:
| Well using square brackets is kinda not preferred with
| Tailwind. You'd rather use something like `bg-blue-400`. And
| even from your example you see that you are writing less
| styles. I agree that going outside what Tailwind provides is
| kinda non-optimal but in general it provides nice building
| blocks that makes keeping the design consistent easier.
|
| I was in the Tailwind is dumb camp also until I tried it. Then
| I realized I can ship my own prototypes faster because I wont
| waste time fine-tuning margins or picking colors. It isn't
| perfect of course but nice when speed is your top-priority.
| johnfn wrote:
| The point of tailwind - well, one of them, anyways - is to
| provide sensible defaults. You then snap those sensible
| defaults together and have good looking UIs without a lot of
| effort. The square bracket notation is a fallback for rare
| cases when those defaults aren't applicable.
| yurishimo wrote:
| Really happy to see this before the end of the year. The JIT
| improvements and comprehensive arbitrary value support will no
| doubt come in handy for quick one-off projects or bespoke landing
| pages.
|
| I'm happy they have also expounded upon some of the more common
| FAQs on the homepage, including the extraction to components.
| etchalon wrote:
| I've never understood CSS frameworks. CSS is the most lightweight
| thing I touch in the front end.
|
| It's predictable, there are a billion ways to accomplish things,
| and it's super easy to namespace yourself to safety.
|
| SASS I understand. It makes writing CSS faster.
|
| Tailwind feels like you have to learn CSS, but you'll never have
| to actually write CSS.
|
| Reminds me of CoffeeScript in that way. You always had to
| understand both It and JavaScript.
| marstall wrote:
| exactly. SASS (and CSS modules) are all I really need. just
| give me direct access to this amazing language, please!
| BigJono wrote:
| I don't even see a need for SASS now that CSS has variables
| and CSS Modules provides composability.
| etchalon wrote:
| loops!
| marstall wrote:
| I do use its inheritance functionality though I have mixed
| feelings about it. I also like how you can group classes
| with in each other.
| deergomoo wrote:
| For Tailwind in particular, it's easier to understand the
| benefit if you consider the three main problems it solves:
|
| 1. Naming things "semantically" is a giant pain. Sure "user-
| card" is easy enough, but when you have to start giving names
| to all the little bits of the user card it quickly becomes
| absurd. Yeah you can use child selectors and stuff to ease that
| a little but then you're basically re-writing your HTML in CSS.
| Tailwind's approach is to say "have a UserCard.{html,vue,js}
| component and move on".
|
| 2. Most codebases have multiple people working on them, and
| those people are often not CSS experts. It is very common to
| end up with giant stylesheets that only grow with time, because
| people are too scared to ever remove or change things in case
| it breaks something seemingly unrelated. Utility frameworks
| (and other modern approaches like styled components) keep the
| styles directly attached to the HTML being styled. You can make
| any change you like, safe in the knowledge that you are only
| affecting the thing in front of you.
|
| 3. It pushes you into a design system. Sure this is achievable
| through Sass/CSS variables, but for Tailwind it's right there
| with a sensible default out of the box, and easily configured
| if you need something different.
|
| I think the important thing is, Tailwind doesn't enable you to
| do anything you can't do by writing well structured CSS,
| because ultimately it _is_ just CSS. However, people aren't
| perfect, and I believe that Tailwind does a genuinely good job
| of helping people avoid common footguns.
|
| If your team is largely composed of CSS wizards who are fine to
| carry on as normal, that's great, you probably won't get much
| out of Tailwind. But for a lot of us, the price of remembering
| some (very consistent, to be fair) shorthand class names is
| well worth not wasting hours battling the cascade and suchlike.
| etchalon wrote:
| 1. Sure, but that's a bit like saying "inline styles solve
| the naming problem". They don't solve it, they just don't
| have it.
|
| 2. There are ways to structure your CSS so that's a mitigated
| issue.
|
| 3. It's not really a design system. It's a theme.
|
| But is it true that every developer I hire has to understand
| CSS. But mostly because I think it's an insanely simple thing
| to learn.
| rasulkireev wrote:
| Obviously this is not a solution for everyone, but tailwindui
| solves all my problems. From that point all the updates are
| suuuuper quick to make.
| rekoros wrote:
| Tailwind made it possible for me (backend developer) to write
| somewhat maintainable frontend code. It's a joy to use both as a
| writer and reader.
| runarberg wrote:
| There is a dead sibling comment which I will repeat with a bit
| kinder words, and with a different caveat.
|
| As a frontend developer I don't like Tailwind for several
| reasons, it brings the styling into the structure. As a
| frontend developer Tailwind is at a forefront of what I would
| consider bad practice and encourages a code style which would
| be a nightmare for me to maintain.
|
| That said. Tailwind seems to be loved be people who are not
| professional frontend developers. It seems to be just the right
| tool for people who are not necessarily proficient in CSS. And
| perhaps people like me (and the dead sibling) need to learn to
| let go and allow other people to have the tools which makes it
| easier for them to do the job which they are not experts at.
| For that reason I understand Tailwind, even though I don't
| agree with it.
| rekoros wrote:
| I like Tailwind _because_ it brings styling into structure.
| Dealing with external CSS has always been really challenging
| for me, and I 've always heretically used inline CSS.
|
| I mean header files are OK, and professional C developers
| probably love them, but not having header files is kind of
| great too :)
| skipants wrote:
| I think your comment has a lot of merit. Personally Tailwind
| has been awesome but I think it's because it makes all these
| abstractions for you. It also forces less experienced
| developers to follow this abstraction rather than making
| their own, which usually ends up as a ball of spaghetti.
|
| I have a similar comment elsewhere in the thread but it
| applies here too, I think: the main drawback of Tailwind is
| that it's extremely general. I'd imagine a well abstracted,
| focused, domain-specific set of CSS created by experienced
| frontend developers will be much better within that domain.
| toomanydoubts wrote:
| I have said it many times, but I'll have a go at it again.
| The reason why inline styles got it's bad reputation is
| mainly because we used to have no way of building reusable
| components. Nowadays, everyone and their mothers are using
| some kind of frontend framework that allows you to reuse
| components, so your inline styles can be mentioned once and
| used everywhere. It's not a problem anymore.
|
| Pair your tailwind with styled components and you can finally
| reach the dream of semantic HTML.
| valtism wrote:
| I am a professional frontend developer working on a large-
| scale react application and I love tailwind. I am proficient
| in CSS, but having colocated html (well, JSX) and css makes
| so much sense, and the design system really helps fast
| iteration while also keeping things looking nice.
| sombremesa wrote:
| I'm a professional frontend developer and I like tailwind.
| Being proficient in CSS is no more a badge of honor than
| being proficient in CIL.
|
| > encourages a code style which would be a nightmare for me
| to maintain
|
| What's a CSS code style that isn't a nightmare to maintain?
| You have one?
| progx wrote:
| As a frontend developer you should hear about components. Or
| did you develop websites not apps?
| runarberg wrote:
| I do components all the time, and I usually do component
| scoped styles.
| lghh wrote:
| I think TWCSS' argument is that we always were bringing the
| styling into the structure.
|
| Show me a site that has CSS Zen garden style replaceable
| stylesheets that totally overhaul the nature of the site.
| It's incredibly rare and almost always not worth the effort.
| What business says "I want to overhaul the styles of my
| application but change no structure at all. I'd posit it's
| near 0.
|
| Even if that's your goal, and I'd argue that it shouldn't be,
| you can still do that with TWCSS and the @apply keyword. You
| can write your generalized names then apply whatever twcss
| keywords you want to them separate from your document's
| structure.
|
| If your overhaul amounts to changing a "theme" you can easily
| do that with twcss. In fact, that's basically the point.
|
| I am a professional frontend developer and I love it.
| spoils19 wrote:
| Speaking as a non-cargo culting developer, Tailwind is evil. It
| doesn't understand CSS nor the document hierarchy it depends
| on, and almost every project that has had a frontend developer
| touch it has turned into an unmaintainable mess.
|
| Not to mention the tooling overhead. I had to revert countless
| JSP files due to strange compilation bugs that resulted in
| classes only sometimes(?) being added.
| nanna wrote:
| > Speaking as a non-cargo culting developer
|
| Remember the HN comment guidelines?
|
| > Be kind. Don't be snarky. Have curious conversation; don't
| cross-examine. Please don't fulminate. Please don't sneer,
| including at the rest of the community.
|
| https://news.ycombinator.com/newsguidelines.html
| [deleted]
| aidos wrote:
| It's not traditional css and you need to accept that if you
| want to work with it. It has a load of benefits in a
| different dimension to css, and personally I think they're
| worth the trade off.
|
| My main issue with it is the inability to control the order
| of precedence with the css rules. It's mostly fine, but when
| you have runtime rules around, say, colouring text based on a
| few different variables, it turns into a bit of mess.
| Unfortunately because of the way it works there's no way to
| implement "last rule wins" at runtime.
| JasonCannon wrote:
| I use tailwind with Angular, and we solve this with using
| [ngClass] to add/remove the class. You could do something
| similar with plain JS as well, and I imagine in most
| frameworks. Although yes, that is annoying to have to deal
| with.
| aidos wrote:
| That's not quite it.
|
| Say you're balancing a bunch of colours where it's say
| mostly black, but you need to change to green in some
| case and red in others.
|
| In css this is easy because you can say "for this
| situation I want this colour". And you can order your
| rules in a sensible way so the more specific cases trump
| the general ones.
|
| In tailwind you can't do that because "text-red text-
| black" etc is ordered by the order in which the utility
| classes are added to the page. So you have to make sure
| you don't add two conflicting classes.
|
| That case doesn't seem so bad, but once you get a few
| different properties to control and a few different
| scenarios, it gets pretty messy.
| trungdq88 wrote:
| Last time I tried the jit or purge mode, some classes were
| missing randomly each build and broke my site. (I followed their
| purge rules very carefully).
|
| The worst thing is it ONLY happens on the production build.
|
| I like Tailwind CSS and I really hope they make it stable.
| lukeholder wrote:
| This is FUD, it is being used very widely. I'm sure it has bugs
| but what doesn't.
| AltruisticGapHN wrote:
| I love Tailwind but now with these updates I'm like "ok
| whatever". Information overload.
|
| There is a point where there are so many utilities; it's just not
| reasonable to ask me to remember them... and at that point where
| I can't keep them in my mind, then the "framework" loses some of
| its appeal and benefits.
|
| Of course I suppose it's up to the user to decide what they want
| to remember, and it is the nature of the framework to become
| exhaustive.
|
| I don't really have an answer to this. Only that it further
| reinforces how TW is a tool, among others, and as it becomes more
| and more complex it can no longer become a "holy grail" sort of
| approach precisely because you lose the benefits of having
| "rails".
| hbn wrote:
| I have a subset of my more commonly-used classes memorized, and
| for everything else it has a fantastic docs site that I keep a
| tab of while working, which also got overhauled with v3.0
|
| https://tailwindcss.com/docs
|
| Cmd+K to search (it's also a pretty damn good, exhaustive
| search too)
| brainzap wrote:
| How do I make a button? I am too dumb to get the simple button
| working.
| gherkinnn wrote:
| <button class="px-3 py-2 bg-green-300 text-green-900">hello,
| brainzap</button>
| ___q wrote:
| Well that's easy, silly! <button
| type="submit" class="inline-flex justify-center py-2 px-4
| border border-transparent shadow-sm text-sm font-medium
| rounded-md text-white bg-indigo-600 hover:bg-indigo-700
| focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-
| indigo-500"> Sign in </button>
|
| A real joy compared to writing CSS, lemme tell ya.
| adamwathan wrote:
| It's fewer than half as many characters as writing the same
| thing in CSS: .btn { display: inline-
| flex; justify-content: center; padding: 8px
| 16px; border: 1px solid transparent; box-
| shadow: 0 1px 2px 0 rgb(0 0 0 / 0.05); font-size:
| 14px; border-radius: 6px; color: #fff;
| background-color: rgb(79 70 229); } .btn:hover {
| background-color: rgb(67 56 202); outline: 2px dotted
| transparent; outline-offset: 2px; box-shadow:
| 0 0 0 2px #fff, 0 0 0 4px rgb(99 102 241), 0 1px 2px 0 rgb(0
| 0 0 / 0.05); }
| dalmo3 wrote:
| And in 1/10th as many keystrokes with the vscode extension
| and autocomplete. Well done my friend.
| guanzo wrote:
| It's also all on one line which makes it harder to read
| than your example and massively bloats the HTML. I prefer
| readability over conciseness.
| adamwathan wrote:
| You can break it across as few or as many lines as you
| like, just like with CSS. .btn { display:
| inline-flex; justify-content: center; padding: 8px 16px;
| border: 1px solid transparent; box-shadow: 0 1px 2px 0
| rgb(0 0 0 / 0.05); font-size: 14px; border-radius: 6px;
| color: #fff; background-color: rgb(79 70 229) }
| .btn:hover { background-color: rgb(67 56 202); outline:
| 2px dotted transparent; outline-offset: 2px; box-shadow:
| 0 0 0 2px #fff, 0 0 0 4px rgb(99 102 241), 0 1px 2px 0
| rgb(0 0 0 / 0.05) } <button class="
| inline-flex justify-center py-2 px-4
| border border-transparent rounded-md shadow-sm
| text-white text-sm font-medium bg-indigo-600
| hover:bg-indigo-700 focus:outline-none
| focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500
| "> Submit </button>
|
| My experience (and the experience of thousands of others)
| is that in practice, an approach like Tailwind is much
| more maintainable, even if it's superficially ugly.
|
| At the end of the day it's a lot easier to understand
| what's happening in a template where you can see all of
| the styles directly attached to each node instead of
| having to map things together in your head across
| multiple files.
|
| For example, for me at least I can't believe how much
| more difficult it is to look at your average CodePen demo
| and understand what is doing what at a glance vs. looking
| at a Tailwind template. With traditional CSS there is
| just _so_ much indirection in comparison.
| [deleted]
| another_story wrote:
| Not OP, but I'm not worried about saving how many
| characters I type. We have autocomplete that fixes much of
| that problem anyways. I'm more worries about being able to
| read things others have written or even my own code when I
| come back to it. I tried Tailwind, and get the praise, but
| I still find it takes more time to read and understand than
| CSS. It just seems cluttered, and I couldn't get over that.
| gunshowmo wrote:
| Looks fantastic. My only concern using this in a full React
| project is its lack of interoperability with standard libraries.
| It seems like for the best experience, you either buy Tailwind UI
| to use with a tailwind project for anything except the most basic
| UIs, reimplement the Tailwind UI components yourself, or have a
| weird mix of css-in-js and Tailwind CSS. Although I love the idea
| of HTML-native inputs all the way through, I tend to immediately
| run into issues where using a native interface instead of a JS-
| based implementation harms the user experience.
|
| Props to the team though - I feel like this is something I'll try
| out for a marketing site.
| crooked-v wrote:
| You may be interested in Chakra UI (https://chakra-ui.com),
| which has low-level details (including default theming)
| basically identical to Tailwind CSS v2 but is built around css-
| in-js via Emotion.
| lghh wrote:
| I like Chakra...mostly. We have ran into some major
| performance issues with it all over our application though.
| The docs [1] make it sound like it's a rare issue, but we're
| not doing anything particularly wild and it became unusable
| at a point due to these issues. Now, we have a "no Chakra
| below this point" rule where certain parts of our application
| are not allows to use Chakra at all and use TailwindCSS + our
| own custom components instead.
|
| [1] https://chakra-ui.com/docs/comparison#the-runtime-trade-
| off-...
| nwienert wrote:
| Shameless self-plug but if you'd like the same idea but that
| works with native as well and has an optimizing compiler that
| outputs clean CSS at build-time, try Tamagui
| (https://tamagui.dev).
| gunshowmo wrote:
| This looks fantastic! Looking forward to diving in a bit
| deeper.
| gunshowmo wrote:
| Nice - I've seen a recent explosion of good libraries. I've
| seen Atlassian, Shopify, and others open source subsets of
| their own libraries as well.
|
| Another less popular one that I have had my eye on for some
| time is Mantine. It seems very polished and composable.
| tshaddox wrote:
| These days don't most popular React UI frameworks support
| passing classes to all the HTML elements they render?
| gunshowmo wrote:
| They do based on what I've seen, you're right. I'm speaking
| more to the consistency of styling across the project, but if
| the UI library is separated out from the rest of the project
| then it shouldn't actually be a concern to compose the
| components with tailwind-styled elements.
|
| Thanks for helping me think through it further!
| gherkinnn wrote:
| You're right as it probably won't work well with MUI [0]
| (formerly React Material) and similar options like Ant [1]. But
| they all accept a theme provider that could hook in to the
| Tailwind config. Never tried it though.
|
| But a swell of less opinionated offerings [2] [3] [4] (more and
| more the popular anyways) work well with Tailwind. In fact,
| when writing your own libs, exposing a className prop makes
| them painlessly customisable.
|
| 0 - https://mui.com
|
| 1 - https://ant.design
|
| 2 - https://www.radix-ui.com/docs/primitives/overview/styling
|
| 3 - https://react-table.tanstack.com
|
| 4 - https://react-spectrum.adobe.com/react-aria/
| gunshowmo wrote:
| Thanks for these ideas! The react-aria seems quite
| interesting to develop a UI library library using Tailwind-
| styled elements while accounting for accessibility.
| handrous wrote:
| > Although I love the idea of HTML-native inputs all the way
| through, I tend to immediately run into issues where using a
| native interface instead of a JS-based implementation harms the
| user experience.
|
| The way HTML forms (in particular, but also things like tables)
| are stuck in a _not even good for the time_ '90s level of
| functionality is an under-appreciated drag on all web
| development, IMO. So very much wasted effort, wheel-
| reinvention, brokenness (a11y, especially) et c. for shit that
| should have been built-in years ago.
| pbowyer wrote:
| > The way HTML forms (in particular, but also things like
| tables) are stuck in a not even good for the time '90s level
| of functionality is an under-appreciated drag on all web
| development, IMO
|
| It absolutely is, but things are changing! Come help us get
| better form widgets built into browsers at at https://open-
| ui.org/.
|
| The website's a bit behind, the Discord and GitHub issues are
| where most discussion happens. We need people who know hte
| pain points to help us.
___________________________________________________________________
(page generated 2021-12-10 23:02 UTC)