loading...

re: Paid Developer tools you can´t live without? VIEW POST

FULL DISCUSSION
 

It is a blessing for backend developers like me who suck at design.

I think Tailwind, at least as used by them on their linked demo site, is a very bad idea for people who suck at design. It promotes utility classes in HTML, like class="px-4 py-2 border-b border-gray-200 sm:flex justify-between items-center bg-white sm:py-4 sm:px-6 sm:items-baseline" which is no better than using inline styles. It's basically the same as using Dreamweaver from the 1990s to make your website.

 

I completely understand what you are saying and I had exactly the same feeling when I saw it for the first time.

But after playing with it a bit I changed my mind.

I think where it plays better, is together with component-based framework like Vue or React, so you create components to avoid repeating the styles. I mean even to a regular template engine that supports "includes" you can take the same approach.

So let´s say you can create a component "Card" where the HTML contains the tailwind directives and use it everywhere in the application. If you want to change how the card looks, it´s just a single place to change.

Also, you can use normal CSS in an external file and apply the tailwind directives if you really can't stand the inline approach.

I have done very simple applications with it. I don´t know if wil scale well for medium and big size projects with many people working on it. Maybe not. Can I see it become a mess to mantain in some projects? yes! Like any technology.

But for personal and small projects, where you want to have a solid design without much effort, together with the amazing library of pre-made components provided by Tailwind UI, I believe it´s a great choice!

 

If you want to change how the card looks, it´s just a single place to change.

But if you want to change the theme of your entire page, you'll need to do it repeatedly to every component.

Tailwind has great support for themes,

Yes they have helpers for their default color pallete like, bg-green, text-blue, etc and would have to change it all places.

But, you can define your own names, and having something like "bg-primary", "bg-secondary", etc, so if you want to change your colors, you just have to change in a config file. (tailwindcss.com/docs/customizing-c...).

Maybe they should promote these practices more. I agree it has the potential to become messy if you are not careful.

As I said, I only use it for small personal projects for now, where these points are not that important. What it gives me in terms of speed and good looking design out of the box, largely out-weights the possible problems you mentioned.

Let´s see, where it goes ;)

 

Stop spreading this misinformation and hate on every post about Tailwind. It is okay for you not to like it, but at least take the time to understand the difference between inline styles and utility classes. Inline styles can be anything you want, utility classes are a defined set of classes that can be constrained and documented.

Many massive companies (including GitHub and StackOverflow) are using this approach with great success.

Please please please read this page with an open mind

 

Stop spreading this misinformation

I'm not spreading misinformation. I'm saying that separation of concerns is still important, and that things like Tailwind - which is only what we're talking about because it's the flavour of the month - are making the web worse for everyone.

Please please please read this page with an open mind

I have. I read it the last time someone objected to my point. However, it says nothing to convince me it's a good idea. It has a section on "extracting classes", which I've ceded before as being an ok way to work, even if nothing novel - but that's not how people are using it. Including Tailwind themselves.

making the web worse for everyone

This is 100% a personal opinion backed by nothing factual. What you can factually prove is that using Tailwind with Purging (which is baked in by default) will result in smaller CSS bundles, safer-to-edit HTML/components, and significantly simpler CSS cascades and specificity. This is why big platforms are adopting it these days. Seriously, go inspect the source on some pages on GitHub.

I'm saying that separation of concerns is still important

Separation of concerns when it comes to HTML and CSS is laughable. They are inherently bound together and require one another. This is why CSS-in-JS libraries, Vue Single File Components, and Native CSS support in Svelte exist.

When will you ever write HTML without CSS, and when will you ever write CSS that isn't targeting specific HTML? You won't. And, as such, utility frameworks allow you to apply specific CSS directly to your markup in the same way you would use GraphQL to only pull the specific data you need from your API in your component.

I understand that you hate Tailwind and utility frameworks. That is entirely acceptable. But do not shy others away from at least giving it an honest attempt for themselves, and let them come to their own conclusions.

I look forward to our next debate on another post highlighting Tailwind :D

 

I think you are still looking for Component libraries, as opposed to atomic CSS.

But that is what current Dev.to don't suggest much, at least according to my another question.

CSS-in-JS components or Single File Components, might be the answer you wanted.

 

Who is this reply to? Sorry, threading is only a level or two deep here :)
If me, then I'm not sure what you mean?

It is a blessing for backend developers like me who suck at design.

NVM, but I actually mean that Tailwind is not meant for backend dev who are suck at design.

For me, it´s amazing for that. ;)

I can build good looking interfaces without much effort thanks to the solid foundation tailwind provides me.

A full-stack need to carefully pick up their battles. Tailwind gives me time to focus on other areas.

