[HN Gopher] TailwindCSS JIT with Arbitrary Values
___________________________________________________________________
TailwindCSS JIT with Arbitrary Values
Author : ccmcarey
Score : 102 points
Date : 2021-04-07 18:05 UTC (4 hours ago)
(HTM) web link (tailwindcss.com)
(TXT) w3m dump (tailwindcss.com)
| yowlingcat wrote:
| Love Tailwind. It delivered on the promise of what I always
| wanted Bootstrap to be. Most notably, the `@apply` directive
| making it possible for me to refactor out my tailwind utility
| classes that I prototype with means that I can move fast and not
| end up with an eventual mess.
|
| I'll echo other folks who have said that using Tailwind has
| significantly increased how quickly I can put together frontend
| stuff -- it's close to a 5x speedup for me workflow wise.
| WORMS_EAT_WORMS wrote:
| This is literally an inline CSS shorthand language now and I love
| it.
| dmlittle wrote:
| Yup! I think the biggest win for me is not having to worry
| about CSS class names. Some people hate the fact that the HTML
| is now less "clean" but I appreciate not having to context
| switch or deduce that a child a tag inside a a div.card has a
| specific styling.
| gvkhna wrote:
| Tailwind is great but the horizontal alignment of all classes is
| definitely not ideal.
|
| Is there a vscode extension that possibly aligns classes in new
| lines? Alphabetical sorting could be nice as well.
|
| Is this on the horizon for the Tailwind team? The intellisense
| extension is quite good so it's possible this is a problem they
| are working on as well.
| beckler wrote:
| I wish there was a convention on the order of classes on an
| element. Like height/width first, padding/margin next, idk what
| next, and then pseudoclass variants at the end, but in the same
| order?
|
| I don't know honestly, I just wish there was a convention.
| jzeltman wrote:
| Check out this extension for VSCode which organizes your
| classes on save. https://marketplace.visualstudio.com/items?i
| temName=heybourn...
|
| Otherwise, I usually try to separate out states when using
| @apply.
|
| ` .example { @apply bg-blue-100; @apply hover:bg-blue-200;
| @apply focus:bg-blue-200; `
|
| But now with JIT you could simplify if you wanted to:
|
| `.example { @apply bg-blue-100; @apply hover:focus:bg-
| blue-200;`
| leipert wrote:
| There are, e.g. this prettier plug-in:
| https://www.npmjs.com/package/prettier-plugin-tailwind or
| headwind: https://github.com/heybourn/headwind
| dillondoyle wrote:
| Maybe you could use data-attribute to group these common
| styles like 'sizing' 'color' etc
|
| something like <div data-css-size='large flex-box display-
| flex' data-css-color="red" data-css-font="gotham
| serif"></div>
|
| then something like [data-css-color*="red"] {color:red;}
|
| I haven't tested this just thinking off the top what might
| work
| gvkhna wrote:
| I like this a lot actually, considering JIT maybe data
| attributes or some tighter integration into react could
| easily be done so there isn't so much reliance on class
| names.
| tpetry wrote:
| This may sound strange first, but there is nothing to argue
| in a team about if you sort them alphabetically.
| gvkhna wrote:
| I agree. Also the reason for alphabetical ordering is
| typically adding in lines will not cause additional changes
| in git blame.
| vsareto wrote:
| I like it. Simple and predictable.
| smoe wrote:
| I have seen various conventions over the years on how to
| order css properties that could be used for ordering tailwind
| style classes. E.g
| https://rhodesmill.org/brandon/2011/concentric-css/
|
| The problem is more, that to my knowledge, none of them got
| wide adaption. You could at adapt them on at least a
| company/team wide level, but don't know what tooling there is
| to make it easily configurable.
| gvkhna wrote:
| I'm ok with a convention but considering how that could
| become it's own complete config maybe alphabetical would just
| be better. Also it typically has less issues with git
| changes.
| lhorie wrote:
| I may just be being pedantic here, but isn't this AOT rather than
| JIT? JIT means the optimizer is code that ships as part of the
| runtime, which is sort of the opposite of what this does.
| colinclerk wrote:
| I've started investigating whether a truly "just in time"
| variant of Tailwind is reasonable. It's almost like a CSS
| transpiler - converting tailwind classnames to their CSS form.
|
| You'll probably always want AOT for the "critical css" in the
| first load, but afterward, JIT might be reasonable.
|
| At a minimum, it should be feasible. You can override
| Prototype's appendChild, replaceChild, and insertBefore to grab
| classnames and generate CSS before the DOM is updated. Everyone
| will tell you this is insane, but it seems to work.
|
| But it's unclear if this leads to something "better" than the
| AOT solution. It feels like code golf: will the transpiler have
| less bytes than the CSS generated by a pure AOT solution? The
| tailwind folks have come up with a really dense way of
| expressing verbose CSS, so I think it's possible!
|
| No affiliation to Tailwind. Just playing on weekends.
| setr wrote:
| Afaict it's just incremental recompilation. The usage of JIT
| seems like a fundamental misunderstanding
| lhorie wrote:
| Agreed, incremental recompilation falls squarely in the AOT
| camp.
| sb8244 wrote:
| The big advantage of tailwind for me is that it solves responsive
| design better than any system I've used before. I'm not amazing
| at frontend styling (I get by), but I feel like a superhero with
| tailwind css and UI (worth the money)
| stanislavb wrote:
| What other frameworks have you tried?
| sb8244 wrote:
| Bootstrap 3, Sass, styled-components. I am sure there's more
| but that's the last few years of stuff
|
| Before Tailwind with PostCSS, I'd probably hand roll some
| Sass-powered UI, or find a template to base it off of.
| mgkimsal wrote:
| I've posted before, but will throw this out again.
|
| When I'm building, I'm typically using a toolkit like vuetify or
| bootstrapvue. These are dozens of components - tested,
| documented, expanded on, and styled (using bootstrap or material
| design or... whatever).
|
| The 'just to go tailwind!' I keep seeing seems to assume I want
| to rebuild components (and then test them) which already exist,
| and are designed to work together. The common refrain is "but all
| those sites look the same!" but... I can change colors, sizes,
| and... when needed, a bit more, by going in to the scss (or
| similar) and recompiling.
|
| I understand the 'purge' stuff in tailwind is nice and useful
| (tested it firsthand) but the time/effort of rebuilding large
| sets of components (which are, often, by and large commodity
| things) is so far a hard sell for me. I was on a team last year
| that was in their second round of developing their own in-house
| UI toolkit - basically recreating most of bootstrap-react, but
| poorly, and with no testing or accessibility, because "bootstrap
| is bad". They were so far behind they thought they were ahead...
|
| I'm just not grokking all the tailwind love. I've played with it,
| and yes... I guess _anything_ that you learn and spend time with
| will, overtime, become 'natural' and save you time.
|
| It's impressive tech, for sure - not trying to downplay it.
| qbasic_forever wrote:
| You want a component library like Tailwind UI:
| https://tailwindui.com/
|
| You're right though that a lot of people who jump straight to
| tailwind probably don't realize that its low level might be too
| low for their needs. A higher level component library like
| bootstrap, tailwind ui, chakra, etc. is a better start in many
| cases.
| weird-eye-issue wrote:
| I actually bought this quite a while back. It is nice, but a
| far cry from what developers typically consider components.
| In fact they are just HTML that you have to copy and paste.
| You have to build the interactivity yourself. I think they
| have recently started integrating them into some JS
| frameworks though possibly.
| mgkimsal wrote:
| Thank you. That's all it seems to be to me, and when people
| say "look at these components", it seems like they've not
| seen value in vuetify, for example.
| davidwparker wrote:
| React and Vue are both coming, in case you haven't seen
| already: https://tailwindui.com/react-and-vue-support/
| qbasic_forever wrote:
| Ah, yeah component makers are in a hard spot right now. You
| can't really write a 'generic' component easily and have to
| take a bet on using whatever JS framework is in vogue--
| react, vue, etc. It's not easy for a react project to pick
| up a vue component and use it or vice-versa. Even ignoring
| the framework incompatibilities, it also requires your
| component users to now buy in to the whole bundler game.
|
| You could work around this by sticking with a generic,
| simpler framework like good ole jQuery. But now your
| framework users in react, vue, etc. are mad that they need
| to pull in kilobytes of JS that's doing what their
| framework already does.
|
| So... as a component author a bundle of HTML and bring your
| own logic is kind of the only low-level option that's
| ubiquitous. Things might get better with web components,
| but it's not all there yet.
| goodoldneon wrote:
| Maybe they're hoping the community creates the framework-
| specific implementations?
| wunderflix wrote:
| I have bought this, too. It's great.
|
| There is also a "free" site, which offers lovely designs:
| https://tailblocks.cc/
| kingdomcome50 wrote:
| It sounds to me like you are just not the target for something
| like tailwind. My impression is that you are likely building
| displays that only require a few different UI components (and
| probably the ones we all see regurgitated over and over). The
| kind of UI where the star of the show is the _information_ you
| are displaying rather than its _behavior_ (of course there is a
| balance).
|
| But for the kinds of applications I build there simply _does
| not exist_ a "UI toolkit" that could save me any amount of time
| worth the hassle of ingesting another library and finagling it
| to my needs for what? Maybe 15% of my UI? The _value_ in the
| tools that I build is partly in the UI I make to interact with
| them.
|
| There is nothing more frustrating than the 5th or 6th time you
| just need the padding to be a little different to make your
| component pop, and you have to slog through the docs/source
| figure out how to adjust 2px...
| weird-eye-issue wrote:
| What kinds of applications do you build? It sounds like
| having pixel perfect components that match exactly what the
| designers want is a really high priority for you. And that is
| fine but man it can really make dev go slower than using
| existing ones and I'm not always sure it's worth it.
| dmitriid wrote:
| I'm now building a back office/admin part of a site. The
| part where designers are rarely seen. And boy, does
| Tailwind help.
| weird-eye-issue wrote:
| In that case wouldn't an existing component library be
| better? For something like that it seems function would
| be favored over design so you could get away with a
| generic looking component library.
| Kaze404 wrote:
| I love TailwindCSS, and this just made it better than I wished
| for. It was always annoying having to use style attributes for
| specific, one-off things and it's great knowing that it won't be
| a problem anymore. Not to mention of course the performance
| improvements.
|
| Can't wait to upgrade Tailwind on my project and try this out :)
| canyonero wrote:
| Kudos to the team on the release. I'm a huge fan of allowing CSS
| via arbitrary class names. I work on team that is in the midst of
| migrating a large codebase away from custom global CSS (with BEM)
| to Tailwind. We frequently have to augment our tailwind.config.js
| file by adding one-off settings and that has always felt wrong.
| This should solve that pain point.
|
| One area I'd love to see Tailwind tackle is better targeting for
| child elements. I understand the library is functional and the
| classes are atomic, but I think being able to chain and target
| arbitrary children elements would be quite powerful.
| jackconsidine wrote:
| I found out about TailwindCSS from the Full Stack Radio podcast,
| hosted by Tailwind's creator. Good for Adam Wathan.
|
| Unfortunately, the podcast hasn't been kept up in the past few
| months. I assume TailWind is taking all of Adam's time now?
| clement75009 wrote:
| That and a baby:
| https://twitter.com/adamwathan/status/1379437055516680202
| Congrats to him!
| davzie wrote:
| I was once a massive Tailwind hater. I remember walking around
| Ipswich with a close friend who is also a developer proverbially
| slagging it off and all those that espoused it as the next best
| thing since sliced bread. Then I actually thought "well I'd
| better jump on this bandwagon before I'm unemployable". I've
| never been able to build stuff so fast. I'm absolutely floored by
| the small learning curve and the speed at which I can put things
| together, especially with the help of TailwindUI too. There's
| something huge to be said about the fact that I don't need to
| context switch to CSS-land out of my markup to style up what I'm
| doing. I didn't realise it, but that overhead of switching to a
| style sheet and going back to modify markup and then viewing the
| results in the browser really just used up my mental energy
| battery. Now, if I was in prison with Adam Wathan and Steve S,
| I'd 100% protect them in the showers if they dropped the soap.
| tomcam wrote:
| It's all fun and games until you're in the prison shower with a
| bunch of Bootstrap goons
| Ronson wrote:
| Funny thing is that in 2025 tailwind will be the new goons
| hardwaregeek wrote:
| That's...the most interesting way I've seen of saying you like
| someone's work.
| Swizec wrote:
| > There's something huge to be said about the fact that I don't
| need to context switch to CSS-land out of my markup to style up
| what I'm doing. I didn't realise it, but that overhead of
| switching to a style sheet and going back to modify markup and
| then viewing the results in the browser really just used up my
| mental energy battery.
|
| Welcome to what us React folk have been saying since at least
| 2016. Splitting your code by language is bad. Vertical slices
| for the win.
| benatkin wrote:
| Agree. Vue and Svelte get this right as well (assuming you
| use SFCs properly), except they don't have bizarre
| preferences for one-way data binding everywhere or typing
| _className_ instead of _class_.
| runarberg wrote:
| Agree with this. Although I'm gonna say it is not the
| single file per-se which is the winning technology here but
| the component scoped styles. When writing vanilla web
| components this can be accomplished with
| `this.attachShadow()`, and in Stencil you write an external
| stylesheet and reference it with a `styleUrl` in your
| `@Component` decorator.
|
| In fact it is kind of nice to put your styles in another
| file if you have a designer on your team who is afraid to
| touch any files that don't have the `.css` extension.
| atonse wrote:
| Can we please add this prison testimonial to the tailwind
| website?
| runarberg wrote:
| > Now, if I was in prison with Adam Wathan and Steve S, I'd
| 100% protect them in the showers if they dropped the soap.
|
| Sorry to go on a tangent here with a commentary unrelated to
| the discussion at hand (which is indeed an interesting one),
| but can we please stop with the rape jokes. They are not funny,
| and may be triggering to a large portion of your readers.
| cloogshicer wrote:
| Agreed, good thing you pointed this out. Here's a really good
| video that discusses this issue:
| https://www.youtube.com/watch?v=uc6QxD2_yQw
| Ashanmaril wrote:
| It's also very nice when you're moving some markup from one
| file to another and not having to worry about where certain
| styles are coming from and copying those over too
| zoover2020 wrote:
| Exactly my experience, haters gonna hate... For CSS, I'd argue
| it _is_ the best thing since sliced bread
| dasil003 wrote:
| I love how quickly you went from publicly denouncing Tailwind
| to panicking that you would be left behind and jumping on the
| bandwagon. I'm imagining this psychological drama playing out
| within the gap between two spoken sentences to your friend and
| it's hilarious.
| jerrygoyal wrote:
| I tried JIT mode, loved its features like arbitrary styles, but
| eventually I switched back to default tailwind config.
|
| So, when you use JIT you no longer get all tailwind classes in
| chrome dev tools only the ones you applied to components. I know
| it's by design to keep css lightweight. But that also means I can
| no longer design UI using Chrome dev tools. Only when I apply tw
| classes directly to component in editor like vscode it reflects
| the change in browser. this back and forth cycle between editor
| and chrome took the fun away from me :(
| NiceWayToDoIT wrote:
| I just ducked all that, and started writing a plain old CSS with
| BEM like a mad man, and know what with a bit of discipline and
| good methodology it works as magic.
| qbasic_forever wrote:
| Yeah I'm with you in that plain old CSS is still perfectly
| good. Now with CSS modules and constructable stylesheets it's
| getting better to make isolated components too.
|
| I think a lot of the love for tailwind are people finally
| getting the mental OK to remove the strict isolation of style
| and template/code which has been dogma for 20+ years. If you're
| using something like vue, svelte, or a good web components
| library you can just define components with all their markup
| and style in one place, all using bog standard CSS. It's fine.
| encoderer wrote:
| Tailwind: Your HTML will look terrible, but your website will
| look great.
| mef wrote:
| I'll take it
| encoderer wrote:
| Same!
|
| Format looks great!
| stephen wrote:
| Don't want to take away from Tailwind, it's great.
|
| That said, self-promotion disclaimer but if you like
| inline/utility CSS, and also like TypeScript/React/Emotion, we've
| got a "Tailwinds-ish" CSS-in-JS library that we've enjoyed so
| far:
|
| https://github.com/homebound-team/truss
|
| Would love to have people try it out.
| chrisweekly wrote:
| This looks pretty cool; Bookmarked.
| halfmatthalfcat wrote:
| I used tailwind for v1 of my marketing site and it seemed fine at
| the time. Fast forward to when I needed to make some changes and
| some tags had 10+ modifiers on them including custom ones...it
| become so hard to figure out what was doing what without
| massively breaking things. I've since moved back to component
| libraries for their simplicity.
| Ronson wrote:
| I want to say that I am a fan of tailwind, it's just funny
| though how you bring up the reality of life. Anyone using
| Tailwind can do whatever they pull out their arse, so it's
| totally hardcore. Then the stars increase, consistencies
| between browsers occur, the tools change, dependencies change,
| ideas come though, requests.
|
| You can copy and paste this whole comment section into 2025 and
| rename Tailwind to "ShitBuckle". The same way bootstrap
| comments could be copy and pasted to tailwind from 2015.
|
| Of course I jest but I find it amusing.
| nickjj wrote:
| If anyone is looking for practical examples of using Tailwind +
| the JIT compiler with various web frameworks and Webpack, I have
| a few example starter projects at:
|
| - https://github.com/nickjj/docker-flask-example
|
| - https://github.com/nickjj/docker-django-example
|
| - https://github.com/nickjj/docker-node-example
| Yabood wrote:
| I've been using tailwindcss and tailwindui for our production
| platform (released), and our new website (in development) and
| couldn't be happier. Once you get the hang of it, you'll be able
| to build stuff very quickly. For our production platform, I have
| it running on top of Angular and Angular material. Getting
| tailwind, angular, and material to work together wasn't easy, but
| once I got it up and running, it was pretty straightforward to
| start building new pages or modify existing ones without having
| to change existing styles.
|
| I had two major complaints and this update fixes both. The first
| is the enormous size of the css file locally, which caused the
| browser to become considerably slower and made the developer
| tools really slow to load when selecting elements. The second was
| the lack of the !important selector.
|
| This is a solid update. Kudos to the team.
| sam_goody wrote:
| Small companies have too many rough edges.
|
| Large companies have too much baggage - fear of breaking
| compatibility, and don't develop new enough things.
|
| There is a certain size where changes are exciting, or certain
| company cultures that encourage new stuff. Tailwind is there, and
| it is always fun to get their update emails.
| sakopov wrote:
| Good god, JIT for CSS... I thought this was one of those joke
| articles about insane complexity of front-end development.
| qbasic_forever wrote:
| Ehhh, systems outside frontend are just as complex. Think of a
| backend service--you've probably got a low-level TCP/HTTP
| handler written in a fast systems language like C/C++, then
| your business logic written in a higher level language like
| Go/JS/Ruby/etc., and that's interacting with your data layer
| using a completely different logic-based SQL language (and
| extra complexity to translate that SQL to your high-level
| language with an ORM layer), and on top of that you probably
| have a rules engine for authorization because you realized the
| systems language was too slow to update and deal with fast-
| changing business requirements.
|
| This is really not that different from the frontend world where
| you've got a markup language to define semantics of the view, a
| logic layer in JS to pull in data with web requests to populate
| the view, and CSS as a style layer to make the view look good.
___________________________________________________________________
(page generated 2021-04-07 23:01 UTC)