Beginner-friendly guide to use Tailwind CSS with Jekyll(mzrn.sh)
mzrn.sh
Beginner-friendly guide to use Tailwind CSS with Jekyll
https://mzrn.sh/2022/04/09/starting-a-blank-jekyll-site-with-tailwind-css-in-2022/
32 comments
>I love building websites the old-fashioned way: with Jekyll.
I suddenly feel very, very old.
I suddenly feel very, very old.
Huh, that was half a joke. But check this out: https://twitter.com/jspeiser/status/1519816372179673088
“Anybody born in the 1900s” is a fun meme to trigger people
Random rant:
I still don‘t get it. Why is inline CSS supposed to be bad but tailwind is supposed to be fine? And yes, inline CSS lacks features like hover and predefined color palettes. Personally, these days I‘m lost in between them all and have started using them all; a framework like bootstrap, some handy thing like tailwind with a prefix and inline CSS for anything I feel like. Did I mention that I like !important ?
So, time to go to hell for saying all of that.
So, time to go to hell for saying all of that.
in my experience things like Tailwind are mostly pushed by managers, not developers
the managers see how simple it is to build complex UIs in Tailwind and then project it into how much resources they can save their company and how quickly they'll be able to iterate on design
a major problem with projects that are built with tailwind is that the code produced is unmaintainable, unreadable spaghetti
you can even see it on their own home page if you scroll down a couple sections
https://tailwindcss.com
tailwind also requires a build system and introduces 500+ npm dependencies, which is a huge security risk
personally i think Tailwind is a solution looking for problem and would avoid it at all costs
the managers see how simple it is to build complex UIs in Tailwind and then project it into how much resources they can save their company and how quickly they'll be able to iterate on design
a major problem with projects that are built with tailwind is that the code produced is unmaintainable, unreadable spaghetti
you can even see it on their own home page if you scroll down a couple sections
https://tailwindcss.com
tailwind also requires a build system and introduces 500+ npm dependencies, which is a huge security risk
personally i think Tailwind is a solution looking for problem and would avoid it at all costs
> in my experience things like Tailwind are mostly pushed by managers, not developers
In my experience, Tailwind adoption is pushed hard by engineers who use it on side projects and see how delightful it is to use.
And if you think it's unmaintainable, maybe you should explain why you feel that way (apart from your clear distaste for it). My counterpoint is that it's amazing to be able to pick up a project after months or years and instantly understand what's going on.
In my experience, Tailwind adoption is pushed hard by engineers who use it on side projects and see how delightful it is to use.
And if you think it's unmaintainable, maybe you should explain why you feel that way (apart from your clear distaste for it). My counterpoint is that it's amazing to be able to pick up a project after months or years and instantly understand what's going on.
we might have different experiences, but in my view when you take the downsides into account: a build system requirement and very large amount of dependencies, then Tailwind isn't worth it
you should avoid large dependency trees and if possible avoid the JS-ecosystem altogether, because these dependencies introduce security vulnerabilities routinely
we already have web components which support scoped styles, so you can just build a component once and reuse it everywhere else in your code
i'd love to hear more counter-arguments though
you should avoid large dependency trees and if possible avoid the JS-ecosystem altogether, because these dependencies introduce security vulnerabilities routinely
we already have web components which support scoped styles, so you can just build a component once and reuse it everywhere else in your code
i'd love to hear more counter-arguments though
I really dislike the js ecosystem, but as mentioned in my other comment, there is barely any security risk in shipping a compiled css file. Most of the deps are just there for file system watching and live-reloads.
Regarding web components, you can just use them with tailwind, they are not complementers. Hell, if you want to have a stylized button, of course just write it once, but the reusability comes from it being a component — I really have to question the reusability of CSS styles that are more complex than a few properties. Like, do you honestly reuse the style of a button in your menu? Perhaps the color scheme and font, but those should be variables to begin with.
Regarding web components, you can just use them with tailwind, they are not complementers. Hell, if you want to have a stylized button, of course just write it once, but the reusability comes from it being a component — I really have to question the reusability of CSS styles that are more complex than a few properties. Like, do you honestly reuse the style of a button in your menu? Perhaps the color scheme and font, but those should be variables to begin with.
> there is barely any security risk in shipping a compiled css file
not when you require 500 dependencies to actually compile the css
imagine running “npm run build” but instead of getting a css file you get your hard drive wiped out, because some author of random npm module decided it’s April Fool’s day today
this is a hard reality than many are not willing to acknowledge because of all the hype around JS
not when you require 500 dependencies to actually compile the css
imagine running “npm run build” but instead of getting a css file you get your hard drive wiped out, because some author of random npm module decided it’s April Fool’s day today
this is a hard reality than many are not willing to acknowledge because of all the hype around JS
I agree that it is currently a very real security risk but at the same time we should ask ourselves what on Earth are our OSs do? Because my phone could protect me from that 100%. Running arbitrary code should pose no such threat ever.
FWIW I'm a (developer turned) manager who took over a team that was using tailwind and said "hey if you wanted you could do X or Y or Z as an alternative to tailwind..." and everyone metaphorically gasped in horror and said that tailwind was better than anything they had collectively done before.
I didn't get it at first either but I think perhaps a surprisingly big part of it is the fact that our UI is based on React and having everything contained within each component so you don't have to go hoping around between files is much nicer. And then it's just a thorough, tasteful and well thought out framework based on modern principles.
I didn't get it at first either but I think perhaps a surprisingly big part of it is the fact that our UI is based on React and having everything contained within each component so you don't have to go hoping around between files is much nicer. And then it's just a thorough, tasteful and well thought out framework based on modern principles.
> tailwind also requires a build system and introduces 500+ npm dependencies, which is a huge security risk
Compile time != run time. Those dependencies will never get to any form of production code.
Compile time != run time. Those dependencies will never get to any form of production code.
Everyone is tired of defending "inline style" for a long while now. It has `hover:bg-gray400` and thing like `md:w-1/3` and some fancy animation too. I think they should start creating 2-3 properties size classes more, currently it's mostly 1:1.
Tailwind employs utility CSS methodology, but it's not equivalent to inline. It standardizes your core elements (colors, font sizing, spacing) which ensures the consistency of a framework mixed with the flexibility of inline.
Any reused styles (eg button) should be turned into a class via composition.
So it's flexible, but also ensures adherence to your company design standards.
Any reused styles (eg button) should be turned into a class via composition.
So it's flexible, but also ensures adherence to your company design standards.
Here is my thought process, but take it lightly as I have not been part of front-end teams for quite a long time. It is more about how your code modules are organized, for what purpose, and how it will be managed.
I would say go bang-bang with all the classes for Marketing/Landing Pages and websites that will change regularly both in code and final designs.
Now, for a user logged in WebApp where many engineers (front + back) will work but want to leverage TailwindCSS without having to write everything from scratch, leverage its capabilities, but start writing your classes -- use TailwindCSS as a utility.
TailwindCSS makes it easy to get in new members to the team, and even new developers, just like Bootstrap does. It gives you the advantage of using it as your tamed tooling, complete with sharable design tokens between designers, the front-end, and the back-end.
I would say go bang-bang with all the classes for Marketing/Landing Pages and websites that will change regularly both in code and final designs.
Now, for a user logged in WebApp where many engineers (front + back) will work but want to leverage TailwindCSS without having to write everything from scratch, leverage its capabilities, but start writing your classes -- use TailwindCSS as a utility.
TailwindCSS makes it easy to get in new members to the team, and even new developers, just like Bootstrap does. It gives you the advantage of using it as your tamed tooling, complete with sharable design tokens between designers, the front-end, and the back-end.
Imagine you have 100 Jekyll templates that all contain a few dozen instances of <div style="display: flex; ..."> don't you feel you're wasting some bandwidth by not creating a .flex { display: flex; } class to handle that common case? This is all Tailwind is doing.
gzip is remarkably efficient to reduce duplicate repeating strings.
You could have 10 classes or raw styles repeated 50 times and all instances of those might condense down to 1 string of WWUElinMSS1J1TQwMFFISi7KtsMiZAuVKU.
You could have 10 classes or raw styles repeated 50 times and all instances of those might condense down to 1 string of WWUElinMSS1J1TQwMFFISi7KtsMiZAuVKU.
Not entirely on topic, but is there anything like a “generic component library” that just gives accessibility and has as little opinion about design as possible, but can them be styled with Tailwind?
I think Tailwind is a great way to get a good looking site very fast, but I’d rather use eg a Toggle component that someone else built and tested than create my own and inevitably make some kind of accessibility mistake.
I think Tailwind is a great way to get a good looking site very fast, but I’d rather use eg a Toggle component that someone else built and tested than create my own and inevitably make some kind of accessibility mistake.
Maybe check out the recently released Zag that uses state machines under the hood to target multiple front end frameworks: https://zagjs.com/
I've gone in the other direction and write plain HTML tags now (in React, or anywhere), then augment it with functionality by passing a reference to the relevant element to a helper class. Very much like A11yDialog[1], which is likely the most well-known example of this concept. The helper class is vanilla Javascript and the API of the class is the DOM itself: if you don't use the correct aria-x and role attributes, it will warn you.
I do this because I hate dealing with the opaqueness of UI components. Every one has its own completely different API, every one imposes unnecessary constraints, and styling them requires you to submit to whatever styling method the library author thinks is best. I just want to have direct control over the DOM dammit! without having some busybody middleman library getting in the way.
This approach makes it very easy to, for example, have a menu button and its menu in completely different parts of the tree, making styling effortless. The helper class handles focus management, so the exact HTML isn't important, as long as the correct attributes are present.
[1] https://a11y-dialog.netlify.app/
I do this because I hate dealing with the opaqueness of UI components. Every one has its own completely different API, every one imposes unnecessary constraints, and styling them requires you to submit to whatever styling method the library author thinks is best. I just want to have direct control over the DOM dammit! without having some busybody middleman library getting in the way.
This approach makes it very easy to, for example, have a menu button and its menu in completely different parts of the tree, making styling effortless. The helper class handles focus management, so the exact HTML isn't important, as long as the correct attributes are present.
[1] https://a11y-dialog.netlify.app/
Plain UI was created with that idea in mind, and it's available in Tailwind, Bootstrap and Bulma!
https://shuffle.dev/blog/2022/01/plain-ui-simple-template-fo...
https://shuffle.dev/blog/2022/01/plain-ui-simple-template-fo...
I personally like and use DaisyUI for such "components" type of things: https://daisyui.com/
Does its job, gets out of my and helpful docs as well.
Does its job, gets out of my and helpful docs as well.
Yes, there are tons of those now. No doubt because of the popularity of things like Tailwind. This one is particularly popular: https://headlessui.dev/
It's a cool idea and I was excited about it at first, but that library is so hard to work with. Way too many layers upon layers of abstraction, and it relies very much on an implicit, nested API that makes it hard to suit your own needs (for your own component's API). Also, the API docs kind-of suck—the docs are good at giving a general overview, but finding specifics about what a particular function returns inevitably seems to require digging into the source code (maybe that's changed, it's been about a year since I tried it).
Horrible experience.
Horrible experience.
Radix is pretty close
Nice Tutorial. Here is my go-to for Jekyll and TailwindCSS -- Jekyll Starter Tailwind[1] by Taylor Bryant.
1. https://github.com/taylorbryant/jekyll-starter-tailwind
1. https://github.com/taylorbryant/jekyll-starter-tailwind
Looks good, I had a similar setup with Gulp up until last year.
But isn't this a bit outdated now? I think it still uses Tailwind CSS 2.
But isn't this a bit outdated now? I think it still uses Tailwind CSS 2.
Being a Starter Kit, it helps compile Tailwind and then remove the un-used CSS. It does not matter if you use Tailwind 2 or 3, it should work.
The idea is that Jekyll is Ruby while the way Tailwind is setup (usually) is easier managed by the available NPMs. This kit makes it easy to marry the two.
I like it as this is simpler than the others I had seen, nothing more than the bare needed to get the work done.
The idea is that Jekyll is Ruby while the way Tailwind is setup (usually) is easier managed by the available NPMs. This kit makes it easy to marry the two.
I like it as this is simpler than the others I had seen, nothing more than the bare needed to get the work done.
But I also love styling them with a bit modern approach: Tailwind CSS.
So I posted a guide on how to make those two work together.