A quick look at Tailwind CSS. 💬 Topics: - Working with CSS; - The benefits of Tailwind; - Utility classes; - Tailwind Configuration; - Tailwind Plugins; #tailwindcss #css
Комментарии • 83
Год назад+14
The dev world is really funny. I remember 6 years ago i was writing atomic css for a small project and i received so much hate from people working with me, "WHY U ARE NOT USING BEM BRO, THIS IS WRONG", i also loved typescript, received the same hate, and i really didn't liked react that much at the time(it's A LOT better now, but still not my favorite). Lesson: don't listen to the hype guys, just do what you like and you will be fine, the dev world is cyclic, you will be finding that the same things that we made back there will rise from the ashes slightly different, and will be the next revolutionary framework or methodology that will deliver the same result that the old ones 🎈🎈
I think one of the most powerful aspects of Tailwind is standardization, which is actually really important when you are running a development team. Rather than having to learn a bespoke CSS system (or deal with the pain of a lack thereof) everybody can learn the same thing once and it applies throughout the project. This is absolutely invaluable! Without some kind of standards in place, projects can quickly devolve into a muddled mess and styling is certainly no exception.
tailwind’s responsivity built-in is so helpful. its difficult to wrap my brain around ems and rems when im in the zone. im happy to let the css framework do it for me.
@SpiritEdits That is correct, and, in all fairness, 99% of the time you'll be using a templating system, regardless of the type of product you are building.
What is the difference between using a bunch os tailwind templates and just using normal css? I may be really dumb here, but the templates don't end up having the same issues with the normal casa classes, like names that are not meaningful, bad reusability and what not?
@@fexofenadinaGenerica Scaling is probaly issue. CSS can get large kinda fast. For example how many times you declare display: flex. And when you using utility system, in your css you have it only one time
@@fexofenadinaGenerica ruclips.net/video/lHZwlzOUOZ4/видео.html This video sum this up well :D nothing is perfect. Everything have advantages and disadvantages and depends on your project.
very good video, I love the explanation. what I still didn't know is, do tailwind package the needed css only or what? It would be nice if you complete this project and open the css generated by it
@pawmeowzing2906 Thank you for your feedback! So Tailwind will scan the project for the utility classes, and compute a resulting CSS file containing only the CSS that's needed. I'm planning to do a more in depth Tailwind video soon, and build a more complex app with it!
I appreciate sharing your thoughts on different css approaches and overview with well explained example of Tailwind. I'm now thinking what is the cost of adoption since you have mentioned steep learning curve and for which type of project Tailwind suites best, since Tailwind seems like a unique thing you will encounter on one project that requires writing your own design language (right?), you learn Tailwind and so has to everyone else, you move on another project that Tailwind is not suited for, but then do not spend time with plain CSS that you could have.
@user-ux9ye1iz5f very well stated! The cost of adoption is high, but it might be worth it if, indeed maintenance gets easier. I would be very curious to get some actual feedback from somebody working with Tailwind CSS in production, in a larger team (like 7-10 frontend devs).
I do not want to work anything else than with Tailwind in a project anymore. It gives you so much control over your design it's awesome. It's still low-level css, so you still need to know how to style with css. So skill-wise you won't hurt much. Steep learning curve wise I'm guessing because you're going to need to style your own buttons, inputs, etc. etc. but you have TailwindUI to give you a head start and is to me almost as easy as what a component library gives you out of the box.
Where I work they use tailwind for all their projects. Its amazing, it allows any developer to jump in and start programing with out having to worry about breaking everything. At first it looks messy, but once you get used to it its impossible to go back.
I also tried to interact with tailwind some time ago, but the syntax made me more reserved, and it seemed a bit strange at first glance. I'll give it another chance now :D Nice video 👍
@bikidas5473 I find CSS maintenance in large projects a real pain, regardless of the technique used. I am expecting that, with tailwind, at least you'd have some clear class name conventions, and css files will not grow as much. It'll definitely help if the UI / UX team create the wireframes / design specs with the tailwind css pros and cons in mind.
after seeing how some people use tailwind i can understand why they think maintenance is very time consuming, instead of creating components to wrap repeated markup they just litter their templates with the same button or container and end up with an insane amount of repetition
Yes, it’s absolutely critical make components out of things that are to be reused. The types of developers to just slap things together, however, will likely have maintenance issues regardless of what they are writing with that approach.
@@Adrian-eq8ch You are right! It is important to mention that you should always try to use your templating language (like I did with React and JSX) to avoid code duplication. @apply should be used only as a last resort, so, in theory, you should't add that many new classes.
What I really don't like with Tailwind is its classes stacking up in the HTML, creating huge unreadable HTML files. It reminds me of inline styling, I consider it is a bad practice. I didn't know the fact that you could have Tailwind in a CSS file, I need to try that 😉 Thanks for the great video as always!
@PierreChevallier Thank you for your feedback! Indeed, the HTML looks messier, and it feels like there is less separation of concerns. I guess this is the tradeoff for writing little to no css. 😅
I've taken to liking atomic CSS recently but not at all to Tailwind, instead of it I prefer to use my own utility classes powered by UnoCSS. I've based my design system on Tailwind (same naming conventions, many of the same classes) but I also implemented an automatic color system that handles light and dark variants automatically and replaced all rtl-based classes with logical ones. On top of that, since it is made with UnoCSS I also exposed a JavaScript core so my frontend can access automatic colors at runtime (for example when I need to draw to a canvas)
@starlederer this sounds pretty nice, but, I fear, you are running into the issue I'm also running into most of the time. Your system is powerful and scalable, but relies on subjective / personal rules only you can impose. Once multiple people start working on the same codebases, things tend to go south :(. The advantage of a tool like Tailwind, even though it might not be as coherent as your in-house built solution, is the larger adoption. Uno CSS looks interesting, but I never got the chance to play with it. Thanks for the suggestion!
@@BeliCsGROM UnoCSS is not a collection of utility classes but an engine that can power any collection of utility classes. You can make it behave very similarly to Tailwind, or you can make it completely different
@@awesome-coding Very true, I do have the privilege of working alone most of the time though and I am planning on documenting my UnoCSS preset just in case. On the side note, there is an UnoCSS preset that behaves almost the same as Tailwind, I actually don't get why the Tailwind team is still doing their own thing instead of building Tailwind on top of UnoCSS
@@starlederer Yeah, I know, the reason behind my kind of explanation is to motivate people to try it out. How it works under the hood, is it runtime generation or static file analysis is irrelevant at the point where someone never tried it.
I honestly have a hard time seeing how some of these utility classes are any better than having inline styles at it feels just as verbose. Sure inline styles cant handle @media, but when my component needs something like that I think it might be time to actually write some css.
Utility classes usually have more than one CSS rule associated with it. Take the `inset-0` class which is equivalent to setting the top, right, bottom and left margins to 0. So, while tailwind is verbose, is not as verbose as writing inline styles in my opinion.
Still not sold. Cons: - have to learn a new way to write css - no separation of concerns, you might even mix @apply with class names and make it even more difficult to scale, possible “pollute” the html with long classes which make the markup less readable - fixed breakpoints. obviously you can add your own breakpoints in css file to make the design fluid and not adaptive but then again this kinda defeats the purpose of it. - by learning a new more abstract way to write css you might lose your touch with plain old good css. There are already so many frond end developers that don’t understand the ins and outs of css. So if they opt-in into tailwind they might never learn proper css. Which is basic.. Am I missing something?!
Answering your points - learning tailwind is easier than learning css in the first place and the viscose extension gives you autocomplete which makes it very easy to find what you’re looking for. Besides, with any css fix you’re gonna need to learn something - separation of concerns is an outdated concept. I’ve always found having my html and css in one place a lot nicer to develop with since you don’t need to move around your ide - you can edit breakpoints in config - I hate writing css. With tailwind I don’t have to context switch as much. You can do 98% of what you need with pure tailwind without needing to touch css
@@hojdog I hear what you say to and I agree it’s easier but do you actually understand what you’re doing? That’s the issue… you abstract too much from css and knowing CSS is essential for a front end developer. I know CSS has dark parts but the same goes for JavaScript. You can learn react or svelte or whatever without prior knowledge in vanilla JS but is that the right way? You’re suggesting the same for CSS. I can accept that separation of concern can more that a personal preference. I don’t know how many different breakpoints you usually end up in a project but for me is for sure more 10. The designs I need to code everyday are requiring that level of polishing so everything works in all screen sizes. So having more than 5 in that config it starts to become tedious work. So I guess I’ll have to use a plain old css file and keep only the “basics” in my config. For the same reason, design requires it, I have to style things using at least 20 or more css properties. Again having 20 classes in my HTML it starts to turn ugly really fast… so @apply would help but I think @apply defeats the purpose of using tailwind in the first place. So I’m concluding that for me personally at least I don’t see the reason to use this framework and I’m kinda against it because I think CSS is an essential skill for a front end developer and I’m afraid as you said someone could start with tailwind and never actually learn how css are working under the hood.
@xphstos_ I agree with you - all frontend devs should have good CSS knowledge, and using a framework could cause people to stop learning the basics. However, don't you think we have the same issues with JavaScript as well? I've seen junior developers starting in Angular, and 2-3 years in not knowing what a promise is. This is awful from a theoretical perspective, but, in practice, those guys are efficient and performing well in their projects. So my point is that we should not dismiss a framework because it helps you avoid working with the basics. That is the appeal of any framework, and some would argue that with time passing by, and with software development advancing at a rapid pace, it might not be that smart to spend time and resources learning the basics. Clearly, CSS is still more then relevant, but we have a lor of such examples from the past: - allocating memory, handling references and garbage collection, which were a big thing in languages such as C / C++. For years developers had to handle all these on their own. Now, if you start with a language such as Java or JavaScript, most of the time you don't even care about things like these, and, even if you do care, you have limited control over them. - closer to us in the web world, DOM handling was a big thing until 2012ish. For years you would use plain JS or jQuery to move siblings around or update the contents of various dom elements. You had to carefully batch the dom reads and writes for performance reasons, and other considerations had to be taken into account. Now, if you start with a UI library / framework the chances are you have no idea what document.querrySelector or element.setAttribute are actually doing. This is not an argument in favor of Tailwind, but my thoughts about the usefulness of frameworks in general, and the overall direction of software development - we are gradually working on higher levels.
@@awesome-coding That's right! Can't say that you're wrong because that was almost the case with me and React. I had some knowledge with JS before I delved into React world and my retrospect is that I wish I had better understanding of the basics back in the day. It took me twice the time to understand some things in react just because my knowledge in basics was mediocre. It's always good to have frameworks cutting dev time in half but we should not forget to polish our skills in basics. But who knows what the "basics" will be in the near future... maybe the future developer would be the one who can describe best the functionality to an AI system.. without even write a single line of code! Sounds too farfetched but we've seen already ChatGPT fixing bugs and write code cleaner and faster than most of us.
I used tailwind for a couple of side projects. The reason why i liked it is also the reason why i stopped using it. To me tailwind is like a more performant, slightly more ergonomic way of doing inline styling. This simplifies some mental overhead, since just by watching ur template, u know exactly why something looks like it looks (if u can still see the forest through all the trees at least) But css is so much more powerful then only inline-styling. I guess u could make use of that power by making ur own utility classes, which i never got around too, but at that point you lose that security that tailwind provides. I mostly ended up combining tailwind with css-modules and was just as horrible of a DX. Now I got back to css-modules exclusively. I dislike all these css-files, writing those long names, having to switch in between files, but at least I don't feel like I am losing out on the power of css. Maybe I will go back at tw at some point and try out the custom utilities path, we will see. Imo styling is still an unresolved question.
@bigmistqke css modules with a module / component is the approach I'm usually taking. The most common issue I have here is that I'm trying to reuse rules, so I'm creating separate css utility files. Then my components are not really standalone anymore from a styling perspective, and slowly but surely it gets more appealing to write the rules in the general utility files than in the modules themselves... 😒🤦♂️
I love your channel but can you change the stock footage that you use? You reused it between videos like 10 times already and it's kind of distracting at this point.
@orabian I get what you are saying. I'm slowly building a collection of stock videos and photos, but it takes time because I'm paying for most of them. I'll try to diversify a little bit more in the future though.👍 Thank you for your feedback!
@@awesome-coding no problem! Your videos are very high quality and when I found your channel I thought that you were an already established creator. But turns out you are a relatively new channel with a very high quality of content. Keep it up!
I wish I could bring myself to like Tailwind, but... Heavens, I've never polluted my HTML so hard with classes. Dismissing the fact that Tailwind can ship out the class used only, is this the only reason why we suddenly find this acceptable again? People gave Bootstrap infinite amounts of s*** for it. And now we do that again... Sometimes I can't bring myself but loathe Frontend development. Not only is it often looked down upon in comparison to Backend, it's always subject to wild, wild changes and trends.
@Leimrey1985 I agree to some extent. I have a backend development background, and, I have to say that things are somewhat messy there as well. Just considering the Java world, you have Java as a primary language, but then people came up with languages such as Kotlin, Scala, or Groovy on top of the JVM. You'll see people loving some and hating others. Framework wise things are muddy as well. Sure, you have Spring as the "defacto" solution, but then you have people getting behind things such as Struts, Vaadin, Play or Grails. Oh, and btw, there are following the official "standard" only to some extent. If you want to go by the book and follow the pure JEE approach, you should go with Java Server Faces instead. And, by the way, JSF is a component based framework, which is a different paradigm than the request based architecture Spring uses. Do you want to talk servers? You have Tomcat, Tommy, Jetty, JBoss, Glassfish and more. Technically some o these are servlet containers while others are application servers, and, no, they are not the same thing, even though they all can run your application. Don't get me started on the database solutions and approaches. Sorry for venting about the Java space, but I believe the sh*t the frontend space is getting for not being standardised is not that fair. Al ecosystems have issues, the frontend / JS space a bit more than others just because of the lower barrier for entry, and the wider adoption.
@@awesome-coding Of course there is nothing entirely mess free. I've worked on Backend systems as well and yeah, things can be tricky. But as a spring developer you're rarely subjected to hot new tools that are new the new rage and if you don't adopt them you're being left out. Just by using Java, Spring, rabbitmq/kafka, Prometheus, Kubernetes, Helm and Docker you're basically openly invited into any job and basically left alone to your vices. Strong opinions exist in Backend too, but it comes with less baggage altogether. Compared to that, look at how many ways frontend development has changed. Static pages, spa, ssr, ssa and so forth. We're being hammered by Web frameworks that all seem to "know it better" and merely keep fragmenting an already tribalist community. Decision fatigue has definitely ruining me and I considering moving back to full Backend positions.
Personally don't like tailwind. I love CSS and writing my own. Building utility classes etc. That said I understand how powerful Tailwind can be. Especially in bigger teams. It's a standard that everyone can use, be maintained etc. Keeps it very simple. I also like keeping the HTML as clean as possible. Arguments for both and as much as I prefer just writing my own CSS. Tailwind definitely has a place and is very powerful.
@mundoSportsnetwork whats's your experience with in house css and utilities on the long run? Is it easy to scale and maintain rules in more complex projects / larger teams?
@@awesome-coding I have just finished a bootcamp. So haven't got any experience in huge teams yet. We did use it for some of the group projects. Both approaches worked well. I'm good at css so set up some utility classes and we all just used those and went out own ways with our own css by having a baseline. no issues. Same with when we used tailwind no issues, you are all using the same way to style and can be easy to help each other. ! I remember reading a post from a seasoned dev and he explained that Tailwind just standardised everything across the board. So different teams didn't have different utility classes etc. Plus when hiring people if they knew tailwind they could pretty much just pick up the styling right away. No need to look through the utility classes or understand the styling. I'm very fast and comfortable with my own CSS but I can appreciate going into a large team where everyone has to collaborate and write legible code which is quick and easy to understand tailwind is a great answer to that. Also depends on goals. I want to work for a place which does very complex/custom designs and builds most stuff from scratch. Fancy marketing websites that sort of thing really. I would imagine most of the code for each site is built from scratch or on a light started template because no one will be similar. But on the other end where you don't need that and its not some fancy site which has a more complex backend, large teams working on different features etc then tailwind is probably the solution with still like MUI etc to keep everything nice and neat!
I like vanilla CSS + SASS a lot. I really like Tailwind though and now prefer Tailwind for nearly everything. The only thing I prefer having is an indicator of what type of element it is, which, I would typically have in a classname before, otherwise I'd specify in an id, but i don't want to be bound by ensuring no duplicates, as i may have multiple of an item. Understanding that without utilities, tailwind relies more on modular element architecture like react to define the element by the file itself so that reusable components are defined once and their styles are defined within that element and not rewritten in the parent file. There is components which is a workaround for non-modular file architecture but this really is a key understanding. Also, I REALLY REALLY recommend this tailwind Udemy course. i'm taking it now and they go over advanced tailwind concepts thouroughtly but concisively. I'm not paid by them or have any affiliation but it's really good: www.udemy.com/course/tailwind-css-zero-to-hero/
@user-bz3cv9ck2l haha! I can relate. Definitely Tailwind has a "first perception" problem because the myriad of utility classes sprinkled in the code. @apply helps you with some of that pain, but, as any tool, it should be used with caution.
The dev world is really funny.
I remember 6 years ago i was writing atomic css for a small project and i received so much hate from people working with me, "WHY U ARE NOT USING BEM BRO, THIS IS WRONG", i also loved typescript, received the same hate, and i really didn't liked react that much at the time(it's A LOT better now, but still not my favorite).
Lesson: don't listen to the hype guys, just do what you like and you will be fine, the dev world is cyclic, you will be finding that the same things that we made back there will rise from the ashes slightly different, and will be the next revolutionary framework or methodology that will deliver the same result that the old ones 🎈🎈
Nice!
I use tailwind on all my projects now. It fits perfectly with component based UIs. For now I don’t see anything better
I think one of the most powerful aspects of Tailwind is standardization, which is actually really important when you are running a development team. Rather than having to learn a bespoke CSS system (or deal with the pain of a lack thereof) everybody can learn the same thing once and it applies throughout the project. This is absolutely invaluable! Without some kind of standards in place, projects can quickly devolve into a muddled mess and styling is certainly no exception.
@dustinwilson2311 well said! while in personal projects or small teams things might work, in large teams and complex projects standards are a must!
tailwind’s responsivity built-in is so helpful. its difficult to wrap my brain around ems and rems when im in the zone. im happy to let the css framework do it for me.
Great video! Would love to see more content on Tailwind.
Thank you! Yes - I will definitely incorporate it in most of my projects moving forward ✌️
I love how fast I can make a simple app for any repetitive task that I need to do using Sveltekit and Tailwind
It feels like Tailwind make much more sense while using somekind of templating system
@SpiritEdits That is correct, and, in all fairness, 99% of the time you'll be using a templating system, regardless of the type of product you are building.
What is the difference between using a bunch os tailwind templates and just using normal css? I may be really dumb here, but the templates don't end up having the same issues with the normal casa classes, like names that are not meaningful, bad reusability and what not?
@@fexofenadinaGenerica Scaling is probaly issue. CSS can get large kinda fast. For example how many times you declare display: flex. And when you using utility system, in your css you have it only one time
@@SpiritEdits you are right, it really is repetitive. So the real advantage of tailwind is like the advantage of using react or svelte. Interesting
@@fexofenadinaGenerica ruclips.net/video/lHZwlzOUOZ4/видео.html
This video sum this up well :D nothing is perfect. Everything have advantages and disadvantages and depends on your project.
very good video, I love the explanation.
what I still didn't know is, do tailwind package the needed css only or what?
It would be nice if you complete this project and open the css generated by it
@pawmeowzing2906 Thank you for your feedback!
So Tailwind will scan the project for the utility classes, and compute a resulting CSS file containing only the CSS that's needed.
I'm planning to do a more in depth Tailwind video soon, and build a more complex app with it!
I appreciate sharing your thoughts on different css approaches and overview with well explained example of Tailwind.
I'm now thinking what is the cost of adoption since you have mentioned steep learning curve and for which type of project Tailwind suites best, since Tailwind seems like a unique thing you will encounter on one project that requires writing your own design language (right?), you learn Tailwind and so has to everyone else, you move on another project that Tailwind is not suited for, but then do not spend time with plain CSS that you could have.
@user-ux9ye1iz5f very well stated!
The cost of adoption is high, but it might be worth it if, indeed maintenance gets easier.
I would be very curious to get some actual feedback from somebody working with Tailwind CSS in production, in a larger team (like 7-10 frontend devs).
I do not want to work anything else than with Tailwind in a project anymore. It gives you so much control over your design it's awesome. It's still low-level css, so you still need to know how to style with css. So skill-wise you won't hurt much. Steep learning curve wise I'm guessing because you're going to need to style your own buttons, inputs, etc. etc. but you have TailwindUI to give you a head start and is to me almost as easy as what a component library gives you out of the box.
Where I work they use tailwind for all their projects. Its amazing, it allows any developer to jump in and start programing with out having to worry about breaking everything. At first it looks messy, but once you get used to it its impossible to go back.
@@gabrielyea Thank you for your feedback!
I also tried to interact with tailwind some time ago, but the syntax made me more reserved, and it seemed a bit strange at first glance. I'll give it another chance now :D Nice video 👍
It definitely has a steeper learning curve, especially compared to other css tools. It is worth the effort though. Thanks for the feedback!
The key to use tailwind is of you want to make your layout fast, long term maintenance is surely a pain 😊
@bikidas5473 I find CSS maintenance in large projects a real pain, regardless of the technique used. I am expecting that, with tailwind, at least you'd have some clear class name conventions, and css files will not grow as much. It'll definitely help if the UI / UX team create the wireframes / design specs with the tailwind css pros and cons in mind.
Please explain all of its features
Will do in a future video!
OMG..sold!
Nothing is as good as TailwindCSS. 🔥
after seeing how some people use tailwind i can understand why they think maintenance is very time consuming, instead of creating components to wrap repeated markup they just litter their templates with the same button or container and end up with an insane amount of repetition
@aritark right! this is why I made a special point of discussing @apply and templating in the video
Yes, it’s absolutely critical make components out of things that are to be reused. The types of developers to just slap things together, however, will likely have maintenance issues regardless of what they are writing with that approach.
@@awesome-coding Won't using @apply turn into the problem you described in 01:46 down the line?
@@Adrian-eq8ch You are right! It is important to mention that you should always try to use your templating language (like I did with React and JSX) to avoid code duplication. @apply should be used only as a last resort, so, in theory, you should't add that many new classes.
What I really don't like with Tailwind is its classes stacking up in the HTML, creating huge unreadable HTML files. It reminds me of inline styling, I consider it is a bad practice. I didn't know the fact that you could have Tailwind in a CSS file, I need to try that 😉 Thanks for the great video as always!
@PierreChevallier Thank you for your feedback!
Indeed, the HTML looks messier, and it feels like there is less separation of concerns.
I guess this is the tradeoff for writing little to no css. 😅
I've taken to liking atomic CSS recently but not at all to Tailwind, instead of it I prefer to use my own utility classes powered by UnoCSS.
I've based my design system on Tailwind (same naming conventions, many of the same classes) but I also implemented an automatic color system that handles light and dark variants automatically and replaced all rtl-based classes with logical ones. On top of that, since it is made with UnoCSS I also exposed a JavaScript core so my frontend can access automatic colors at runtime (for example when I need to draw to a canvas)
@starlederer this sounds pretty nice, but, I fear, you are running into the issue I'm also running into most of the time. Your system is powerful and scalable, but relies on subjective / personal rules only you can impose. Once multiple people start working on the same codebases, things tend to go south :(. The advantage of a tool like Tailwind, even though it might not be as coherent as your in-house built solution, is the larger adoption.
Uno CSS looks interesting, but I never got the chance to play with it. Thanks for the suggestion!
UnoCSS is tailwind on steroids, it should not be a problem for someone who knows tailwind to addapt.
@@BeliCsGROM UnoCSS is not a collection of utility classes but an engine that can power any collection of utility classes. You can make it behave very similarly to Tailwind, or you can make it completely different
@@awesome-coding Very true, I do have the privilege of working alone most of the time though and I am planning on documenting my UnoCSS preset just in case.
On the side note, there is an UnoCSS preset that behaves almost the same as Tailwind, I actually don't get why the Tailwind team is still doing their own thing instead of building Tailwind on top of UnoCSS
@@starlederer Yeah, I know, the reason behind my kind of explanation is to motivate people to try it out. How it works under the hood, is it runtime generation or static file analysis is irrelevant at the point where someone never tried it.
I honestly have a hard time seeing how some of these utility classes are any better than having inline styles at it feels just as verbose. Sure inline styles cant handle @media, but when my component needs something like that I think it might be time to actually write some css.
Utility classes usually have more than one CSS rule associated with it. Take the `inset-0` class which is equivalent to setting the top, right, bottom and left margins to 0.
So, while tailwind is verbose, is not as verbose as writing inline styles in my opinion.
Chakra ui👍
Still not sold.
Cons:
- have to learn a new way to write css
- no separation of concerns, you might even mix @apply with class names and make it even more difficult to scale, possible “pollute” the html with long classes which make the markup less readable
- fixed breakpoints. obviously you can add your own breakpoints in css file to make the design fluid and not adaptive but then again this kinda defeats the purpose of it.
- by learning a new more abstract way to write css you might lose your touch with plain old good css. There are already so many frond end developers that don’t understand the ins and outs of css. So if they opt-in into tailwind they might never learn proper css. Which is basic..
Am I missing something?!
Answering your points
- learning tailwind is easier than learning css in the first place and the viscose extension gives you autocomplete which makes it very easy to find what you’re looking for. Besides, with any css fix you’re gonna need to learn something
- separation of concerns is an outdated concept. I’ve always found having my html and css in one place a lot nicer to develop with since you don’t need to move around your ide
- you can edit breakpoints in config
- I hate writing css. With tailwind I don’t have to context switch as much. You can do 98% of what you need with pure tailwind without needing to touch css
@@hojdog I hear what you say to and I agree it’s easier but do you actually understand what you’re doing? That’s the issue… you abstract too much from css and knowing CSS is essential for a front end developer. I know CSS has dark parts but the same goes for JavaScript. You can learn react or svelte or whatever without prior knowledge in vanilla JS but is that the right way? You’re suggesting the same for CSS.
I can accept that separation of concern can more that a personal preference.
I don’t know how many different breakpoints you usually end up in a project but for me is for sure more 10.
The designs I need to code everyday are requiring that level of polishing so everything works in all screen sizes.
So having more than 5 in that config it starts to become tedious work. So I guess I’ll have to use a plain old css file and keep only the “basics” in my config.
For the same reason, design requires it, I have to style things using at least 20 or more css properties. Again having 20 classes in my HTML it starts to turn ugly really fast… so @apply would help but I think @apply defeats the purpose of using tailwind in the first place.
So I’m concluding that for me personally at least I don’t see the reason to use this framework and I’m kinda against it because I think CSS is an essential skill for a front end developer and I’m afraid as you said someone could start with tailwind and never actually learn how css are working under the hood.
@xphstos_ I agree with you - all frontend devs should have good CSS knowledge, and using a framework could cause people to stop learning the basics. However, don't you think we have the same issues with JavaScript as well? I've seen junior developers starting in Angular, and 2-3 years in not knowing what a promise is. This is awful from a theoretical perspective, but, in practice, those guys are efficient and performing well in their projects.
So my point is that we should not dismiss a framework because it helps you avoid working with the basics. That is the appeal of any framework, and some would argue that with time passing by, and with software development advancing at a rapid pace, it might not be that smart to spend time and resources learning the basics. Clearly, CSS is still more then relevant, but we have a lor of such examples from the past:
- allocating memory, handling references and garbage collection, which were a big thing in languages such as C / C++. For years developers had to handle all these on their own. Now, if you start with a language such as Java or JavaScript, most of the time you don't even care about things like these, and, even if you do care, you have limited control over them.
- closer to us in the web world, DOM handling was a big thing until 2012ish. For years you would use plain JS or jQuery to move siblings around or update the contents of various dom elements. You had to carefully batch the dom reads and writes for performance reasons, and other considerations had to be taken into account. Now, if you start with a UI library / framework the chances are you have no idea what document.querrySelector or element.setAttribute are actually doing.
This is not an argument in favor of Tailwind, but my thoughts about the usefulness of frameworks in general, and the overall direction of software development - we are gradually working on higher levels.
@@awesome-coding That's right!
Can't say that you're wrong because that was almost the case with me and React.
I had some knowledge with JS before I delved into React world and my retrospect is that I wish I had better understanding of the basics back in the day.
It took me twice the time to understand some things in react just because my knowledge in basics was mediocre.
It's always good to have frameworks cutting dev time in half but we should not forget to polish our skills in basics.
But who knows what the "basics" will be in the near future... maybe the future developer would be the one who can describe best the functionality to an AI system.. without even write a single line of code!
Sounds too farfetched but we've seen already ChatGPT fixing bugs and write code cleaner and faster than most of us.
I used tailwind for a couple of side projects. The reason why i liked it is also the reason why i stopped using it. To me tailwind is like a more performant, slightly more ergonomic way of doing inline styling. This simplifies some mental overhead, since just by watching ur template, u know exactly why something looks like it looks (if u can still see the forest through all the trees at least) But css is so much more powerful then only inline-styling.
I guess u could make use of that power by making ur own utility classes, which i never got around too, but at that point you lose that security that tailwind provides. I mostly ended up combining tailwind with css-modules and was just as horrible of a DX.
Now I got back to css-modules exclusively. I dislike all these css-files, writing those long names, having to switch in between files, but at least I don't feel like I am losing out on the power of css.
Maybe I will go back at tw at some point and try out the custom utilities path, we will see. Imo styling is still an unresolved question.
@bigmistqke css modules with a module / component is the approach I'm usually taking. The most common issue I have here is that I'm trying to reuse rules, so I'm creating separate css utility files. Then my components are not really standalone anymore from a styling perspective, and slowly but surely it gets more appealing to write the rules in the general utility files than in the modules themselves... 😒🤦♂️
Personally, for me it's pointless either way. I'm awful at design, so I just stick with component libraries. Favourite at the moment is Mantine.
Fair enough! :D Thanks for the Mantine suggestion!
I love your channel but can you change the stock footage that you use? You reused it between videos like 10 times already and it's kind of distracting at this point.
@orabian I get what you are saying. I'm slowly building a collection of stock videos and photos, but it takes time because I'm paying for most of them. I'll try to diversify a little bit more in the future though.👍
Thank you for your feedback!
@@awesome-coding no problem! Your videos are very high quality and when I found your channel I thought that you were an already established creator. But turns out you are a relatively new channel with a very high quality of content. Keep it up!
@@InfiniteRain_ Thank you for the kind words!
I wish I could bring myself to like Tailwind, but... Heavens, I've never polluted my HTML so hard with classes. Dismissing the fact that Tailwind can ship out the class used only, is this the only reason why we suddenly find this acceptable again? People gave Bootstrap infinite amounts of s*** for it. And now we do that again... Sometimes I can't bring myself but loathe Frontend development. Not only is it often looked down upon in comparison to Backend, it's always subject to wild, wild changes and trends.
Why not use @apply?
@@ful_kush seems deprecated
@@ful_kush proving my point about fast changing. @apply is deprecated and even before that tailwind Devs heavily discouraged the use of it.
@Leimrey1985 I agree to some extent. I have a backend development background, and, I have to say that things are somewhat messy there as well.
Just considering the Java world, you have Java as a primary language, but then people came up with languages such as Kotlin, Scala, or Groovy on top of the JVM. You'll see people loving some and hating others.
Framework wise things are muddy as well. Sure, you have Spring as the "defacto" solution, but then you have people getting behind things such as Struts, Vaadin, Play or Grails. Oh, and btw, there are following the official "standard" only to some extent. If you want to go by the book and follow the pure JEE approach, you should go with Java Server Faces instead. And, by the way, JSF is a component based framework, which is a different paradigm than the request based architecture Spring uses.
Do you want to talk servers? You have Tomcat, Tommy, Jetty, JBoss, Glassfish and more. Technically some o these are servlet containers while others are application servers, and, no, they are not the same thing, even though they all can run your application.
Don't get me started on the database solutions and approaches.
Sorry for venting about the Java space, but I believe the sh*t the frontend space is getting for not being standardised is not that fair. Al ecosystems have issues, the frontend / JS space a bit more than others just because of the lower barrier for entry, and the wider adoption.
@@awesome-coding Of course there is nothing entirely mess free. I've worked on Backend systems as well and yeah, things can be tricky. But as a spring developer you're rarely subjected to hot new tools that are new the new rage and if you don't adopt them you're being left out. Just by using Java, Spring, rabbitmq/kafka, Prometheus, Kubernetes, Helm and Docker you're basically openly invited into any job and basically left alone to your vices. Strong opinions exist in Backend too, but it comes with less baggage altogether. Compared to that, look at how many ways frontend development has changed. Static pages, spa, ssr, ssa and so forth. We're being hammered by Web frameworks that all seem to "know it better" and merely keep fragmenting an already tribalist community. Decision fatigue has definitely ruining me and I considering moving back to full Backend positions.
Tailwind is better, try using it for a few months and then go back to normal CSS it is very frustrating
Personally don't like tailwind. I love CSS and writing my own. Building utility classes etc.
That said I understand how powerful Tailwind can be. Especially in bigger teams. It's a standard that everyone can use, be maintained etc. Keeps it very simple.
I also like keeping the HTML as clean as possible.
Arguments for both and as much as I prefer just writing my own CSS. Tailwind definitely has a place and is very powerful.
@mundoSportsnetwork whats's your experience with in house css and utilities on the long run? Is it easy to scale and maintain rules in more complex projects / larger teams?
@@awesome-coding I have just finished a bootcamp. So haven't got any experience in huge teams yet.
We did use it for some of the group projects.
Both approaches worked well. I'm good at css so set up some utility classes and we all just used those and went out own ways with our own css by having a baseline. no issues.
Same with when we used tailwind no issues, you are all using the same way to style and can be easy to help each other. !
I remember reading a post from a seasoned dev and he explained that Tailwind just standardised everything across the board. So different teams didn't have different utility classes etc. Plus when hiring people if they knew tailwind they could pretty much just pick up the styling right away. No need to look through the utility classes or understand the styling.
I'm very fast and comfortable with my own CSS but I can appreciate going into a large team where everyone has to collaborate and write legible code which is quick and easy to understand tailwind is a great answer to that.
Also depends on goals. I want to work for a place which does very complex/custom designs and builds most stuff from scratch. Fancy marketing websites that sort of thing really. I would imagine most of the code for each site is built from scratch or on a light started template because no one will be similar.
But on the other end where you don't need that and its not some fancy site which has a more complex backend, large teams working on different features etc then tailwind is probably the solution with still like MUI etc to keep everything nice and neat!
@@ShredBundy420 Thank you for your response!
you are like 1 year late
better late than never ✌️
I like vanilla CSS + SASS a lot. I really like Tailwind though and now prefer Tailwind for nearly everything. The only thing I prefer having is an indicator of what type of element it is, which, I would typically have in a classname before, otherwise I'd specify in an id, but i don't want to be bound by ensuring no duplicates, as i may have multiple of an item. Understanding that without utilities, tailwind relies more on modular element architecture like react to define the element by the file itself so that reusable components are defined once and their styles are defined within that element and not rewritten in the parent file. There is components which is a workaround for non-modular file architecture but this really is a key understanding. Also, I REALLY REALLY recommend this tailwind Udemy course. i'm taking it now and they go over advanced tailwind concepts thouroughtly but concisively. I'm not paid by them or have any affiliation but it's really good: www.udemy.com/course/tailwind-css-zero-to-hero/
Thank you for your suggestion!
I hated tailwind, then I found @apply
@user-bz3cv9ck2l haha! I can relate. Definitely Tailwind has a "first perception" problem because the myriad of utility classes sprinkled in the code.
@apply helps you with some of that pain, but, as any tool, it should be used with caution.