[HN Gopher] Play with TailwindCSS in the Browser
___________________________________________________________________
Play with TailwindCSS in the Browser
Author : Brajeshwar
Score : 213 points
Date : 2022-06-10 10:43 UTC (12 hours ago)
(HTM) web link (play.tailwindcss.com)
(TXT) w3m dump (play.tailwindcss.com)
| martini333 wrote:
| Tailwind feels so wrong. But then you try it. Never been more
| happy building web apps!
| no_wizard wrote:
| This is awesome. I did see this dropped right alongside Tailwind
| V3, or there abouts.
|
| One thing I wish Tailwind did with production builds is take all
| those CSS classes and run them through a css-modules transpiler.
| If they can detect the names in the files, can't they also use
| the same lexer to do replacements on the code too?
|
| That would be the ultimate efficiency, in terms of bytes saved.
| rco8786 wrote:
| Im sorry but I don't understand how anyone can look at that and
| think it's a good way to build UIs. I'm almost certainly in the
| wrong, considering how popular this library seems to be getting,
| but holy heck that looks like a tedious mess to work with. It's
| like you have to learn every raw CSS selector, and then also
| learned how it's represented in Tailwind, and then scatter that
| all over your markup.
| peterkelly wrote:
| Any time spent learning tailwind is much better invested in
| learning plain CSS, since it's basically just syntactic sugar
| for style attributes. And learning CSS itself will be useful
| for many years to come, well beyond the lifetime of any given
| framework.
|
| The browser's built-in CSS support _is_ the framework, I don 't
| understand why people try to build things like this on top of
| it unless they're adding real value.
| pocketsand wrote:
| It's really not just syntatic sugar for style.
|
| It's a design system as well as a set of utility classes.
| Consider the difference between
|
| <span style="color: #cccccc">Gray text</span> and <span
| class="text-gray-700">Gray text</span>
|
| In the former, you can't just redefine what gray means.
| You've hard set it to a value you need to keep track of and
| keep consistent. On the right, you can configure what "700"
| means, switch between a cool gray or a blue gray, etc.
| my80thaccount wrote:
| Those are both just opaque values, if you wanted to gsub
| them it would be exactly the same.
| jakelazaroff wrote:
| So use a custom property instead (don't use inline styles
| tho): <span style="color: var(--text-
| gray-700)">Gray text</span>
|
| Or use Sass or something. This problem has been solved for
| like 15 years.
| hbn wrote:
| I want the styles to be in the template though, because I
| don't want to bounce back and forth between 2 files when
| designing a single UI. And it's not just inline styles,
| there's some things Tailwind can do that a style tag
| can't. Such as screen size breakpoints.
|
| Here's how to make a div have 0.5rem of left/right
| padding on mobile, and 2rem on any screen larger:
| <div class="px-2 sm:px-8">
|
| I'd much rather do this than mess with CSS's horrible
| media query syntax myself. And when I come back to this
| later, I don't have to cross-reference between (probably
| badly named) classes across 2 files to figure out how
| that div behaves.
| jakelazaroff wrote:
| Okay, but now we're back to Tailwind being back to
| syntactic sugar for styles (you can definitely put media
| queries in a style tag).
|
| I disagree with your preference; all the classnames are
| not easily parseable and obscure the markup, and I much
| prefer the CSS media query syntax. But that's, like, just
| my opinion, man. If you like it better, don't let me stop
| you!
| skttl wrote:
| >(you can definitely put media queries in a style tag)
|
| How?
| jakelazaroff wrote:
| <style>@media (min-width: 100px) {}</style>
| azemetre wrote:
| This is what tailwind does already. Colors are defined as
| design tokens in a config file:
|
| https://tailwindcss.com/docs/customizing-colors#color-
| object...
|
| Utility CSS is by far my favorite way to write CSS,
| especially in teams. It allows you to extract out
| multiple classnames that encapsulate all styles into a
| single classname.
|
| Why would you use Sass when plain CSS does the job
| better? Tailwind is just normal CSS, all the build steps
| are ways of making your stylesheets more efficient and
| removing dead code but it's all still CSS no preprocessor
| necessary.
| brightball wrote:
| But it does add real value.
|
| Aside from creating a standard naming scheme for your style
| guide, they also simplify specific CSS tag features by
| ensuring they can be consistent across browsers without you
| having to tweak each style.
|
| Outside of that, they acknowledge that you're not going to
| use custom CSS tags that often because 9 times out of 10
| you're going to style something in one place in a template
| and your programming language will repeat it for you...so
| there's no real value to creating a dedicated class.
|
| Another that I've found over the lifecycle of a project is
| that developers forget what CSS is where and end up simply
| creating new classes for things that they need rather than
| trying to reuse existing ones...which leads to your CSS
| growing constantly over time. With Tailwind I rebuilt my
| entire personal site, brightball.com and ended up with 20
| lines of custom CSS. This after restyling the entire site and
| making it responsive. And I was able to do all of it in an
| afternoon without ever having even made a responsive site
| before.
|
| What they've done is created "Rails for Style Guides" and it
| works beautifully. The Refactoring UI book (fast read) from
| the authors of Tailwind goes into the importance and
| reasoning for everything they do and it makes absolutely
| perfect sense.
|
| https://www.refactoringui.com/
| RyanGoosling wrote:
| I use Bootstrap components. I'll use Bootstrap utility classes
| (essentially what TailwindCSS is) for some one-off margin
| bottom ("mb-3"). Using TailwindCSS alone seems bad to me. Using
| TailwindCSS is pointless when using Bootstrap (Bootstrap
| Utilities)
| pocketsand wrote:
| It pushes you to componentize common UI elements. Feel bad to
| have long utility classes that look like <button class="bg-
| blue-700 border border-transparent hover:bg-blue-900 ring-2
| ring-offset-2">. Change it to:
|
| <submit-button>Submit</submit-button> using whatever tooling
| you prefer.
|
| If you don't use this style, maybe you won't like it.
|
| I've found it's a waste of time to extract classes for items
| that are not repeated. And putting utilities in components
| lightens your "master" CSS file and makes it a lot easier to
| work with CSS.
|
| I've found that the "cascading" part of style sheets almost
| always breaks down in larger projects. Small components seem to
| avoid those breakdowns while allowing for reusability.
| RyanGoosling wrote:
| I wonder if this new element is compatible with a blind
| person's screen reader. Any input?
| moray wrote:
| That is called Class in CSS...
| aidos wrote:
| This is all so played out now.
|
| People that haven't used Tailwind come along and say, "this
| is silly, just use css". The people who have used it say,
| "you should try it, it's not what you think."
|
| There are a bunch of subtle differences with Tailwind that
| make it quite a different experience.
|
| Really, it's closer to inline-styles++ than anything else.
| The style only applies to the element you're styling. This
| is by design as it means you can change that one style
| without wondering what else you've broken across your app.
|
| But you get variations that inline styles can't do (and
| aren't fun to do in css either): `text-green hover:text-red
| dark:hover:text-white` (interaction states, light/dark
| mode, responsive etc etc). This makes a huge difference
| when you're actually building this stuff.
|
| Personally, from a DX point of view, I really like it. I
| find it faster than anything else when I'm building and
| it's easy to debug too; no need to fish for the styles,
| they're inline on the element I'm styling.
|
| The biggest wart is the inability to functionally build up
| styles. For example, you have a bunch of js and you need to
| flip between several different colour states (say for an
| input that has "disabled | errored | valid | pristene").
| There's no great way to force one of your classes to "win"
| because they're all just classes and the way they were
| added to the page will determine which border colour wins,
| for example.
| the_other wrote:
| > It pushes you to componentize common UI elements. Feel bad
| to have long utility classes that look like <button
| class="bg-blue-700 border border-transparent hover:bg-
| blue-900 ring-2 ring-offset-2">. Change it to: <submit-
| button>Submit</submit-button> using whatever tooling you
| prefer.
|
| Even when you do that, you're still delivering the long,
| repetitive mark-up to the browser, rather than relying on the
| CSS engine to handle this for you. You're making the DOM MUCH
| MUCH heavier than it needs to be and ignoring the rendering
| engine that's optimised to handle this role. It seems
| wasteful all 'round. I confess I'm guessing here, and haven't
| tested it, but I suspect a simple, axiomic CSS file and
| simpler HTML file would produce faster rendering than
| Tailwind, and travel over the network faster.
|
| Tailwind improves the developer experience at the expense of
| badly optimised code bloating and slowing the user
| experience. The developer experience benefits are debatable,
| too: I freaking hate using CSS toolkits and would much rather
| just write CSS or SASS bespoke to my apps. I have more
| control and can tailor a solution for the problem.
| jolux wrote:
| > I confess I'm guessing here, and haven't tested it
|
| Maybe you shouldn't make unsubstantiated claims like this
| then?
|
| > Tailwind improves the developer experience at the expense
| of badly optimised code bloating and slowing the user
| experience.
|
| I only say this because if your claims about performance
| are wrong, your comment seems to boil down to "I don't like
| CSS frameworks," which is fine, nobody's forcing you to use
| Tailwind.
| pocketsand wrote:
| The overhead from processing class names is trivial.
|
| Things like ads or heavy images actually slow the user
| experience. This type of thing isn't worth worrying about.
| nojs wrote:
| > Even when you do that, you're still delivering the long,
| repetitive mark-up to the browser, rather than relying on
| the CSS engine to handle this for you.
|
| The crazy repetition of classes gzips away though so there
| really isn't any extra overhead.
| madeofpalk wrote:
| I'm with you. I'm pretty into neat experimental frontend + css
| stuff, and I'm baffled by how passionate Tailwind's fans are.
| It always feels like there's something I'm missing.
|
| In all fairness, I've never actually tried it.
| danielvaughn wrote:
| You should give it a shot, but IMO what makes it worth it is
| the Tailwind Intellisense plugin. I can design an element in
| just a few keystrokes, it's amazing.
| christophilus wrote:
| > In all fairness, I've never actually tried it.
|
| I was of your opinion until I tried it. Been using it for
| over a year on my current project, now.
|
| I recently built a little prototype without using Tailwind,
| and man... I didn't realize how big a quality of life
| improvement Tailwind is until I stopped using it. It's really
| hard to imagine going back.
|
| Edit: I've been building websites since 2000, and know CSS
| quite well, and hope to never write much CSS again.
| chrisshroba wrote:
| Agreed - they even include almost at the top of their
| homepage [1] a quote from the creator which includes: "If
| you can suppress the urge to retch long enough to give it a
| chance, I really think you'll wonder how you ever worked
| with CSS any other way."
|
| [1]: https://tailwindcss.com/
| rozenmd wrote:
| > In all fairness, I've never actually tried it.
|
| That's what you're missing. Try it.
| divan wrote:
| Building UIs with typesetting engine and bunch of styling
| classes is fundamentally wrong. CSS is broken by definition.
| Tailwind makes it a bit less broken on practice.
| jononomo wrote:
| I had the exact same opinion after working with tailwind for a
| week, but then, after a couple more weeks, I fell in love and
| decided that this is what CSS should have been from the start.
| sph wrote:
| The usual answer, however trite, is "don't knock it till you've
| tried it."
|
| I haven't found a convincing explanation of why exactly this is
| better until I've used it in a project, and since then I'm
| completely sold. The semantic CSS concern separation pipe dream
| has always been snake oil in real projects.
|
| Long live Tailwind.
| danielvaughn wrote:
| I ended up deleting like 30% of my React components after
| switching to Tailwind, because suddenly they just felt like
| unnecessary overhead. Tailwind FTW.
| jonwinstanley wrote:
| Also - no more constant switching between the HTML and the
| corresponding style rules
| [deleted]
| jonwinstanley wrote:
| I totally thought this until I started using it on a full
| project. Six months in and I can't imagine writing traditional
| CSS or nested SASS classes anymore.
|
| Combined with either Flexbox or CSS Grid, the speed with which
| you can put together a good looking web page is crazy fast.
| hbn wrote:
| I thought it looked silly when I started my current job and
| saw it for my first time in their frontend applications.
|
| Took a little bit to get the hang of, but once I did I was
| working WAY faster without the mental overhead of having to
| cross reference 2 text files (HTML + CSS) to build the same
| UI, keep them in sync, come up with names, etc. I iterate so
| much quicker, refactoring is so much faster cause you can
| literally just cut and paste a block of elements, throw them
| somewhere else, and they just render properly cause you
| brought the styles along with them. Screen size breakpoints
| make it so much easier to make responsive UIs. You get a
| free, built-in layout and color system.
|
| It eliminated basically all the major painpoints of building
| UIs that I had before. I use it in all my personal projects
| now.
| nazka wrote:
| Is it not because you forgot CSS and instead remember the
| tailwind names?
| jonwinstanley wrote:
| Haha.
|
| No, I still know CSS but I can't imagine coming up with
| class names for everything then going to a different file
| to define rules. Feels so long winded and hard to keep on
| top of.
| cmehdy wrote:
| I do not know much about CSS but Tailwind was very
| straightforward, and through it I got to learn things in CSS
| which weren't made obvious before. It's funny that you use the
| terms "tedious mess" because that's exactly how I feel about
| CSS without it. Handling screen sizes, print, colors, and
| simple layouts.. all that seems way too annoying to do in pure
| CSS to my non-frontend-dev mind, and trivial to do with
| Tailwind.
| clementmas wrote:
| I gave it a shot and now I like it. I don't have to add classes
| to my HTML and separate my CSS. I find it more maintainable.
| The built-in config and colors are also quite good.
| danielvaughn wrote:
| I nearly always use the built-in config. Though oddly enough,
| I don't like the new colors (>=3.0 I think), because there's
| just too many of them now. What I appreciated was the
| restricted option set; now it just feels like I need to worry
| about design decisions, which is what Tailwind let me _not_
| worry about.
| agloeregrets wrote:
| > It's like you have to learn every raw CSS selector, and then
| also learned how it's represented in Tailwind, and then scatter
| that all over your markup.
|
| In my experience, tailwind is pretty close to the real CSS
| properties. What I found to be wonderful and freeing about it
| is that it stops the middle step of engineering and naming
| classes and naming elements with class names and let's you just
| do styling. There's also a really great plugin for VS code that
| adds intellisense. Personally I found the modifiers that allow
| you to target pseudo selectors like :hover to be a superpower.
| I totally understand the other side of the argument though.
| It's a lot.
| jonwinstanley wrote:
| CSS has special syntax for media queries, hover states, dark
| mode etc. If anything, once you are into it Tailwind is far
| more "guessable".
| agloeregrets wrote:
| Correct, but wring all of those can get confusing and
| adding a single psudoselector syntax for something is at
| least a few lines and figuring out how to organize css.
| Scss is definitely better for this but even then it's a bit
| nebulous remembering which selector has the states in them.
| enobrev wrote:
| I wasn't a big fan of the idea before trying it and then I
| tried it for a small project. I get the appeal, but as the
| project grew in complexity, I found I disliked managing
| tailwind
|
| But the experience while writing the code is pretty excellent.
| It made me realize that what I really want (personally) is to
| have my css inlined in my editor when writing / editing it, and
| otherwise remain out of the way in my css file.
| aidos wrote:
| Oooo. That's an interesting idea. Being able to toggle
| className to be `className="..."` in vim.
|
| Would be interesting to see what an experience of being able
| to toggle between classless and class-only jsx looked like.
| vlod wrote:
| That would make it more appealing for me. Just saw this
| proposal:
|
| "Add the option to hide class attribute in vscode plugin" h
| ttps://github.com/tailwindlabs/tailwindcss/discussions/7922
| onion2k wrote:
| _It's like you have to learn every raw CSS selector, and then
| also learned how it's represented in Tailwind, and then scatter
| that all over your markup._
|
| That's exactly what it is.
|
| But... you have to do that _regardless_ of what you use for CSS
| layout. If you 're not using Tailwind (or something like it)
| then you're going to end up creating classes using the raw CSS,
| and then naming them yourself, and then having to remember what
| you called them. Hopefully you're good at that and you can
| remember, else you'll duplicate things. Hopefully your entire
| team are aligned on the same naming conventions, or your
| project's styles will be a total mess.
|
| Maybe you'll use styled-components or another CSS-in-JS
| solution, which helps a bit by making your styles scoped to
| components so they don't interfere with things outside of where
| they should, but then you'll have to keep a set of constants to
| use across all of them anyway, which puts you back at the same
| problem as plain CSS - you need to remember what's been set,
| and not duplicate things.
|
| Ultimately, Tailwind is a really well designed abstraction of
| inline styles that means you don't have to worry about
| inconsistency and duplication of things any more. It's another
| thing to learn but because it's so similar to raw CSS it's not
| actually a lot of effort. It works well.
| azangru wrote:
| > Hopefully you're good at that and you can remember, else
| you'll duplicate things. Hopefully your entire team are
| aligned on the same naming conventions, or your project's
| styles will be a total mess. - CSS classes
| can be named on a per-component basis, according to one of
| the well-established naming conventions (BEM, SMACSS, or
| whatever). This does not require remembering the names of
| other classes. - With the arrival of web components,
| styles can be scoped within the shadow DOM; and the name
| collision becomes a non-issue; as well as keeping track of
| _all_ the CSS that's written in the project. If CSS classes
| don't leak, you can focus your attention only on a given
| component and ignore the rest. - Instead of CSS-in-JS,
| one could use CSS modules, which are just regular CSS with a
| build step. The relevant project-level (site-level, page-
| level) constants can be defined as CSS constants on the root
| element.
| calvinmorrison wrote:
| > That's exactly what it is.
|
| Which is why this is basically reinventing inline styles.
| With some shorthand.
|
| How did we go from removing <u> and <b> to calling it <div
| class="bold" an improvement?
| tomtheelder wrote:
| It's a lot like inline styles. The big advantage is that
| you create a design language with the helper classes, and
| then your devs are constrained to use it. No one can add a
| border radius of 11 if you only have utility classes for 8
| and 16, or whatever. Historically you couldn't do that if
| you were using inline styles.
|
| You could do it with a cascading approach, but if you're
| building a component based application (this is what
| Tailwind is really for) then you already have an
| abstraction for re-usability. Trying to layer another one
| on top usually results in a really difficult to reason
| about mess of interlacing components and style classes.
|
| In short it's a way to use an inline-type styling approach,
| which is suitable for component based apps, without giving
| up the ability to constrain developers to a limited design
| language.
|
| There are a TON of other benefits for utility classes over
| inline, but I think what I described is the biggest one
| (media queries, pseudo selectors, stylesheet caching for
| reduced page load, etc.)
|
| > How did we go from removing <u> and <b> to calling it
| <div class="bold" an improvement?
|
| You can still use <u> and <b> if you want to. Adding a
| utility bold class also works fine.
| dangerface wrote:
| It seems like the main advantage of tailwind is that you
| don't have to learn how CSS cascading and specificity works,
| which is a fair advantage as most frontend developers I talk
| to don't even realise that specificity is a thing.
|
| I don't see the advantage over inline style tho. I see
| abbreviations as a disadvantage as its just as fast to type
| background as it is bg but background is clearly more
| intelligible.
|
| How do you deal with side effects for example I think bg-red
| is the brand red but some one has modified that class so it
| now has a border. You could prevent this with convention but
| then you have the same issues as using css with specificity
| and people not understanding the conventions around it.
|
| I think its easier for every one to just force your frontend
| developers to just learn CSS and use it.
| teen wrote:
| Tailwind has a lot of advantages if you read the
| documentation rather than conjecture about what you think
| it might do.
| tomtheelder wrote:
| Tailwind is actually a lot like inline styles in certain
| ways. Whether that's a good thing or not depends on your
| use case. If you are using a component based framework it
| ends up, IMO, being _way_ better and less complicated to
| use the abstraction you already have, your components, as
| your styling abstraction rather than trying to layer a
| second abstraction (the cascade approach) on top of it.
|
| The biggest advantage over inline styles is that you are
| constrained. The idea is that you set up the primitives for
| your application's styling system: which colors are in use,
| which font weights, all the way to things like which border
| radii are valid. Your devs can then only use those.
|
| You are correct that theoretically you can modify them to
| do anything, but in practice I find that people are
| extremely unlikely to violate the scheme (in ways like you
| described, adding a border to bg-red).
|
| As for abbreviations? I think that's probably just eye of
| the beholder. Since you tend to add a lot of these to your
| HTML it helps it not get too ridiculously out of hand.
|
| I spent years working with more traditional CSS schemes
| (including my all time least favorite, BEM), and it was
| pretty consistently a nightmare within the context of
| component driven applications. For a while now I've worked
| with tailwind and it feels like a massive step in the right
| direction.
|
| I think it's one of those things that really doesn't make
| sense until you try it and feel the difference for
| yourself.
| blain_the_train wrote:
| > you're going to end up creating classes using the raw CSS
|
| A program can read what looks like inline css and produce
| class names for youand put those in class files.
|
| When developing your see "height 20px" In your app its
| compiled to "h-20" with a css file "h-20: height 20"
|
| This is better because you don't have to learn another way to
| express the same logic.
| pythonaut_16 wrote:
| So Tailwind with more steps
| the_other wrote:
| > If you're not using Tailwind (or something like it) then
| you're going to end up creating classes using the raw CSS,
| and then naming them yourself, and then having to remember
| what you called them.
|
| This is true. But if we better taught the cascade and
| promoted the idea of global styles rather than pretending
| it's a problem then more people would be better at this and
| the problems would gently recede.
|
| We (the high-end front-end dev community) have fallen into
| the habit of using class names where we really wanted IDs and
| using components when we really wanted global styles. I feel
| we have been pushed in this direction by developers who
| didn't understand the technology properly. The Tailwind
| author clearly understands it, so I'm not targeting them...
| but they are supporting the people who don't see why the
| cascade is useful.
|
| We have megabytes of code to create the impression of global
| consistency (components, style libraries, CSS-modules...)
| shipped to millions of users every hour. Browsers do that for
| us already. Embrace the simplicity of
|
| button { border: foo; color: bar; } .callout button { color:
| aux; }
|
| It's so clear, so elegant. The obsession with modularising
| everything, and then applying a DSL to get between the
| modules, makes the language's inherent convenience, elegance
| and clarity so much harder to work with that it boggles my
| mind.
| jsf01 wrote:
| If your projects are small enough that relying on the
| cascade is a reliable option, you probably don't need
| tailwindcss. If you're working with 50+ devs on the same
| code base with many moving parts and shared components, you
| can't afford to verify whether the cascade breaks something
| on every single change. So imo there's nothing inherently
| wrong with your post, it's just that tailwindcss doesn't
| really excel until you're working with a bunch of people
| authoring css in a shared codebase. (That said, now that
| I've drunk the kool aid I use tailwind or windi css even on
| my own projects. It's pretty great once you know it.)
| ryanf wrote:
| We collectively tried the approach you're describing, and
| we stopped doing it because it sucks. It looks nice in
| simple cases, but the lack of encapsulation or locality
| makes it impossible to change upstream styles without
| breaking something somewhere else. Also you have to use
| horrible BEM-style names to avoid accidental collisions
| between styles from different parts of your app, which kind
| of ruins the elegance in itself.
| 1shooner wrote:
| > It's so clear, so elegant.
|
| The thesis of Tailwind is that the cascade actually becomes
| very unclear and inelegant at scale, and I would say the
| reason it's so popular is that many devs share that
| experience.
| ramesh31 wrote:
| Cascading is excellent for websites. Terrible for
| applications. There's no concept of anything even
| remotely similar in any other UI technology. Native
| applications have use the "scoped component" paradigm for
| decades, and the web is finally catching up.
| deergomoo wrote:
| This is the crux of it really. It makes a whole lot of
| sense to have cascading styles in documents. I don't want
| to have to explicitly set a text colour for each
| individual paragraph.
|
| But the opposite is largely true for UI elements. For
| one, I'm probably using some external templating or
| component framework to repeat them, because they mostly
| likely have behaviour attached and HTML by itself has no
| good story for that. For two, I pretty much _never_ want
| their styling to be modified by the context in which
| they're used.
| andiareso wrote:
| But this isn't much different than:
|
| <Button class=`border text-gray ${override}`/>
|
| <CalloutButton /> extends <Button override="text-blue" />
|
| I'd argue you have less markup to write overall if you are
| modularizing component logic/styling
| meowtimemania wrote:
| One gripe I have with tailwind, is overriding styles is
| difficult. The .text-blue style will only override .text-
| gray if it is declared later in the css document.
|
| for example if the corresponding css file is this: .text-
| blue { color: blue; } .text-gray { color: gray; }
|
| Then in your above example, both Button and CalloutButton
| will have gray text because .test-gray has higher
| specificity than .text-blue
| [deleted]
| LouisSayers wrote:
| And what about your :hover, ::before etc, where do you
| put those? (genuinely curious)
| timdorr wrote:
| Those have utility classes:
| https://tailwindcss.com/docs/hover-focus-and-other-states
| seek wrote:
| Tailwind supports those
|
| https://tailwindcss.com/docs/hover-focus-and-other-
| states#ho...
|
| https://tailwindcss.com/docs/hover-focus-and-other-
| states#be...
| rjknight wrote:
| You have to learn the browser layout _model_ , yes - you need
| to know what flexbox is, or how padding or transforms or line
| height works. But Tailwind provides sensible defaults for how
| those things are applied, which removes a lot of potential for
| screwups. It also removes most of the potential for badly
| "architected" CSS, where you accidentally end up with a set of
| classes that don't compose together in a predictable fashion.
| This greatly lowers the cognitive burden, which helps when
| collaborating with others or even with your past and future
| self.
|
| I get that it is aesthetically ugly, but if you can stop caring
| about that then you might find that it's better on most other
| dimensions.
| andiareso wrote:
| I thought the same thing before requiring to use it on an open-
| source project I was collaborating on.... it changed my mind
| within a few hours. It is a God send.
|
| Like others have said, the selector logic is top-notch and not
| having to build your own styles is great as they are pre-
| defined. You can always modify the styles any way you want and
| add your own custom ones too.
|
| It looks "gross", but it's very practical. If you follow the
| best standards for component sizing, you should never really
| have much of a problem with the styling getting in the way.
| yen223 wrote:
| I've noticed this pattern with Tailwind specifically where
| people who look at it hate it, but people who tried it love
| it. I've tried it, and I like it.
|
| This phenomenon encourages me to try something out before
| forming an opinion.
| isleyaardvark wrote:
| It generally seems like the only objection is "it looks
| weird" whereas the people who use it invariably say it
| dramatically improves ease of development and prevention of
| bugs.
| mythz wrote:
| If your project is setup to use Tailwind in watch mode where
| you can view your changes at every save, there's nothing quite
| as productive.
|
| You get fast iterations without ever having to leave your
| markup to hunt down to find all the classes elements are using
| which uses their own structure & nomenclature, esp. if you need
| to support responsive layouts which every project implements
| differently that usually grows into some unmaintainable mess.
| With tailwind's utility classes it's all right there on the
| element, using intuitive prefixes and shorthand class names
| derived from the CSS properties it uses.
|
| It's also the only framework I've used where you can copy
| markup from a number of different sources and it will look
| exactly the same as the preview where you got it from without
| it being distorted by the websites leaking cascading CSS
| styles.
| f3b5 wrote:
| Tailwind is a thin wrapper for the people scared of CSS. I use
| Tailwind at work, and it opened my mind to the benefits of an
| "ugly" html layout with inline styling. However, being there
| now, I think that inline CSS offers the better "Tailwind
| experience" - CSS requires no setup, and learning it properly
| is a good investment for the future when Tailwind, like so many
| other frameworks, will inevitably end up on the frontend
| dumpster fire.
| stefanfisk wrote:
| how would you use media queries or pseudo selectors in inline
| CSS?
| f3b5 wrote:
| Good point, I don't know of any way of doing that inline.
| So that's definitely a good convenience function in
| Tailwind!
|
| My lived approach to inline vs. not-inline is: why not
| both? Inline is great for prototyping, and for edge cases,
| like specific margins for wrapper divs. Where CSS classes
| really shine is when it comes to mature / often used
| components.
| [deleted]
| pcthrowaway wrote:
| Pseudo elements as well
| megaman821 wrote:
| I was about to say, if anything it shows there is demand
| for the style tag to handle pseudo selectors. Setting up
| some CSS variables on the root and accessing them through
| the style tags would provide most of the benefit of
| Tailwind.
| tomtheelder wrote:
| Inline CSS has a few HUGE drawbacks compared to Tailwind, but
| I think the biggest by far is that your devs are totally
| unconstrained in what they can do for styling. You're forced
| to rely solely on convention to not, for example, violate
| your color palette, or use the wrong border radius, or the
| wrong padding value. For a small app with a small team and no
| concrete design system that's not a big deal. At scale that
| is absolutely massive.
|
| A few of the other advantages of Tailwind: - reduced noise in
| the markup compared to raw inline styles, with the underlying
| styles getting cached by the browser - utility classes can
| contain multiple properties that should always go together -
| media queries!
|
| You should learn what CSS is actually doing as well, but
| realistically Tailwind is, like you said, a pretty thin
| wrapper on CSS. Learning Tailwind usually just means learning
| CSS, with some different property names.
| mightybyte wrote:
| Completely agree with you. I greatly prefer something like
| PicoCSS (https://picocss.com/) which tries to use plain HTML5
| as much as possible.
| clementmas wrote:
| Interesting. I like the idea of clean HTML. It's probably
| great for small projects but I'm not sure it would scale for
| bigger applications.
| mightybyte wrote:
| In my experience with larger applications no matter what
| CSS framework you use you eventually want to ditch it and
| move to fully custom CSS. Starting with this kind of a
| clean HTML base makes that easier IMO.
| tomtheelder wrote:
| That was my experience... until I used Tailwind. The
| thing is, it basically is fully custom CSS. It's just
| inline since you already have a re-usability abstraction
| if you are building a component based application. It's
| not even really a CSS framework at all. It's infinitely
| less prescriptive than what you usually see.
| MarquesMa wrote:
| > and then scatter that all over your markup
|
| This is not how you use Tailwind. Back then there was no such
| concept as component, so people need to write CSS classes to
| encapsulate and reuse styles.
|
| Now Components are everywhere, and when you write components
| and CSS classes at the same time, you're non-obviously
| duplicating structures (Write components, then write classes
| corresponding that component).
|
| In essence, Tailwind (or styled components and such) makes
| component mechanic as your single source of abstraction.
| likortera wrote:
| Because most people worry more about maintainability, ease of
| writing, modifying, performance, resulting bundle size,
| tooling, consistency, etc and very few about "how it looks".
|
| Everyone that complains about tailwind is because they didn't
| use it yet.
|
| Yes, looks weird at first. That's not everything that matters.
| seabea wrote:
| I'm really tired of needing to wade through these sort of
| comments. This is not a unique criticism.
|
| If you don't don't get it, either try it out or move on.
|
| These comments add no value to the conversation.
| rco8786 wrote:
| My apologies for having a discussion on a discussion forum
| rajasimon wrote:
| I have eight years in full stack development experience and
| after tried four times Tailwind a chance now I am back to Bulma
| and going steadily.
| jordanmorgan10 wrote:
| Fun Tailwind play story: I developed nearly my entire site using
| it. All the IDEs were simply slower. With Tailwind's component
| based approach, it was no problem to develop each part in
| isolation and plug it in once it looked good on their playground.
| fareesh wrote:
| Seems like a cognitive nightmare to have this in projects. I'm
| not sure what problem it solves other than doing everything in
| one file as opposed to multiple files.
| annagrigoryan2 wrote:
| I use this a lot! Also I love the youtube channel that they have
| Tailwind labs, as a non-css person I appreciate how easy my life
| is with Tailwind.
| My90thaccount wrote:
| config_yml wrote:
| As someone who's been doing CSS for 20 years now, I think
| Tailwind is an absolute blessing. They've gone a bit crazy with
| the latest features, but the core of it is so productive to
| use, especially in teams. Big fan here.
| irrational wrote:
| > They've gone a bit crazy with the latest features
|
| Can you elaborate? What are the latest features?
| yurishimo wrote:
| I think they are referring to custom values. As a part of
| the move to the JIT compiler, it's possible to define
| arbitrary classes and have Tailwind pick up on it and
| create a class.
|
| Consider this. `text-red-500` is an out of the box class
| from TW that gives you a solid red text color. With the new
| JIT compiler, I can write `text-[#BADA55]` and the compiler
| is smart enough to generate a class with that hex code as
| the value for the color. You can use this syntax for almost
| any available class.
|
| This feature is useful for some cases (marketing sites with
| finicky pixel perfect requirements) but it can also be
| abused. It's up to your team to decide where it makes sense
| to break out of the design system, or if you should add
| that new value as a token to be reused throughout the app.
| config_yml wrote:
| Arbitrary Variants looks a bit crazy to me (I haven't used
| it yet though):
| https://github.com/tailwindlabs/tailwindcss/pull/8299
| criswell wrote:
| I know it's going to be abused to hell like everything
| popular but definitely a useful power tool.
|
| It'll be really nice for container queries when they're
| ready. Something like: `wider-than-[500px]:hover:text-
| red-500` and so on.
|
| Also super nice for `:has` (although ordering is a
| concern at the moment): `[:has(:invalid)]:bg-red-500`.
| My90thaccount wrote:
| Once again, productivity is not the ultimate goal of a
| profession. Your product is suffering in quality because you
| are taking shortcuts.
| kaba0 wrote:
| Do you have any basis on claiming that the product suffers
| in quality from using tailwind?
| config_yml wrote:
| It's not, but it's important. And contrary to what you say,
| using Tailwind is productive for me AND increases quality.
| So that's a win for my product.
| dgb23 wrote:
| That's making a whole bunch of assumptions about professional
| web devs, including the people who maintain Tailwind and
| similar libraries.
|
| Also accessibility and HTML classes are completely orthogonal
| concerns.
| julianbuse wrote:
| I agree that tailwind may not be the most elegant way to style
| a webpage, and I also prefer classes and regular css or sass,
| but I don't think you will convince anyone to give up tailwind
| with such a toxic comment. Perhaps it would just be better if
| you stopped ruining hn for the rest of us. Additionally,
| styling and accessibility are not related (unless your layout
| is terrible, but that is just as doable with css).
| EudaimonBlue wrote:
| "People who know these things think tailwind is a travesty"
|
| Sounds like people don't like changes to things that they are
| used to.
|
| Overall Tailwind really does make styling cleaner.
| My90thaccount wrote:
| It makes your job easier at the expense of the quality of
| your product.
| jonwinstanley wrote:
| How does it affect quality?
| My90thaccount wrote:
| Tailwind means making your HTML non-semantic, usually
| backed by JavaScript. This has created an arms race where
| parsers such as screen readers need to do ever-evolving
| heuristics to provide a reader mode. The code usually
| cannot be modified or even viewed in a readable form by
| users. Of all things, it's not user-centric.
|
| You're going to tell me next that you have a JSON
| interface instead. But that's a site-specific API that's
| designed for vendor lock-in. You're going to find that
| doesn't work and need to create a universal format. And
| now you have completely recreated the problem HTML was
| intended to solve originally.
|
| All of this wasted effort that web Devs do doesn't come
| from nowhere. The people with slow browsers or
| accessibility needs are absorbing your productivity gains
| 1:1.
| jonwinstanley wrote:
| Pretty sure you haven't really looked at Tailwind.
|
| It's as semantic as you make it. And it works without JS.
| danielvaughn wrote:
| I'm sorry but this doesn't make any sense at all, what on
| earth are you talking about? I'm all for constructive
| criticism, even if it's harsh, but this makes it sound
| like you've literally never read anything about Tailwind
| at all.
|
| First, Tailwind has literally no opinion on whether your
| html is semantic or not. Second, it isn't "backed by
| javascript", that's nonsense and is just self-evidently
| not true. Third, "people with slow browsers" _benefit_
| because the CSS footprint is smaller. Fourth, the quality
| of the site _improves_ with Tailwind because developers
| can spend their unused energy on other enhancements.
|
| Why get on this thread and spew a bunch of bullshit?
| What's the point dude.
| criswell wrote:
| Looking forward to the takes on your 91st account.
| jozzy-james wrote:
| class names have no bearing on semantics
| kaba0 wrote:
| Semantic web is a lie. HTML and CSS is not expressive
| enough in itself to pull that off - you are guaranteed to
| put many many divs purely for stylistic reason all around
| your website. Also, as mentioned there is nothing in
| tailwind requiring only divs, you can use any semantic
| tag you want, and the whole page can be completely static
| without an ounce of js..
|
| At least know the topic you criticize.
| my80thaccount wrote:
| atonse wrote:
| The semantic web feels like yet more yak shaving. Focus
| on adding value to people.
|
| I know this cuz I was a big ra ra cheerleader for the
| semantic web 15 years ago.
|
| But then I found it made no bloody difference in actually
| helping people.
|
| I'd much prefer if we all spent our energy building
| better, smarter screen readers.
| EudaimonBlue wrote:
| The JS part is just clean up the final result result of
| classes.
|
| From what I've seen online using Tailwind over other
| frameworks like Styled Components, gives +5x speed ups.
| So it is not wasted effort.
|
| > The code usually cannot be modified or even viewed in a
| readable form by users.
|
| That's right, most of the time it is even minified. It'
| is not meant to be read by humans but by the browser.
| Poor accessibility is is a result of it not being
| prioritized designing/development of a product.
| pupppet wrote:
| Every time I see TailwindCSS code I feel like the world has gone
| crazy or I've just got too old.
| jozzy-james wrote:
| or you might just be working on stuff where the abstractions
| don't provide a lot of benefit.
| anon1378 wrote:
| I cannot believe how anyone can look at the following code below
| and think that it's maintainable, just for an input box with
| additional styles for states: <input
| type="text" value="tbone" disabled class="mt-1 block w-full px-3
| py-2 bg-white border border-slate-300 rounded-md
| text-sm shadow-sm placeholder-slate-400
| focus:outline-none focus:border-sky-500 focus:ring-1 focus:ring-
| sky-500 disabled:bg-slate-50 disabled:text-slate-500
| disabled:border-slate-200 disabled:shadow-none
| invalid:border-pink-500 invalid:text-pink-600
| focus:invalid:border-pink-500 focus:invalid:ring-
| pink-500" />
|
| How is mushing every single style into a class attribute supposed
| to help with readability and maintainability? Even if you use
| `@apply` to reduce the clutter, you are basically venturing back
| into "vanilla" CSS territory, and which their docs expressly said
| to avoid (https://tailwindcss.com/docs/reusing-styles#avoiding-
| prematu...).
|
| And even if I decided to march forward with tailwind CSS despite
| all of this, how do I format the code? Break up the classes for
| different states into separate lines, like so?
| <input type="text" value="tbone" disabled class="mt-1 block
| w-full px-3 py-2 bg-white border border-slate-300
| rounded-md text-sm shadow-sm placeholder-slate-400
| focus:outline-none focus:border-sky-500 focus:ring-1 focus:ring-
| sky-500 disabled:bg-slate-50 disabled:text-
| slate-500 disabled:border-slate-200 disabled:shadow-none
| invalid:border-pink-500 invalid:text-pink-600
| focus:invalid:border-pink-500 focus:invalid:ring-pink-500" />
|
| Yeah, I do not see how this is more readable than plain CSS. Is
| all of this worth it, just to avoid having the developer think up
| of class names, or defining their own theme using CSS variables?
| zachrip wrote:
| I like tailwind a lot actually, but I agree with you about the
| readability of some classes. It'd be cool if the vscode
| extension helped with that in some way.
| mattferderer wrote:
| > Is all of this worth it, just to avoid having the developer
| think up of class names, or defining their own theme using CSS
| variables?
|
| Yes. You're starting out with a well thought out set of
| variables & themes. You can tweak if you need. You can add
| extensions. There are lots of HTML/CSS components written for
| Tailwind online you can copy/pasta into your project.
|
| But for me the biggest win is just having a ton of variables I
| can use. I also only use it when building component type
| architecture & I try to keep my components small & focused.
| wiredearp wrote:
| aniforprez wrote:
| This is a hell of a lot of unsubstantiated mud slinging that
| really adds nothing to the conversation
| dham wrote:
| The problem is you're looking at a single input box. Typically
| those would be defined as an object and have a prop passed in
| to configure colors and such. You're typically using it with a
| frontend framework or web components. If you're in Rails you
| can use ViewComponents or use apply syntax for primitives.
| Primitives are the outlier. You define them once and they're
| out of the way.
|
| Where it shines is when you're not looking at primitives. Most
| dev work is pushing pixels around for layouts making things
| responsive, padding, margins, flex direction stuff. And in
| those cases Tailwind shines because you aren't constantly
| trying to come up with class names around div and sections. You
| are authoring you're css right with your markup. The
| productivity gains is unlike any other tool you can introduce
| to an org.
|
| Going back and reading a component and making modifications is
| incredibly nice too because I can just understand everything
| that's happening right out the gate. I'm not going back and
| forth between 2 or 3 files and trying to un nest complicated
| SCSS in my head.
| dangerface wrote:
| If you are doing components in react instead of using classes
| how does this solve the problem of coming up with class
| names? You still have to come up with the class name you just
| apply it to your react component instead of in css.
| deergomoo wrote:
| Because you only have to name <MyInput>, not .my-
| input__label, .my-input__tooltip, .my-input__validation-
| error etc etc
| jozzy-james wrote:
| without even touching the pseudo selectors, your example is
| roughly this with vanilla css (didn't check the exact values
| from the TW config, just for illustration purposes)
| input { margin-top: 1rem; width: 100%;
| padding: 2rem 3rem; background-color: white;
| border: 1px solid slate; border-radius: 25%;
| font-size: 1rem; box-shadow: rgba(0, 0, 0, 0) 0px 0px
| 0px 0px, rgba(0, 0, 0, 0) 0px 0px 0px 0px,
| rgba(0, 0, 0, 0.1) 0px 10px 15px -3px,
| rgba(0, 0, 0, 0.05) 0px 4px 6px -2px }
|
| now, most of that is pretty straight forward - but you're just
| going to end up with a whole lot of copypasta when you need to
| implement outline/focus/shadow/etc state on many elements. and
| maybe on some specific instances of them you don't want that,
| so then you have to create a class just to override your global
| defaults
| playbooks wrote:
| Next we need a TailwindCSS CSSZenGarden demo.
| jonwinstanley wrote:
| ...flashback to maybe 2003 and the Zen Garden blowing my mind!
| faebi wrote:
| I think part of the tailwind appeal is the top-notch integration
| into vscode. It made the learning experience even better for me.
| One of my favorite features are the large but limited color
| palettes in combination with states. I always found it messy to
| add another once-used button style to bootstrap, plus, then
| suddenly my button lives in multiple files.
|
| Here's a nice green example button, written out of my head during
| my holidays: rounded p-2 border text-green-800 bg-green-100
| hover:bg-green-200 active:bg-green-300 border-green-200
| hover:border-green-300 active:border-green-400
|
| It's long but somehow it's easy, readable, customizable and
| consistent. The limitations are still there though, just think of
| transitions and animations.
|
| Personally, I would also be happy if inline styles wouldn't be
| with their limitations, but that entirely another topic.
| friendlypeg wrote:
| Is there a VSCode plugin that help you do something like this:
| when I type text-20px it will try to find the closest class e.g.
| text-sm automatically?
| criswell wrote:
| Intellisense would help a lot with this task:
| https://gist.github.com/crswll/db0d276bbf0884b003f3715d48e68...
| atonse wrote:
| No but when you select an intellisense suggestion, before
| hitting enter, it'll show you the underlying css. That can sort
| of give you the same effect even if in reverse.
| clementmas wrote:
| Tailwind CSS IntelliSense will give you a list of all the
| possible classes with the associated pixel value.
|
| You can also do text-[20px] if you really need that specific
| size.
| irrational wrote:
| For someone who usually avoids divs in favor of semantic tags,
| that many divs makes me uncomfortable ;-)
|
| I presume the use of so many divs is a stylistic choice and not a
| requirement?
| jonwinstanley wrote:
| Yes, you can add Tailwind rules to any element, use of Semantic
| elements is obviously preferred but not essential
| k__ wrote:
| I like the Tailwind approach, but I still start projects with
| Bootstrap, because it comes with a nicer out-of-the-box
| experience.
|
| Also, it seems to me that Bootstrap started following the
| utility-classes approach more and more over the years (px-1,
| flex-column, etc.)
|
| Bootswatch themes are nice too.
| samwillis wrote:
| Having used bootstrap 5 on project, I love the new utility
| classes. Find myself using them all the time, having been
| sceptical of that style of css I'm a compleat convert.
|
| I think BS 5 is a nice middle ground between the older BS and
| Tailwind.
| k__ wrote:
| Yes.
|
| BS5 is pretty nice, but it could be smaller, haha.
| apineda wrote:
| I would recommend open props over tailwind. No special tooling,
| no JIT complexity, just straight up css variables / json tokens.
| You're also not stuck littering your markup with tailwind classes
| later that can become difficult to track down if you ever do want
| to refactor / change methods.
| jozzy-james wrote:
| cool, not sure how that works in PHP tho
| ttty wrote:
| remorses wrote:
| It would be nice if we started adding more css features to inline
| styles seeing the success tailwind css has.
|
| The only reason I use tailwind is that I can keep styles close to
| markup, I would just use inline styles if they had access to
| media queries and pseudo selectors
| gpspake wrote:
| I describe tailwind to people as a lightweight, classname-based
| abstraction over vanilla css rules.
|
| Unlike bootstrap where the button classname represents a
| collection of inherently opinionated and obfuscated css rules,
| the classnames map directly to the rules themselves - without any
| obfuscation behind a button class or opinions about what a button
| is. You can look at a tailwind classname and understand exactly
| what css rule is being applied. It's universally repulsive at
| first sight. Everyone who loves tailwind said "hell no" - but
| they pushed through it and ultimately understood the value in it.
|
| The reason that Bootstrap can't continue to exist as it does
| currently is because our js implementations have taken center
| stage and bootstrap requires a js implementation for many of its
| components. This means to use bootstrap with react for instance,
| you need a third party lib like reactstrap.
|
| Tailwind is JS agnostic and frees you up to use the react (ng,
| vue, etc) ecosystem's idiomatic implementations for things like
| tooltips without adopting an entire bootstrap abstraction like
| reactstrap. Any respectable UI lib will allow you to pass
| classnames as props. You just pass in some tailwind classes as
| props and call it a day.
|
| If your initial reaction is "this is ugly" I encourage you to dig
| deeper. Imagine never having to think of a name for a css class
| or context switch in to a 400 line css file to figure out what
| button means. I like tailwind :)
| halotrope wrote:
| There is only two kinds of people. The ones that don't like
| Tailwind and the ones that have used it.
|
| I know it is conceptually "wrong" and a bunch of well crafted CSS
| classes would be more elegant. In the end it works, works really
| well and makes collaboration dead simple. Commonly used groups of
| classes can either be aliased by @apply or used in a (react)
| component. I used CSS way before Tailwind was a thing and in
| hindsight I created a lot of utility classes that resembled a
| weakly-structured, somewhat incomplete version of Tailwind.
|
| It might be a bit verbose, it might be easy to abuse but it works
| damn well. On top of that there are some design guardrails built
| in that really help with the consistency of e.g spacing, colors
| and fonts. Easy to achieve good looking results without risking
| stuff always looking the same like with Bootstrap or Material.
|
| It is a bit like Github Copilot. The only way to "get" it is to
| try it.
| zach_garwood wrote:
| I'm apparently one of the few that tried it and didn't like it.
| I think it didn't click with me because we're already using Vue
| components to scope our styles, and honestly we don't use
| utility classes that much.
| nazka wrote:
| No at the end you end up having to learn all their classes, for
| almost no gain in speed of dev, and then you forget how to do
| stuff in CSS.
|
| For me Tailwind barely make it anything faster but I have to
| learn all their classes and then I am stuck to have to relearn
| CSS when their is custom stuff. Maybe for greenfield or MVP
| sure. But if you are on a big project you have one or more
| designers and 99% of the time you have things that needs to be
| customized.
| deergomoo wrote:
| > then you forget how to do stuff in CSS
|
| This is completely nonsensical because Tailwind classes are
| almost all just shorthand aliases for single CSS properties.
| You cannot use Tailwind without understanding CSS; it _is_
| CSS.
| dawnerd wrote:
| Re working with designers: that's why the tailwind config
| exists.
| erokar wrote:
| I've used Tailwind on many projects at work for about a year
| now. I do not like it.
|
| Tailwind seemingly affords an easy way of writing inline
| styles, but it 1) clutters the HTML, 2) leads to repetition and
| makes people break the DRY principle (yes, you should extract
| to components, but people don't always do that), 3) uses names
| that can be similar but are not identical to CSS properties and
| feels like a bad abstraction.
|
| If you use something like Svelte, where you can write local CSS
| within a component I fail the see the benefit of Tailwind. For
| me Tailwind is the most ill-conceived frontend tech I've had to
| use in later years.
| pcthrowaway wrote:
| I actually love Svelte, but generally feel much more
| productive in React, in part, because Tailwind seems to work
| better with it.
| ramesh31 wrote:
| > 1) clutters the HTML,
|
| Or, it makes your HTML far more representative of the state
| of your application, rather than having to open up a CSS file
| and match to the class name + whatever madness you have going
| on in your SASS with mixins and conditional style logic.
|
| > 2) leads to repetition and makes people break the DRY
| principle (yes, you should extract to components, but people
| don't always do that)
|
| Blindly following DRY is dogma. Not everything can (or
| _should_ ) be a component. The number one mistake I see with
| new React developers is "over componentization", where
| _everything_ is a sub component, and now I 'm digging through
| 5 different files to work on a feature. Use the "rule of
| three" here. The first time you write something, don't even
| think about making it a component. The second time you write
| it, start planning how to generalize. The third time you need
| it, make it a component.
|
| Copy/pasting is OK. Declaratively laying out your UI rather
| than generating it through configuration is OK. Having no
| abstractions is better than a bad or even mediocre
| abstraction.
| tomtheelder wrote:
| Component local CSS is fine too, as long as you use a theme
| system to constrain CSS choices. I think in practice they are
| pretty similar, but I personally way prefer the ergonomics of
| Tailwind.
| dimgl wrote:
| Naw, I don't feel this way. I'm not a huge fan of Tailwind.
| I've used it and I get the appeal, but I think it's the next
| flavor of the year. Next year we'll have something that
| supersedes it.
| monkey_monkey wrote:
| I've been using Tailwind since 2018, so maybe it's the
| flavour of the decade?
| alx__ wrote:
| Yeah it freaks people out not used to the benefits of utility
| classes.
|
| We're converting our app components to using Tailwind. But
| there was some initial resistance as the current setup of css-
| in-js was fine. Fine but not great, and we had ended up with a
| lot of weird custom css blobs over time.
|
| One side benefit is you can just install Tailwind and use it in
| isolated way. Which is what I did. Converted a couple
| components to using Tailwind and demoed them. Got positive
| feedback. Most element only need a handful of classes. And the
| elements themselves are just normal HTML with a class.
|
| Components feel quicker to scan now. Initially skeptical devs
| have noted the ease at which they can build out a new
| component. Without having to get bogged down in writing css.
|
| Which to me is the real goal of Tailwind, improving DX by
| abstracting the boring and error prone way of writing CSS for
| applications.
| kanonieer wrote:
| > There is only two kinds of people. The ones that don't like
| Tailwind and the ones that have used it.
|
| I know a lot of people who have tried but didn't like Tailwind.
| I think most people like it on a greenfield project, but that
| number drops off when they go back to a Tailwind project after
| some time.
| andiareso wrote:
| Meh everyone ultimately has a personal preference so it's a
| bit hyperbole to say that everyone that hasn't used it would
| like it.
|
| Just like everything, it would depend on the project, team,
| and individual.
|
| I personally was against it until I used it.
| hbn wrote:
| Tailwind projects are the only ones I've hopped into for my
| first time (i.e. never seen the codebase before) and I can
| immediately be productive cause I don't have to wrap my head
| around one specific person's ideas of how classes should work
| and what all the names mean.
|
| Same applies for my own code that I come back to after a year
| or 2 of not having touched it. It's way easier to parse a
| template that declares its own styling than a template with
| references to style classes that may be across multiple
| CSS/SCSS files and are probably badly named
| Starlevel001 wrote:
| > There is only two kinds of people. The ones that don't like
| Tailwind and the ones that have used it.
|
| I exclusively write server-side templates with minimal to no
| javascript. I don't like Tailwind because it doesn't work for
| that.
| heartbreak wrote:
| Why does it not work for server-side templates?
| aniforprez wrote:
| If anything it feels like Tailwind would work great
| specifically for this use case
| squidbeak wrote:
| Two kinds of people -- and me, apparently. Because I'm obliged
| to use it occasionally and it's as if 90s html never went away.
| fleaaa wrote:
| Am I only one that feeling like code readability is a bit gross?
| jonwinstanley wrote:
| At least with a Tailwind attribute you know what you are
| getting.
|
| A named CSS class can contain any definition and even if you
| are certain of those definitions, they can change depending on
| what the element is contained within.
| LordHeini wrote:
| Yep but unfortunately the "classic" way of writing CSS does
| look equally awful after some time with multiple people on a
| larger project. The html is cleaner but the CSS becomes an
| awful mess.
|
| The moment the first important! or inline stuff creeps into the
| page you are doomed. Utility frameworks feel a bit like giving
| up at the start and just rolling with it.
|
| The major problem i see with these frameworks is that it is
| harder to maintain a consistent style across teams or even a
| few devs.
| dgb23 wrote:
| You use refactoring/code structure techniques just like with
| regular code. Group stuff into components that belong together,
| use sensible names etc.
|
| The cost of tailwind is that you do a bit of upfront work, when
| defining your design system/tokens in their config. The benefit
| is high default performance (css is less bloated) and high
| productivity because you tend not to switch to CSS/SCSS and get
| a natural DRYness from working with it.
| lloydatkinson wrote:
| No, there are in fact many people who do not read the docs.
|
| https://tailwindcss.com/#:~:text=Worried%20about%20duplicati...
| .
| cglace wrote:
| But ergonomics are so much better. I've seen my team increase
| throughput dramatically after switching to tailwind.
| andix wrote:
| Usually you build reusable components with tailwind, so that
| you archive DRY. With React for example (or any other
| technology).
|
| The huge benefit is, that you don't split up HTML and CSS, you
| only write HTML.
| quickthrower2 wrote:
| Plain HTML yes.
|
| Using a web framework? No.
|
| It is clever in that half of it is missing: the
| componentisation that React (etc.) brings with it makes this
| shine.
|
| You can also define normal CSS classes based on the utility
| classes if you so wish.
|
| Tailwind after 4 hours of learning curve is so much nicer than
| cutting css or using old skool css frameworks. Some of that is
| because ready designed components exist that you can copy.
|
| With an old skool css framework once you hit an edge case you
| can be snookered and spend ages diagnosing why because of some
| clever stuff they done.
|
| Tailwind says "yeah css was a bad idea, let us abstract it away
| a bit" and does a nice job.
| danielvaughn wrote:
| I've used Tailwind in quite a few projects at this point. It's
| a bit gross, yeah. But overall that's a small price to pay for
| all the benefits it brings.
| krono wrote:
| Utility classes aren't Tailwind's invention and neither are style
| systems/constraints.
|
| I even believe that their particular implementation is a total
| mess with way too much and continuous overhead, and that you're
| probably better off building your own system.
| grayrest wrote:
| Tailwind's implementation _is_ a total mess. I have a custom
| preset for UnoCSS [1] focused on Tailwind compatability and use
| that for my company 's low code platform. It's a couple orders
| of magnitude better for both size and latency and switching has
| allowed me to delete all the supporting code I'd written to
| work around Tailwind-the-implementation's shortcomings. I have
| minor complaints about Uno but I recommend it if you're having
| trouble with Tailwind.
|
| [1] https://github.com/unocss/unocss
|
| If you mean build your own design system then I've built four
| separate design systems in SCSS since 2009. I've been fine with
| switching to Tailwind instead because I can get similar results
| customizing the theme, it's more comprehensive than my systems,
| and the network effect advantages of somethign popular vs my
| one-off thing.
| samtimalsina wrote:
| I was in the camp "this-is-bullshit" until recently. It felt
| backwards. We recently switched to Tailwind for one of our
| projects, and Tailwind was a delight to use, especially with its
| VS Code extension. Code readability is surprisingly not that big
| of a deal because we use components. Of course if you are looking
| at the raw HTML in chrome tools, it can get disorienting. For
| folks that are worried about having to learn yet another
| "language", the learn curve is pretty short.
| andiareso wrote:
| I'm in the same boat. I laughed the first time I saw it on
| Hacker News and thought it was the dumbest replacement to just
| using style tags.
|
| Boy I felt like an idiot when I started using it.
|
| I spend way less time going from idea in my head to actual
| concept now.
|
| Foolish boy.
| danielvaughn wrote:
| yep. With the VSCode extension, you don't even need to read the
| docs. I would just type in what I thought I wanted, and most of
| the time it would work. It's awesome.
| jbaczuk wrote:
| I've found Tailwind to be great for getting a project going
| quickly. It's pleasant to use when you get started, but it can
| become a pain later on when you have a lot of styles to maintain.
| I've been using it everyday at work for a year and a half, and
| wished I would have known a few things before I started using it.
| Here are a few:
|
| 1 - It encourages styling on the fly. Because it is faster
| initially, you don't have to constantly switch between a CSS file
| and your markup, it feels good to style it as you go, and gives
| you an initial productivity boost. But it can cost you in
| technical debt later, so be careful.
|
| 2 - It makes your markup really messy. You end up repeating the
| same utility classes over and over. Then you can forget which
| utility class you used for things that should be defined globally
| like spacing or colors, and have components with different styles
| and not one place where you can change it.
|
| 3 - It makes debugging styles in the browser difficult (you
| change the style of one class, it affects everything, not just
| the tag/component you are working on. Having component-based
| classes allows you to debug styling on individual components much
| easier. I find myself debugging by actually adding the utility
| classes to the markup.
|
| 4 - You have to memorize another name for every many css
| properties (e.g. line-height => leading), or just be constantly
| in the docs. VSCode extensions are helpful, but it does not
| always detect that you are trying to type a Tailwind class, esp.
| if it's dynamically generated classnames. It can also make VSCode
| run slower.
|
| 5 - Some CSS properties are missing values as options, so you
| have to customize it out of the gate (e.g. min-height) or use the
| custom m-h-[value] syntax, but why not make all of tailwind like
| this?
|
| 6 - Trying to sync Tailwind configurations between projects (e.g.
| between a component library and an application) can become
| tedious.
|
| Like anything, I think good styling is probably a combination of
| global styles, utility classes, and component classes. Something
| like Tailwind + Bootstrap + SASS on top of your own custom
| classes might make for a good tool, IMO.
| jozzy-james wrote:
| 1. Being able to run a dev build (with no PurgeCSS) and use the
| .cls area of dev tools to quickly throw together TW classes to
| get stuff sorted, then carry over to the final resting place is
| wonderful. Compared to manually typing each property and value
| on the element and then copypasta'ing from there.
|
| 2. If you need to use the same group of utility classes over
| and over, extract to a class - either with @apply (if you want
| to keep the flexibility of config updates) or vanilla.
|
| 3. I'm not sure I'm following here - if you're changing the
| value of a tailwind class, you should do that via the config
|
| 4. I've found the naming differences easy enough to follow -
| line-height vs leading makes sense if you come from a design
| background. I think the biggest gotcha I had early on was
| everything is mobile first by default - so sm:* is actually
| _larger_ than the default.
|
| 5. the JIT is a wonderful addition, but does come with overhead
| currently - so that's why it (i assume) isn't just the default
| way of doing things.
|
| 6. not a problem i've run across, but why would a component
| config supersede an app config?
|
| to your last point, we use tailwind in conjunction with a fair
| amount of legacy sass to do what we need (many small nuances,
| spread across 4 different sites, that are otherwise the same) -
| I would urge against mixing tailwind and SASS if only for the
| build speed, PostCSS should be able to do everything you need
| there and it'll just make the builds a bit faster.
|
| tho I feel like what myself and my team works on is a far cry
| from your standard HN web app - so my experiences are probably
| very different.
| baryphonic wrote:
| I just learned tailwind a couple weeks ago for a small project. I
| really love it--I've gone from being a CSS hater to not having to
| think much about CSS.
|
| The documentation is excellent, with working examples. It has
| taught me about CSS properties I didn't know existed. Instead of
| attempting to grok the entirety of the MDN docs, I can quickly
| use configurations that work. (The ubiquitous Seinfeld references
| are an enjoyable treat, too, though YMMV.)
|
| The other important piece is that the tooling is great. I use the
| VS Code extension, and beyond the excellent intellisense, the
| extension gives me exactly which properties and values are
| generated by the Tailwind classes when I mouseover.
|
| The only "complaint" I have is that sometimes in larger projects,
| I'd want to create reusable style components (almost like traits)
| that could be reused in components that appear similar but whose
| behavior is distinct. This is a minor complaint because Tailwind
| actually allows for this, but the syntax is slightly awkward.
|
| In all, I'm much more productive, and I imagine my code is more
| maintainable. It's certainly smaller without dozens of lines of
| CSS including the commented out sections.
| monkey_monkey wrote:
| Also of interest is the 'Play CDN' feature, which allows Dev
| Tools experimentation
|
| https://tailwindcss.com/docs/installation/play-cdn
| dandep wrote:
| started using tailwind when I hadn't mastered css and it actually
| speeded up my learning, because: - faster iteration and
| experimenting - tw docs are great learning material too - tw
| classes are made by experts so you can indirectly learn what are
| best practices
| xkcd1963 wrote:
| I tried it out for a project and I regret it. Following
| reasoning:
|
| - CSS was created so no inline styling would be necessary. By
| assigning CSS attributes to classes we are back at inline
| styling. The html just explodes if you don't put the tailwind
| classes somewhere else, but then again, CSS is already here for
| that
|
| - one wastes time learning new naming conventions. Most frontend
| developers have internalised CSS attributes
|
| - it runs through a javascript lib. That makes the setup more
| complicated. Browsers support CSS natively so why build something
| on top of that
| tomtheelder wrote:
| I think there's a chance that you're using it in a project it
| isn't suited to. For your first reason, component driven
| applications provide a compelling reason to go "back" to inline
| styling. You already have your abstraction, and adding another
| one (cascading styles) does you no favors. It just creates two
| interleaving re-usability schemes that are a nightmare to
| maintain in parallel. This is the same reason that component-
| local CSS has become very popular.
|
| Second one is a reasonable enough criticism. Never bothered me,
| but I think it's fair.
|
| Third: it's really designed for bundled, JS-based, component
| driven applications. In that context it's a breeze to set up,
| and really no more difficult than native CSS. By the way, the
| reason they do that is so it can do some clever things like
| removing the utility classes from the CSS that you actually
| ship to reduce payload size. There's no reason that you can't
| just build the entirety of Tailwind and just ship that as your
| CSS.
| jozzy-james wrote:
| it isn't really _designed_ for JS based applications, but if
| you're not at least running vite/webpack/etc with PurgeCSS
| then your builds will be rather bloated and you lose out on
| customizing the settings - if you really just don't care,
| then you can run the default CDN build
| ChrisArchitect wrote:
| Something new here?
|
| Why submit this? Been part of the docs/demo page for years.
| 65 wrote:
| I used to be a Tailwind hater.
|
| I couldn't fathom why anyone would ever use it. And then I used
| it. It seriously makes CSS significantly easier to maintain,
| dramatically reduces your CSS build size, and is really good for
| teams if you're trying to use consistent CSS throughout your UIs.
| You also don't need to go back and forth between CSS file and
| HTML file.
|
| If you're on the fence, try it out. I think it's the future of
| writing CSS.
| Existenceblinks wrote:
| The truth about web design is there's only a few things that
| repeat in semantics, that's why lowest level token works. At
| the end of the day, web design is mostly color, space, font,
| barely things that are higher. If you have some buttons and
| form inputs pattern, your design is almost done (excluding non-
| ui state/behavior).
| abdellah123 wrote:
| The future? Have you tried imba.io?
| [deleted]
| gedy wrote:
| I really like utility classes and think Tailwind is really
| smart for many usecases, but the drawback with Tailwind is even
| if you componentize, your code is sprinkled with very specific
| visual classes like for shadows, border radius, etc. When
| companies want to refresh their look and feel, it's really
| annoying to change everything to remove now unwanted shadows,
| etc. In spite of it's age, I've found Bootstrap is better for
| this as it uses predefined component classes that can be
| restyled without rewriting the app or components (but also has
| some handy utility classes).
|
| I know you can define your own component classes in TW, but
| then you've just recreated Bootstrap/Bulma/etc, but with no 3rd
| party components available. (Tailwind UI is just some limited
| copy paste code snippets last I looked.)
| bpicolo wrote:
| > but with no 3rd party components available
|
| There are a bunch of great 3rd party components available in
| tailwind now. https://daisyui.com/ is one I've been using.
| They're usually a tad bit lower level than typical framework
| component libs, but the flexibility is great.
|
| A great thing about that is they're not React-specific, Vue-
| specific, etc. You can use them in everything from raw html
| to your JS library flavor of choice.
| gedy wrote:
| DaisyUI is a nice approach and hope it succeeds. We were
| looking to use that until we realized it's almost identical
| to Bootstrap, and that we were just using Tailwind as an
| elaborate way to make a custom Bootstrap theme at build
| time. Company decided to go with BS5 instead.
| likortera wrote:
| Have you ever had to change the company's look and feel with
| anything else than tailwind?
|
| I had to do it with a BEM codebase, and I also had to do it
| with tailwind. The tailwind situation was by far the easiest
| one. And it was because I was not afraid to remove things
| that could break unrelated parts of the application. Not
| allowing developer to hand write CSS is a great restriction
| for a good bunch of developers. The messes out there are
| unbelievable.
| calvinmorrison wrote:
| > Have you ever had to change the company's look and feel
| with anything else than tailwind?
|
| Yes, many times, with normal CSS. It's basically the point
| of cascading style sheets. Sticking to proper class names
| and elements makes reskinning a breeze.
| likortera wrote:
| > It's basically the point of cascading style sheets
|
| The "cascading" part is what makes it incredibly
| complicated. Keeping the "cascade" in sync with the
| actual markup is not a trivial task in teams with many
| people of different skills levels.
|
| Not everyone is a top 1% dev, so we need easier and safer
| tools so that everyone can work and maintain a codebase.
|
| > Sticking to proper class names and elements makes
| reskinning a breeze.
|
| This is more easily said than done. It's like saying
| "Just don't write bugs". Every single project I find that
| has been built with BEM and similar patches after a
| couple years are just a mess and their CSS becomes
| "append only", as there's no guarantee that removing
| something won't break in unexpected ways.
| calvinmorrison wrote:
| You're just shifting work though. The commit will now
| contain 10000 non html structure changes to an html,
| phtml, whatever, instead styles to a CSS sheet. Might as
| well go back to doing inline styles. There's a reason we
| don't do that anymore.
| [deleted]
| yurishimo wrote:
| This isn't the 90s. We all use file includes now. If
| you're working on a view file longer than a couple
| hundred lines, properly formatted, you're not abstracting
| enough or it's a one off marketing thing.
| kristiandupont wrote:
| Crazy, in my entire career I've never been involved in a
| redesign that didn't involve the entire layout but only
| changed some colors, paddings and drop shadows.
| calvinmorrison wrote:
| Definitely done it a bunch of times. Marketing comes out
| with some new web font crap they want and we need to go
| adjust everything. Flat face buttons become popular so we
| get rid of the pseudo 3d ones. They want to launch a new
| webstore but dont want to redesign, lets just steal one
| we have and reskin it a bit.
| gedy wrote:
| > Not allowing developer to hand write CSS is a great
| restriction for a good bunch of developers.
|
| I agree, main point is that I think there are better tools
| for large codebases. We had a "no CSS" rule where we used
| bootstrap components and utility classes only.
| shroompasta wrote:
| Yeah, I've tried tailwindcss, but having many rules of css on
| one line isn't even at all legible, nor do I want to use
| horizontal scrolling.
| pcthrowaway wrote:
| This, and the tendency towards repetition, is my biggest
| issue with tailwind (and I still love it).
|
| It tends to make the code pretty ugly.
|
| There are ways to improve things somewhat (moving "bundles"
| of classNames into properties of a local or global cssClasses
| object and adding those to your elements' className), but you
| lose the intellisense when editing classes and it often ends
| up feeling like the extra friction isn't worth it. Having the
| styles _right there_ seems to be a key part of what makes
| using tailwind so productive.
|
| We have enough decisions to make regarding design as it is,
| adding organization, naming, selection, and attempting to
| maintain a sensible hierarchy into the mix leads to a fog of
| decision fatigue that I didn't realize existed until I tried
| Tailwind and it lifted.
| telman17 wrote:
| There are formatters for your text editor that can help
| alleviate some of this.
| mritchie712 wrote:
| for haters, color management is a good starting example of why
| it's good.
|
| https://tailwindcss.com/docs/customizing-colors
| lolinder wrote:
| Color management is easy in SCSS, too, though. I just have a
| _colors.scss file and enforce that no color is ever used that
| isn't in that file.
|
| If I'm working with a designer rather than designing my own
| UIs, that they have a default color palette isn't helpful, so
| what do I gain from Tailwind?
|
| EDIT: Reading some other comments, I wonder if part of the
| reason I don't see the utility is that I use Vue, not React.
| It sounds like Tailwind solves a lot of the same problems
| that Vue+SCSS does.
| andrei_says_ wrote:
| Including Tailwind's list of colors in an scss codebase is
| trivial.
|
| Same for spacing and font sizes if you need these
| standardized and haven't done it already.
|
| Which we always did way before tailwind was invented.
| bpicolo wrote:
| One good part is the generated classes for every color.
| Background colors, font colors, border colors... everything
| in the color palette is usable as `bg-blue-500`, `text-
| blue-500`, `border-blue-500` etc. Could be reproduced in
| css for sure, but it's a great set of defaults that you can
| utilize cross-repo. Standardization is a powerful concept.
| ramesh31 wrote:
| The killer for SASS nowadays is CI. You're either using the
| (ancient, slow) Ruby implementation of SASS, or node-sass
| which requires a native binary build and causes headaches
| across environments. Furthermore, with Post-CSS, the
| feature set of SASS has been completely subsumed by the
| latest CSS standard. There's really no good reason to use
| it anymore.
| Rapzid wrote:
| For large apps yes; all Sass compile options are slow
| with embedded Sass being the least slow BUT:
|
| Does your tooling even support embedded Sass?! Vite does
| not. Our version of webpack does not.. The Cenobites
| would LOVE Sass; never ending performance pain.
| toastal wrote:
| It's Sass, not SASS.
|
| The native libsass is much faster. The headaches come
| from people trying to distribute binaries and libraries
| through NPM.
| jbenner-radham wrote:
| If we're being pedantic technically it's npm and not NPM
| ;)
| no_wizard wrote:
| You should really be using the dart-sass[0] build (just
| `sass` on npm). None of the headaches of native binaries
| or using ruby, its pure JavaScript (its a dart codebase
| transpiled to JS). It is very fast.
|
| [0]: https://sass-lang.com/documentation/#older-versions
| ramesh31 wrote:
| >I couldn't fathom why anyone would ever use it. And then I
| used it. It seriously makes CSS significantly easier to
| maintain, dramatically reduces your CSS build size, and is
| really good for teams if you're trying to use consistent CSS
| throughout your UIs. You also don't need to go back and forth
| between CSS file and HTML file.
|
| Same. I always said they'd pry my stylesheets from my cold dead
| hands. But then I tried it, and I'll never go back. I feel like
| it's time to let go of those last vestiges of the old "web
| development" paradigm, and start treating the browser as what
| it is; a universal VM for application development.
| mooktakim wrote:
| It's really for the React generation. People used to embedding
| the code, markup and style all in one file.
|
| I've tried multiple times to use it, but I always end up using
| something like bootstrap. Funnily enough, I paid for tailwindui
| and take the styles and reproduce them in bootstrap css.
|
| Bootstrap community seems to have given up. They only want to
| sell templates. The default is ugly. Sometimes I think about
| going back to bootstrap 2.
| mattwad wrote:
| If you're using React, check out Material UI. I was a big fan
| of Bootstrap, but I didn't like that there was still so much
| for me to build. MUI comes with components for things like
| user avatars out of the box. But it doesn't get in the way at
| all either, it's very customizable at the theme and the
| component level (I'm using it with styled components, and I
| love not having to come up with class names for everything).
| I've also tried Antd and it's impossible to customize.
| swyx wrote:
| agree. i'm a cynic turned convert as well. even told a friend
| it caused ugly unreadable classname soup and that zero-runtime
| CSS-in-JS solutions (like linaria, but even css modules) could
| do more with a lower learning curve (because you Actually Write
| CSS instead of tailwind shortcuts).
|
| then i tried learning it and it turns out that Tailwind's
| constraints both help my design and help with the learning
| curve
|
| wrote up full thoughts in an old post https://www.swyx.io/why-
| tailwind
| [deleted]
| Vinnl wrote:
| _If_ you 're using a component-based architecture (e.g. when
| using React, Vue or Angular), otherwise it can get pretty
| annoying. But if you do, it's pretty great; you don't really
| need the abstraction of reusable classes, when you already have
| reusable components, and getting rid of useless abstractions
| makes me a happy programmer.
| nojs wrote:
| I am using it with traditional Django + Jinja2 for templating
| now which is working well. With {% macro %} you basically get
| fully reusable "components" on the backend so there's limited
| copy pasting of tailwind classes.
| aaronbrethorst wrote:
| This isn't meant as a contradiction of your point, but there
| are plenty of ways to use component-based architectures with
| server-side rendered apps, too, like GitHub's ViewComponent
| gem for Rails. https://viewcomponent.org
|
| Also, I'd go so far as to say that if you're not using a
| component based architecture for your web app's view layer,
| you're creating a ton of extra work for yourself.
| cgarvis wrote:
| +1 Using it in a Elixir/Liveview app. Using
| phx_component_helper has made making those components
| really easy. https://phx-component-helpers-
| demo.onrender.com
| debrice wrote:
| I would add that, even for regular HTML you can write CSS
| using @apply and still leverage the nice structure tailwind
| provides while creating your component CSS classes.
| deckard1 wrote:
| > it's the future of writing CSS.
|
| Tailwind didn't invent utility classes. We've done this since
| the '90s.
|
| > significantly easier to maintain
|
| Disagree totally. Utility classes are good for rapid
| prototyping. But they clutter your code, mix semantics with
| presentation, and are a pain in the ass when it comes to code
| reuse. The cascade part of CSS is, believe it or not, actually
| _useful_ for code reuse. Need to change a font deep in some
| nested component? Not a problem with CSS. Tailwind, you 're
| fucked. You'll need to modify each component layer to pass down
| a class prop. Or do some ugly context hack.
| inopinatus wrote:
| * Tailwind doesn't claim to have invented utility classes,
| nor even utility-first CSS architecture.
|
| * HTML has always mixed semantics and presentation.
|
| * It's terrific for production applications because we don't
| lovingly hand-craft each DOM node. Far from being an enemy of
| reuse, it enables refactoring at the point of HTML
| generation, and aligns particularly well with partials and
| view helper functions/objects.
|
| * The cascade is still there; you're not fucked. Not even if
| you've been suckered into using some react-like framework.
| [deleted]
| jozzy-james wrote:
| > We've done this since the '90s.
|
| no, we really didn't. tho i'll agree that utility classes
| have been a thing for longer than
| tailwind/bootstrap/tachyons/pico/etc have existed
|
| > mix semantics with presentation
|
| there is nothing semantic about class names: nothing, zero,
| zilch - using IDs are even worse due to specificity, with
| none of the "semantic" benefit. focus on the correct top
| level wrappers
|
| part of me wonders about the extent of what HN commenters
| actually _do_ on the web regarding styles, or if they just
| slap together some homogenous web app or static site where
| its rather easy to not have a design team needing flexibility
| on every little thing.
|
| case in point, our main "button" has about 15 different base
| variants (that *3 currently) depending on context, not
| counting the interaction states.
| krainboltgreene wrote:
| Okay so one huge difference between now and the late 90's is
| that we have several very popular ways to create "components"
| of HTML/JS/CSS. From react to liveview it's very popular.
| This is important because it's much easier to maintain.
| anthonylee wrote:
| I tried it out last year. Absolutely love it.
| DecayingOrganic wrote:
| As a side note, you can configure prettier for automatic class
| sorting for tailwind! It makes a huge difference in terms of
| code readability and maintenance.
|
| https://tailwindcss.com/blog/automatic-class-sorting-with-pr...
| phreack wrote:
| Thank you so much for sharing that! I had no idea how much I
| even needed this, my classes tend to get incredibly messy and
| it'd always bothered me.
| hanifc wrote:
| I've seen this exact comment so many times over the past year
| or two that I think it's finally time that I try it out.
| srik wrote:
| I was where you were and am glad I got over my reticence
| because it's genuinely feels like a pleasure to use now.
| Another good aspect is that while you're using tailwind's
| custom identifiers, you still have to write real CSS and so
| are quite likely to end up refining your own CSS skillset in
| the process.
| fc373745 wrote:
| I completely disagree.
|
| To fix the css + jsx in one file, just write your styled
| components at the bottom of your component.
|
| If you ever seen a react component completely riddled with
| Tailwind, you'll realize how messy and uncoordinated it looks.
|
| Even I would consider switching between two files just to avoid
| that style of css.
|
| Furthermore the necessity to utilize horizontal scroll because
| adding 10+ more rules will inevitably break your prettier
| printWidth rule is, by far, the most annoying aspect of
| Tailwind. absolute inset-0 bg-gradient-to-r
| from-cyan-400 to-sky-500 shadow-lg transform -skew-y-6
| sm:skew-y-0 sm:-rotate-6 sm:rounded-3xl position:
| absolute; top: 0; left: 0; right: 0;
| bottom: 0; linear-gradient(45deg, #fff, #000);
| box-shadow: 1px 1px 1px 0 rgb(0 0 0 / 0.05); transform:
| skewY(60deg); border-radius: 4px; transform:
| rotate(60deg);
|
| Consider these two snippets, after time of not looking at your
| css code, do you think 10+ rules on one line is maintainable?
|
| Not even close, ask yourself to change a css property - you
| would have to iteratively go from left to right until you find
| it, whereas looking from top down you can immediately catch the
| css rule you want to find.
|
| Succinct doesn't mean maintainable, and sometimes verbosity
| does.
|
| Tailwindcss isn't even close to being the future.
| andrei_says_ wrote:
| I think it is already the present for people who don't want
| to learn CSS.
|
| I can go as far as using some of its standardized constants
| in my BEM codebases.
|
| Snark aside, I believe the future of CSS is closer to ITCSS -
| working with the cascade to minimize the need to modify
| styles.
| jozzy-james wrote:
| your vanilla CSS doesn't actually work the same since the
| second transform overrides the first one
| majkinetor wrote:
| You seem to miss the bigger point - Tailwind constraint your
| css use so that you don't imagine stuff in ad-hoc manner.
|
| And you can split, and sort classes with editor plugins which
| makes it almost equally good as your example.
| shroompasta wrote:
| i think you missed his point to be honest.
|
| Regardless of where place your tailwindcss or where you
| split / sort classes, reading iteratively from left to
| right, especially if the css rules are numerous, is not
| legible.
|
| just looking at the two examples above, and already I can
| tell how much it would be easier to maintain verbose css.
| majkinetor wrote:
| So u cant manage the little bigger list of words? And you
| can manage way complex software behavior at the same
| time? Particularly if it lets you manage small subset of
| CSS ?
| jonfleck wrote:
| I wrote a "function" for this exact reason. It'll display the
| classes in a much easier to read way. It also can type check
| to ensure that all classes are valid. I say function in
| quotes because it's actually a babel macro that's get
| compiled down so there's no runtime cost!
| https://github.com/fleck/class-types.macro#better-
| prettier-f...
| aidos wrote:
| You can do both of those things with Tailwind. Put the css
| only components at the bottom and use them in your main
| component if you want. Break the classes over multiple lines
| if you want.
|
| The difference between your 2 examples is that TW allowed you
| to handle media queries seamlessly but you couldn't do that
| in your styles example.
| teen wrote:
| Each styled-component also increases your css payload size
| linearly
| [deleted]
| shroompasta wrote:
| i'm not sure what you mean by 'seamlessly'
|
| but a media query in styled components would just be
| @media (max-width: 700px) { css here }
|
| it's not that much harder.
|
| Also, the lack of address of real problems of tailwindcss
| of OPs comment in terms of mantainability is something you
| consider.
|
| reading iteratively from left to right especially if it has
| 10+ css rules, in terms of legibility, is not really all
| too great.
|
| I would absolutely hate to adjust something in tailwindcss,
| after not seeing the codebase in a month's time.
|
| Whereas regular css properties, i can easily find by eye.
| aidos wrote:
| "Also, the lack of address of real problems of
| tailwindcss of OPs comment in terms of mantainability is
| something you consider."
|
| Not sure what you mean by that. I've been doing this
| since we did layouts with tables and shims in the 90s.
| I've found TW pretty nice to maintain myself.
|
| "It's not _that_ much harder ", but a) it's a simple
| example and b) now you're going to litter your code with
| a load of hard coded media widths?
|
| Let's talk about something concrete. Let's take a really
| simple layout that changes border and margin responsively
| (this, for me, is seamless). <div
| className="m-8 lg:m-0"> <div
| className="border-2 md:border-4"> Content
| </div> </div>
|
| How would you do that?
| jmoreno94 wrote:
| Your eye gets trained eventually. Also most of our
| components look something like this once class names
| start to get long. const
| inputWrapperClass = classNames( 'flex flex-col
| gap-y-1', 'group-focus:border-blue-500',
| isDisabled ? 'opacity-50' : null );
| return ( <label className={inputWrapperClass}>
| {...} </label> )
|
| In practice our "full-stack" developers are writing less
| and less CSS because they're just using the components
| that encapsulate all of this, our frontend developers get
| code completion for our design system tokens, and we
| haven't had to ship any new CSS classes in the last few
| months.
|
| Our new hires are able to just use the design system
| tokens rather than going in and saying `padding: 5px` and
| `padding: 4px` because the designer didn't think it was a
| big deal. They just write `p-1` and that covers it.
|
| All the components get tree-shaken and only ship the
| styles they need so bundle size gets reduced as well.
|
| If I had my dream team of 10x frontend developers and a
| perfect design team who always follows the rules they
| create then yes I would use regular css with css
| variables, but I don't.
|
| I am more than happy to sacrifice "separation of
| technologies" for a happier team, more consistent
| styling, and faster delivery times.
| bpicolo wrote:
| Same. People touted semantic CSS as the future for ages, and
| that's what I was taught in my first role out of college. Parts
| of that made sense (e.g. de-noising html), so I was against
| tailwind, but it's has quickly become one of my favorite tools.
|
| I am pretty conservative in terms of "use boring tech", because
| I see so much reinventing of the wheel and making the same
| mistakes, but Tailwind is not in that camp!
|
| I was never happy with any of the CSS in JS solutions in React
| land - all of them felt tedious or boilerplate-heavy compared
| to Vue's CSS model, which is excellent. Writing css and getting
| component scoping for free are great.
|
| But with tailwind I've minimized usage of Vue CSS too. I pull
| it in occasionally when I need specific overrides of the
| tailwind component lib I'm using, but other than that I don't
| even need to touch css.
| abhayhegde wrote:
| As a self-taught web developer, Tailwind has been a breeze to
| use, especially since I can play with default properties that
| already fit in nicely. Gives so much customizability.
|
| However, I do find it laborious some times, since I have to
| define properties for each div every time, instead of just
| selecting things by CSS classes. Or I am doing this wrong.
| lloydatkinson wrote:
| You are in fact doing things very wrong. You're supposed to be
| creating components or view partials or whatever you framework
| calls them and use those. The homepage literally has examples
| of doing this with multiple frameworks.
| vsroy wrote:
| People here are complaining about how Tailwind is annoying
| because the className strings are too long. The correct solution
| is to write a quick 1-file helper.
|
| See:
| https://gist.github.com/vedantroy/80fb2feb21b07b6f53032b8725...
|
| I wrote that. It allows me to do stuff like:
| const Button = tw.div(` bg-blue-500
| rounded `)
|
| Any complaint about how tailwind forces overly long class names
| should probably look at this comment first.
| deergomoo wrote:
| I'm not sure if JSX supports it but Vue templates and of course
| just regular old HTML allows a class to span multiple lines
| anyway. It doesn't all have to be on one huge line.
___________________________________________________________________
(page generated 2022-06-10 23:01 UTC)