[HN Gopher] Tailwind CSS vs. Pico CSS (2022)
___________________________________________________________________
Tailwind CSS vs. Pico CSS (2022)
Author : tosh
Score : 56 points
Date : 2024-09-11 13:53 UTC (2 days ago)
(HTM) web link (edofic.com)
(TXT) w3m dump (edofic.com)
| citizenpaul wrote:
| People still complain about the tailwind build process and I
| agree and would not use it bc of that except.. Tailwind has had a
| stand alone executable builder available for a long time.
| (Including at the writing of this article)You can just drop the
| exe and either add it to your path or run it directly. No node or
| npm/npx needed.
|
| https://tailwindcss.com/blog/standalone-cli
| hu3 wrote:
| Isn't that still a build step?
| crowcroft wrote:
| Yea, the standalone tool is nice, but I want to be able to
| throw a script in my app's head tag and call it a day.
| cporrast wrote:
| you can do that as well, just include Tailwind through
| their CDN [0]
|
| [0] https://tailwindcss.com/docs/installation/play-cdn
| citizenpaul wrote:
| Sure but I've seen people complaining not that there is any
| build step but that they think it requires the whole node/npm
| ecosystem to be installed for it to work.
|
| At this point I don't think anyone doing anything beyond a
| landing page is working without some sort of build process
| anymore.
| gkoberger wrote:
| I feel like these are two very, very different tools. Pico (or
| something similar) is great for a Just-Works framework where
| things look simply and nice. For a lot of things, this is good
| enough.
|
| But Tailwind is for building... anything. It's better to think of
| it as inline styles with syntactical sugar. Yes, this has
| historically been something to avoid. But as components become
| more common, it moves the DRY to the HTML level (rather than CSS
| classes).
|
| It's not for everyone or everything, but I've loved it. There's a
| joke that the hardest part of CS is naming things, and this
| removes having to map classes and IDs across two different files.
| danielvaughn wrote:
| That's exactly how I feel. I didn't realize how much of a
| productivity-stopper class naming was until I stopped doing it.
| It's amazing how much faster you move.
| abhgh wrote:
| I entirely agree. They get compared a lot but to me they seem
| to solving different problems. Pico if you want something asap,
| and you are ok with sticking with it's opinionated styles.
| Tailwind if you want control - now, or if not now then later,
| i.e., you see your application evolving.
|
| Personally for me, the opinionated pico styles don't work
| because I'm usually building high density interfaces and pico
| has stuff that I'd consider good for marketing kind of sites,
| e.g., buttons with large text (I think you can override/add
| styles but if it comes to that you should reconsider this
| choice anyway).
|
| Another advantage for tailwind is that I can use to style
| components from other frameworks to my liking, e.g., skeletonUI
| or bits-UI.
|
| A common complaint with tailwind is the long class names. While
| true I think it's unavoidable due to the flexibility it
| provides. But that's not why it doesn't bother me: the names
| make _sense_ (like you say) and they 're _composable_ , i.e.,
| you can put together or parse these class names piecewise.
|
| PS: I should add that this article is fair in the sense that it
| doesn't prescribe over another, just shows which is best for
| what.
| PUSH_AX wrote:
| I think people should still think of TW as classes, because
| they are, and it doesn't need to be more complex than that.
|
| Thinking of TW as inline styles is harmful imo, the specificity
| works differently and there are a number of things that TW
| offers that isn't possible inline. Plus inline just carries a
| stigma which helps people dunk unfairly on TW.
| wvenable wrote:
| The selling point of TW is that it is, effectively, styles.
| That's what distinguishes it from what I could call just
| normal CSS. It has value over inline styles -- otherwise it
| wouldn't exist -- but it's still the same principle.
| geenat wrote:
| Nothing stopping you from using them together. Its all just CSS
| danielvaughn wrote:
| CSS is global, so I'd highly recommend against using two
| separate CSS systems. Even Tailwind introduces several global
| styles via its own reset. Years ago, I worked on a team that
| used both Bootstrap and Foundation, and even over the course of
| 5 years was unable to disentangle them.
| tengbretson wrote:
| Tailwind's global reset is pretty aggressive.
| recursive wrote:
| Maybe you can use the new css @layers to box it in.
| recursive wrote:
| I've been using one of these semantic classless CSS systems for
| an application I've been developing for the past ~6 months with a
| team of ~3. It's working great so far. We didn't even install it
| from a package manager. Just copy and paste the file straight
| into source control. (attributions intact, don't worry licensing
| enthusiasts) Customizations go right into the original file.
|
| Feels amazing.
| Nathanael_M wrote:
| Which one have you been using?
| recursive wrote:
| simple.css https://simplecss.org/
| knowsuchagency wrote:
| This could be a series.
|
| t-shirt vs sweater car vs truck cat vs dog
| red_hare wrote:
| I don't think these are the same, but as a non-web-developer who
| likes building web side-projects, I love pico.css. It's fantastic
| for forms and the light grid/container stuff.
|
| My stack these days is Flask + HTMX + Alpin.js + Pico.css and I
| write almost nothing but Python and HTML.
| thornewolf wrote:
| replace Flask in-place with FastAPI and you get a bunch of QoL
| stuff for free w/ no drawbacks.
|
| - wonderful integration with pydantic for serialization -
| background tasks - autogenerated swagger docs - dependency
| injection per-route
|
| "in-place" is a stretch, you will have to change code, but I
| found it to be a very speedy task to migrate a codebase from
| flask to fastapi.
| ecuaflo wrote:
| I use the same principle as pico but from scratch with tailwind.
| It does too much magic and it's far too complex and undocumented
| to be able to modify a piece of it you need to change. In my
| global stylesheet I style inputs all one way and target aria and
| state selectors for more specific styling. I still use inline
| styles for more unique cases.
|
| They are two different techniques that can work together well. If
| I'd make any comparison, it'd be between pico and tailwind's
| typography plugin specifically.
| mmckelvy wrote:
| The workflow I'm trending towards is a design system (e.g. Radix
| UI) for the bulk of the styling, inline styles for most
| customizations (shouldn't be too many), and then plain CSS with
| classes on occasion (e.g. I have an override I need to use in
| multiple places or an animation). The little CSS you do need can
| be isolated if you're using a framework like Remix.
| qwertyuiop12 wrote:
| I use both and they work like a charm. But I disable the tailwind
| base styles ;)
| mlboss wrote:
| The real problem is the lack of css understanding. Once you learn
| basics of css and start using developer console/debugger it
| becomes easy.
|
| Also, most of the time all you need is flexbox https://css-
| tricks.com/snippets/css/a-guide-to-flexbox/
| sesm wrote:
| Grid is much better for macro layout, too bad Facebook yoga
| (and react-native) is stuck with flexbox.
___________________________________________________________________
(page generated 2024-09-13 23:01 UTC)