[HN Gopher] Tailwind CSS v3.0
___________________________________________________________________
Tailwind CSS v3.0
Author : pspeter3
Score : 411 points
Date : 2021-12-09 18:33 UTC (4 hours ago)
(HTM) web link (tailwindcss.com)
(TXT) w3m dump (tailwindcss.com)
| 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?
| 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.
| 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.
| 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.
| 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.
| 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
| 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.
| 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.
| 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]
| 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.
| 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.
| 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.
| 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/
| 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.
| 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.
| ___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...
| 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...
| 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.
| 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)
| 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 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?
| 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.
| 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.
| 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.
| seanwilson wrote:
| Take a look at the https://tailwindcss.com/ page and
| search for "div". Can you replace them all more semantic
| tags? If not, can you remove them and still style it the
| same way?
| 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.
| 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/
| 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.
| 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.
| 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.
| 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
| 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.
| tlamponi wrote:
| Sounds a bit like a glorified <el
| style="display:flex;justify-content: start;">... ?
| 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.
| bamboozled wrote:
| This, I've used it only for about a week, there's no way I
| could go back now.
| agumonkey wrote:
| For toying / prototyping it's way nicer than I'd ever expect.
| Seriously fun. I now inject tailwing anywhere possible.
| 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 ?
|
| Not really. They approach site design from pretty different
| angles.
|
| 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 as 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
| 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
| 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) }
| 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.
| 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.
| 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.
| 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.
| 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 $
| 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
| Ataraxy wrote:
| The waterfall columns layout is really nice.
| 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.
| [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.
| 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.
| 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.
| 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?
| 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.
| 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); }
| [deleted]
| 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-09 23:00 UTC)