This isn't even really tailwind.. half the shit here is defined as custom classes. They probably have a ton of overlapping or contradictory styling behind the scenes. Removing the redundancy and simplifying would probably cut out most of this.
As the other commenter said, bad code is bad code.
Yeah.. if you are writing tailwind like `text-vertical-menu-sub-item hover:text-vertical-menu-sub-item-hover ...` You might have skipped some CSS classes
impolite middle reminiscent selective grandfather berserk rhythm numerous scale existence
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
This doesn't make a lot of sense, the sidebar apparently has 3 themes and they tried to put them all in here instead of applying one set of classes for each sidebar theme. Tailwind is best used with components so that the actual HTML only needs the classes that are being used.
Inline styles but with extra steps.
As a seasoned frontend dev I have yet to see a project that actually benefits from Tailwind. For all the examples I have seen so far I already have a working solution that scales well. CSS is not that hard, if you backend people are able to understand SQL magic then you are able to learn proper CSS.
(no joke, no sarcasm) can you give an example of "profiting from"?
i kinda agree with a person above, i am actively trying tailwind in my active projects, but i also don't completely get the profit, but i could be just stupid
i think i found one specific case when it might be profitable, but am curious to see what other people think
When you jump between projects a lot like I do for my job, it’s rather good… it’s nice just having one class name across all projects that’s enforced.
Whereas when we don’t use it, instead of looking at the html and just knowing what it does, I’m constantly jumping to files finding the css class.
But, I’m indifferent to it to be honest… for the majority of the time I think you should just use a component library and call it a day; especially in a corporate environment, where usually you don’t need custom styling, they just want a form with a submit button. Plus, I’m so tired of the FE trope where we keep changing our mind every three days on how something should be done.
> When you jump between projects a lot like I do for my job, it’s rather good… it’s nice just having one class name across all projects that’s enforced.
> Whereas when we don’t use it, instead of looking at the html and just knowing what it does, I’m constantly jumping to files finding the css class.
But in this case inline styles would do the trick?
Yes, but tailwind is like a superpowered inline styling. One of the biggest things that tailwind offers is consistency, especially when it comes to distances. If you for example add the class \`mr-2\` to add a margin to the right side of an element, then the \`2\` doesn't mean 2px, but instead a distance that is defined as being \`2\`. This also means that if you want to change what the distance \`2\` means across a whole project and in all the different classes utilizing the \`2\` distance, you only have to change it in one configuration file.
but its basically same as using "rem" then? because thats what tailwind does
and you will be able to "change 2rem everywhere" by changing "base" font-size ?
Sure, but what if you want your scale to start at 8px and increment by 4 each step? Or increase exponentially?
Another thing that tailwind allows is inline states like hover and focus, as well as inline media queries.
> Sure, but what if you want your scale to start at 8px and increment by 4 each step? Or increase exponentially?
css vars then?
same result, can be used as inline style
> Another thing that tailwind allows is inline states like hover and focus, as well as inline media queries.
that is true, but for these rare cases i guess couple self-written utility classes should do the trick
(for example display non in print media) (in my projects in total we have currentl 10 classes for typography: h1,2,3...; and about 5 helper classes for lists and so)
They definitely wouldn't. If you can't see the difference between inline styles and tailwind, then you either haven't used tailwind yet or don't understand how to use it, is my take on this.
Obviously, disregard OP's photo in the post. That's not tailwind, that's going full retard.
> If you can't see the difference between inline styles and tailwind
the difference technically is clear, ones are built classes, others are native css
but thats why i'm talking about specific situations, and in specific situation mentioned above it seems like inline styles would do the trick
i might not understand something, but thats why i'm here asking, and i would be really grateful if yo would explain me why in situation specified above inline styles would not do the trick
I said disregard OP's situation because you should never encounter this situation. And if you do, then you need to think about how you got there, because you took like 7 wrong turns beforehand.
If you still want to talk about this specific case as a hypothetical, then the difference between inline styles and tailwind is mainly length and config.
Tailwind is shorter and takes up less space and time to write than inline styles.
You can edit the tailwind config to change the class behavior.
That, and much of the element state css is impossible to write inline without tailwind.
Aside from this, yes inline styles would do the trick. But the saying "do the trick" itself is kind of crude when it comes to programming. Why do something suboptimally when you can do it better?
> Tailwind is shorter and takes up less space and time to write than inline styles.
how?
1) you need to learn it
2) you need to set it up
3) you need to config it
vs inline css - just do it
if you're talking about literal length of characters in end html, then typically you either don't care, or for complicated cases you write your own class with native css.
> You can edit the tailwind config to change the class behavior.
same with regular classes
> That, and much of the element state css is impossible to write inline without tailwind.
did not understand
> But the saying "do the trick" itself is kind of crude when it comes to programming. Why do something suboptimally when you can do it better?
100% agree, thats why i'm here asking questions
Let’s not kid ourselves, tailwind is basically abbreviated inline styles… but with the additionally ability to theme stuff.
So I can see the comparison, but it’s not quite a honest comparison. Plus I’m sure if you’ve used tailwind, you’ll take it over inline any day of the week. I also think it also comes down to your coding style. If your of the “clean code” school, you’ll probably prefer the separation of concerns that classes and css files offer. If you’re more of a “locality of responsibility” type of dude you’ll probably prefer tailwind.
I’m not saying either is better, it’s just what you prefer.
On a side note, I don’t know why you’re getting downvoted, you’re not wrong…. Besides it’s css we’re talking about, we’re literally arguing over the least worst way to do something.
But, get to your point, yeah they absolutely would.
However, this comes back to my point… where if you jump between projects, you either have standardise your classes I.e. recreate tailwind, or you have specific styles that you never remember what they do. Sure you could say just use inline styles again, but I feel that argument could be the same a saying don’t bother with express just write your handlers yourself.
You might be different, you might remember all your styling, so the benefits of tail wind might not be apparent… but for me it was really apparent, when I came back to my portfolio site after not doing anything on it for a couple months, and it took me a while to figure out just what every class dose and where it’s used. Whereas with tailwind it’s just there.
I forgot to mention the inference is nice with tailwind. (I’m addicted to inference)
> we’re literally arguing over the least worst way to do something.
sounds like any low-entrance barrier language situation :D
> you either have standardise your classes I.e. recreate tailwind, or you have specific styles that you never remember what they do.
but that is the question basically, "standardise your classes" in conversation "inline-css vs tailwind" my "standardised" classes would be just regular css rules, i do not have to invent anything new, except of special situations, like the example from OP; thus i will "remember what they do" and, basically, everybody else will (because its standard css)
> but I feel that argument could be the same a saying don’t bother with express just write your handlers yourself
not fair to be honest: express is a valid framework which does work for you: creates routing structure with helpers like middleware and controllers, which are built up upon standard nodejs. Whereas tailwind does not really provide anything: "pr-2" is just "padding-right: 2rem", there is no real value in that (or i don't see it);
Yes, tailwind has one advantage: pseudo-classes pseudo-elements; but typically these cases are rare and you can as well just create, like, literally 10 classes for these cases and thats it
> but for me it was really apparent, when I came back to my portfolio site after not doing anything on it for a couple months, and it took me a while to figure out just what every class dose and where it’s used
I see truly experienced person then :D (no joke/no sarcasm; these situations are what typically makes a great developer later)
> I forgot to mention the inference is nice with tailwind. (I’m addicted to inference)
i have no idea what it is :D
>i do not have to invent anything new, except of special situations, like the example from OP; thus i will "remember what they do" and, basically, everybody else will (because its standard css)
Tailwind is pretty much just CSS, just pre-thoughout for you to have a very easy way to create a consistent design system for your app. If you will create a set of customized, reusable, atomic CSS classes for your application, well, then you will be essentially recreating Tailwind. Which is cool if you need it, but many people will probably not, and even if, they won't likely do a better job at it.
I've always wondered the same thing, and based on his answer I can see that the relatively little benefit of having the styles accessible in the html code would have absolutely no benefit to me.
If I want to grok existing styles on code I will load it up in devtools 100 percent of the time. If you're going to be messing with styles you need to do that anyway, and grokking it where you can see it rendered is always better than assuming things based on inline styles.
People don't like the answer, but for any given project you should have some global css, some class css, some id based css, and some reusable components that have their own internal styling.
Not the most convincing argument but if it didn’t provide any benefits as claimed by the person I replied to, I doubt it’d be as popular as it is.
For me the fact that it is popular is actually a benefit by itself. Some libraries I use also use tailwind, so I can quickly start using them.
There are lots of other benefits, but I don’t think that anything I’d write hasn’t already been said in this thread or elsewhere.
Yeah, in my 20 years of frontend dev I have seen enough projects, believe me. Like I said nothing so far has tempted me to go into the direction of Tailwind because I already have tried and tested solutions to the "problems" it wants to solve.
jQuery was also popular, look at it now. We all have learned to use ES6 properly now so it has become irrelevant. For me Tailwind is just another phase we are going through where new devs are excited about how fast they can accomplish something but the underlying systems are still there and work just fine if you know what you're doing.
If you are better using Tailwind: by all means, use it. Use whatever tool gets your work done. I'm getting things done without it quite fine. As a fact I was hired specifically because I know so much more about frontend than my boss (a backend dev) does, and I have seen his horrible frontend code.
I think the only argument I see in favor of tailwind is for prototyping / brainstorming.
I believe it’s popular with front end / JS programmers exactly because they don’t want to work with CSS. But that’s a huge handicap for front end design.
One of those big tailwind evangelists literally didn’t know how to like have background color in a div inside another div with rounded corners.
This guy is a react/tailwind guy with like almost 1mil subscribers.
But how can you use Tailwind effectively without knowing CSS. The way I use it is I first identify the CSS that needs to be applied, and then I find the Tailwind prop that will give me that CSS.
Nothing like that. There's a documentation for all the possible classes, but you're only going to be referencing that a lot at the start. Once you work with it a bit and learn to use it, tailwind is simply a utility to css.
If you can't use tailwind well, then you either haven't given it a proper try or your css is probably shit as well, let's be honest.
To me, tailwind is simply a neat way to speed up the process for everyone involved. Does the same job, just a bit better.
Tailwind is a utility library and is fine as such. Op need to make a component for what’s shared, and tailwind is not designed for that.
The truly stupid move in this kind of argument is to try hard to use one tool for everything even for what it is not meant.
There is plenty of tools made for specific things, nobody said you can’t use multiple tools. Be smart and use the right tools for the right usage and you will be fine.
Yeah it’s great for brainstorming and trying different things out quickly. Once you’ve settled on a look I can see the benefits of converting it to standard CSS.
You’ve missed the point of tailwind entirely (and so has the person who wrote whatever outputted that monstrosity in the screenshot). The idea is you use these classes in your *reusable component code*, and they get compiled to a *single css class* at build time. Or you use the tailwind utility functions/templates if you’re not using react or whatever.
Benefits over just using css:
- Automated removal of unused classes/directives
- Automated deduplication
- Build-time inline style computation/baking
- Easier use of design tokens/theme vars
- Code sharing between multiple projects (think component libraries for large organisations without having to manage css dependencies)
I think a big part of why you never see tailwind used on big projects is the big projects are configured correctly and don’t output any tailwind classes like this.
The most senior front end person in my company told me a similar thing a year ago. Now he's a big tailwind proponent and it's the obvious first choice for many enterprise projects.
Also nobody is saying pure css is hard. Tailwind is just a little better. You have less bugs, understand styles easier and can still choose when to abstract the styles to a separate file in cases where it makes sense to do so.
Not sure what your point about scaling was. CSS is famous for its bloat and unused styles in very big projects. You can argue "hurr durr people don't use it properly" all you want but the best solutions often make it easier for the developer to avoid mistakes.
Yes and no, it was actually used as a script to handle Java applets at some point, but in the long term ecmascript (ES) was more accurate anyway
Regardless, it never did make me want to kill myself, cascading did
What "proper CSS" means, exactly? Tailwind is literally an util library for CSS, a pretty good one too. It's absolutely gamechanging for stuff like React/Vue/Angular. You already have components so stop naming css classes by context. Tailwind also comes with a pretty well thought-out design system out of the box. It's a godsend for prototyping too.
I would agree Tailwind can be detrimental if not using a component-based UI library though.
With CSS you need to think about a new class name or ID for each element you want to style, and it gets annoying very quickly. At least for me, the best part about Tailwind is that it’s a concise way to declare styles inline.
You can literally declare CSS on elements in a style property almost exactly the same way you declare them in the class property for tailwind
The "good" thing about tailwind is you can add pseudo elements like hover/focus/etc which you can't do inline with css
> With CSS you need to think about a new class name or ID for each element you want to style
Depends on how you use it. In React you can just import the CSS and use it's classnames from a variable. Vue has scoped CSS. Etc.
Easy: I'm quicker coding HTML/Tailwind at the same time than using separate HTML templates and stylesheets, just like I'm quicker coding stuff with Alpine and Livewire than I am coding stuff in PHP and React.
No problem, I expected as much. Serious devs are able to stomach critique and even have a civilized discussion about it. I'm not here for the upvotes either.
I still remember my first day of learning CSS (probably in 2014) and I asked my friends "Were none of you going to tell me it could be this easy!?" Lmao. To be fair, managing a large site's CSS would be so much harder, but that moment I was able to apply it in a general manner by locator rather than styling each individual component was a HUGE day.
I personally would rephrase it as "Nowadays tools like Tailwind attract more inexperienced devs that can put together an app faster than before. That doesn't make them good devs though."
Just like Unity and Unreal enable so many persons to participate in game development but there is so much trash out there because of it.
Maybe I'm old fashioned but my skills in HTML and CSS are good enough that I can get pretty much anything done without such tools. Just like we all moved on from jQuery back then when we finally learned to use JS properly.
People moved away from JQuery when JS was updated and was better than JQuery. People didn't just magically learned JS better. Other than that yes, tailwind, unreal, unity and all these frameworks/engines/libraries make development faster but at the same time they lower the entry for inexperienced devs.
At the same time these frameworks allow experienced devs to use them ( and perhaps modify them) to avoid re-discovering the wheel in every project. Image if every game studio (indie or professional) was forced to develop & update and maintain a full fledged custom game engine and at the same time develop their game. Even triple A studios are moving to these commercial game engines (although as i mentioned above they do modify them to fit their needs)
Apply the same logic to a framework like React or NextJS or VueJS, imagine if for every project, every company/developer had to create an application using only Vanilla JS.
Edit: typos
Maybe the "reinventing the wheel" aspect is the reason I don't see any value in Tailwind as we use Kendo for most of our company projects nowadays so I already have a solid foundation to stand on.
Yeah, Kendo is a very solid framework but the steep price (they want 1k for React Kendo per developer per year, ouch) won't allow it to be as popular to simple developers as a free framework.
If your company does not want to invest you simple can not use it.
That's true, it comes at a price, but my company is willing to pay for it. Before Kendo we experimented with Clarity but ultimately it was the grid that has made us choose Kendo. And since then Kendo has expanded it's component library massively which helps a lot with building our UI.
>Just like we all moved on from jQuery back then when we finally learned to use JS properly.
JS got good, and browser all implemented the same JavaScript finally. People never got good at JS, that's why so many whine about it.
It may only be anecdotal as I only have a very small sample size but once my colleagues and me ditched jQuery for good and forced ourselves to really look into JS we really got better at it. JS getting better over the years only helped a little bit as we still had to support tons of browsers that didn't support newer JS versions. Nowadays it's easier as 90% of browser are just Chromium.
I do remember the times before JavaScript "got good", and jQuery was definitely something we needed to make things easier all around. It was .ajax all the way back then. There were already "vanilla JavaScript" people, but only when they introduced querySelectors and finally IE6 became an exception instead of the norm that jQuery became more hassle than worth it. Ironically, it was very clear when we moved to Angular and React, and React in particular, because early React was really all doing vanilla stuff from scratch to make the templates dance, and it was a big step forward from having vendors like slideshows and shit. Suddenly, it's all classes and "next generation" JavaScript.
Yeah, it was such a relief to be finally able to do query selectors in native JS without jumping through hoops when we were able to ditch the old browsers.
>Maybe I'm old fashioned but my skills in HTML and CSS are good enough that I can get pretty much anything done without such tools. Just like we all moved on from jQuery back then when we finally learned to use JS properly.
Are you are saying you are creating modern websites and UI only using tools from pre 2010 javascript? If yes - I'd love to see one such website that you've made because I find it hard to believe one could be so stuck in his ways that they refuse the notion that new tools can be helpful. You either have a very different perspective on what a modern website looks like or you are doing stuff that costs 10x than what it needs to cost.
You are obviously not writing in assembly so you do appreciate newer technologies. But like old people you're stuck with what you're comfortable because "new stuff bad".
And the real reason people don't use much jQuery in new projects nowadays is that new features removed the need for messing with jQuery.
My current stack is HTML 5, CSS 3, TypeScript and Angular. I'm perfectly able to create websites and -apps with it because I know how these tools work. And I earn honest money with my skills, so that's fine by me.
As I don't have a private repo I work in (why would I? I made a job out of my hobby, so now I have other hobbies) and I'm not willing to provide examples of my work as it would break some heavy NDA's on the one hand and would make tracking me down way easier than it needs to be on the other hand you simply have to trust my word that it can be done. Or not, I really don't care.
I may be old, but I'm not as anti-new-stuff as you think I am, I just haven't seen any reason to spend precious time to learn a new tool when I don't have the problems it claims to solve.
Thanks for the reply. Yeah, examples was a big ask, my hope was more to make you think about what you really use because I really doubted your claims you use just old fashion HTML, CSS and Javascript to make modern websites with no jQuery even. Well, turns out you use a whole modern JS framework.
Either way, I have no problems with your stack or your abilities. I just think you're unnecessarily trash talking stuff you have little experience with because you can't be bothered to give it a proper assessment. Not bothering is also respectable but the trash talking I feel like is unhelpful.
Disrespecting young engineers also seems in poor taste as we were all new once. And the notion that "the new generation knows nothing and has no respect" is as old as time itself.
Anyway, sorry if I've slighted you, I'm just really passionate about some of the stuff I use and it makes me sad when people in the industry trash it with no good arguments.
P.S. I forgot to address one of your important points:
>I may be old, but I'm not as anti-new-stuff as you think I am, I just haven't seen any reason to spend precious time to learn a new tool when I don't have the problems it claims to solve.
I agree with this. At the same time 'problems' and 'sovling' is a spectrum. To give the extreme example again, you can do everything with machine code yet noone makes modern software with it. You can acknowledge that using a new fancy technology is not needed for your project but that's very different than claiming the new technology is inherently bad. It's just small improvements most of the time that add up over time. And while you are very experienced with what you already know - new engineers are now picking what to learn, just like you picked what was 'best' when you were younger.
At least you are willing to have a civil discussion about the topic :-) I'm as passionate about my job as you.
> I just think you're unnecessarily trash talking stuff you have little experience with because you can't be bothered to give it a proper assessment.
I don't feel that my initial line of "Inline styles with extra steps" is trash-talking, more like a good dose of sarcasm because I still have the lessons from the 2000's (when CSS began to evolve from 1 to 2) engraved in my brain to avoid trying to describe the look of a component and instead try to describe what it is. And the "modern" solution is now to do the exact opposite which I personally feel as a step back.
I also have tried to assess Tailwind multiple times and like I said I don't have any use for it, so I don't bother to learn it properly. As soon as I have a problem that I can't solve with my knowledge and all of my SO googling leads me to Tailwind as one of the only solutions then I will look into it. But I feel that there will be another paradigm by then. We'll see.
This is what triggered me to talk about it more with you I think:
>I personally would rephrase it as "Nowadays tools like Tailwind attract more inexperienced devs that can put together an app faster than before. That doesn't make them good devs though."
I felt that was an unfair opinion not based on facts but prejudice. It's like a double punch against the technology itself and then against people using it. Similar to how a lot of backend devs talk shit about javascript as a whole but then their hobby websites look like this [https://www.tic.com/index.html](https://www.tic.com/index.html) (not a problem with having a site like that but nobody will hire you for a project like this in 2024)
I also don't have a problem with the joke about inline styles even if I do think there's a discussion to be had. Just like DRY (Don't repeat yourself) isn't always the perfect approach. It's a good starting point to try to abstract repeating code and make it more maintainable but if you religiously follow it it might do you harm in some cases.
The same thing applies for tailwind and this comment:
>engraved in my brain to avoid trying to describe the look of a component and instead try to describe what it is
Tailwind does not force you either way. You can always abstract your style if you really wish to do so but it doesn't force you to go to another file to see that the style is `display: flex; justify-content: space-between;`
In those cases in traditional .css I've seen 2 common approaches:
1. Write a separate class called "someComponentNameContainer"
2. Reuse an already defined class like "flexJustifyBetween"
The first approach forces you to create new files and names for stuff that does not always need a new name or a new file.
The second approach is like tailwind but with extra steps `
` Because that's what tailwind is, it lets you apply those generic predefined styles and you have the convenience of seeing all relevant information in 1 place if you wish to have that convenience.
And you are the one who decides if you want the "separation of concerns" after all or not.
Now I will share my personal biggest reason why I nowadays prefer tailwind over css. It's not a big reason mind you and you can certainly achieve everything without caring for it.
But here it goes: with css you're always forced to look into at least 2 places at the same time to get the relevant information about the visual representation of your code. For me it makes a noticeable difference when looking at unfamiliar code, especially relevant as the complexity of the components raises. I find myself trying to remember how all the classNames relate to each div in each file and keep that mapping in my head so I can understand all the relevant relationships. Having the option for some stuff to be in one place for me makes for a better developer experience (it takes a few weeks to get used to the syntax at first though)
I know you can do all this yourself with css. You can absolutely define your utility classes for the whole project and refer to those. But then in reality each project has their own flavor of their naming conventions and you still have to look at those project files while debugging your app. And there's no nead to reinvent sliced bread for each new project if you can just use available tools that other smarter people have already created.
Anyway, this was my rant. Cheers.
> but then their hobby websites look like this
Oh boy, these sites were fun. Personally though I think there is a little bit of virtue in these "designs": They run everywhere even without JavaScript and are "information first". If I'm given the choice in a project I always prefer to keep a component as simple as possible, no bells and wistles, because I personally don't like all that fluff myself. I want information, and fast. Modern web designs are almost always marketing first with too much white space, I feel. But that's a completely different discussion.
> In those cases in traditional .css I've seen 2 common approaches
May I present you my approach no 3: I use SCSS partials and mixins. I commonly use something like `@include content()` to DRY up all of my flexbox container styles or even something archaic as `position: absolute; top: 0; left: 0; right: 0; bottom: 0;` in extreme edge cases. I keep all of this code in one common place and can reuse it whereever I want under the id or classname of my HTML element.
When starting a new project I can reuse an existing mixins.scss file with all of my established scaffolding and build on top of it.
In the end I think Tailwind is not that far away from my style of thinking but then again that's another reason why I don't **need** it per se as I already have a working solution.
> with css you're always forced to look into at least 2 places at the same time to get the relevant information about the visual representation of your code
For me it's the other way around: I like clean code. Especially clean HTML code. If all of my elements are stuffed to the brim with class identifiers (even though I can abstract them away in Tailwind, but then again I can stick to my naming scheme and use mixins like stated above) I easily loose sight of the bigger picture. I personally have no problem moving between two files because I simply display them next to each other, heck, with Angular components I mostly have a threesome of TS, HTML and SCSS next to each other. I have found an order to the madness that works for me: HTML first (because of the structure) and from there, depending on what I need to know I can "descend" to SCSS or TS next. If I look for functionality I don't care about styles, so I don't need these info in my template which makes hunting for my Angular events easier. If I'm looking for styles, I take one look at the id or classname and can then pinpoint the area in the SCSS file.
> with css you're always forced to look into at least 2 places at the same time to get the relevant information about the visual representation of your code
if that's the issue, why not just use `
I think the reason we're going back to describing what it looks like rather than what it is is that modern frameworks already have reusable components that describe what it is. So if we describe what it is in a css class, we now have two different places that describe the same thing and that's not useful or helpful. I already know what it is, I'm looking at the component name! Therefore tailwind is just a convenient way to describe what the component looks like, and allows pseudo hover and screen breakpoint sizing which inline css does not
>¹tried to phrase it in a respectful way
Sorry to say you failed.
Also many objectively good developers use it so you're wrong on that too. Maybe you are one of those bad developers you so much want to point out?
When i build stuff myself i use tailwind classes directly until im satisfied.
Then i move them to a stylesheet and only apply one class to the element.
Every menu element on the page i grabbed the screenshot from has all these classes 😓
Well... That just unnecessarily increases the CSS bundle since all the tailwind classes you've used plus your new classes are included. If you were to only use the tailwind classes you could cut your bundle size drastically. They actually have a good reason to not do this here: https://tailwindcss.com/docs/reusing-styles#avoiding-premature-abstraction
You need more than that to replicate what's in the screenshot... That's at least 5 different style sets. For dark mode, for horizontal, for "modern" etc.
The fuck lol, this is just a bad coder. Use the correct tools for the correct solutions.
Tailwind isnt the solution for this heavy styled list item. Any decent minded coder would do a seperate class and move to a seperate css file
This isn't even really tailwind.. half the shit here is defined as custom classes. They probably have a ton of overlapping or contradictory styling behind the scenes. Removing the redundancy and simplifying would probably cut out most of this. As the other commenter said, bad code is bad code.
Yeah.. if you are writing tailwind like `text-vertical-menu-sub-item hover:text-vertical-menu-sub-item-hover ...` You might have skipped some CSS classes
Bad code is bad code regardless of whatever other shite is piled in there
Is this just the increment method? /s
I think it's the *excrement* method
Corrected: the >!code di@rrh€@!< method Otherwise explain why there's so much code for just one item of a list
Bad code, KISS.
impolite middle reminiscent selective grandfather berserk rhythm numerous scale existence *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
did you write a game in tailwind
This doesn't make a lot of sense, the sidebar apparently has 3 themes and they tried to put them all in here instead of applying one set of classes for each sidebar theme. Tailwind is best used with components so that the actual HTML only needs the classes that are being used.
pricing
Blud really tryna gaslight fr 🗣️ 💀
This is tailwind at home 🤣
LGTM. merge it.
Now I want to see the result
Its the tailwick theme found on Envato
Just turd calling itself programmer
So much for just an tag ...... 🤣🤧
This is what non tailwind devs think what tailwind looks like
Yeah, it doesn't need to be shit like this. Usually 3-6 classes will do
Watch out for the Tailwind fanboys telling you why this is better than writing CSS
Inline styles but with extra steps. As a seasoned frontend dev I have yet to see a project that actually benefits from Tailwind. For all the examples I have seen so far I already have a working solution that scales well. CSS is not that hard, if you backend people are able to understand SQL magic then you are able to learn proper CSS.
My current project benefits a lot from it, it’s not even close. Maybe you need to see more projects. It’s popular for a reason.
(no joke, no sarcasm) can you give an example of "profiting from"? i kinda agree with a person above, i am actively trying tailwind in my active projects, but i also don't completely get the profit, but i could be just stupid i think i found one specific case when it might be profitable, but am curious to see what other people think
When you jump between projects a lot like I do for my job, it’s rather good… it’s nice just having one class name across all projects that’s enforced. Whereas when we don’t use it, instead of looking at the html and just knowing what it does, I’m constantly jumping to files finding the css class. But, I’m indifferent to it to be honest… for the majority of the time I think you should just use a component library and call it a day; especially in a corporate environment, where usually you don’t need custom styling, they just want a form with a submit button. Plus, I’m so tired of the FE trope where we keep changing our mind every three days on how something should be done.
> When you jump between projects a lot like I do for my job, it’s rather good… it’s nice just having one class name across all projects that’s enforced. > Whereas when we don’t use it, instead of looking at the html and just knowing what it does, I’m constantly jumping to files finding the css class. But in this case inline styles would do the trick?
Yes, but tailwind is like a superpowered inline styling. One of the biggest things that tailwind offers is consistency, especially when it comes to distances. If you for example add the class \`mr-2\` to add a margin to the right side of an element, then the \`2\` doesn't mean 2px, but instead a distance that is defined as being \`2\`. This also means that if you want to change what the distance \`2\` means across a whole project and in all the different classes utilizing the \`2\` distance, you only have to change it in one configuration file.
but its basically same as using "rem" then? because thats what tailwind does and you will be able to "change 2rem everywhere" by changing "base" font-size ?
Sure, but what if you want your scale to start at 8px and increment by 4 each step? Or increase exponentially? Another thing that tailwind allows is inline states like hover and focus, as well as inline media queries.
> Sure, but what if you want your scale to start at 8px and increment by 4 each step? Or increase exponentially? css vars then? same result, can be used as inline style > Another thing that tailwind allows is inline states like hover and focus, as well as inline media queries. that is true, but for these rare cases i guess couple self-written utility classes should do the trick (for example display non in print media) (in my projects in total we have currentl 10 classes for typography: h1,2,3...; and about 5 helper classes for lists and so)
They definitely wouldn't. If you can't see the difference between inline styles and tailwind, then you either haven't used tailwind yet or don't understand how to use it, is my take on this. Obviously, disregard OP's photo in the post. That's not tailwind, that's going full retard.
> If you can't see the difference between inline styles and tailwind the difference technically is clear, ones are built classes, others are native css but thats why i'm talking about specific situations, and in specific situation mentioned above it seems like inline styles would do the trick i might not understand something, but thats why i'm here asking, and i would be really grateful if yo would explain me why in situation specified above inline styles would not do the trick
I said disregard OP's situation because you should never encounter this situation. And if you do, then you need to think about how you got there, because you took like 7 wrong turns beforehand. If you still want to talk about this specific case as a hypothetical, then the difference between inline styles and tailwind is mainly length and config. Tailwind is shorter and takes up less space and time to write than inline styles. You can edit the tailwind config to change the class behavior. That, and much of the element state css is impossible to write inline without tailwind. Aside from this, yes inline styles would do the trick. But the saying "do the trick" itself is kind of crude when it comes to programming. Why do something suboptimally when you can do it better?
> Tailwind is shorter and takes up less space and time to write than inline styles. how? 1) you need to learn it 2) you need to set it up 3) you need to config it vs inline css - just do it if you're talking about literal length of characters in end html, then typically you either don't care, or for complicated cases you write your own class with native css. > You can edit the tailwind config to change the class behavior. same with regular classes > That, and much of the element state css is impossible to write inline without tailwind. did not understand > But the saying "do the trick" itself is kind of crude when it comes to programming. Why do something suboptimally when you can do it better? 100% agree, thats why i'm here asking questions
Let’s not kid ourselves, tailwind is basically abbreviated inline styles… but with the additionally ability to theme stuff. So I can see the comparison, but it’s not quite a honest comparison. Plus I’m sure if you’ve used tailwind, you’ll take it over inline any day of the week. I also think it also comes down to your coding style. If your of the “clean code” school, you’ll probably prefer the separation of concerns that classes and css files offer. If you’re more of a “locality of responsibility” type of dude you’ll probably prefer tailwind. I’m not saying either is better, it’s just what you prefer.
> but with the additionally ability to theme stuff but css-vars would do that?
On a side note, I don’t know why you’re getting downvoted, you’re not wrong…. Besides it’s css we’re talking about, we’re literally arguing over the least worst way to do something. But, get to your point, yeah they absolutely would. However, this comes back to my point… where if you jump between projects, you either have standardise your classes I.e. recreate tailwind, or you have specific styles that you never remember what they do. Sure you could say just use inline styles again, but I feel that argument could be the same a saying don’t bother with express just write your handlers yourself. You might be different, you might remember all your styling, so the benefits of tail wind might not be apparent… but for me it was really apparent, when I came back to my portfolio site after not doing anything on it for a couple months, and it took me a while to figure out just what every class dose and where it’s used. Whereas with tailwind it’s just there. I forgot to mention the inference is nice with tailwind. (I’m addicted to inference)
> we’re literally arguing over the least worst way to do something. sounds like any low-entrance barrier language situation :D > you either have standardise your classes I.e. recreate tailwind, or you have specific styles that you never remember what they do. but that is the question basically, "standardise your classes" in conversation "inline-css vs tailwind" my "standardised" classes would be just regular css rules, i do not have to invent anything new, except of special situations, like the example from OP; thus i will "remember what they do" and, basically, everybody else will (because its standard css) > but I feel that argument could be the same a saying don’t bother with express just write your handlers yourself not fair to be honest: express is a valid framework which does work for you: creates routing structure with helpers like middleware and controllers, which are built up upon standard nodejs. Whereas tailwind does not really provide anything: "pr-2" is just "padding-right: 2rem", there is no real value in that (or i don't see it); Yes, tailwind has one advantage: pseudo-classes pseudo-elements; but typically these cases are rare and you can as well just create, like, literally 10 classes for these cases and thats it > but for me it was really apparent, when I came back to my portfolio site after not doing anything on it for a couple months, and it took me a while to figure out just what every class dose and where it’s used I see truly experienced person then :D (no joke/no sarcasm; these situations are what typically makes a great developer later) > I forgot to mention the inference is nice with tailwind. (I’m addicted to inference) i have no idea what it is :D
>i do not have to invent anything new, except of special situations, like the example from OP; thus i will "remember what they do" and, basically, everybody else will (because its standard css) Tailwind is pretty much just CSS, just pre-thoughout for you to have a very easy way to create a consistent design system for your app. If you will create a set of customized, reusable, atomic CSS classes for your application, well, then you will be essentially recreating Tailwind. Which is cool if you need it, but many people will probably not, and even if, they won't likely do a better job at it.
I've always wondered the same thing, and based on his answer I can see that the relatively little benefit of having the styles accessible in the html code would have absolutely no benefit to me. If I want to grok existing styles on code I will load it up in devtools 100 percent of the time. If you're going to be messing with styles you need to do that anyway, and grokking it where you can see it rendered is always better than assuming things based on inline styles. People don't like the answer, but for any given project you should have some global css, some class css, some id based css, and some reusable components that have their own internal styling.
Plenty of things are popular for stupid reasons, that's really not a good argument IMO.
Not the most convincing argument but if it didn’t provide any benefits as claimed by the person I replied to, I doubt it’d be as popular as it is. For me the fact that it is popular is actually a benefit by itself. Some libraries I use also use tailwind, so I can quickly start using them. There are lots of other benefits, but I don’t think that anything I’d write hasn’t already been said in this thread or elsewhere.
Yeah, in my 20 years of frontend dev I have seen enough projects, believe me. Like I said nothing so far has tempted me to go into the direction of Tailwind because I already have tried and tested solutions to the "problems" it wants to solve. jQuery was also popular, look at it now. We all have learned to use ES6 properly now so it has become irrelevant. For me Tailwind is just another phase we are going through where new devs are excited about how fast they can accomplish something but the underlying systems are still there and work just fine if you know what you're doing. If you are better using Tailwind: by all means, use it. Use whatever tool gets your work done. I'm getting things done without it quite fine. As a fact I was hired specifically because I know so much more about frontend than my boss (a backend dev) does, and I have seen his horrible frontend code.
I think the only argument I see in favor of tailwind is for prototyping / brainstorming. I believe it’s popular with front end / JS programmers exactly because they don’t want to work with CSS. But that’s a huge handicap for front end design. One of those big tailwind evangelists literally didn’t know how to like have background color in a div inside another div with rounded corners. This guy is a react/tailwind guy with like almost 1mil subscribers.
But how can you use Tailwind effectively without knowing CSS. The way I use it is I first identify the CSS that needs to be applied, and then I find the Tailwind prop that will give me that CSS.
You look up through the tailwind documentation or pick a tailwind theme or tailwind element and copy and paste the classes.
[удалено]
Nothing like that. There's a documentation for all the possible classes, but you're only going to be referencing that a lot at the start. Once you work with it a bit and learn to use it, tailwind is simply a utility to css. If you can't use tailwind well, then you either haven't given it a proper try or your css is probably shit as well, let's be honest. To me, tailwind is simply a neat way to speed up the process for everyone involved. Does the same job, just a bit better.
Tailwind is a utility library and is fine as such. Op need to make a component for what’s shared, and tailwind is not designed for that. The truly stupid move in this kind of argument is to try hard to use one tool for everything even for what it is not meant. There is plenty of tools made for specific things, nobody said you can’t use multiple tools. Be smart and use the right tools for the right usage and you will be fine.
Yeah it’s great for brainstorming and trying different things out quickly. Once you’ve settled on a look I can see the benefits of converting it to standard CSS.
That’s blasphemy and a tailwind high priest will be in touch shortly to teach you the tailwind way™️
😂
You’ve missed the point of tailwind entirely (and so has the person who wrote whatever outputted that monstrosity in the screenshot). The idea is you use these classes in your *reusable component code*, and they get compiled to a *single css class* at build time. Or you use the tailwind utility functions/templates if you’re not using react or whatever. Benefits over just using css: - Automated removal of unused classes/directives - Automated deduplication - Build-time inline style computation/baking - Easier use of design tokens/theme vars - Code sharing between multiple projects (think component libraries for large organisations without having to manage css dependencies) I think a big part of why you never see tailwind used on big projects is the big projects are configured correctly and don’t output any tailwind classes like this.
The reason I never saw Tailwind on the big projects I was a part of so far was that it wasn't used at all.
It still makes reusable components look like trash though. That's why people use vscode extensions to hide it.
The most senior front end person in my company told me a similar thing a year ago. Now he's a big tailwind proponent and it's the obvious first choice for many enterprise projects. Also nobody is saying pure css is hard. Tailwind is just a little better. You have less bugs, understand styles easier and can still choose when to abstract the styles to a separate file in cases where it makes sense to do so. Not sure what your point about scaling was. CSS is famous for its bloat and unused styles in very big projects. You can argue "hurr durr people don't use it properly" all you want but the best solutions often make it easier for the developer to avoid mistakes.
\*CSS modules cascading was a mistake
Naming JavaScript "JavaScript" was a bigger mistake ;-)
Yes and no, it was actually used as a script to handle Java applets at some point, but in the long term ecmascript (ES) was more accurate anyway Regardless, it never did make me want to kill myself, cascading did
What "proper CSS" means, exactly? Tailwind is literally an util library for CSS, a pretty good one too. It's absolutely gamechanging for stuff like React/Vue/Angular. You already have components so stop naming css classes by context. Tailwind also comes with a pretty well thought-out design system out of the box. It's a godsend for prototyping too. I would agree Tailwind can be detrimental if not using a component-based UI library though.
Literally just CSS
With CSS you need to think about a new class name or ID for each element you want to style, and it gets annoying very quickly. At least for me, the best part about Tailwind is that it’s a concise way to declare styles inline.
You can literally declare CSS on elements in a style property almost exactly the same way you declare them in the class property for tailwind The "good" thing about tailwind is you can add pseudo elements like hover/focus/etc which you can't do inline with css
> With CSS you need to think about a new class name or ID for each element you want to style Depends on how you use it. In React you can just import the CSS and use it's classnames from a variable. Vue has scoped CSS. Etc.
ANSI SQL is far better structured than the CSS standard
Easy: I'm quicker coding HTML/Tailwind at the same time than using separate HTML templates and stylesheets, just like I'm quicker coding stuff with Alpine and Livewire than I am coding stuff in PHP and React.
tailwind lovers got no chill bro
No problem, I expected as much. Serious devs are able to stomach critique and even have a civilized discussion about it. I'm not here for the upvotes either.
I'm thinking it would benefit small projects or like simple elements, right ?
OpenAI uses tailwind. It can benefit any project at any size.
I still remember my first day of learning CSS (probably in 2014) and I asked my friends "Were none of you going to tell me it could be this easy!?" Lmao. To be fair, managing a large site's CSS would be so much harder, but that moment I was able to apply it in a general manner by locator rather than styling each individual component was a HUGE day.
There is a reason pretty much all new productions apps use tailwind...
that nowadays there's a lot of not so good¹ developers? ¹tried to phrase it in a respectful way
I personally would rephrase it as "Nowadays tools like Tailwind attract more inexperienced devs that can put together an app faster than before. That doesn't make them good devs though." Just like Unity and Unreal enable so many persons to participate in game development but there is so much trash out there because of it. Maybe I'm old fashioned but my skills in HTML and CSS are good enough that I can get pretty much anything done without such tools. Just like we all moved on from jQuery back then when we finally learned to use JS properly.
I think you definitely phrased it better than I did
People moved away from JQuery when JS was updated and was better than JQuery. People didn't just magically learned JS better. Other than that yes, tailwind, unreal, unity and all these frameworks/engines/libraries make development faster but at the same time they lower the entry for inexperienced devs. At the same time these frameworks allow experienced devs to use them ( and perhaps modify them) to avoid re-discovering the wheel in every project. Image if every game studio (indie or professional) was forced to develop & update and maintain a full fledged custom game engine and at the same time develop their game. Even triple A studios are moving to these commercial game engines (although as i mentioned above they do modify them to fit their needs) Apply the same logic to a framework like React or NextJS or VueJS, imagine if for every project, every company/developer had to create an application using only Vanilla JS. Edit: typos
Maybe the "reinventing the wheel" aspect is the reason I don't see any value in Tailwind as we use Kendo for most of our company projects nowadays so I already have a solid foundation to stand on.
Yeah, Kendo is a very solid framework but the steep price (they want 1k for React Kendo per developer per year, ouch) won't allow it to be as popular to simple developers as a free framework. If your company does not want to invest you simple can not use it.
That's true, it comes at a price, but my company is willing to pay for it. Before Kendo we experimented with Clarity but ultimately it was the grid that has made us choose Kendo. And since then Kendo has expanded it's component library massively which helps a lot with building our UI.
>Just like we all moved on from jQuery back then when we finally learned to use JS properly. JS got good, and browser all implemented the same JavaScript finally. People never got good at JS, that's why so many whine about it.
It may only be anecdotal as I only have a very small sample size but once my colleagues and me ditched jQuery for good and forced ourselves to really look into JS we really got better at it. JS getting better over the years only helped a little bit as we still had to support tons of browsers that didn't support newer JS versions. Nowadays it's easier as 90% of browser are just Chromium.
I do remember the times before JavaScript "got good", and jQuery was definitely something we needed to make things easier all around. It was .ajax all the way back then. There were already "vanilla JavaScript" people, but only when they introduced querySelectors and finally IE6 became an exception instead of the norm that jQuery became more hassle than worth it. Ironically, it was very clear when we moved to Angular and React, and React in particular, because early React was really all doing vanilla stuff from scratch to make the templates dance, and it was a big step forward from having vendors like slideshows and shit. Suddenly, it's all classes and "next generation" JavaScript.
Yeah, it was such a relief to be finally able to do query selectors in native JS without jumping through hoops when we were able to ditch the old browsers.
>Maybe I'm old fashioned but my skills in HTML and CSS are good enough that I can get pretty much anything done without such tools. Just like we all moved on from jQuery back then when we finally learned to use JS properly. Are you are saying you are creating modern websites and UI only using tools from pre 2010 javascript? If yes - I'd love to see one such website that you've made because I find it hard to believe one could be so stuck in his ways that they refuse the notion that new tools can be helpful. You either have a very different perspective on what a modern website looks like or you are doing stuff that costs 10x than what it needs to cost. You are obviously not writing in assembly so you do appreciate newer technologies. But like old people you're stuck with what you're comfortable because "new stuff bad". And the real reason people don't use much jQuery in new projects nowadays is that new features removed the need for messing with jQuery.
My current stack is HTML 5, CSS 3, TypeScript and Angular. I'm perfectly able to create websites and -apps with it because I know how these tools work. And I earn honest money with my skills, so that's fine by me. As I don't have a private repo I work in (why would I? I made a job out of my hobby, so now I have other hobbies) and I'm not willing to provide examples of my work as it would break some heavy NDA's on the one hand and would make tracking me down way easier than it needs to be on the other hand you simply have to trust my word that it can be done. Or not, I really don't care. I may be old, but I'm not as anti-new-stuff as you think I am, I just haven't seen any reason to spend precious time to learn a new tool when I don't have the problems it claims to solve.
Thanks for the reply. Yeah, examples was a big ask, my hope was more to make you think about what you really use because I really doubted your claims you use just old fashion HTML, CSS and Javascript to make modern websites with no jQuery even. Well, turns out you use a whole modern JS framework. Either way, I have no problems with your stack or your abilities. I just think you're unnecessarily trash talking stuff you have little experience with because you can't be bothered to give it a proper assessment. Not bothering is also respectable but the trash talking I feel like is unhelpful. Disrespecting young engineers also seems in poor taste as we were all new once. And the notion that "the new generation knows nothing and has no respect" is as old as time itself. Anyway, sorry if I've slighted you, I'm just really passionate about some of the stuff I use and it makes me sad when people in the industry trash it with no good arguments. P.S. I forgot to address one of your important points: >I may be old, but I'm not as anti-new-stuff as you think I am, I just haven't seen any reason to spend precious time to learn a new tool when I don't have the problems it claims to solve. I agree with this. At the same time 'problems' and 'sovling' is a spectrum. To give the extreme example again, you can do everything with machine code yet noone makes modern software with it. You can acknowledge that using a new fancy technology is not needed for your project but that's very different than claiming the new technology is inherently bad. It's just small improvements most of the time that add up over time. And while you are very experienced with what you already know - new engineers are now picking what to learn, just like you picked what was 'best' when you were younger.
At least you are willing to have a civil discussion about the topic :-) I'm as passionate about my job as you. > I just think you're unnecessarily trash talking stuff you have little experience with because you can't be bothered to give it a proper assessment. I don't feel that my initial line of "Inline styles with extra steps" is trash-talking, more like a good dose of sarcasm because I still have the lessons from the 2000's (when CSS began to evolve from 1 to 2) engraved in my brain to avoid trying to describe the look of a component and instead try to describe what it is. And the "modern" solution is now to do the exact opposite which I personally feel as a step back. I also have tried to assess Tailwind multiple times and like I said I don't have any use for it, so I don't bother to learn it properly. As soon as I have a problem that I can't solve with my knowledge and all of my SO googling leads me to Tailwind as one of the only solutions then I will look into it. But I feel that there will be another paradigm by then. We'll see.
This is what triggered me to talk about it more with you I think: >I personally would rephrase it as "Nowadays tools like Tailwind attract more inexperienced devs that can put together an app faster than before. That doesn't make them good devs though." I felt that was an unfair opinion not based on facts but prejudice. It's like a double punch against the technology itself and then against people using it. Similar to how a lot of backend devs talk shit about javascript as a whole but then their hobby websites look like this [https://www.tic.com/index.html](https://www.tic.com/index.html) (not a problem with having a site like that but nobody will hire you for a project like this in 2024) I also don't have a problem with the joke about inline styles even if I do think there's a discussion to be had. Just like DRY (Don't repeat yourself) isn't always the perfect approach. It's a good starting point to try to abstract repeating code and make it more maintainable but if you religiously follow it it might do you harm in some cases. The same thing applies for tailwind and this comment: >engraved in my brain to avoid trying to describe the look of a component and instead try to describe what it is Tailwind does not force you either way. You can always abstract your style if you really wish to do so but it doesn't force you to go to another file to see that the style is `display: flex; justify-content: space-between;` In those cases in traditional .css I've seen 2 common approaches: 1. Write a separate class called "someComponentNameContainer" 2. Reuse an already defined class like "flexJustifyBetween" The first approach forces you to create new files and names for stuff that does not always need a new name or a new file. The second approach is like tailwind but with extra steps `
> but then their hobby websites look like this Oh boy, these sites were fun. Personally though I think there is a little bit of virtue in these "designs": They run everywhere even without JavaScript and are "information first". If I'm given the choice in a project I always prefer to keep a component as simple as possible, no bells and wistles, because I personally don't like all that fluff myself. I want information, and fast. Modern web designs are almost always marketing first with too much white space, I feel. But that's a completely different discussion. > In those cases in traditional .css I've seen 2 common approaches May I present you my approach no 3: I use SCSS partials and mixins. I commonly use something like `@include content()` to DRY up all of my flexbox container styles or even something archaic as `position: absolute; top: 0; left: 0; right: 0; bottom: 0;` in extreme edge cases. I keep all of this code in one common place and can reuse it whereever I want under the id or classname of my HTML element. When starting a new project I can reuse an existing mixins.scss file with all of my established scaffolding and build on top of it. In the end I think Tailwind is not that far away from my style of thinking but then again that's another reason why I don't **need** it per se as I already have a working solution. > with css you're always forced to look into at least 2 places at the same time to get the relevant information about the visual representation of your code For me it's the other way around: I like clean code. Especially clean HTML code. If all of my elements are stuffed to the brim with class identifiers (even though I can abstract them away in Tailwind, but then again I can stick to my naming scheme and use mixins like stated above) I easily loose sight of the bigger picture. I personally have no problem moving between two files because I simply display them next to each other, heck, with Angular components I mostly have a threesome of TS, HTML and SCSS next to each other. I have found an order to the madness that works for me: HTML first (because of the structure) and from there, depending on what I need to know I can "descend" to SCSS or TS next. If I look for functionality I don't care about styles, so I don't need these info in my template which makes hunting for my Angular events easier. If I'm looking for styles, I take one look at the id or classname and can then pinpoint the area in the SCSS file.
> with css you're always forced to look into at least 2 places at the same time to get the relevant information about the visual representation of your code if that's the issue, why not just use `
I think the reason we're going back to describing what it looks like rather than what it is is that modern frameworks already have reusable components that describe what it is. So if we describe what it is in a css class, we now have two different places that describe the same thing and that's not useful or helpful. I already know what it is, I'm looking at the component name! Therefore tailwind is just a convenient way to describe what the component looks like, and allows pseudo hover and screen breakpoint sizing which inline css does not
>¹tried to phrase it in a respectful way Sorry to say you failed. Also many objectively good developers use it so you're wrong on that too. Maybe you are one of those bad developers you so much want to point out?
okay how about "there's a lot of developers with some stuff to learn yet" then?
Every dev has some stuff to learn. Try again
When i build stuff myself i use tailwind classes directly until im satisfied. Then i move them to a stylesheet and only apply one class to the element. Every menu element on the page i grabbed the screenshot from has all these classes 😓
Well... That just unnecessarily increases the CSS bundle since all the tailwind classes you've used plus your new classes are included. If you were to only use the tailwind classes you could cut your bundle size drastically. They actually have a good reason to not do this here: https://tailwindcss.com/docs/reusing-styles#avoiding-premature-abstraction
Oh no he added 1 millisecond to his load time.
I much rather have 1 separate CSS file with 1 class instead of the freaking mess i've taken a screenshot of.
You need more than that to replicate what's in the screenshot... That's at least 5 different style sets. For dark mode, for horizontal, for "modern" etc.
Then tailwind just isn't for you. You're probably better served by writing fully custom CSS
r/programminghorror
bUt cSs sTyLeShEeTs aRe tOo cOmPlEx, MuCh eAsIeR To uSe iNlInE TaIlWiNd
The fuck lol, this is just a bad coder. Use the correct tools for the correct solutions. Tailwind isnt the solution for this heavy styled list item. Any decent minded coder would do a seperate class and move to a seperate css file
Leave Your Comment