[HN Gopher] DaisyUI - Tailwind CSS Components
___________________________________________________________________
DaisyUI - Tailwind CSS Components
Author : jonifico
Score : 441 points
Date : 2021-07-30 04:39 UTC (18 hours ago)
(HTM) web link (daisyui.com)
(TXT) w3m dump (daisyui.com)
| jcq3 wrote:
| Yet another bootstrap? I don't see any difference. Sorry I'm not
| a frontend dev, what's the value added of this?
| jbverschoor wrote:
| So I don't understand. People are complaining about bootstrap for
| defaults. Then daisyui has great defaults, and the same class
| names. I see no reason to customize daisy.
| timwis wrote:
| Interesting side effects of css utility frameworks: I was trying
| to scrape a website that uses tailwind this week and it's really
| difficult, as nothing had a unique class name.
| jokethrowaway wrote:
| That's not very nice, maintainability suffers in the same way.
| You can obfuscate your classes later on.
|
| But alas, the battle for semantic css has already been lost and
| the community keep going in the opposite way (first bootstrap,
| which was halfway through, now tailwind which is basically
| inline styles with variables).
| gear54rus wrote:
| It is also an effect of various css-in-js shit, you can't know
| what the element does if it doesn't have a tooltip. Because now
| the class name is gibberish.
| sandGorgon wrote:
| this is so good!
|
| I wish the author would also put up a purchase page on
| https://themeforest.net/ . I dont mind optionally paying for it -
| especially a nicely packaged starter for nextjs, etc
| mukhidairyfarm wrote:
| India`s Biggest Hi Tech Organic Dairy Farm in BK Gujarat
| https://www.mukhidairyfarm.com
| ceiphr wrote:
| I love the little Cyberpunk theme example.
| irrational wrote:
| Anyone with experience using Tailwind UI want to comment on how
| this compares?
| Brajeshwar wrote:
| Here is my quick observation on a cursory glance.
|
| DaisyUI is beautifully written. This can be the kit with a
| boatload of work done for you. Think like Bootstrap but better
| with Tailwind. You can use this to teach how to write well
| thought-out CSS codes, separation, and extensibility.
|
| TailwindUI is more like Bourbon[1] (was my go-to Sass tool) but
| on the structural interfaces done for you. I'm standardizing
| out Web, WebApps, and marketing materials to start with
| TailwindUI. Someone with good chop of CSS/Tailwind won't likely
| need to use TailwinUI but it can be a fast tool for teams. It
| is highly extensible but also has the double-edge sword
| criteria that a rookie can just keep copy-pasting, repeating
| codes and still work (not a good thing).
|
| Will we use DaisyUI for the team? Unlikely!
|
| Will I use it for some quick but still larger project,
| marketing page? I might very likely.
|
| 1. https://www.bourbon.io
| nkmnz wrote:
| Using tailwindUI a lot. This doesn't come close in terms of
| visual quality.
| ing33k wrote:
| I recently used Tailwind UI to build
| https://zcashblockexplorer.com
|
| Tailwind UI is great! ( please note that I a primarily a
| backend dev with limited knowledge of CSS )
|
| Looking forward to explore DaisyUI soon !
| FrontAid wrote:
| That page broke tabbing through interactive elements by using
| nested focussable elements like this: <div
| tabindex="0"><input ...></div>
|
| Because of that, it is sometimes necessary to tab twice to focus
| the next element. Not sure whether that is a problem of DaisyUI
| in general or just their website. But it is definitely annoying.
| swyx wrote:
| Other tailwind component libraries I track:
|
| - https://github.com/thedevdojo/tails
|
| - http://tailwindcomponents.com/
|
| - https://tailwindui.com/components
|
| - https://merakiui.com/
|
| - https://www.gustui.com/
|
| - https://mertjf.github.io/tailblocks/
|
| - https://shuffle.dev/ Tailwind visual builder
|
| (from my resources list https://github.com/sw-yx/spark-joy/)
| NaN1352 wrote:
| Looks good. I'd really like to use this. Mainly I like that the
| author used same approach as I do whereby with careful use of low
| specificity, a custom "btn" class can be further customized just
| by adding TW classes (ie. not css specificity issues).
|
| My only gripe with this is that you should then use a clearly
| defined and separate naming convention for custom classes, for
| example SuitCSS is good:
|
| Not
|
| btn btn-large rounded-full
|
| But
|
| du-Btn du-Btn---primary rounded-full
|
| ie. PascalCase component names,
|
| optional prefix (eg. du for daisy ui, because other apps also
| have their prefix see eg. Twitch and Algolia css)
|
| Bem conventions like double dash for modifier as opposed to a
| descendant
|
| https://github.com/suitcss/suit/blob/master/doc/naming-conve...
|
| So yeah I would like to be able at a glance to know where a class
| is from. "btn" is not from tailwind, but where is it from? What
| if my app uses multiple components, from third party etc? It's
| not clear.
|
| Other than that This is better than Bootstrap approach even with
| custom classes, because you take care of css specificity problem
| (assuming you can add a tw class anywhere and override the
| builtin custom classes)...
|
| this is the middle way that nobody uses for whatever reason, the
| one that makes sense, but requires a good basic understanding of
| css specificity as well as setup stringent css linter
|
| Also using a convention would let you use a good linter on the
| custom selectors
|
| https://github.com/postcss/postcss-bem-linter
| e12e wrote:
| Why mix in Pascal case ?
| FractalHQ wrote:
| I am so glad that I took the time to get fast with CSS. I can
| build unique UIs in real time, and with Svelte Components,
| everything is automatically scoped to the component. I would
| waste so much time and gave a lot of analysis paralysis if I had
| to choose from all these cool looking libraries and frameworks,
| learn their api's, and then learn how to override them more and
| more over time.
| thrownaway561 wrote:
| so you recreate bootstrap with tailwinds... we've come full
| circle.
| [deleted]
| whoisjuan wrote:
| I'm not saying this is ugly but the visual execution of some of
| these components is poor. No good usage of padding in some
| examples, poor ratios between the typography and the containers,
| inconsistent use of different line widths and border radius,
| weird and incosistent design choices in spacing and
| proportions...
|
| I mean. This looks alright and it will certainly make any UI look
| pretty decent, but the execution is not superb like the actual
| TailwindUI library which is incredibly well thought from a visual
| design perspective. Those components are perhaps less shiny than
| these but they are incredibly functional and way more
| intentional.
|
| This is a good effort though and I hope to see it improving.
| joexuyi wrote:
| Agreed. Not to sound too critical, but it looks off.
| AngeloAnolin wrote:
| I think it is not a fair comparison with the Tailwind UI where
| there's probably more than one person doing the work plus the
| whole expertise of the actual Tailwind authors in the mix.
|
| If you are able to observe what is severely lacking in this
| implementation, I am pretty sure that the Github author would
| welcome your suggestions / comments / PRs and any contribution
| to make this better.
|
| For a start, this is actually good (enough).
|
| In the same vein that TailwindUI is still continuing to evolve
| as the maintainers are finding optimization to make it better.
| whoisjuan wrote:
| Totally agree and I mean it with no animosity. As an adopter
| of Tailwind, I really want to see more of these components
| kits and for the exisiting ones to keep improving.
| onion2k wrote:
| Back when Bootstrap 2 was the most popular UI library one of
| the biggest problems with it was that the defaults were good
| enough that no one changed them, and consequently every SaaS
| startup's product looked the same for about 5 years. Pushing
| people to tweak things while still giving them a solid
| foundation is a good thing.
|
| I'm not saying that's necessarily the case here, but there is a
| strong argument in favor of _not_ making the default theme for
| a UI library look perfect.
| jhgb wrote:
| > the defaults were good enough that no one changed them, and
| consequently every SaaS startup's product looked the same for
| about 5 years
|
| Sounds like native GUI experience on Mac or Windows for quite
| some time, then? I'm certainly not offended when all buttons
| look the same. At least I immediately know that they're
| buttons.
| breakfastduck wrote:
| I take it you dislike native software then...
| onion2k wrote:
| I'd do 100% of my job in a browser if I had the option.
| hashedout wrote:
| This argument makes perfect sense. The easy adoption that
| never gets updated in future sounds bland.
| mosburger wrote:
| I still think about the quote I once heard around that era...
| "Made with Bootstrap" is the "ft. Pitbull" of web design.
| thomasfl wrote:
| A few pull requests could fix most of what you mentioned, if
| the maintainer approved it.
| udbhavs wrote:
| This sort of stuff was difficult to figure out when I was
| learning HTML/CSS, do you know of any guides which list similar
| rules and how to make "proper" use of properties like borders,
| padding, typography etc?
| brainbag wrote:
| The Non-Designer's Design Book is the best resource I know of
| for learning general design guidelines, which apply to what
| you're asking. I've bought this book for many developers and
| they've all loved it.
| chrisweekly wrote:
| https://every-layout.dev
| MonaroVXR wrote:
| I have made notes about these things you're asking. But no
| idea how to share them.
| AnonC wrote:
| You could refine them, group the points and put up a blog
| post (or a GitHub page) and share that here (as its own
| submission). If it's with visual examples, all the more
| better. I'm sure somebody will find it useful.
| dceddia wrote:
| This stuff all falls under the umbrella of "design". One
| thing that helped me a ton was the articles at
| https://learnui.design - especially the 2-part "Rules for
| Designing Gorgeous UI". The course itself is also excellent.
| bennyp101 wrote:
| Refactoring UI [1] is a good place (from the guys behind
| Tailwind) - admittedly I've drunk the Tailwind koolaid, but
| there are some useful tips on there from a designer POV
|
| [1] https://www.refactoringui.com/
| lawn wrote:
| I dislike Tailwind's choice of inlined styles in html, but
| I agree that the advice in the book is very good.
| tailspin2019 wrote:
| Unrelated tangent: I'm always frustrated when I see a
| recommendation for a book only to go and look it up and
| find that it's actually an "ebook" (in this case PDF).
|
| Not to make a value judgement on ebooks, but I just
| really like physical books sometimes - if it was on
| Amazon I likely would have bought it.
|
| Again, not a value judgement on the content - I'm sure
| it's great (I'm a paid and happy user of TailwindUI)
| lawn wrote:
| Yeah I agree, there's something about holding a book in
| your hands. I also think it helps hold my focus and lets
| me retain what I read better.
| dqx wrote:
| Graphic design
| antigirl wrote:
| Fair points but TailwindUI bundle is EUR258, this is free.
|
| https://tailwindui.com/pricing
| tailspin2019 wrote:
| I agree that there is room for improvement - though I think
| it's not a bad V1 at all.
|
| A lot of the products I see turning up on Show HN would look
| infinitely better if they used this library. (The ones where UI
| design is clearly not the solo-developer's strength).
| hashedout wrote:
| This is a very nice step in making Tailwind more Bootstrap like
| (read beginner friendly). One common complaint about Tailwind is
| that it makes the HTML look very full (full of classes).
|
| A very good example on OP's website for a button:
|
| Using tailwind: <a class="inline-block px-4 py-3
| text-sm font-semibold text-center text-white uppercase transition
| duration-200 ease-in-out bg-indigo-500 rounded-md cursor-pointer
| hover:bg-indigo-600">Button</a>
|
| Using daisy: <a class="btn btn-
| primary">Button</a>
|
| Although I personally think that the corners at a bit too rounded
| by default, giving it a very amateur look but I think you can
| customize that.
|
| But a very promising project indeed.
| joexuyi wrote:
| so why not just use bootstrap? I'm new to web development, but
| I thought the whole point of TailwindCSS is that it is more
| customisable than Bootstrap.
| hashedout wrote:
| What if you as a beginner can start using Tailwind
| immediately with this library and can learn tailwind's
| utility classes at your own pace when you need to customize
| anything?
|
| I'm not sure about this path, but it might be good for a
| beginner.
| thecryptodiver wrote:
| Yeah, this seems more like the combo of ease of Bootstrap +
| the extendability of Tailwind.
| volkandkaya wrote:
| It is hard to breakout of Bootstrap defaults.
|
| Both libraries have pros and cons.
| supermatt wrote:
| Thats exactly what this component library does:
| https://daisyui.com/components/button
|
| If you want to do in "raw" tailwind (i.e. without this
| component library), you can use layers to create your own
| component classes, e.g.: @layer components {
| .btn { @apply inline-block px-4 py-3 text-sm font-
| semibold text-center uppercase transition duration-200 ease-in-
| out rounded-md cursor-pointer; } .btn-primary {
| @apply text-white bg-indigo-500 hover:bg-indigo-600; }
| }
| karlerss wrote:
| If it's just one class per property, you could just type out
| the CSS. Using emmet in IDE is probably faster than finding
| the tailwind classes with autocomplete.
| automatic6131 wrote:
| >If it's just one class per property, you could just type
| out the CSS.
|
| You can, but then it rarely happens that you want the CSS
| to be fixed in that way for all time: the brilliance of
| tailwind is that you get resposniveness just by adding a
| few more classes. You cannot do that with inline CSS.
| FractalHQ wrote:
| This is the one pro-tailwind argument I can agree with.
| Sometimes I'll use their shorthand md: & sm: in @apply in
| place of media queries. The advantage is that they remain
| local to their relevant selectors.
|
| Makes me think- all I would really want is to be able to
| have multiple values in css. Maybe something like .
|
| .card { width: 5rem md: 10rem; }
|
| Snap... am I on to something?
| Nullabillity wrote:
| Sass/Scss let you nest media queries inside of selectors
| years ago.
| FractalHQ wrote:
| And the result is html and css that is easier to read
| later. I'm so fast with CSS that Tailwind inevitably slows
| me down as an app scales.
| hardwaresofton wrote:
| I agree with the positive sentiment, but a cynical take might
| be that we've basically found our way back, traveling in a
| circular pattern.
|
| It looks like Tailwind and Tachyons are useful tools but they
| do have a sweet spot, and I've run into the annoyance of 20+
| classes in my tiny projects as well. Descriptive
|
| Real changes to the landscape have been made along the way:
|
| - Flexbox and to a lesser extent grid are grokked by many
|
| - People are much more willing and able to use CSS variables
|
| - Shadow DOM encapsulation and other methods of isolating
| styles from one component to another are well explored
|
| - there's some stuff on the horizon where people are JITing
| here and there and writing custom compositors ("Houdini" and
| related tech)
|
| But I'm not sure there have been any large paradigm shifts in
| CSS over the last 10 years, and Tailwind no matter how
| successful it's been commercially and in the headspace of
| developers seems to have been largely a very useful somewhat
| passing obsession.
| hashedout wrote:
| I see this not as a replacement, but as a novice choice. As
| noted in the documentation, you can use tailwind classes to
| customize existing components but if you do not want to you
| can use it like bootstrap. Even for building a quick
| prototype which can be made to look good in future is a use
| case for this.
| hardwaresofton wrote:
| I want to note that I was talking about tailwind vs
| bootstrap and others in the abstract, less so about DaisyUI
| _specifically_.
|
| What lead me to make the comment was the discussion point
| that "btn btn-primary" was so much more useful than 20+
| tailwind classes. I agreed (it's something I have come
| across as well), but
|
| It's clear that Daisy UI will get you up and running
| quickly and there are lots of similar projects out there
| that do things like this, but the meta discussion around
| whether we're going in circles or if we've actually moved
| forward and found a nice mix between what was the bootstrap
| style (1-2 classes that do all the work) and
| tailwind/tachyons (5-10+ classes that do the work).
|
| To make the discussion less meta -- is the future things
| like DaisyUI? Bootstrap like classes but with the outlet
| for overriding _not_ being manual CSS but actually being
| tailwind-style classes? In the past it was Bootstrap + your
| special large class /baked in styles, but in the future
| maybe it's "btn btn-primary box-shadow" or whatever,
| clearly a middle point of sorts
| piaste wrote:
| I'm not a frontend developer so I've been watching this
| from the outside over the years of reading HN.
|
| The impression I got is that Tailwind is essentially CSS
| 2.0 with warts ironed out (sorry for the unpleasant mixed
| metaphor):
|
| A) CSS / Tailwind: lots of little 'atomic' classes
| describing individual visual properties. Easy to
| understand, easy to customize, but slow to read, slow to
| get started, with plenty of stuff to learn
|
| B) CSS frameworks / Tailwind components: fewer classes
| declaratively describing the component's role (eg 'btn-
| primary'). Quick to get started, elegant to read, but
| prone to abstraction leakage and trickier to bend to your
| own exact specifications
|
| There's always been a need for both kind of tools for
| different projects, in the same way that e.g. network
| programming may involve anything from bit-banging
| commands to high-level protocols.
|
| Over the years CSS frameworks kept improving, but CSS was
| much slower to do so - although it acquired flexbox,
| grid, etc., the language limitations stayed, and they
| were bad enough to spawn SASS/LESS out of a genuine need.
|
| Tailwind saw a ton of hype and adoption because all the
| developers who had always wanted to go the (A) road now
| had a well-designed set of simple classes they could use
| with a lot fewer footguns, plus a bunch of developers who
| had adopted (B) because it was the road that had all the
| momentum suddenly realized that they probably wanted to
| use (A) once it was made less painful.
|
| DaisyUI and similar projects don't do anything that
| Bootstrap didn't do for CSS, but by building on top of
| Tailwind it means that, when your project or resources
| grow and you want to move from (B) to fully customizing
| your style in (A), you will be able to write your
| individual little graphic touches in Tailwind instead of
| plain CSS.
| bennyp101 wrote:
| I tend to use it with some sort of component system -
| vue/react/svelte - so writing the classes out once
| doesn't bother me.
|
| I actually like it, as looking at the code I can see
| exactly what it does. 'btn-primary' doesn't convey
| anything to me. 'rounded text-sm font-bold py-2 px-3 bg-
| indigo-300' I know exactly what that is going to look
| like.
|
| I also appreciate the removal of classes not needed if
| using a build step - much nicer to have a small css file
| that has exactly what you use, rather than a bootstrap
| style kitchen sink
| [deleted]
| dmitriid wrote:
| No. No. It's a link disguised as a button. Stop doing that.
| runarberg wrote:
| Why? A "create" button that takes you to a creation page is
| still a link to that page and should be a link. It looking
| like a button indicates an action that the user understands.
| It is accessible, semantically correct, and follows accepted
| design conventions. What is the problem?
| dmitriid wrote:
| > Why?
|
| Because there's an expected built-in behaviour to these
| elements.
|
| > It is accessible, semantically correct, and follows
| accepted design conventions.
|
| There's nothing accepted about disguising a link as a
| button. Especially when it literally does no action except,
| you know, linking to a different page.
|
| Though, of course, there are ambiguous situations,
| especially in the context of PWAs. But code examples are
| not an ambiguous situation.
| bennyp101 wrote:
| I think that ship has sailed, I really don't think that
| average users expect a button to 'do something' (in the
| sense it submits a form or something). Going to a
| different page /is/ 'doing something' as far as users are
| concerned. Certainly not the internet of old where a form
| was a form, and a link was a link.
| dmitriid wrote:
| An average user has no idea what's going on in modern
| software anymore, to be honest. Nothing is what it seems
| and is redesigned every couple of months
| runarberg wrote:
| On the GitHub front page there is a sidebar with a second
| level heading for "Repositories". Next to the heading
| there is a: <a class="btn btn-primary"
| href="/new"> New </a>
|
| Below the heading there is a list of repos which had a
| recent activity by you. Each list item has a link to an
| that repo. <a class="dashbord-
| underlined-link" href="/namespace/repo">
| namespace/repo </a>
|
| There is a substantial difference between these two
| links. One takes you to a location, the other one starts
| a process which ends with an action.
|
| As a user you are not going to be clicking the "New"
| button everyday. Maybe once a month, maybe once a year.
| So you are likely not going to remember where it is from
| the last time you clicked it. If you don't find it when
| you need it, you will get frustrated. It needs a lot of
| visual weight relative to the other links in this nav
| section. Giving the same weight as a button is a
| reasonable decision.
| louissm_it wrote:
| Eh, unless an app is a SPA (where you attach event handlers
| to buttons to run client side validation or something like
| that) it's way simpler to have a form route to another
| resource via a link. But users think of them more as actions
| than links, so its perfectly reasonable to disguise a link as
| a button.
|
| edit: I said "form", but I meant page. Forms actually use
| buttons!
| rvense wrote:
| With Tailwind, if you write out something like that more than
| once or twice, you're really supposed to bundle it together.
| Either as a plain CSS class, or a component in your framework
| of choice.
|
| I suppose a library of common elements is a good thing to have,
| but the reason I like Tailwind is that I can use the utilities
| at first and then easily gather them together as plain CSS
| classes as and when that makes sense to me.
| mikevm wrote:
| But if you're going to hide away CSS inside a component, why
| not just use inline CSS? What does Tailwind add to this?
| Cthulhu_ wrote:
| As others commented, inline CSS has downsides. But there
| are libraries out there that allow you to write a block of
| CSS alongside your component that are neatly packaged into
| a CSS file, like Styled Components (https://styled-
| components.com/).
| dgb23 wrote:
| Well for one you cannot use all CSS features inline, some
| of them are pretty important. Then there are also bad
| performance implications of using pure inline styles.
|
| But in terms of structuring your code, there are related
| concepts in other areas of programming:
|
| The most general concept applied here is stratification or
| layering. You want to decompose your code into more general
| pieces so you can use those pieces to compose the actual
| solutions.
|
| Example: Say you wanted to write a compiler. It typically
| much easier to simplify, AKA decompose the compiler into a
| scanner, parser, analyzer, optimizer, emitter etc. The
| users of your compiler probably don't care that you
| decomposed and layered your code. But you _do_ care, since
| you can reason about your code in terms of small /local
| problems. Maybe you don't stop there. Your scanner can be
| stratified further, so you can easily build evolve and
| reason about it.
|
| This is the primary thing these types of libraries do. They
| give you generalized building blocks that have
| compositional semantics that make sense. You can use their
| sane defaults or generate them from scratch using a design
| system.
|
| Secondly the atoms are discretely defined. You're not
| dealing with all possible values for each property but with
| sets that you can join/compose. The generated classes have
| this little mini-syntax that you first need to get used to
| a bit, but after a while you'll easily remember the prefix
| schema of your classes (Tailwind's documentation site is
| also very well made). Tailwind cross joins the atoms for
| you, but then also deletes all the classes you didn't use
| in your project.
| oefrha wrote:
| Whenever I read a comment like this I feel like talking to
| someone who's never used Tailwind nor written inline CSS.
| How do you write inline CSS for pseudo-classes like :hover,
| :focus, :disabled? Media queries for breakpoints and dark
| mode? Not to mention more advanced features like divide-,
| space-, group-hover:, etc.
| rvense wrote:
| 1) A set of a classes with consistent names for scales,
| colours, etc. You're not working with hex codes or pixel
| values. It's a more writable and much more readable syntax
| than inline styles.
|
| 2) It has variants for hover, etc (e.g.: class="bg-black
| hover:bg-white"). AFAIK you can't do that with inline
| styles.
|
| 3) I find it plays nicely with a workflow where I start out
| not knowing exactly what I'm doing, which is almost all of
| the time. I can smash ahead and do things in the class=""
| of each tag, then as I notice that I'm repeating myself, I
| grab small chunks of the class list and put them in
| '@apply's in a CSS file. Bottom-up, liek.
|
| The class lists are just a lot more manageable than inline
| styles. They're copy-pastable and really easy to read when
| you get used to it, as long as the lists aren't too long.
| listenallyall wrote:
| a _very_ underrated feature of Tailwind is it 's excellent
| documentation with immediate search. Want italic text? In
| straight CSS, how long will it take to look up is it font-
| style: italic; or text-style: italic or text-italic: true ?
| Tailwind's docs make it virtually instant. Even more
| impressive with flex and grid layouts (is it justify-items
| or align-items, etc). I find that Tailwind reduces the time
| from "idea in brain" to "implemented on page" by about 90%,
| now multiply that by dozens or hundreds of individual page
| elements. (to be fair, I don't do a ton of front end so I
| forget the CSS syntax quite often)
| BigJono wrote:
| This is the worst "feature" ever.
|
| What's the point in spending 20 hours learning some
| custom interface that's only used in like 5% of projects
| and will probably be gone in 5 years, when you could
| spend 30 hours learning the standard that's been around
| for decades and understand every library for years to
| come?
|
| Just learn CSS, it's not that hard.
| aniforprez wrote:
| You... don't? Spend 20 hours learning, that is
|
| I never sat down for hours to learn it. I just started
| using it. Most of the classes were very intuitive with a
| working knowledge of the box model. For anything else I
| just searched the docs or even better, got the VSCode
| plugin to suggest the correct one
|
| It's not a custom interface. It's just classes. It's got
| a type of syntax, sure, especially for media queries but
| it's not much different than "learning" the classes from
| bootstrap
|
| It's literally just CSS but abstracted as convenient
| classes as the name "utility classes" implies already. I
| don't understand why people keep telling others to learn
| CSS instead. I also hate dealing and writing CSS cause
| it's cumbersome and unwieldy and this is a much better
| way of styling my HTML and getting immediate feedback
| antihero wrote:
| Tailwind gives you rules and constraints.
| bennyp101 wrote:
| Because you don't have to use it in a component system.
| It's not a case of hiding it away, it just has a system for
| building your own css library kind of thing if you want to
| andrewingram wrote:
| There's a pretty good article by Sarah Dayan about this,
| which was written in response to one of the more recent
| Tailwind dramas on Twitter:
|
| https://frontstuff.io/no-utility-classes-arent-the-same-
| as-i...
| hashedout wrote:
| Yes, the way I use it is with Svelte. I've created a list of
| components in Svelte (buttons, links, dropdowns, tables,
| etc.) I think with how tailwind makes you html look (very
| full of classes), it is perfectly matched with a component
| based framework.
|
| That way you get the full tailwind experience without the
| tedious rewriting of components.
| axegon_ wrote:
| Great! Over the past 6 months or so I've noticed a trend which I
| like: people are less obsessed with all the modern react-angular-
| vue-js-everything-html-css-bad notion and a lot of people are
| starting to admit that this whole sack of gibberish is
| unmanagable and unmaintainable(the web got it's own version of
| segfaults where something crashes and no one has even the
| slightest idea why) and we are coming full circle back to the
| late 2000's internet. Which to my mind was the golden age of the
| internet: you could slap a vga cable onto a potato and it had the
| computational power to display any page, whereas in recent years
| a single page eating up 200+ mb of your memory and increasing the
| cpu usage by 15-20% was a completely normal phenomenon. Oh and
| let's not forget "ew jquery, that's 200kb, that's horrible" all
| while bundle.min.js is a 15mb freak. Good job, personally I had
| completely lost hope, now I am starting to have some.
| Aeolun wrote:
| I tried using Tailwind, but I just couldn't get into it. It's
| like having to learn CSS all over again because the classnames do
| not map 1-1 with their respective properties, and autocomplete is
| lacking.
|
| Conversely, Chakra UI Box, which does more or less the same thing
| is super easy to get into.
|
| This looks nice, but I kind of feel like we've come full circle
| two full times to get to this point.
| bennyp101 wrote:
| I'm not sure why you would want them to map 1-1? Might as well
| just write inline styles surely?
|
| For autocomplete, have you seen
| https://tailwindcss.com/docs/editor-support ?
|
| I use it in PHPStorm and VSCode and I get class name
| autocompletion just fine.
| mhitza wrote:
| Autocompletion works for now, but won't work in the future
| when JIT mode is default (unless they figure out some
| trickery).
|
| As a JIT mode user, the 1-1 naming would really be useful
| now.
| robertwt7 wrote:
| So much love for tailwind, I love it. Honestly though I haven't
| use any other component than Material-UI for the past couple of
| years. I was thinking to convince my previous company to buy
| tailwind-ui just for the sake of curiosity :p but then I know I
| won't use it much. So not sure..
|
| In the end the point of all of us using tailwind is because its
| not "opinionated" like bootstrap right?
| DLA wrote:
| Using DaisyUI for three projects currently and LOVE the hell out
| of it. Don't get me wrong I love some TailwindUI as well, but the
| simplicity of Daisy is fantastic. Winning combination for us:
| DaisyUI + TWCSS + AlpineJS + Go Fiber server & templates.
| eenberg wrote:
| That page is extremely slow without hardware acceleration. It
| (hw-accel) was off for me because I updated some things without
| restarting Chromium, but I dunno. It doesn't "spark joy" with me.
| elwell wrote:
| Yeah it is lagging for me too. And I do have hardware accel off
| as well, because of a chromium bug.
| shock-value wrote:
| I am seeing that also. Continuously used ~50% of my 2015
| Macbook Pro's discrete GPU and caused the system fans to kick
| off, just looking at the components on the landing page.
| geenat wrote:
| Super laggy components.
| eric4smith wrote:
| Very welcome. Sometimes the amount of classes needed in Tailwind
| is enormous.
|
| I paid for the TailwindUI pack too. But as nice as Tailwind is,
| the guys who built TailwindUI don't really get or understand a
| lot of real-world design patterns.
|
| A lot of stuff in there is needlessly complicated. Our team end
| up trimming down things to 50% of the markup that they use, while
| retaining full responsiveness.
|
| Overuse of flex for simple paradigms is a constant complaint of
| mine.
|
| Hope DaisyUI improves Tailwind in some way.
|
| Anyway... sorry to get sidetracked on a sidebar.. lol.
| maxcan wrote:
| Exactly. I paid for TailwindUI too but have been disappointed
| by the execution in code. I love the visual design, but give me
| some abstractions and not 20 classes per element.
|
| TUI design + DaisyUI's abstractions is the dream.
| tailspin2019 wrote:
| > the guys who built TailwindUI don't really get or understand
| a lot of real-world design patterns
|
| It's all relative. It's clear they understand more than I do,
| and I'm not a _terrible_ UI designer, so paying for TailwindUI
| has been a no-brainer in terms of the value delivered to my
| projects so far.
| NaN1352 wrote:
| I would suggest the use of convention like SuitCss for your
| custom component classes so you can lint them thoroughly to
| ensure low specificity.
|
| I would recommend to use a prefix on your custom classes, to
| "namespace" them. "btn" is far too generic. This can even be
| linted by eg. postcss-bem-linter.
| nickjj wrote:
| There's also https://tailkit.com/, the markup is pretty
| reasonable. It was designed by someone who has been making
| themes for ~10 years.
|
| I did a review of Tailkit in general here:
| https://nickjanetakis.com/blog/reviewing-tailkit-300-tailwin...
| Mike_Andreuzza wrote:
| >>>Our team end up trimming down things to 50% of the markup
| that they use, while retaining full responsiveness.
|
| I have to agree with this.
| runawaybottle wrote:
| My goodness Bootstrap, how far ahead of your time you were. To
| this day we copy you, god bless you m'lord.
|
| Nope, I reject this. We should be so much farther ahead than
| this. It's the garbage fullstack developers that need this crap
| to make a good ui. They don't belong on the frontend, and I'm
| pretty tired of it.
|
| Our UI/UX will get shittier and shittier if we coddle this group.
| [deleted]
| aniforprez wrote:
| This is probably one of the saltiest comments I've read here
| nunodonato wrote:
| welcome to bootstrap
| btbuildem wrote:
| Ok, I'll guess I'll be the lone voice of dissent here. I don't
| like it. I think it goes against the concept of utility classes /
| functional CSS. As soon as you start making component-level
| classes, things begin to become opinionated and you lose the
| universality.
|
| My understanding of the functional CSS approach was that you'd
| make a button component, and use the variety of "atomic" classes
| to style it. If you're using a "btn" class etc, it muddles the
| distinction of where the semantics live, and things get harder to
| reason about / debug.
| midrus wrote:
| Well, this is true, but to me this provides a set of good
| defaults instead of starting from scratch. I see this very
| useful for example for side projects, where I don't want to
| start from scratch on every experiment I do.
|
| For a work project, I'd use just tailwind for the reasons you
| mention.
| manquer wrote:
| Absolutes are the problem. DaisyUI gives the flexibility of
| using Tailwind directly or higher level classes.
|
| Tailwind is great but sometimes you end up having 10-15+
| classes for basic components that makes the _code_ harder to
| read and reason with.
|
| We should have utility classes and composability, but relying
| on them exclusively is also not necessarily the best way
| either.
| azemetre wrote:
| Can't you just use @apply to make a single uniform style that
| utilizes all those classes?
|
| That's my understanding at least, like if you want to make a
| button, instead of have the same 10+ classes posted
| everywhere you make a new class with @apply and keep the
| styles uniform.
|
| Then in the future if you need to change one of the core
| utilities it's also easily updated to all you the @apply
| classes you make.
|
| Am I misunderstanding the purpose? I've only used tailwind
| twice.
| manquer wrote:
| yes you can use @apply. DaisyUI also supports @apply
| directives as well both for their own and tailwind clases.
|
| However you have to use them yourself. With vanilla
| Tailwind there is no out of the box @apply directives
| already set you can use. Think of DaisyUI as basically a
| whole set of @applies someone already made for you.
|
| For users new to frameworks with utility focus it can be
| less steep learning curve to experiment and all the out of
| the box abstractions can reduce the need for having your
| own.
| ratww wrote:
| Tailwind is supposed to be used with components. Often it's
| React/Vue/Web components, but CSS components with @apply,
| like you're doing, also work perfectly fine.
| doytch wrote:
| You're right, it isn't really utility/functional CSS - it's
| more akin to BEM [1] at this point. But having used both...I
| think it's pretty much six-of-one, half-dozen of another; you
| can write good or poor CSS both ways! :D
|
| [1]: http://getbem.com/introduction/
| Brajeshwar wrote:
| For those wishing to learn the intricacies and beauty of
| Tailwind, this is a good source. Well written code but might lack
| the finesse of design. Then use TailwindUI[1] as a kit for your
| design/frontend team.
|
| 1. https://tailwindui.com
| soheil wrote:
| Oh I pray that I remember this website next time I'm looking for
| an HTML/css template. Great job, this UI looks so polished and is
| as modern as it gets.
| Brajeshwar wrote:
| A much simpler Bootstrapped powered one popped up on Hackernews
| recently, https://frontendor.com
| sgt wrote:
| Recently bought Tailwind UI. Haven't really used it much except
| for a concept UI, and didn't work completely out of the box (you
| kind of have to know something about Tailwind the open source
| project first).
|
| Aside from that, it looks like a really convenient way to put
| together a web UI when you don't really want to focus on the UI
| part of your app too much.
|
| Not too expensive either, I think it was $175 or so.
| hardwaresofton wrote:
| In this space also: https://blocks.wickedtemplates.com
|
| (NOTE: I did not WickedBlocks/WickedTemplates -- it's the awesome
| work of the folks over at WickedTemplates
| https://wickedtemplates.com, which they shared on HN I believe a
| while back)
|
| I'm actually working on a little side project right now where I
| turn wickedblocks into a set of usable native web components (as
| in drop an <import> tag and the component on your page and you're
| off to the races), because I think that's a much more composable
| way to use these snippets copy & pasting HTML, looks like Daisy
| needs to be next.
|
| [EDIT] A bit annoying to others probably to drop a lede and I
| have no idea when I'll get done and publish it with the blog post
| so if someone just wants to see the code:
|
| https://gitlab.com/mrman/landing-gear
|
| If anyone wants to contribute a snazzy icon I'd love to take it!
| There's no landing page to showcase it yet but there's files like
| lg-left-header/index.html[0] which showcase usage and the
| intended simplicity.
|
| Obviously if you're trying to get started, use the blocks as
| they're presented and the awesome work done by WickedTemplates
| (they've also got some ready-to-go straight out of the box
| templates and other stuff for you to use on their main site!),
| but if you're interested in lit[1]-powered drop-in components,
| follow that space.
|
| [EDIT2] - For those taking a look at the code, note that there
| are like... 4 variants of the left-header component. Half of the
| time spent getting this out (it's all simple in theory -- just
| copy + paste and swap out static text for variables) was figuring
| out which parts to unify and which parts to keep separate for
| easy drop-in use. There's not much there yet, but it's more a
| matter of me finding time to sit down and make these decisions
| for every kind of component on the wickedblocks page.
|
| There are some concerns like i18n that I've punted on by just
| making sure that all static text were component inputs, but
| ideally integration with browser-supported i18n[2] is the proper
| way to do things in a minimal but standards compliant way.
|
| [EDIT3] - Added note to make it clear I didn't create
| WickedBlocks/WickedTemplates
|
| [0]: https://gitlab.com/mrman/landing-gear/-/blob/main/lg-left-
| he...
|
| [1]: https://lit.dev/
|
| [2]: https://developer.mozilla.org/en-US/docs/Mozilla/Add-
| ons/Web...
| Mike_Andreuzza wrote:
| Nice one.
| jpomykala wrote:
| You are trying to solve problems which were created by Tailwind,
| and you end up with Bootstrap.
| peterkelly wrote:
| I've never used Tailwind, but am familiar with Bootstrap. When
| looking at the examples, the ones on the right looked pretty
| much exactly like Bootstrap and I didn't understand what was
| interesting or novel about it.
|
| Is the code on the left (with lots of classes) actually what
| tailwind is like to use in practice?
| lyian wrote:
| Yes, the core idea is that you use a class which applies one
| css property to the HTML element. In practice you can end up
| with a lot of classes.
| ushakov wrote:
| yes!
|
| https://tailwindcss.com
| Phillips126 wrote:
| > Is the code on the left (with lots of classes) actually
| what tailwind is like to use in practice?
|
| As a fan of tailwind, I can say that I initially thought this
| was dumb and it would be hard to read through a huge number
| of classes applied to each HTML element. Later, I found that
| for many of my reusable components, I could combine classes
| into a single class. As an example, my stylesheet may look
| like this: @tailwind base; @tailwind
| components; @tailwind utilities; @layer
| components { .button { @apply text-2xl p-2
| bg-gray-100 text-gray-600 border border-gray-200 cursor-
| pointer hover:bg-gray-200 hover:border-gray-300; }
| }
|
| I can now just give all of my reusable buttons the ".button"
| class instead of the giant string above.
| zkldi wrote:
| But why would you use @apply instead of something like:
| .button { background-color: $gray-100;
| border: 1px $gray-200 /\* so on... \*/
| }
|
| i don't understand how these "micro" css classes actually
| help versus just setting the property.
| e12e wrote:
| It's a straitjacket to reduce inconsistency across
| different sections of a large app/family of apps - and
| which help a bit with finding common styles for
| refactoring.
|
| It's not so much about what you do as a single designer
| on the initial design, more about what a team of
| designers do when adding new apos/modules to an existing
| product.
|
| In theory you could use bootstrap and a theme - but your
| fellow team members _will_ get lost, re-invent some
| styles etc.
|
| I'm inclined to solve this problem with discipline and
| corporal punishment - but I'm afraid the tailwind-people
| are on to something.
|
| Basically the cascading part of css does not work well
| for applications / a suite of applications - it works
| better for actual hypertext documents (like sgml might) -
| where you can make a _layout_ that works, while the
| browser handles the user experience (UX). When layout
| /design becomes "just" part of how an app looks, but the
| important is how it beheaves (including things like
| hover, expanding menus etc) - bare CSS doesn't work as
| well. Not technically, but from a perspective of an
| evolving code base.
| neurotrace wrote:
| After working with Tailwind for a period of time I came
| to the exact same conclusion. You can achieve all of this
| in a better way using CSS variables. You can transform
| this: @tailwind base; @tailwind
| components; @tailwind utilities;
| @layer components { .button { @apply
| text-2xl p-2 bg-gray-100 text-gray-600 border border-
| gray-200 cursor-pointer hover:bg-gray-200 hover:border-
| gray-300; } }
|
| in to this: .button { font-
| size: var(--text-2xl); padding: var(--p-2);
| background-color: var(--gray-100); color:
| var(--gray-600); border: solid 1px
| var(--gray-200); pointer: cursor; }
| .button:hover { background-color:
| var(--gray-200); border-color: var(--gray-300);
| }
|
| Adjust variable names to taste. No build step, no extra
| tooling, just as readable in my opinion. On top of that,
| using CSS variables means that those values can be
| changed at runtime. You basically get user-driven theming
| for free.
|
| I'm building an app like this right now and it's been
| lovely.
| e12e wrote:
| How do you deal with media queries/responsiveness?
| neurotrace wrote:
| I'm on mobile so forgive me for not giving more extensive
| code examples. In my case, I'm building my app with
| React, TypeScript, and react-jss. I've got an enum which
| stores my common media queries and I just use it in the
| style declaration. button: {
| [MediaQueries.Medium]: ... }
|
| I can't use CSS variables for that but I personally don't
| think it's useful to let the user redefine those queries
| anyway
| zkldi wrote:
| I really like this approach - I forget CSS has native
| variables now (maybe it has had it for a while?) and
| always think of scss's $variables.
| wishinghand wrote:
| Couldn't you just write a normal CSS class though, instead
| of going through the rigmarole of Tailwind?
| bilekas wrote:
| This is actually beautiful, and really clean.. I will definitely
| be giving this a try. Nice job!
| XCSme wrote:
| I am not sure this is production-ready. I had a look over some
| components and the UI/UX is poor in general (bad alignment,
| padding, bad accessibility, no proper focus traps, no keyboard
| support, etc.). Maybe some of those are lacking because it is a
| CSS-only implementation? But you still can't use them as it is
| without proper accessibility support.
| happy_one wrote:
| Is there something exactly like this that doesn't depend on
| tailwind?
|
| Using bootstrap themes are what I do now but they always have a
| limited number of components and don't have ready to go, copy-
| pastable documentation.
|
| Ideally I'd have a library that I can just copy paste beautiful
| pre-made components.
| chris_st wrote:
| Really like DaisyUI, it's a nice quick way to get a light,
| consistent page built.
|
| I recently found a problem with DaisyUI, put up an issue, and it
| was promptly and politely fixed.
| z3t4 wrote:
| As an old school web dev I write semantic HTML by hand and try to
| avoid using classes...
| gcatalfamo wrote:
| Could somebody who used both this and Bulma give an overview?
| volkandkaya wrote:
| DaisyUI is a great starting point but it is missing a lot to make
| it functional and then you end up recreating the wheel.
|
| I agree with some comments that it is lacking that wow factor
| that TailwindUI has.
|
| I'm working on https://versoly.com/ which is a Tailwind Website
| builder and have ran into a bunch of issues with Tailwind when it
| comes to building static sites.
|
| I love that Bootstrap offer "btn btn-primary" and it makes it
| very easy to keep a consistent site.
|
| For Tailwind to take off it needs
|
| - A list of components (maybe 20 ish, buttons, tabs, navbars
| being the main ones) - JS for components - Container system (I
| have built one that works similar to Bootstrap and makes it much
| easier to create responsive layouts quickly)
|
| Once those core parts have been built I believe developers will
| create more advanced libraries such as lightboxes etc which will
| save even more time.
|
| I'm a big fan of the new https://github.com/vuejs/petite-vue
| which is only 5kb and comes with a lot of power. Also combining
| it with something like
| https://github.com/CaptainCodeman/x-transition would be
| interesting.
|
| I really want to see Tailwind grow so if you're interested in
| opensource or want to create paid UI kits feel free dm as I have
| a ton of ideas.
| kristiandupont wrote:
| >For Tailwind to take off it needs
|
| You have a lot higher standards than I about what "taking off"
| means :-D
| volkandkaya wrote:
| It is doing amazing.
|
| But I talk with a lot of full stack and backend developers
| who still use Bootstrap. They even own TailwindUI and other
| templates but stick to Bootstrap.
|
| That to me means there is a big issue with Tailwind and the
| developer experience.
|
| Once solved Tailwind will grow even faster and help more
| developers/companies.
| vachi wrote:
| My team and I also made a similar library, more so for
| dashboards. https://github.com/mutable/meiosis
| tpetry wrote:
| I am more impressed by the landing page than the actual
| components. Is anyone aware of a good component library for
| landing/marketing pages for Tailwind?
|
| There are toolkits like https://frontendor.com but they all
| follow the 5-10 year old "theme" of insanely packed content you
| had seen on SaaS pages some years ago. Together with many
| photographs or flat humans... I can't find anything with "new"
| approach which uses more padding, much more detail to typography,
| bigger fonts etc. shown very good on the https://tailwindcss.com
| landing page. Or any hint where all the new startups get their
| designers for these new fresh layouts?
| BigJono wrote:
| I must be getting old because I literally don't get front end
| devs these days...
|
| The landing page is like a few divs with some position centres.
| What would you even use a "component library" for in this case?
| The only thing on the entire page with any complexity
| whatsoever are the component demos (which are obviously part of
| this DaisyUI thing itself) and the code blocks/syntax
| highlighting, which I'm sure there's a billion libraries for
| already.
|
| I'm really struggling to come up with any sort of other
| dependency that would help me build that page any faster than
| just opening the text editor and shitting out some HTML and
| CSS.
|
| Do people just spend so much time working with Bootstrap and
| whatever other cruft that they just never bother to learn the
| basics?
|
| At this level of simplicity and for churning out marketing
| pages where you don't care about maintainability, you're
| probably better off looking for a WYSIWYG editor rather than a
| library.
| da39a3ee wrote:
| You must indeed be getting very old. The purpose of the
| library is not to implement its own landing page.
| Pluiesurlavitre wrote:
| Did you check https://tailwindui.com/ ?
| bennyp101 wrote:
| There is an awesome[1] site for tailwind that has lots of
| places that could give you ideas.
|
| Or you could buy the Tailwind UI[2] - they add lots fairly
| often.
|
| [1] https://github.com/aniftyco/awesome-tailwindcss [2]
| https://www.tailwindui.com
| devops000 wrote:
| Very cool! Would be great to have tile as checkbox component.
| https://youtu.be/h_7gV44rA-Q?t=19
| catmanjan wrote:
| I've heard a lot about how great tailwind is, can anyone point to
| some good examples of people using it? Most of what I can find is
| just samples
| leodriesch wrote:
| https://github.com/vercel/commerce
| cjohansson wrote:
| I believe in semantic class-names, I know one can transform
| tailwind into cleaner markup but it seems to introduce more work
| than just building from scratch
| csabakissi wrote:
| One of the best looking tailwindcss components. I'm wondering if
| this library will grow in the future to something much bigger.
| ponyous wrote:
| This library highlights the biggest issue of tailwind for me.
|
| > Clean HTML
|
| The rest of your code will still use bunch of shitty tailwind
| shortcuts that are really chaotic the moment you build something
| more than a simplest component.
| Phillips126 wrote:
| I mentioned it in another comment, but I felt the same way
| until I figured out there is a solution. Here is an example of
| a simple CSS file with a reusable button class:
| @tailwind base; @tailwind components; @tailwind
| utilities; @layer components { .button {
| @apply text-2xl p-2 bg-gray-100 text-gray-600 border border-
| gray-200 cursor-pointer hover:bg-gray-200 hover:border-
| gray-300; } }
|
| I can now just give all of my reusable buttons the ".button"
| class instead of the giant string above. I can even add more
| styles or overwrite existing styles to give it a different look
| such as: <button class="button bg-red-100 text-
| red-600">Click Me</button>
| tomcooks wrote:
| Real nice, pity the "see component" popup that appears when
| clicking on anyhomepage component prevents from checking it out
| and there is no way to hide said popup
|
| Real nice, looks professional and casual - well done!
| btbuildem wrote:
| Yeah you have to look with your eyes and not your cursor
| conatus wrote:
| Cool to see this out, but there is something about Tailwind I've
| never really got. And this is not from abstraction, but in
| production use on a number of pretty large sites.
|
| Each Tailwind class corresponds to a CSS property, with a few
| exceptions where you have utility classes for degrees of that
| property (for example, padding, margin). Then along come these
| CSS component libraries, which substitute a thicket of these
| utility classes for a single class. Including Tailwind UI itself.
|
| Given that the relationship of class to property is one to one,
| why not cut out the middle person and just use CSS directly?
| There seems no real advantage. You've basically indepedently re-
| invented CSS, while adding a strange layer of additional
| abstraction on top. It is nice and fast to write it in the HTML
| I'll grant, but, the speed advantage is not so great that it is
| worth it compared to the mental overhead of other aspects of
| working with Tailwind (e.g. having to trim all the classes with
| automated scripts and so on).
|
| Perhaps I am missing something here?
| verisimilidude wrote:
| For each project, there's a unique balance between HTML, CSS,
| and the greater organization.
|
| Consider a site that mostly renders Markdown or XML documents.
| Tailwind is probably the wrong choice. You have less control of
| the HTML content in this case, because it's generated. If you
| want to use Tailwind here, you'd need to make liberal use of
| Tailwind's @apply directive for basic declarations, which IMO
| is not the best expression of Tailwind usage. On the other
| hand, you have a lot of control over the CSS. It makes more
| sense to write the CSS directly.
|
| Now consider an organization with many separate web properties,
| which all require consistent branding. The organization has a
| UI guy who creates universal stylesheets and components for use
| across sites. Here you have less control over the CSS, and more
| over the HTML. Tailwind makes more sense. You can add all the
| utility classes to HTML that you want, with few overrides or
| other enterprise pull-ups.
|
| This latter scenario also highlights one of Tailwind's
| strengths. Tailwind limits your options. If you need to keep a
| brand consistent across a large number of properties, Tailwind
| keeps you in the guardrails of the style guide. I can't be the
| only one who's worked at an organization where there's supposed
| to be only one shade of blue to represent the brand, but you
| wind up finding 160 different shades of blue throughout the
| CSS.
|
| Anyway, Tailwind has its time and place. I love it when it
| fits.
| armchairhacker wrote:
| We've gone full circle - CSS components to inline CSS-in-HTML
| back to CSS components.
|
| But I actually think I will use this. A big problem with CSS is
| that you end up making overrides no matter how composable you
| make the classes. And some simple things (e.g. responsiveness)
| are unintuitive and / or annoying to do in CSS. Hence Tailwind's
| "CSS-in-HTML" mini classes. But that doesn't fill the core
| purpose of CSS, bigger general-purpose classes to avoid
| repetition. Combine the two (general classes + mini classes for
| slight case-by-case fixes) and you get the best CSS experience
| I've seen so far (at least I think, I haven't tried it yet).
| tenaciousDaniel wrote:
| idk, I've been using tailwind for the past 4 months on a large
| and complex project, and I haven't had to override a single
| class. There were a few instances in which I needed to write
| custom css to handle certain scenarios, but that is roughly
| 100-200 lines of css.
|
| I also never had to do it when I was using Emotion, and I used
| that for 2 years.
| rmetzler wrote:
| I also haven't done much CSS since bootstrap 2.x days. I wonder
| if there is some tooling you would run in your CI to propose
| CSS changes - not failing like most linters but just nudge the
| devs a little to improve on low hanging fruits.
| edoceo wrote:
| Back in the day it was `grep style=` in the code. All over-
| rides started there, then would (eventually?) get promoted.
| NaN1352 wrote:
| Correct you explained better than I did.
|
| Using a convention for custom classes helps distinguish from tw
| classes and other libraries, and allows stringent linting of
| css selectors to make sure the specificity issue is covered
| (without using !important on all tw and custom utilities which
| imho is a bad solution).
|
| https://github.com/postcss/postcss-bem-linter
| 411111111111111 wrote:
| It's not really full circle considering that tailwind-ui has
| always been how the people that created tailwind made their
| money.
|
| Tailwind never wanted to remove component libraries, they just
| wanted a straightforward and easy way to make these components.
| faeyanpiraat wrote:
| Op meant it in a bigger-picture-way.
|
| Oldschool custom stuff -> BS -> Tailwind -> Tailwind with BS
| UX
| beardedetim wrote:
| > A big problem with CSS is that you end up making overrides no
| matter how composable you make the classes. And some simple
| things (e.g. responsiveness) are unintuitive and / or annoying
| to do in CSS.
|
| 10000% agree with this. I have found that copy/paste until you
| need to go back and change the same value a few times is worth
| its weight in salt with CSS. Never has "a poor abstraction is
| worse than duplicate code" been truer than in CSS.
|
| What I found in my FE days ways that it wasn't until the
| project shipped and we were iterating on v2 did the actual
| reusable classes appear.
| blacktriangle wrote:
| I think the thing with Tailwind that people are missing is the
| opinion that CSS's bigger general purpose classes to avoid
| repetition have failed. However, most of us are using some kind
| of HTML templating system. What matters is that the design work
| only happens once in the code, repetition in the finished
| product is just fine. So moving the job of avoiding repetition
| out of CSS and into your HTML templating system is the right
| way to go.
| armchairhacker wrote:
| HTML templating (specifically FreeMarker macros) is what i'm
| doing now.
|
| There are still some cases where classes are useful, like JS
| or when I have very different components with some shared
| style. But these are mostly edge cases. FreeMarker has some
| other problems though.
| dimal wrote:
| Interesting. I write CSS with absolutely no overrides. I
| compose at the JSX component level, so there's one Button
| component used everywhere, not a btn class that gets applied to
| random <button> components. I usually need to reuse more than
| just a style, so why not encapsulate it at the component level?
| If I _do_ want to compose individual styles, I use Sass mixins.
|
| And I find that looking at a single media query over semantic
| classes to be far easier to understand than utility classes
| scattered over multiple elements. Looking at tailwind
| responsive classes hurts my brain.
| debarshri wrote:
| I am new to UI/UX. Is it comparable to bootstrap? How is it
| actually different from the CSS and UI component libraries?
| saadeghi wrote:
| You could say it's a component library like Bootstrap but it's
| customizable in core because it's based on Tailwind CSS. For
| example if you want to customize a Bootstrap button, you need
| to write additional CSS files. With daisyUI you can simply add
| a class name.
| hu3 wrote:
| > For example if you want to customize a Bootstrap button,
| you need to write additional CSS files
|
| No you don't need to write CSS files for that. Bootstrap also
| offers utility classes.
|
| If I want to customize padding I can add "p-3" or "p-4" class
| for example.
|
| Same for other properties including colors like "bd-
| blue-800".
|
| See: https://getbootstrap.com/docs/5.0/customize/color/
| debarshri wrote:
| Is it similar to reactstrap or react bootstrap?
| kemyd wrote:
| That's an interesting approach with bootstrap-like class names.
|
| At Shuffle[1], we create templates for Tailwind, Bootstrap,
| Bulma, and Material-UI and need to convert UI libraries from one
| technology to another.
|
| We decided to write converters that can transform HTML classes &
| Tailwind config to Sass config.
|
| Probably, we will release it as open-source soon.
| // Example: // Tailwind.config to Sass // button.js
| const { theme } = require('../theme.config.js');
| module.exports = { bootstrap: { 'input-btn-
| font-size': theme.fontSize.sm[0], 'input-btn-
| padding-y': theme.spacing[4], 'input-btn-padding-x':
| theme.spacing[6], }, bulma: { 'size-
| normal': theme.fontSize.sm[0], 'button-padding-
| vertical': theme.spacing[4], 'button-padding-
| horizontal': theme.spacing[6], }, }; //
| HTML export const mappings = [ {
| from: ['flex', 'flex-wrap', '-mx-4'], to: ['row']
| }, }
|
| [1] https://shuffle.dev
| gauchojs wrote:
| I feel like designing for the web is so hard compared to elements
| that work on the phone. This elements look very "phone sized".
| midrus wrote:
| This looks awesome. Definitely will use it in my next project.
| Great work!!!!!
| [deleted]
___________________________________________________________________
(page generated 2021-07-30 23:01 UTC)