It's explaining the same things in slightly different ways. I still don't think that my points are fully addressed within the first few dozen comments. In-fact, one of the prevailingly common comments in that thread is that it makes styling easier for non-CSS developers, which to me is an indication that those developers don't care about the quality of the CSS (how can they if they don't know CSS and aren't actually writing it?).
It might work fine for them, but it's a bit like using a hammer to force screws into wood. Over time the workmanship of the whole thing will suffer.
However, I see we will never agree about the merits of Tailwind, and that's the great thing about this kind of technology, the very fact that we can disagree on the tech ultimately means that we get better tech in the future.
But if you look at bootstrap the most popular css framework, you will notice that it is mixing the styles and the html template too.
When using bootstrap, you put bootstrap's style classes into the html. So it is not fair to say that tailwind is bad because it is violating the separation of concerns.
Being a hard core backend developer and trying to write clean code, you may hesitate to use tailwind and its utility approach. But more and more people, are coming to enjoy utility approach. Most ui frameworks are based on utility first approach.
However, when building my own site, I did not use any ui framework. I tried to do it in the cleanest way so chose to do it with scss + flexbox + BEM. Not many irrelevant style classes. But I have to say this approach may take more time.
Not quite. Dependecies of anything should be limited to one way. It's quite ridiculous to be specifying so many classes in the HTML for styling, and it means that it a) doesn't lend itself very well to a component based system and b) ties itself too closely to Tailwind, meaning it's almost impossible to break from it cleanly in the future unless you create something that mirrors the exact behavior of Tailwind.
Oh, and as for the filesize of Tailwind: over 1½MB uncompressed. That's way too much for the browser to be expected to parse on a low end mobile device.
Ashley Sheridan, I find your angle about saying that hmtl/css/js to be separated is fairly incomplete. If you think about everything that exists in any decent piece of software, then everything is a tree of components (or views, or divs or whatever you call them) and these things will have some associated styling perhaps, some logic perhaps etc)
It makes most sense for these things, if they exist in one place, to be defined in the component. What you then want is a mechanism for moving styling or logic to a more global place, if it makes sense to. But lots of the time, it makes sense to have it next to the place that it's needed.
Separating for the sake of it is like just introducing a service orientated architecture or micro services, just because.
Also, it's like organising by technology, rather than by feature, which I think makes a lot more sense. A big folder of all controllers or views (as many frameworks organise) doesn't really make sense to me, once you've done a lot of organising by feature.
Ashley, this talk clarifies Vasyl's points. They specifically address separation of concerns, clarifying that even CSS garden isn't separated as you believe. Because although the html has no awareness of the css, the css is fully aware of the html. Should the html change, the css breaks.
I started listening to the talk as a skeptic, and it really cleared things up for me.
It's explaining the same things in slightly different ways. I still don't think that my points are fully addressed within the first few dozen comments. In-fact, one of the prevailingly common comments in that thread is that it makes styling easier for non-CSS developers, which to me is an indication that those developers don't care about the quality of the CSS (how can they if they don't know CSS and aren't actually writing it?).
It might work fine for them, but it's a bit like using a hammer to force screws into wood. Over time the workmanship of the whole thing will suffer.
However, I see we will never agree about the merits of Tailwind, and that's the great thing about this kind of technology, the very fact that we can disagree on the tech ultimately means that we get better tech in the future.
Yes, It is good to separate concerns.
But if you look at bootstrap the most popular css framework, you will notice that it is mixing the styles and the html template too.
When using bootstrap, you put bootstrap's style classes into the html. So it is not fair to say that tailwind is bad because it is violating the separation of concerns.
Being a hard core backend developer and trying to write clean code, you may hesitate to use tailwind and its utility approach. But more and more people, are coming to enjoy utility approach. Most ui frameworks are based on utility first approach.
However, when building my own site, I did not use any ui framework. I tried to do it in the cleanest way so chose to do it with scss + flexbox + BEM. Not many irrelevant style classes. But I have to say this approach may take more time.
Again and again and again people think that CSS or HTML are concerns. Remember.
A concern is synonymous to the word feature. (See Wikipedia for example.)
Your need to separate FEATURES, not technologies.
Not quite. Dependecies of anything should be limited to one way. It's quite ridiculous to be specifying so many classes in the HTML for styling, and it means that it a) doesn't lend itself very well to a component based system and b) ties itself too closely to Tailwind, meaning it's almost impossible to break from it cleanly in the future unless you create something that mirrors the exact behavior of Tailwind.
Oh, and as for the filesize of Tailwind: over 1½MB uncompressed. That's way too much for the browser to be expected to parse on a low end mobile device.
50kb is my uncompressed Tailwind file. Because Tailwind goes together with PurgeCSS.
Mate, I beg you. Just google it before writing this nonsense. This is basics.
Ashley Sheridan, I find your angle about saying that hmtl/css/js to be separated is fairly incomplete. If you think about everything that exists in any decent piece of software, then everything is a tree of components (or views, or divs or whatever you call them) and these things will have some associated styling perhaps, some logic perhaps etc)
It makes most sense for these things, if they exist in one place, to be defined in the component. What you then want is a mechanism for moving styling or logic to a more global place, if it makes sense to. But lots of the time, it makes sense to have it next to the place that it's needed.
Separating for the sake of it is like just introducing a service orientated architecture or micro services, just because.
Also, it's like organising by technology, rather than by feature, which I think makes a lot more sense. A big folder of all controllers or views (as many frameworks organise) doesn't really make sense to me, once you've done a lot of organising by feature.
Ashley, this talk clarifies Vasyl's points. They specifically address separation of concerns, clarifying that even CSS garden isn't separated as you believe. Because although the html has no awareness of the css, the css is fully aware of the html. Should the html change, the css breaks.
I started listening to the talk as a skeptic, and it really cleared things up for me.
youtu.be/R50q4NES6Iw