As a backend dev, don't you find this violates separation of concerns? The HTML should have no knowledge or care about the appearance it has, which Tailwind classes do. However, Tailwind could be used if you're using a preprocessor like SASS or LESS, using classes in the HTML that describe the element/component and then building your CSS based on extending the Tailwind styles.
Hey mate. Just found this little tweet for you. It's doing a better job to explain things than me in this thread. twitter.com/drewm/status/122940127...
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.
I'm not sure if anybody already posted this but here is a link to a blog post of the author of tailwind css explaining why "Separation of Concerns" is a Strawman in his opinion and how he got from the "traditional" way of handling styling to utility first classes: adamwathan.me/css-utility-classes-...
It is a very convincing read and totally reflects how I feel about the topic given the years I spend developing web applications.
You should give tailwind css a try on your next side project.
I did read it, but I'm still not convinced. Even just looking at the CSS that results on the Tailwind site there seems like too much, coming in at 144kB uncompressed. While that's not as bad as some of the sites that seem to be using the full Tailwind without anything stripped out, it's still more than feels necessary for a website like that.
That's not very big at all and also is due to the fact that the tailwind website itself uses most of the utility classes including all the breakpoints for demonstation purposes in the examples. The average website will have much less than that.
The site you are writing this on has >400kB of uncompressed css.
And adding just some examples of the most popular css frameworks websites: getbootstrap.com has 153kB uncompressed, bulma.io has 437 kB uncompressed, materializecss has 161kB uncompressed. Semantic UI has a whooping 628kB uncompressed. So all of those are acutally bigger in uncompressed size.
Stackoverflow has about 700 kB of uncompressed css. Reddit is a little hard to measure as they load css in chunks but in total it's also way above 144kB. Netflix has >700 kB. Instagram has >300 kB.
A more common example may be ottonow.de (a german shopping website). It uses tailwind css and has some more semantic css added. Total css uncompressed is 64 kB.
Also it has to be noted that tailwind builds do not grow at the same rate if you add new elements to the site. If you use all the available utility classes (which should never be the case) it reaches its maximum size while on a website with semantic css it will still grow as you have to add more and more css.
But even if it would be true that tailwind builds are somewhat bigger in uncompressed size: If that is your best argument in response to the article I linked then you will find about any excuse to not have to change your mind. This isn't even a metric that is very relevant. Much more relevant is kB over the wire and time to interactivity. Compressed size is absolutely fine and the tailwind site feels very snappy to me. No issues whatsoever.
This whole discussion reminds me of the people that said reactjs was bad when it came out. Now if you ask about any web or full stack dev they wouldn't look back for a second.
I think there's a lot of hype surrounding Tailwind that's touting it as a magic bullet that will solve all problems. The fact that there are a lot of websites out there using over 1MB of Tailwind is a sign that it isn't. Now, for whatever reason, something is going wrong on those websites. Maybe the developers didn't run any cleanup tools afterwards, but the question then becomes "should they need to?"
How did you count those websites and how do you know that it's "lots" in relative terms? Can you provide some examples of those websites?
Also, why should I care? There are many sites out there that are incredibly poorly made not using tailwind at all. I don't measure the usefulness of a professional tool in terms of the number of people that don't know or don't bother to use it correctly. Running the "cleanup tools" is a matter of minutes to setup and a matter of seconds to run if you know how to do it and doesn't have any weight compared to the improvements in productivity and maintainability. And knowing how to do it is a 5 minute read in the "Optimizing for Production" section of the docs. I don't see how this is even an argument. Also ff you use a bundler like webpack to develop your web application in the first place the build chain is usually already there. You just have to provide the paths to your templates or react components or whatever it is you are using and the tool does the rest.
And yes, there is a hype around it but I like to stick to the actual arguments for why this tool is better than the others for my use cases. I'm not interested in tailwind because everybody talks about it but because it has convincing actual arguments for it while having many years of experience in developing web applications with the existing tools and knowing their weaknesses and pain points.
If that were truly the case, there wouldn't be websites out there using 1MB+ tailwind.css files. Given that there are, there is clearly an issue where PurgeCSS (or an equivalent) isn't a natural part of the ecosystem. Even if it seems a natural pairing, unless it's a first class citizen partnership, it means that Tailwind has the same problem of other CSS frameworks/libraries: there's a lot that just isn't needed.
There has always been and will always be a problem with people not bothering to ship bad code. How does the number of websites that have shitty bundle sizes has anything to do with that? It's 10 min of work to setup the optimisation and the fact that those people didn't do it is not a problem of tailwind or purgecss but the fact that those people do not care.
You claim is basically: Not all people fasten their seatbelts therefore cars are bad unless the have a built-in first class automatic seatbelt fastener.
If it's not built-in and enforced by the library/framework, it will be ignored, and eventually becomes almost a defacto standard.
It's more similar to people not fastening their seatbelts because seatbelts aren't part of the car, and the driver needs to install them when they purchase the car. Because they're not built in, people won't use them unless something enforces their use.
Again, there is a section in the docs describing the optimisation process which is literally a few-minute read and easy to follow and understand. The docs also describe, how to install tailwindcss and that includes autoprefixer and postcss. The reason that tailwind doesn't enforce installation of those is, that nowadays many people have custom build-chains and tools and there is no one-size-fits-it-all approach. Still, the recommendations are to install it and the docs only really describe how to install those together. Everybody that follows the "Installation" section will install it.
Your argument still boils down to "Some people don't care about bundle size and ignore the installation instructions therefore the framework itself sucks". Have you even read the docs? It clearly points out that you should install postcss together with tailwind and also how to do so. Not following that is a failure of the user, not of the framework.
I find that most developers misuse the word "concern". Often Frontend devs think that technology is concern. But CSS or HTML or JavaScript are not concerns. They are technologies, languages.
Here is what Wikipedia says:
When concerns are well-separated, there are more opportunities for module upgrade, reuse, and independent development. Hiding the implementation details of modules behind an interface enables improving or modifying a single concern's section of code without having to know the details of other sections and without having to make corresponding changes to those other sections.
The less files you need to edit to make a necessary change - the better your concerns are separated. (Hence I like Vue.js.)
In other words a concern is: a searchable drop down component, or a user profile page, or a login form, or feature of some kind. But not a programming language.
Tailwind is the next step in the concern separation game. My HTML and classes (and some JavaScript) are blended together within the <template>. It allows me to drop <style> and the css language altogether. Thus concentrating my concern more within the <template>.
Having fewer files to update doesn't really mean you've separated concerns. An extreme example is the typical spaghetti code where your entire app logic is within 1 or 2 files.
Blending multiple languages together into a single file feels very much like the opposite of SoC. The code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Think about it in terms of dependency injection. You should remove tight coupling, and ensure that each layer only knows about the it's immediate relations.
But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev that doesn't know much about the front end, but it's basically the equivalent of not using dependency injection because you prefer each class to create all the instances of everything it needs by itself. Sure, it works, and it can be done very quickly, but it's not clean, and it isn't going to be very maintainable at scale.
Hi @ashley
, I like that you are fond of separating the concerns but when it comes to HTML and CSS whether you put them in a different file or not when you make changes you'd have to touch both of them as the HTML fully relies on the specifics of its design from CSS.
Tell that to the people who produce the wonderful designs at CSS Zen Garden. The HTML absolutely does not need to change with the CSS whenever there are changes.
That's usually down to developers not separating concerns correctly. If it's adding/removing content, sure, that makes sense, but if it's just because you need to change the appearance of something, then it's a sure sign that something wasn't done in the cleanest way.
I think this can stem from two scenarios: devs who are up against the wall with a tight deadline (this is probably the number one reason for unclean code), or devs who aren't as experienced with frontend and don't know the best approach to a particular task. These scenarios happen, and they will always happen. What we should constantly try and do though is always learn and strive to do things the best way possible. Tailwind voids separation of concerns, and contributes (in a bad way) to the overall file size of the page. That's absolutely not the best thing to do for the web.
AND
Maaate, your are so very wrong by saying that Tailwind increases page size. Actually, it's quite the opposite. Full gzipped CSS is 10-20kb for large websites. And 5kb for my entire medium website (~20 pages).
Again, you have no ideas what you are taking about until your try it.
I can't explain what is a red colour to a blind person who never saw it.
If you're counting page size only on the Gzip version, then you're missing the point. Total bytes downloaded is a metric, but not the only important one. Lots of repeated code makes for absolutely amazing gz compression resulting in very small downloaded bytes, but it still has to be uncompressed, parsed, etc, all of which can have a pretty major impact on devices on the lower end of the capability spectrum. Look at both compressed and uncompressed. It's not an absolute 1:1 match against required processing power on the end users device, but it's a fairly good indicator.
What's the point of measuring uncompressed if the entire internet delivers compressed?
Also, uncompressed Tailwind is also much smaller than the classic Semantic CSS approach.
I feel like you're looking for any excuse to prove that I'm wrong just to prove that I'm wrong without even googling anything about Tailwind. 😂
We measure compressed for transport performance, and uncompressed for performance on lower end devices. If a file is 50kB uncompressed, that's alright (although still very high for something like a blog or personal website), but if it uncomressed to 1MB, then it has a big impact on devices with less power (basically what a huge chunk of the world is using). The bigger the file, the more memory it requires to hold (a low end device doesn't have an unlimited amount of memory), and it requires more processing power to parse, thus leading to longer delays on First Meaningful Paint (FMP), more impact against battery life, etc.
You say I need to Google things before replying, but I feel that you don't actually understand the points I'm making. I understand what you're saying, but your arguments aren't refuting my points, so there's nothing yet for me to "Google".
Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.
Is it really? That number seems like it might be a wild guess without substantiation. Just by looking at a few sites using it, you can see that most often, the produced files are large (taken from a list of top sites using Tailwind, and Tailwinds own site):
Site
Compressed
Uncompressed
tailwindcss.com
19.15kB
110.21kB
support.zwift.com
127.85kB
1.84MB
loyalcompanion.com
57.77kB
390.61kB
fri.uni-lj.si
186.62kB
1.84MB
quad.hw.com
127.85kB
1.84MB
holstee.com
95.82kB
694.33kB
dmc-modesto.com
61.5kB
329.36kB
delraymedicalctr.com
61.5kB
329.36kB
wigwamwonderland.co.uk
52.81kB
301.19kB
askfavr.com
113.43
1.02MB
If a websites CSS file is in the hundreds of kB uncompressed, that's not great, but if it reaches MB, then something is awfully wrong.
Now, you could argue that this is just because they haven't got any kind of purge/pruning as a part of their build process, but that same argument could be made of any CSS, it's not a unique thing that only Tailwind has, so it's not a factor. What absolutely is a factor is the default, and as you can see from a couple of these websites that include the default (non custom) Tailwind CSS, the result is in the MB end of the scale.
You can ignore this if you don't know or care about the impact this has on low powered devices (e.g. mobiles, which is what most of the worlds web browsing is performed on these days) but that doesn't actually make the problem go away.
So, you can keep on requesting that I "try Tailwind before bashing it", but I think I have shown that I do understand what I'm arguing. I'm not trying to downplay your own development experience, but I am not wholly certain you understand the point I'm trying to make.
Ehm. Ashley just provided you exact numbers - so your assertion, that "no one uses Tailwind without PurgeCSS" is already proved to be wrong, before you wrote that. And your main argument is, that Ashley is false because YOU think he hasn't tried it. Thats not an argument for (or against tailwind), thats just bad argumentation style.
I want to pick up one main point in your argumentation:
"The less files you need to edit to make a necessary change - the better your concerns are separated."
If this is true, than tailwind is really bad in separation of concerns. Let's think about a simple example: Lets say we have a website with multiple forms on it. We decide to make all form elements have a grey text color and round corners so we add to douzens of files (doesn't matter if its HTML, Vue, Blade, Twig or whatever) these tailwind classes. Some days later, a designer (or the CI team) decides, that all form elements should be with green text color and without a border.
Now the 1000$ question - how many files do you have to update if you use tailwind? How many if you use for example bootstrap?
And if you are talking about file sizes and performance - CSS (zipped or unzipped) is just one messurment (and tailwind isn't that great in this category either). What about HTML size? Surfing on a website visiting 30 pages of it, I will only download (and parse) the css one time, but the HTML 30 times. So what is smaller and faster:
First of all - this comparison isn't a very good argument for your point. It shows, that uncompressed html with utility-first is just trash. Gzip is worse and only with brotli it is minimal better (0.8 kb).
You also mentioned, that utility first is soooo easy, but it only perform well, if you add extra steps to it, so you weaking your own point.
Second: This comparision isn't fair at all. She compares an "old" version of a side, which grews over time with a completle new created, optimzied version. Its like you would say - hey, my new Honda is much better then my 30 years old BMW.
To be fair, a lot of the arguments in the video are true or some kind of true. But she basically only picks aspects, where utility-first aproach is performing well. The aspects which dont fit well for her point are ignored or she just says "its ugly, but live with it". She also compares more or less "hardcore" sematic vs "utility first" mixed with semantic ("create button classes") and promote it as a feature of utility first only.
I totally understand, that the new kid in the block has to show his muscles, but this "I am the new super hero for all cases and everything what we have done till now is wrong," behavior is just stupid.
He had a lot better objections to the idea of TailwindCSS than "I don't like it". You're not really refuting any of his objections. So to me it seems you're putting forth the inverse of what Evan said. It comes across as: "I like it. Look, it's popular. You just don't understand it". It's not very convincing for us readers trying to evaluate TailwindCSS on balanced terms. I was hoping for better arguments and refutations in favour of TailwindCSS here, really.
As a backend dev, don't you find this violates separation of concerns? The HTML should have no knowledge or care about the appearance it has, which Tailwind classes do. However, Tailwind could be used if you're using a preprocessor like SASS or LESS, using classes in the HTML that describe the element/component and then building your CSS based on extending the Tailwind styles.
Hey mate. Just found this little tweet for you. It's doing a better job to explain things than me in this thread.
twitter.com/drewm/status/122940127...
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
I'm not sure if anybody already posted this but here is a link to a blog post of the author of tailwind css explaining why "Separation of Concerns" is a Strawman in his opinion and how he got from the "traditional" way of handling styling to utility first classes: adamwathan.me/css-utility-classes-...
It is a very convincing read and totally reflects how I feel about the topic given the years I spend developing web applications.
You should give tailwind css a try on your next side project.
I did read it, but I'm still not convinced. Even just looking at the CSS that results on the Tailwind site there seems like too much, coming in at 144kB uncompressed. While that's not as bad as some of the sites that seem to be using the full Tailwind without anything stripped out, it's still more than feels necessary for a website like that.
That's not very big at all and also is due to the fact that the tailwind website itself uses most of the utility classes including all the breakpoints for demonstation purposes in the examples. The average website will have much less than that.
The site you are writing this on has >400kB of uncompressed css.
And adding just some examples of the most popular css frameworks websites: getbootstrap.com has 153kB uncompressed, bulma.io has 437 kB uncompressed, materializecss has 161kB uncompressed. Semantic UI has a whooping 628kB uncompressed. So all of those are acutally bigger in uncompressed size.
Stackoverflow has about 700 kB of uncompressed css. Reddit is a little hard to measure as they load css in chunks but in total it's also way above 144kB. Netflix has >700 kB. Instagram has >300 kB.
A more common example may be ottonow.de (a german shopping website). It uses tailwind css and has some more semantic css added. Total css uncompressed is 64 kB.
Also it has to be noted that tailwind builds do not grow at the same rate if you add new elements to the site. If you use all the available utility classes (which should never be the case) it reaches its maximum size while on a website with semantic css it will still grow as you have to add more and more css.
But even if it would be true that tailwind builds are somewhat bigger in uncompressed size: If that is your best argument in response to the article I linked then you will find about any excuse to not have to change your mind. This isn't even a metric that is very relevant. Much more relevant is kB over the wire and time to interactivity. Compressed size is absolutely fine and the tailwind site feels very snappy to me. No issues whatsoever.
This whole discussion reminds me of the people that said reactjs was bad when it came out. Now if you ask about any web or full stack dev they wouldn't look back for a second.
I think there's a lot of hype surrounding Tailwind that's touting it as a magic bullet that will solve all problems. The fact that there are a lot of websites out there using over 1MB of Tailwind is a sign that it isn't. Now, for whatever reason, something is going wrong on those websites. Maybe the developers didn't run any cleanup tools afterwards, but the question then becomes "should they need to?"
How did you count those websites and how do you know that it's "lots" in relative terms? Can you provide some examples of those websites?
Also, why should I care? There are many sites out there that are incredibly poorly made not using tailwind at all. I don't measure the usefulness of a professional tool in terms of the number of people that don't know or don't bother to use it correctly. Running the "cleanup tools" is a matter of minutes to setup and a matter of seconds to run if you know how to do it and doesn't have any weight compared to the improvements in productivity and maintainability. And knowing how to do it is a 5 minute read in the "Optimizing for Production" section of the docs. I don't see how this is even an argument. Also ff you use a bundler like webpack to develop your web application in the first place the build chain is usually already there. You just have to provide the paths to your templates or react components or whatever it is you are using and the tool does the rest.
And yes, there is a hype around it but I like to stick to the actual arguments for why this tool is better than the others for my use cases. I'm not interested in tailwind because everybody talks about it but because it has convincing actual arguments for it while having many years of experience in developing web applications with the existing tools and knowing their weaknesses and pain points.
Mate, in this thread I told them few times that none is using Tailwind without PurgeCSS.
But they simply ignore this fact.
No point in arguing here.
If that were truly the case, there wouldn't be websites out there using 1MB+ tailwind.css files. Given that there are, there is clearly an issue where PurgeCSS (or an equivalent) isn't a natural part of the ecosystem. Even if it seems a natural pairing, unless it's a first class citizen partnership, it means that Tailwind has the same problem of other CSS frameworks/libraries: there's a lot that just isn't needed.
There has always been and will always be a problem with people not bothering to ship bad code. How does the number of websites that have shitty bundle sizes has anything to do with that? It's 10 min of work to setup the optimisation and the fact that those people didn't do it is not a problem of tailwind or purgecss but the fact that those people do not care.
You claim is basically: Not all people fasten their seatbelts therefore cars are bad unless the have a built-in first class automatic seatbelt fastener.
If it's not built-in and enforced by the library/framework, it will be ignored, and eventually becomes almost a defacto standard.
It's more similar to people not fastening their seatbelts because seatbelts aren't part of the car, and the driver needs to install them when they purchase the car. Because they're not built in, people won't use them unless something enforces their use.
Again, there is a section in the docs describing the optimisation process which is literally a few-minute read and easy to follow and understand. The docs also describe, how to install tailwindcss and that includes autoprefixer and postcss. The reason that tailwind doesn't enforce installation of those is, that nowadays many people have custom build-chains and tools and there is no one-size-fits-it-all approach. Still, the recommendations are to install it and the docs only really describe how to install those together. Everybody that follows the "Installation" section will install it.
Your argument still boils down to "Some people don't care about bundle size and ignore the installation instructions therefore the framework itself sucks". Have you even read the docs? It clearly points out that you should install postcss together with tailwind and also how to do so. Not following that is a failure of the user, not of the framework.
I find that most developers misuse the word "concern". Often Frontend devs think that technology is concern. But CSS or HTML or JavaScript are not concerns. They are technologies, languages.
Here is what Wikipedia says:
The less files you need to edit to make a necessary change - the better your concerns are separated. (Hence I like Vue.js.)
In other words a concern is: a searchable drop down component, or a user profile page, or a login form, or feature of some kind. But not a programming language.
Tailwind is the next step in the concern separation game. My HTML and classes (and some JavaScript) are blended together within the
<template>. It allows me to drop<style>and the css language altogether. Thus concentrating my concern more within the<template>.Having fewer files to update doesn't really mean you've separated concerns. An extreme example is the typical spaghetti code where your entire app logic is within 1 or 2 files.
Blending multiple languages together into a single file feels very much like the opposite of SoC. The code is tightly coupled both ways, the HTML depends on the specifics of Tailwind, making it very difficult to move or change in the future. Think about it in terms of dependency injection. You should remove tight coupling, and ensure that each layer only knows about the it's immediate relations.
It's actually vice versa. It was very easy to move and change a component written with Tailwind. Extremaly easy. 😉
But you're putting the responsibility of appearance on the HTML, which it shouldn't care about. I realise it makes things easier for a backend dev that doesn't know much about the front end, but it's basically the equivalent of not using dependency injection because you prefer each class to create all the instances of everything it needs by itself. Sure, it works, and it can be done very quickly, but it's not clean, and it isn't going to be very maintainable at scale.
If you Google other people opinions on Tailwind you'll find numerous claims that it is actually more scalable, more maintainable.
To believe all those people you'd need to try it yourself.
Let's close this thread until you compare the traditional semantic CSS with Tailwind yourself on a real project.
Cheers! 😀
twitter.com/lesliecdubs/status/122...
I found this just now. A poll on twitter. 😀
Hi @ashley , I like that you are fond of separating the concerns but when it comes to HTML and CSS whether you put them in a different file or not when you make changes you'd have to touch both of them as the HTML fully relies on the specifics of its design from CSS.
Tell that to the people who produce the wonderful designs at CSS Zen Garden. The HTML absolutely does not need to change with the CSS whenever there are changes.
It certainly does not!
But the reality is that 80% of the time HTML and CSS have to be changed simultaneously.
That's usually down to developers not separating concerns correctly. If it's adding/removing content, sure, that makes sense, but if it's just because you need to change the appearance of something, then it's a sure sign that something wasn't done in the cleanest way.
I think this can stem from two scenarios: devs who are up against the wall with a tight deadline (this is probably the number one reason for unclean code), or devs who aren't as experienced with frontend and don't know the best approach to a particular task. These scenarios happen, and they will always happen. What we should constantly try and do though is always learn and strive to do things the best way possible. Tailwind voids separation of concerns, and contributes (in a bad way) to the overall file size of the page. That's absolutely not the best thing to do for the web.
Tailwind improves separation of concerns IMO.
AND
Maaate, your are so very wrong by saying that Tailwind increases page size. Actually, it's quite the opposite. Full gzipped CSS is 10-20kb for large websites. And 5kb for my entire medium website (~20 pages).
Again, you have no ideas what you are taking about until your try it.
I can't explain what is a red colour to a blind person who never saw it.
If you're counting page size only on the Gzip version, then you're missing the point. Total bytes downloaded is a metric, but not the only important one. Lots of repeated code makes for absolutely amazing gz compression resulting in very small downloaded bytes, but it still has to be uncompressed, parsed, etc, all of which can have a pretty major impact on devices on the lower end of the capability spectrum. Look at both compressed and uncompressed. It's not an absolute 1:1 match against required processing power on the end users device, but it's a fairly good indicator.
What's the point of measuring uncompressed if the entire internet delivers compressed?
Also, uncompressed Tailwind is also much smaller than the classic Semantic CSS approach.
I feel like you're looking for any excuse to prove that I'm wrong just to prove that I'm wrong without even googling anything about Tailwind. 😂
We measure compressed for transport performance, and uncompressed for performance on lower end devices. If a file is 50kB uncompressed, that's alright (although still very high for something like a blog or personal website), but if it uncomressed to 1MB, then it has a big impact on devices with less power (basically what a huge chunk of the world is using). The bigger the file, the more memory it requires to hold (a low end device doesn't have an unlimited amount of memory), and it requires more processing power to parse, thus leading to longer delays on First Meaningful Paint (FMP), more impact against battery life, etc.
You say I need to Google things before replying, but I feel that you don't actually understand the points I'm making. I understand what you're saying, but your arguments aren't refuting my points, so there's nothing yet for me to "Google".
Tailwind final CSS file (unzipped) is about 10-20 times smaller comparing to traditional semantic CSS approach.
Again, try Tailwind before bashing it.
Is it really? That number seems like it might be a wild guess without substantiation. Just by looking at a few sites using it, you can see that most often, the produced files are large (taken from a list of top sites using Tailwind, and Tailwinds own site):
If a websites CSS file is in the hundreds of kB uncompressed, that's not great, but if it reaches MB, then something is awfully wrong.
Now, you could argue that this is just because they haven't got any kind of purge/pruning as a part of their build process, but that same argument could be made of any CSS, it's not a unique thing that only Tailwind has, so it's not a factor. What absolutely is a factor is the default, and as you can see from a couple of these websites that include the default (non custom) Tailwind CSS, the result is in the MB end of the scale.
You can ignore this if you don't know or care about the impact this has on low powered devices (e.g. mobiles, which is what most of the worlds web browsing is performed on these days) but that doesn't actually make the problem go away.
So, you can keep on requesting that I "try Tailwind before bashing it", but I think I have shown that I do understand what I'm arguing. I'm not trying to downplay your own development experience, but I am not wholly certain you understand the point I'm trying to make.
Mate. PurgeCSS is built into Tailwind-css. No one uses Tailwind without PurgeCSS.
Also, that number is coming from my two large projects.
I'm trying to tell that your point is based on false (or lacking) info.
Before bashing anything your should study it.
Ehm. Ashley just provided you exact numbers - so your assertion, that "no one uses Tailwind without PurgeCSS" is already proved to be wrong, before you wrote that. And your main argument is, that Ashley is false because YOU think he hasn't tried it. Thats not an argument for (or against tailwind), thats just bad argumentation style.
I want to pick up one main point in your argumentation:
"The less files you need to edit to make a necessary change - the better your concerns are separated."
If this is true, than tailwind is really bad in separation of concerns. Let's think about a simple example: Lets say we have a website with multiple forms on it. We decide to make all form elements have a grey text color and round corners so we add to douzens of files (doesn't matter if its HTML, Vue, Blade, Twig or whatever) these tailwind classes. Some days later, a designer (or the CI team) decides, that all form elements should be with green text color and without a border.
Now the 1000$ question - how many files do you have to update if you use tailwind? How many if you use for example bootstrap?
And if you are talking about file sizes and performance - CSS (zipped or unzipped) is just one messurment (and tailwind isn't that great in this category either). What about HTML size? Surfing on a website visiting 30 pages of it, I will only download (and parse) the css one time, but the HTML 30 times. So what is smaller and faster:
Tailwind:
Traditional aproach
May I ask you to watch this 17 min video before making any more false statements?
youtube.com/watch?v=R50q4NES6Iw
First of all - this comparison isn't a very good argument for your point. It shows, that uncompressed html with utility-first is just trash. Gzip is worse and only with brotli it is minimal better (0.8 kb).
You also mentioned, that utility first is soooo easy, but it only perform well, if you add extra steps to it, so you weaking your own point.
Second: This comparision isn't fair at all. She compares an "old" version of a side, which grews over time with a completle new created, optimzied version. Its like you would say - hey, my new Honda is much better then my 30 years old BMW.
To be fair, a lot of the arguments in the video are true or some kind of true. But she basically only picks aspects, where utility-first aproach is performing well. The aspects which dont fit well for her point are ignored or she just says "its ugly, but live with it". She also compares more or less "hardcore" sematic vs "utility first" mixed with semantic ("create button classes") and promote it as a feature of utility first only.
I totally understand, that the new kid in the block has to show his muscles, but this "I am the new super hero for all cases and everything what we have done till now is wrong," behavior is just stupid.
Let's just see if it's better than the existing CSS frameworks. Time will tell.
twitter.com/GuamHat/status/1316845...
He had a lot better objections to the idea of TailwindCSS than "I don't like it". You're not really refuting any of his objections. So to me it seems you're putting forth the inverse of what Evan said. It comes across as: "I like it. Look, it's popular. You just don't understand it". It's not very convincing for us readers trying to evaluate TailwindCSS on balanced terms. I was hoping for better arguments and refutations in favour of TailwindCSS here, really.
Time will tell. :)
State of CSS 2020 review: dev.to/lukekyl/2020-state-of-css-i...
