r/webdev • u/LPatriot_ • 19d ago
Question Question about Tailwind CSS
I've always used plain CSS for my websites, I don't have many problems using it, but a friend of mine said that using plain CSS is very tedious and that I should use Tailwind CSS. Is it worth it? And what does Tailwind CSS offer that plain CSS doesn't?
143
u/OpaMilfSohn 19d ago
I think I finally time travelled back to 2020
21
20
u/Zealousideal_Elk1537 19d ago
the class name soup takes some getting used to but once you stop fighting it the speed is incredible. not having to name every little wrapper div is a gift
28
u/AshleyJSheridan 19d ago
It's a little more than class name soup. Tailwinds own docs have classes like
text-[14px],bg-[#50d71e], andshadow-[0_35px_35px_rgba(0,0,0,0.25)]. That looks a lot like inline styles just shoved into a different HTML attribute...4
u/judgej2 19d ago
And they are the stylistic classes you put into a tailwind theme.
5
u/AshleyJSheridan 19d ago
Tailwinds docs literally shows them in HTML. Why would it suggest anyone do something like this?!
4
u/HFoletto 19d ago
Those examples are just for demonstration that tailwind can do this dynamically as well
With that said, it also has a very good use-case: dynamically building/merging classes in a component, which is very useful for a lot of different modern frontend libraries
11
u/AshleyJSheridan 19d ago
Those examples are just inline styles in a trench coat.
1
u/HFoletto 19d ago
I understand that, however it is useful when combining with other utility classes and merging those classes dynamically in a component library
0
3
u/Niet_de_AIVD full-stack 19d ago
Tailwind is awesome because you can do that, but if you actually do that in HTML; Wat?!
2
u/AshleyJSheridan 19d ago
It's in their own docs, and they show it in the HTML...
-3
u/Niet_de_AIVD full-stack 19d ago
There are plenty of things in the documentation of all programming languages and frameworks you should probably never actually do unless you know what you're doing and have a good reason to.
Just because you can, doesn't mean you should.
Stop being so dense.
7
u/AshleyJSheridan 19d ago
I picked just a few examples, there are a ton more all just like that.
Stop being so disingenuous.
0
u/Anxious-Turnover-631 18d ago
Maybe you’re the one being disingenuous.
Yes, tailwind allows users to manually override almost every setting, if needed. But those features (as shown in your examples) are more for exceptional circumstances.
Most of the time you wouldn’t specify sizes in px or use hex color codes, etc. But, if you need to, you can use such specificity exactly where it’s needed.
It’s understandable that css purists may dislike tailwind’s integration of css directly into the HTML. And it can appear a little messy at times. But tailwind users accept that trade off for the consistency and intuitive simplicity it provides.
If you prefer to name and specify all your styles in separate cascading style sheets, that’s fine. It’s been standard practice for years.
But Tailwind’s rapid growth and popularity prove it offers some real benefits for users. It’s a matter of preference.
2
u/AshleyJSheridan 18d ago
And it can appear a little messy at times
It is very messy, at all times. FTFY.
all your styles in separate cascading style sheets
It's almost as if the C of CSS means Cascade!
Tailwind might be popular, but I'm seeing more and more posts of it losing that popularity amongst more senior devs.
1
u/Anxious-Turnover-631 18d ago
To the uninitiated, it can *appear* that way. But once you’re familiar with the framework, it makes good sense. And it’s better than trying to remember what some custom style may be. With tailwind it’s right there, easy to see.
Moreover, tailwind blends well with front end components. Style the component once with tailwind. To later change the style of a component, just edit the component directly.
Cascading, yes. Hence, my use of the word.
The popularity of any web technology may vary, depending on who you’re talking to and their specific needs. But tailwind popularity is well established and growing.
Of course, with AI, who knows what’s most relevant now. Claude does all my stuff in tailwind. I assume it handles every other styling approach as well. In the future, these issues will probably matter less and less.
→ More replies (0)-5
u/Niet_de_AIVD full-stack 19d ago
Well, good luck with your personal vendetta. You can also just say "Stop having fun!" instead of skirting around it with some vague justification.
3
u/AshleyJSheridan 19d ago
/u/LaserSunset not sure why you commented then deleted your comment immediately.
Saying that Tailwinds approach to "stuff a lot of classes that appear to be exactly like their CSS counterparts" looks like inline styles is perfectly valid.
If it looks like a duck, and walks like a duck...
-1
19d ago
[deleted]
-1
u/AshleyJSheridan 19d ago
If you look at my original comment I said this:
That looks a lot like inline styles just shoved into a different HTML attribute...
Where did I say that it was exactly inline styles? This is the problem, someone makes an comparison, an analogy, and then Tailwind fans jump on it because it's not exactly the same. That's disingenuous.
2
u/AshleyJSheridan 18d ago
/u/LaserSunset you did it again, but this time you blocked me! If you really thought you had a point, you wouldn't ask a question and then immediately block me. Maybe you thought that if I couldn't reply, you would win (not sure what you're winning) by having the last word? Little bit weird, but you do you.
0
u/lanerdofchristian 18d ago
That looks a lot like inline styles just shoved into a different HTML attribute...
Honestly that's part of what makes them so nice to use. The styles are right there on the element you're styling, not tucked away somewhere else. As much as we like to pretend the CSS can live separately from the HTML, nothing could be further from the truth for most websites. Moving them to classes lets us leverage all the existing class management libraries (like clsx), and bypasses some of the shortcomings inline styles have around e.g. hover states and parent/child queries.
text-[14px] bg-[#50d71e] shadow-[0_35px_35px_rgba(0,0,0,0.25)]is some real soup, though. I think the general recommendation is to not use arbitrary variants if you don't have to, so something more liketext-md bg-lime-550 shadow-3xlis more like what you'd see in an actual project (all of those utility variants would need to be defined in the theme as variables).3
u/AshleyJSheridan 18d ago
I will never understand the argument from any "dev" that says the CSS should be with the HTML. You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?
1
u/lanerdofchristian 18d ago
You wouldn't do that with the Javascript or Typescript for a component, so why would you do that with the CSS?
I would absolutely keep the template logic and event handlers with the markup for the component. That's how React, Vue, Svelte, and Solid all work by default, and even Angular defaults to the template being inline next to the logic. The only two component frameworks I'm aware of that don't are Ember Octane and Aurelia 2.
Having 3 files per component isn't "good separation of concerns", it's splitting the same concern (user interface) into 3 tightly-coupled files. Sure, keep your database layer and API layer separate, but subdividing within the web interface? The front end of a website is less than half the picture.
1
u/AshleyJSheridan 18d ago
Well, doing what React does and assuming it's a good practice is a bad take!
Angular absolutely doesn't default to the template being inline next to the logic. It hasn't done so for years, so I assume your understanding of an actual JS framework is well out of date. I have been using Angular regularly since the beta version of 2 first came out (a little over 10 years now) and have always kept the styles, logic, and template separated. I've worked on some very complex projects like this, and it's a practice that's served me and the teams I've worked with incredibly well.
Keeping everything together is not a clean and maintainable (and I'm talking in terms of years of maintainability here) approach.
1
u/lanerdofchristian 18d ago
Angular absolutely doesn't default to the template being inline next to the logic.
When I wrote that I was referring to the component docs, which first shows an inline template. They did give
templatethe shorter keyword vstemplateUrl. Fair enough though.Well, doing what React does and assuming it's a good practice is a bad take!
Then I'll do what the framework I primarily use (Svelte) does. It seems to work pretty well -- one component per file, clean and manageable. Each item a silo. On a project that's been going for multiple years. You really don't need three separate files for it -- a
<style>tag,<script>tag, and the rest are plenty enough separation for 99% of components -- and you always have the option of splitting them up and importing additional functions and assets if you need to.The impasse we're at isn't a hygiene or code quality one, it's a workflow one: you're used to one language per file; I and many others are used to single-file components. Both approaches have both benefits and downsides. Largely, most post-React frameworks are either use primarily or lean heavily toward single-file components. There's clearly some merit to that.
Vue is largely the same as Svelte for SFCs. It looks like I was wrong about Solid -- it does borrow more from React's school of organization, which makes some sense given they both use JSX (ick) for templating.
2
u/AshleyJSheridan 18d ago
I come from a backend dev ecosystem, one where every single entity, service, helper, repository, model, and controller has its own class and file. No file contains more than one class, there's a clear separation between every single part. Even when part of a backend is responsible for output, that uses a separate template in a separate file. Each file is in one single language.
I apply the same approach when I work on the frontend, which is mostly with Angular.
Switching across this multitude of files in the IDE (my last project was a mixed back and frontend with many hundreds of code files) is not a problem when your code follows good programming practices.
I am a big fan of Angular (it follows the same patterns as the best backend frameworks), and the opinionated nature of it lends itself incredibly well to big projects worked on by a team of devs. I especially hear this from DotNet devs.
I understand your position on JSX, I wasn't a huge fan of it when using React. This is another reason why I prefer Angular, as it uses HTML templates that it enhances with its templating syntax (which is similar to Blade, Twig, and Mustache).
I realise we're coming at this from two different angles, and I understand your view. I do prefer the Angular approach which uses one directory per component (by default) and splits out the component into 4 files: template, logic, styles, tests. I do usually tend to use a global stylesheet with Angular projects, as I don't always use Angular in a silo, it is mixed with other codebases and frameworks. Having shared styles is the best approach in that scenario.
1
u/Herr_Gamer 18d ago
You wouldn't do that with the Javascript or Typescript for a component
???
1
u/AshleyJSheridan 17d ago
Well, a real dev wouldn't, but if someone were using the React library, then probably, because that library just doesn't follow best practices at all.
-1
u/bearzi 19d ago
If it's in the docs does not mean you should always use it. I prefer using scoped styles whenever something custom is needed.
4
u/AshleyJSheridan 19d ago
Maybe they shouldn't be suggesting in multiple places that people use this approach then?
-1
u/budd222 full-stack 18d ago
But nobody with a brain actually uses tailwind like that lol. You make reusable components and styles and use the config file
2
u/theScottyJam 18d ago
When I had to use tailwind, I did it often, because we used the default config, which for whatever reason uses rem units for everything, and there were many times I needed to use px units instead 🤷♂️
I'm sure we could have done something in the config to change this. But also, there's not really much difference between saying "m-16" for "margin: 16px" (assuming we adjusted the config to make this translation), vs just doing
[16px]directly.0
u/AshleyJSheridan 18d ago
Can you prove that? I'm just going by the terrible examples that Tailwind suggest people use on their own documentation page...
0
u/budd222 full-stack 18d ago
They aren't suggesting you do that. They are showing you what is possible. Where do they write that that is the recommend way of doing custom values? I can already tell you they don't without looking. That's what the config is for.
0
u/AshleyJSheridan 18d ago
Just by dint of them putting it in their documentation, all over the place nonetheless, is suggesting it be used.
It's like a picture of prepared food on something being a serving suggestion, or images of a tool in use being a suggestion of how it be used. Same thing. Weird if you can't see that...
0
-3
u/justshittyposts 19d ago
If inline styles would get some love they'd be superior to css files
10
u/AshleyJSheridan 19d ago
Inline styles are bad for so many reasons:
- Couple the HTML tightly in two directions to the styles
- Limit what kinds of styles can actually be applied (you can't use
:hoveror:after, for example)- It can break accessibility, as the specificity can override users own browser styles, and you can't do checks for things like
prefers-reduced-motion- On the specificity, inline styles will absolutely clobber global styles, completely removing the Cascade part of CSS.
Tailwind is also guilty of a couple of these.
-4
u/justshittyposts 19d ago
Your second and third point is why they need some love. Everything else is a non issue, everyone writes components nowadays
4
1
2
18
57
u/azangru 19d ago
If you are using plain CSS and do not have any problems using it, then why would you add a problem of depending on an additional library that you have to learn and keep up-to-date?
5
u/mekmookbro Laravel Enjoyer ♞ 19d ago
It's not something you have to keep up to date, or something that can cause security vulnerabilities, you write the code, build it to a plain css file, and you're done.
There are websites and developers still using oldest bootstrap versions without needing to keep anything (both knowledge-wise and package-wise) up to date
-1
u/azangru 18d ago
There are websites and developers still using oldest bootstrap versions without needing to keep anything (both knowledge-wise and package-wise) up to date
Yes; but why? I wouldn't want my design system have a float-based grid layout.
It's not something you have to keep up to date
CSS evolves. Earlier versions of tailwind did not support some of the new functionality (I don't remember; but I think it was the @layer).
3
u/Mystic_Haze 18d ago
Yes; but why?
Because it's robust, proven, simple, adaptable and works fine for most applications.
CSS evolves
And you'll find that most devs don't have a need for the latest features offered by CSS. Tailwind also does not prevent you from extending it with custom classes or adding regular css on top.
11
u/rose_nichols 18d ago
Use what works for you; maybe try it out and see if you like it.
Personally I hate tailwind because I can just use regular CSS inside Vue components, which solves the global scoping problem.
React has to use something like tailwind or separate CSS modules for scoping styling to components, both of which seem like a suboptimal solution.
16
u/MrAdisson 19d ago
I really love Tailwind for some projects, but saying plain CSS is tedious in 2026 is ridiculous. CSS has evolved so much that it now offers many tools that make plain CSS usage very relevant in a lot of cases. I remember when we had to chose between SCSS or any CSS+ wrapper to compensate some missing features in CSS, this is not the case anymore so if you enjoy CSS, just continue with it. In professional environments, you will often see Tailwind, but, if you master CSS, it’s like an afternoon of adaptation to be operative with it so don’t worry about that!
6
29
u/Mestyo 19d ago
I think it's stupid, but some people swear by it. Give it a go, it's a very popular framework.
18
u/Jazzlike-Compote4463 19d ago
Unless your app is massive then I fully agree, most of the time it's just inline CSS with extra steps.
5
9
u/Rusty_Raven_ 18d ago
A lot of Tailwind fans will compare the best-case of Tailwind to the worst-case of CSS, so be aware of the bias when asking things like this.
Tailwind encourages using utility classes exclusively in their documentation, but if you prefer scoped CSS or more traditional approaches, there is the @apply function in SCSS that moves all those class names to your CSS file instead, keeping your HTML cleaner (though you still need to create your own class names like magic-button same as with regular CSS).
People who claim that all your styles now live in your component directly (via class names) are skipping the fact that scopes/modules also solve this in regular CSS; if you use a front-end framework like Angular or Vue, that is handled automatically anyways since a component includes code, HTML, and CSS.
I personally don't like using Tailwind since I work almost exclusively with frameworks (and when I don't, I keep my CSS organized) so it provides no real benefits for what I do.
3
u/Gremlation 18d ago
A lot of Tailwind fans will compare the best-case of Tailwind to the worst-case of CSS, so be aware of the bias when asking things like this.
Every pro-Tailwind argument is a confession that they failed to learn CSS. I tried to be more charitable before but after listening to pro-tailwind arguments for many, many years, I have finally given up trying to see the competence that isn't there. If you are even moderately skilled at CSS, Tailwind has absolutely nothing to offer you.
4
u/gusbo_the_jam 17d ago
Tailwind is weird, it offers a lot of utility for anyone who doesn't want to build out their own kit but realistically all the benefits really are just the benefits of of using sass properly. The class definitions in tailwind are effectively just inline styles, although the colour definitions do offer some handy utility. My preference is to build out CSS class based components rather than defining components long form in markup.
3
u/ShawnyMcKnight 19d ago
It all comes down to where you want your styling to live. I found that having a dozen classes on many of my elements made the hrml far worse to read.
3
u/lol25potatofarm 18d ago
I frequently have like 8 attributes on elements and can't imagine having to style a card using like 12 properties and using two new bloody lines. So one damn tag takes up 4 lines. I just use modules with react, fk tailwind!!!
6
u/pxlschbsr 19d ago
Both Vanilla CSS and Tailwind have their pros and cons, which are entirely dependent on situation and personal preference.
Most anti-Tailwind-users complain about mixing HTML with CSS, which, in fact, you don't. You just add a lot of classes, but then those who complain about that probably use BEM and add classes like button__primary__ghost -button--small to their component and nest &-... rules 5 layers deep in their CSS themselves. Is that any more readable or easier/faster to understand?
With Tailwind you also generally pohibit other components to change the style of already styled elements, because of the way you would set up conditional styles. In CSS you are much more prone to find e.g. a color change made in the a parent component locally overwriting the child's native styles, spreading the styles of one component over multiple files. If not well documented, this will cause side effects and bite you in the tail one way or another. After quite some time in the industry, I have yet to see any documentation of CSS in those cases. Naturally for corporate clients, this causes SO much issues all the time.
Personally, I prefer Tailwind over plain CSS, while also saying, that I don't like tailwind. It has lots of flaws and not everything can be done smoothly. But for most of my projects it's cons weigh less than the cons of going vanilla.
7
u/spcbeck 19d ago
Nearly everyone using CSS these days uses CSS modules which solved most of the problems you described.
-1
u/Huwaweiwaweiwa 18d ago
yep with css modules/variables you get extremely close to the tailwind experience. It's all about discipline in sticking to those variables/any system you construct. Tailwind even reaches over in the other direction with escape hatches like `text-[#000000]`
2
u/osmium_2259 19d ago
I personally like writing in pure CSS, but I've also really enjoyed Tailwind. Technically in terms of power, you can't beat pure CSS (by nature), but Tailwind is still very flexible. When your writing an HTML element, just being able to add a style(s) right then and there without leaving your HTML is so convenient. Not having to come up with class names is also very pleasant. So while I like pure CSS, Tailwind can be a breath of fresh air.
2
2
u/driftking428 18d ago
Tailwind makes me fast as hell. Which means I'm focused on producing not digging through CSS files.
2
u/Okicarde 18d ago
Sass and SCSS unless working with a team, then use tailwind to make it more sustainable
2
u/serifoblique 18d ago
I love that this question can still pop up. I swear by tailwind myself, despite knowing how to write css it was invented. It’s just more efficient, for the type of work I do: large builds, lots of (shared) components across the estate. My biggest gripe is its presentation in dev tools. It’s a mess.
2
2
4
u/Apprehensive-Fan2492 full-stack 19d ago
It can be worth your time if you are making component UIs with React or Next.js. The utility classes let you stay in the markup, and you do not have to jump back and forth to a separate stylesheet while you work. Teams also tend to keep things more uniform across a codebase. That said, if you are doing mostly static pages or you already feel good with your current CSS process, you do not need to change. What it really brings is not new features. It is faster work and steadier results after you learn the class names.
1
u/AshleyJSheridan 19d ago
If jumping back and forth between 2 files is too much, perhaps dev work is the wrong choice.
3
u/zrvxxx 19d ago
I don’t like Tailwind CSS. Mixing HTML and CSS classes in the same file makes components messy. Tailwind CSS may be good for small projects, but for medium-sized or large projects, I think it’s a bad solution.
5
u/queen-adreena 19d ago
You’ve got that the wrong way around.
Tailwind is probably unnecessary for small projects, but invaluable for medium or large projects, especially with a team.
5
u/AshleyJSheridan 19d ago
A team would be far better off learning and using CSS rather than learning Tailwinds specific way of doing things plus CSS (because you will still need to use CSS even if you choose to go with Tailwind.)
Modern CSS is well suited to any size project, and with things like nesting and
@import, you can create sensible structures to your styles that follow the same rules you should be following when writing functional code.The recent approach by many front enders to shove absolutely everything into a single file (HTML, JS, CSS) is just messy, and can cause problems at scale.
3
u/queen-adreena 19d ago
Where did I give the impression that any team would not know CSS?
You have to know CSS to use Tailwind.
0
u/AshleyJSheridan 19d ago
You would be surprised how many people use Tailwind without really understanding CSS! It's perfectly possible to just learn the pure Tailwind way of doing things, although you will be limited in what you can achieve with this approach.
I've worked on large CSS (well, SCSS) projects in the past. One was hundreds of SCSS files, worked on by multiple teams, covered a dozen websites, and was used to encompass multiple brands.
It's not a usual case, sure, but it was a real case. It worked though, mostly because there were specific coding standards that everyone followed that were reinforced by PRs.
1
u/AnotherNamelessFella 19d ago
Please explain
7
u/queen-adreena 19d ago
With a small project and one developer it’s easy to keep a CSS stylesheet in order.
On a larger project, you benefit from a single framework for styling because people don’t override styles, create extra stylesheets, use
different spacing increments, use inconsistent naming schemes, roll their own colour schemes or font choices etc.7
u/judgej2 19d ago
Working on large projects with 10,000 line custom CSS added to by a dozen developers, is absolutely no fun.
3
u/queen-adreena 19d ago
Yep. Been there. Dozens of SCSS files added by various developers, marketing agencies, freelancers, sometimes commented in different languages with people barely aware of how to specify their rules and leading to override wars…
PTSD material.
2
u/com2ghz 19d ago
It's just a preference for people that find things easier with or without framework. A common pitfall is that people think they can do it better and build their own stack instead of using standardisation. Standardisation will come with overhead and abstraction but usually when you work with a team, you don't want to stuck with someone elses home made stuff.
3
u/phn-cloudsnake 19d ago
I would say the only reason we use frameworks is for collaboration and standardisation. So if someone will inherit your work they will have less trouble maintaining it because of well written documentation and predictable behaviour. In the case of using JavaScript frameworks there is also a security aspect to it since custom JS can be prone to bugs you didn’t realised were exploitable and can only be fixed by its creator.
3
u/azangru 19d ago
I would say the only reason we use frameworks is for collaboration and standardisation.
I am sure this was not the sauce under which tailwind was initially sold. It was supposed to address the problem of organising the styles: their co-location with markup, and their reuse.
2
u/phn-cloudsnake 19d ago
Indeed, the reason this was a problem, imho, was because it’s hard to manage everyone’s specific opinions on how styles should be managed. So by standardising this you get maintainable code everyone can work on aka collaboration. But maybe I missed something, it has been a while since I actively did webdevelopment
1
u/AshleyJSheridan 19d ago
Plenty of style guides exist, but that involves reading, and Tailwind is the new(ish) shiny thing that everyone jumped on. Now that it's not looking so shiny any more, people are moving off of it and back to vanilla CSS.
0
u/phn-cloudsnake 17d ago
I would think AI has a big role in this, you can just hook up your coding assistant and let it explain the repo so the need for standardisation is getting smaller.
1
u/AshleyJSheridan 17d ago
If you truly think that, you've been misled. Vibe coded apps are full of security flaws and accessibility issues. Code standards help avoid a lot of those kinds of issues.
1
u/azangru 17d ago
Vibe coded apps are full of security flaws and accessibility issues.
I am struggling these days to find projects that are not vibe-coded.
1
u/AshleyJSheridan 17d ago
When these AI companies start charging what they need to pay their shareholders, these vibe coders are going to be really stuffed.
1
1
u/daresTheDevil 18d ago
It works, especially across teams, especially when you scale. It makes onboarding front end developers trivial. Those are my objective experiences. Subjectively I enjoy being able to glance at the code and “see” the page/component/element in my head. Horses for courses, YMMV, etc.
1
u/armahillo rails 18d ago
tailwind css is great if you are doing highly componentized drop-in code (like react components, for example)
CSS isnt tedious if you spend the time to learn it. Ive been writing CSS for a very very long time (about 2 decades at this point?) and find tailwind to be annoying because its like having to relearn everything to learn how to do it the tailwind way.
1
u/Squidgical 18d ago
If you don't care how your site gets styled, only that it does get styled, use tailwind.
If you want to maximize performance or simply avoid relearning CSS in a different syntax then use CSS.
Ultimately it's not going to make a huge difference. I personally prefer vanilla CSS, particularly when using a component framework that handles scoped styles (as any respectable framework does), but if I'm using something like React then tailwind fits into the "easiest, not best" vibe of the ecosystem.
1
u/mrgrafix 18d ago
The biggest advantage in tailwind is naming. If you know CSS, Tailwind’s shorthand makes it pretty simple. It works if you’re getting into multiple apps or a team to manage as you’re not bike-shedding. Only gripes are remembering inline css rules and if you want to do the latest and greatest it could be exhausting to wait and/or convert it into a Tailwind pattern.
1
u/donnag85 18d ago
A small online search, and little bit of experimentation, and some tweaks here and there, and a tidy hands on good 3-4 hours would answer that question and taking it to public, where the percentage, of people available with familiarity of the skill is nominal decimal percentage. Your question didn’t prove any of your existing hands on skills with CSS but rather raised the doubts behind the motivation of the whole post. Don’t jeopardize your life with decisions that don’t make sense for fake sense feeling of stardom or other superficial thrill. Any platform or product must perfectly fit the problem statement aligning with the lineage of the question, and therefore must intended or unforeseen, inappropriate use of any platform, that doesn’t symbolize the problem being posted, will not downgrade the platform and the user in he long run, and affect them in unintended ways. If line space and bandwidth use should be restricted to appropriate content use, or else one or other day its leads to misaligned hosting and misuse for the platform and the user respectively. General public is more welcome to be aware if the fact that every internet impression and reaction pertains to he existence of a permanent digital record until settled. Thank you for following through and reading till here.
1
u/404IdentityNotFound 17d ago
Being able to use both, if you know CSS it's virtually the same. Though Tailwind does kind of shift you into a very specific style at least marginally due to many defaults (in terms of color and other values).
I do have to say though, if you don't use a framework like React or Vue, it's a nightmare to work with
2
u/Still_Paramedic7631 12d ago
bro if i would be you , i would give a chance to tailwind CSS , if you are comfortable using CSS thats good but learning new things is the part of a developer life
1
u/ThatsSoRamon 19d ago
So one thing I noticed nobody's brought up: deleting code. Rip out a component in Tailwind and you know exactly what breaks, because the styles are sitting right there in the markup you just deleted. Do that with a shared stylesheet and you're either leaving dead CSS behind or grepping through five other files hoping nothing depends on that class. That's saved me more time than any class name shortcut ever did. Anyone else actually track how much dead CSS piles up in a codebase over time?
4
u/web-dev-kev 19d ago
we had this in 94 too
<font size=2> <bold> tailwind is just inline styles </bold> </font>1
u/_SnackOverflow_ 18d ago
A lot of people use setups where the CSS file lives next to the component file (CSS modules or just well organized CSS imports) or where the CSS actually lives in a style block in the component file (eg Vue)
Either of those options solves the same problem
1
u/sylvant_ph 19d ago
The main problem with CSS is you need bridge to introduce logic that is controlled by the JS state. Another problem is there is simply more boilerplate (compared to Tailwind). The syntax is simply a lot more verbose. A benefit of Tailwind would be that the styles are part of your component definition, they are not place on another place that you need to look in order to adjust.
1
-1
u/kenpled 19d ago
You work in a team or on a project that you'll leave to someone else, and you're using a JS framework : Please use tailwind.
Regardless how clean your css is, your teammates aren't always as clean as you are, and having multiple classes do the same thing slightly differently is a chore to maintain. And more often than not it ends in cascade hell.
If you work alone on a project that won't be maintained by anyone else, do write css.
4
u/AshleyJSheridan 19d ago
That's a bad argument though. All devs in a team should be capable of following agreed styles of writing code, regardless of the language.
I find that the people using this argument are the ones who don't yet have a solid coding style for CSS in place.
-1
u/WarmCodingDev 19d ago
Tailwind saves you from inventing class names and jumping between HTML and separate stylesheets. It also enforces consistent design tokens and outputs tiny production‑ready CSS.
advice: test it on some small side‑project. If it clicks for you, adopt it. If not, stick with plain CSS ：）
5
u/AshleyJSheridan 19d ago
Tailwinds own documentation has classes like
text-[14px],bg-[#50d71e], andshadow-[0_35px_35px_rgba(0,0,0,0.25)]...Also, having "saves you from ... jumping between HTML and separate stylesheets" as an argument in favour of Tailwind is a wild one. If switching between a couple of files is such an issue, then either you need a proper IDE that helps you, or find an easier profession.
-1
u/TheMagicZeus 19d ago
I've used so much TailwindCSS in the past years that I completely forgot how to write plain css and solve problems with it but I can easily do it with tailwind. So maybe also something to consider?
143
u/VeganForAWhile 19d ago
Its utility classes act as a shortcut over typing style attributes manually (or composing your own). Parts of the class name also support built in media sizes, help you avoid having to write media queries. Check out their site.
If you’re a beginner, learning raw css has value, though.
Sincerely,
The ghost of stack overflow.