Edit: Maybe I should add the fact that I moved my personal website from Bulma to Tailwind CSS which was 12726 lines of CSS to 805 lines of CSS. Which made my stylesheet go down from 247.1kb to 13kb. I already have had tried to use the minimum possible in Bulma. With Tailwind CSS load only the used CSS.
As a perfectionist, I am very picky when it comes to my choice of an abstraction layer. Tailwind CSS has been a great abstraction layer IMO. I wrote about it here as well - dev.to/unsungnovelty/explaining-wh....
But our job, as developers, is to do exactly that. Translate business requirements and domain knowledge to code, without ambiguity and without context loss.
This. Our job's to translate things to solutions. HOW we do it is irrelevant. A lot of companies (Especially VC funded), nor the end users care which tool we used. All they could care is whether they get what they want, the way they want it, by the time they want it. That is it.
But... It's hard
There is also something called Pit of success which was coined by Jeff Atwood. CSS is a perfect example of a tool which instead of directing you towards pit of success, directs you towards pit of despair. In short, a tool/technology/language by default should make it hard for you to fail and direct you towards success. And CSS is an example of pit of despair. And IMO, Tailwind CSS makes it much more manageable.
I love CSS as a technology. When I have time, I still write plain CSS to brush up my skills. I love CSS Grid a lot. But I would be lying if I say CSS is not a PITA. Also, Tailwind CSS still makes you think in CSS as I mentioned in the blog. Unlike component based CSS frameworks, for working with Tailwind CSS, you still need to know some CSS at least. And as you work with it, Tailwind CSS helps you learn plain CSS. Whereas component based CSS frameworks like bootstrap and bulma makes you forget what you know in CSS. It is far better than navbar classes IMO.
Personally I understand where you are coming from. At least I think I do. Cos I used to think similarly. But it's all about balance. And the right tool is extremely subjective based on your requirements and the time you have to name a few. :)
Unlike component based CSS frameworks, for working with Tailwind CSS, you still need to know some CSS at least. And as you work with it, Tailwind CSS helps you learn plain CSS.
This is something I've experienced too. I've even found myself going back to Tailwind's docs for looking up something about how CSS works (e.g. the different parts of flexbox).
A lot of companies (Especially VC funded), nor the end users care which tool we used
This is the biggest part of the problem I've personally experienced. If they don't care, we're the only ones remaining who should still do, ideally. I don't suggest throwing out all existing frameworks right now and going Vanilla. I just advocate for using it more, improving it or at least trying to stick to best practices. Because clearly, the direction we're going right now is concerning.
I agree that it's all about balance, and using the right tool for the job.
I just advocate for using it more, improving it or at least trying to stick to best practices. Because clearly, the direction we're going right now is concerning.
That is a good POV. End goal being plain CSS. The utility classes does crowd HTML markup. Which is my only problem with Tailwind CSS so far. But developer experience Tailwind CSS provides is better for me though. And with components based frameworks like Bootstrap, I pay a lot in performance.
With Tailwind CSS, I bundle only what I use. So as a dev, I am more happy thanks to the developer experience (DX) and performance. So the truth is, at least for a some time, I don't see a reason to go back to plain CSS or component based frameworks.
Yes, tailwind can be nice for POC.
Although, tailwind let's you forget how to name things properly, and adds a big mess of obfuscated elements, and thus should never be used in production or just projects that scale.
I agree with the markup getting crowded with the utility classes. While it is not recommend IIRC, you can create components and redirect it to a class name and use Tailwind CSS that way. But this issue and naming convention which is not needed cos you are not using components anymore anyways against:
Better DX (If you know CSS). You definitely need to know CSS for this framework unlike Bulma.
High performance. Load only used CSS. Nothing more or less.
Rapid UI development.
Knowledge transfer from CSS to Tailwind CSS is very less. You are not learning a whole new set of class names and how to use it. Instead you are translating it to well selected utility classes which provides a well designed design API. To me utility classes are aliases of CSS properties, for most part.
Learn CSS while using Tailwind CSS. This is just bonkers. I can't say this for any CSS framework.
You can configure the framework extensively. and use CSS properties which are not natively supported by Tailwind CSS. You can also use any values with any units you want even though your utility class doesn't have that value.
This means, if I want to use a CSS property which is not yet supported in Tailwind CSS,
I can use it like [clip-path:circle(50%)]. Voila! I just used clip-path property which is not supported in tailwind CSS. Configuring a CSS framework is a long and bumpy road in other frameworks. Also, it kills the whole point of using a framework because of the way it is designed.
Also the same way, I can use any values with any units with a utility class like
For width, w-[80%] or w-[90rem]. This means I can use a value outside of the default width values natively without hacks.
I don't know about you. For me pros outweighs the cons. You get the best of both worlds. A framework's convenience and CSS's performance. If you are using a CSS framework today, Tailwind CSS is one of the best if not the best. Like I said earlier, there is always a price to pay with abstractions. It is up to you to see if the pros outweighs your cons for your project/product. If it does, you should use it and don't, if it doesn't. :)
I currently work as a software developer with OneCare Media (https://www.onecare.com/). When I'm not coding I enjoy going for walks, watching sports, and karaoke.
Location
Redmond, WA, USA
Work
Senior Frontend Developer at Microsoft Contractor with TEKsystems
Nikhil,
You mentioned "Our job's to translate things to solutions. HOW we do it is irrelevant.".
I wouldn't quick necessarily agree with that because if dev A creates very confusing, hard-to-update code when dev B is working on it that's an issue.
However, if dev A creates code that is considered a "hack" by some developers but still gets the job done and isn't dangerous and dev B can update it that's OK.
I think you missed an important part which went along with the quoted statement. I said it is irrelevant to the employers and end users. I wasn't talking about developers.
The scenarios that you mentioned as well, both the scenarios are relevant to the developers. Not necessarily for the employers or end users as I mentioned earlier.
A website with the mentioned first scenario can succeed and the second scenario can fail if the translation of solutions and business doesn't go well. Also vice versa. I definitely agree with you on the fact that the developers should write clean and understandable code. And that we should avoid magic and hacks as much as possible.
But with regards to the topic at hand, I don't think Tailwind CSS is a hack. Also, it actually teaches plain CSS and provides performance while doing it. I cannot say the same for component based CSS frameworks which are always a performance hog and makes you forget plain CSS. They only provide performance value when they can be utilised to the max, which mostly will be in a large project. Otherwise there is a performance tax.
Apart from the utility classes crowding the markup, I don't see any problem here. Not to mention if you want, you can make those into components and use it that way. The official typography plugin also provides sane defaults to many html elements through prose utility class. So for me, the pros outweighs the cons by many a mile. But that is just my use case. I don't think one abstraction layer can make everyone happy. And that is fine. It's the same reason why we have many choices. :)
I currently work as a software developer with OneCare Media (https://www.onecare.com/). When I'm not coding I enjoy going for walks, watching sports, and karaoke.
Location
Redmond, WA, USA
Work
Senior Frontend Developer at Microsoft Contractor with TEKsystems
I heard you say "Our job's to translate things to solutions. HOW we do it is irrelevant." Yet, I still believe that code solutions are still relevant to managers if trying to edit or add to the current code is extremely difficult and time confusing.
So yes, managers should definitely know in a general and easy-to-understand way if a previously created code is time confusing to add to or edit.
But, if code is structured in a way that's easy to edit and can be scaled up, then managers don't need to know as many details.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Edit: Maybe I should add the fact that I moved my personal website from Bulma to Tailwind CSS which was 12726 lines of CSS to 805 lines of CSS. Which made my stylesheet go down from 247.1kb to 13kb. I already have had tried to use the minimum possible in Bulma. With Tailwind CSS load only the used CSS.
As a perfectionist, I am very picky when it comes to my choice of an abstraction layer. Tailwind CSS has been a great abstraction layer IMO. I wrote about it here as well - dev.to/unsungnovelty/explaining-wh....
This. Our job's to translate things to solutions. HOW we do it is irrelevant. A lot of companies (Especially VC funded), nor the end users care which tool we used. All they could care is whether they get what they want, the way they want it, by the time they want it. That is it.
There is also something called Pit of success which was coined by Jeff Atwood. CSS is a perfect example of a tool which instead of directing you towards pit of success, directs you towards pit of despair. In short, a tool/technology/language by default should make it hard for you to fail and direct you towards success. And CSS is an example of pit of despair. And IMO, Tailwind CSS makes it much more manageable.
I love CSS as a technology. When I have time, I still write plain CSS to brush up my skills. I love CSS Grid a lot. But I would be lying if I say CSS is not a PITA. Also, Tailwind CSS still makes you think in CSS as I mentioned in the blog. Unlike component based CSS frameworks, for working with Tailwind CSS, you still need to know some CSS at least. And as you work with it, Tailwind CSS helps you learn plain CSS. Whereas component based CSS frameworks like bootstrap and bulma makes you forget what you know in CSS. It is far better than
navbarclasses IMO.Personally I understand where you are coming from. At least I think I do. Cos I used to think similarly. But it's all about balance. And the right tool is extremely subjective based on your requirements and the time you have to name a few. :)
This is something I've experienced too. I've even found myself going back to Tailwind's docs for looking up something about how CSS works (e.g. the different parts of flexbox).
This is the biggest part of the problem I've personally experienced. If they don't care, we're the only ones remaining who should still do, ideally. I don't suggest throwing out all existing frameworks right now and going Vanilla. I just advocate for using it more, improving it or at least trying to stick to best practices. Because clearly, the direction we're going right now is concerning.
I agree that it's all about balance, and using the right tool for the job.
That is a good POV. End goal being plain CSS. The utility classes does crowd HTML markup. Which is my only problem with Tailwind CSS so far. But developer experience Tailwind CSS provides is better for me though. And with components based frameworks like Bootstrap, I pay a lot in performance.
With Tailwind CSS, I bundle only what I use. So as a dev, I am more happy thanks to the developer experience (DX) and performance. So the truth is, at least for a some time, I don't see a reason to go back to plain CSS or component based frameworks.
Yes, tailwind can be nice for POC.
Although, tailwind let's you forget how to name things properly, and adds a big mess of obfuscated elements, and thus should never be used in production or just projects that scale.
I agree with the markup getting crowded with the utility classes. While it is not recommend IIRC, you can create components and redirect it to a class name and use Tailwind CSS that way. But this issue and naming convention which is not needed cos you are not using components anymore anyways against:
This means, if I want to use a CSS property which is not yet supported in Tailwind CSS,
[clip-path:circle(50%)]. Voila! I just usedclip-pathproperty which is not supported in tailwind CSS. Configuring a CSS framework is a long and bumpy road in other frameworks. Also, it kills the whole point of using a framework because of the way it is designed.Also the same way, I can use any values with any units with a utility class like
w-[80%]orw-[90rem]. This means I can use a value outside of the default width values natively without hacks.I don't know about you. For me pros outweighs the cons. You get the best of both worlds. A framework's convenience and CSS's performance. If you are using a CSS framework today, Tailwind CSS is one of the best if not the best. Like I said earlier, there is always a price to pay with abstractions. It is up to you to see if the pros outweighs your cons for your project/product. If it does, you should use it and don't, if it doesn't. :)
A self-proclaimed perfectionist uses “Cos”; oh the irony! 😉
I completely missed this comment! :D
Nikhil,
You mentioned "Our job's to translate things to solutions. HOW we do it is irrelevant.".
I wouldn't quick necessarily agree with that because if dev A creates very confusing, hard-to-update code when dev B is working on it that's an issue.
However, if dev A creates code that is considered a "hack" by some developers but still gets the job done and isn't dangerous and dev B can update it that's OK.
Hey Matt,
I think you missed an important part which went along with the quoted statement. I said it is irrelevant to the employers and end users. I wasn't talking about developers.
The scenarios that you mentioned as well, both the scenarios are relevant to the developers. Not necessarily for the employers or end users as I mentioned earlier.
A website with the mentioned first scenario can succeed and the second scenario can fail if the translation of solutions and business doesn't go well. Also vice versa. I definitely agree with you on the fact that the developers should write clean and understandable code. And that we should avoid magic and hacks as much as possible.
But with regards to the topic at hand, I don't think Tailwind CSS is a hack. Also, it actually teaches plain CSS and provides performance while doing it. I cannot say the same for component based CSS frameworks which are always a performance hog and makes you forget plain CSS. They only provide performance value when they can be utilised to the max, which mostly will be in a large project. Otherwise there is a performance tax.
Apart from the utility classes crowding the markup, I don't see any problem here. Not to mention if you want, you can make those into components and use it that way. The official typography plugin also provides sane defaults to many html elements through
proseutility class. So for me, the pros outweighs the cons by many a mile. But that is just my use case. I don't think one abstraction layer can make everyone happy. And that is fine. It's the same reason why we have many choices. :)Hi Nikhil,
I heard you say "Our job's to translate things to solutions. HOW we do it is irrelevant." Yet, I still believe that code solutions are still relevant to managers if trying to edit or add to the current code is extremely difficult and time confusing.
So yes, managers should definitely know in a general and easy-to-understand way if a previously created code is time confusing to add to or edit.
But, if code is structured in a way that's easy to edit and can be scaled up, then managers don't need to know as many details.