But again, this is my personal experience and my goals.

 

Also not sure, if this reply is for me, but I read that post and some comments there, from what I read, Tailwind is planning to create Vue, and React components in the future, instead of only HTML versions. I guess it would be similar with Buetify and Vuetify, so you would have a let´s say tw-button element.

Still, for me the big advantage of Tailwind is there good looking design by default.

Tailwind did made a good showroom, though.

But, originally I intended this for Ben.

 

I agree with that. It's the reason I tend to avoid frameworks like Bootstrap. Furthermore, if you need to build more complex custom layouts (e.g. out of a PSD), such frameworks might even end up being an obstacle rather than a help. A few years back I would use bootstrap or whatever framework for its grid layout, but today, with native CSS solutions like flexbox and grid, it seems to me that it's not worth it.

Actually, at some point, I used to use a CSS Grid framework because it was implementing flexbox, which seemed intimidating at the time (Bootstrap was on version 3, which hadn't implemented it yet). It was great for simple layouts, but on more complicated designs trying to fit the HTML markup to the conventions of the framework was a nightmare. Eventually, I ditched it completely and decided to properly learn how to use flexbox. It was one of the wisest choices I've made, as learning was much easier than I thought, and since then styling a page became much easier on every aspect.

In my opinion, the biggest drawback of such frameworks is that there is a danger that you will end up learning the framework and forget the actual CSS without a good enough payoff. Doing <div class="sm:flex;"> instead of putting display: flex; on a media query, not only won't save you from any worthwhile trouble but if you get used to it you might unfamiliarize yourself with how things actually work.

 

Hi Ben, what you see in their landing page is not how it really meant to be used. It's just for demo purposes and fast prototyping. In practical use cases, you would make components to group classes or to re-use the markup. Read more at Extracting Components docs.

which is no better than using inline styles

Inline Styles does not support media queries and pseudo-classes. Also, it will add a high specificity to your CSS. Last but not least, managing consistent values for padding, margin, color... is very hard with inline-styles unlike using Tailwind utility classes. So it's unfair to assume they are the same or worse.

It may be truly overwhelming at first, but once you get used to it will be very useful and practical.

 

I don't think it's overwhelming at all, I see what people are doing with it and I'm aware that you can make classes in a similar way to extending in Less or Sass, e.g. (pseudocode):

.my-semantic-element {
 (extend/use/whatever) text-green padding-10px font-cool-caps;
}

However, that's not how people work. It's not how people do things in the real world. Evidence? Their site doesn't. Their site does it that "bad" way, and if even they won't do it right, why would any of their users?

You might point out a couple of technical ways it's better than inline styles, but practice-wise, it's the same. It's encouraging mixing presentation and markup, which wasn't a good idea 10 years ago and it's suddenly a good idea now because it's the easy way.

Yes, you can @apply in Tailwind as well. So, in the end, it's the good ol' CSS, with Tailwind website acting as a showroom.

@ ben

By overwhelming I meant it makes you hesitating or refusing to consider using it. What you see in their site is the compiled code. You can't tell if they are using it wrong or not. Most likely they have used component based approach to re-use the markup. The whole point of the website is to showcase the versatility and the power of their utility-based framework. It will make no sense if they used class names and used @apply directive which will obscure the versatility and dictate a CSS naming convention which is not the aimed goal behind the framework.

which wasn't a good idea 10 years ago [...]

Since 10 years ago a lot has been changed. Mixing presentation and markup is a real complication when using a monolithic approach. But now, you can separate the logic of your app in a small digestible and encapsulated components. Such approach wasn't easily possible 10 years ago as today there's a lot of powerful build tools that make such thing possible.

Some people even decide to mix markup + presentation + business logic in a single component when using JS frameworks like React, Angular or VueJS. Yet, they succeed to delivery a powerful and maintainable web apps.

My point is, as technology advance the decision making changes too. For example, years ago computers were limited in memory and storage that made developers very concerned about managing every single byte of memory. Now such concerns are tend to be called micro-optimization.

Myself included I still hesitate to mix the three layers in a single file. I still tend to be influenced by the old school way. However, when you mix them you're not automatically wrong. It always depends on how you do it.

 

Inline Styles does not support media queries and pseudo-classes. Also, it will add a high specificity to your CSS

Still, IMO, it might be only marginally better than plain inline style. (in most aspects)

However, right now, even if I am still not convinced about including the whole Tailwind (and Purge CSS), I am very convinced that I should write CSS in Atomic style. I even used names similar to Tailwind website.

I cannot see how supporting responsive design and adding low CSS specificity to the element is "only marginally better". A big portion, if not the biggest, of your visitors will be using mobile devices.

Code of Conduct Report abuse