loading...

re: Which CSS library do you prefer and WHY ? VIEW POST

FULL DISCUSSION
 

We prefer no framework - because CSS in 2020 is amazing. The libraries just seem like an added mess.

<parent-component>
  <child-component>
    <!-- stuff -->
  </child-component>
</parent-component>

Is nice to read.

<div id="w23" class="col-2h padding border-2 drop-shadow-5 pull-left">
  <div class="inner-left col-2 col-12md">
    <!-- stuff -->
  </div>
</div>

Isn't. (for us)

Here's an example looking at tailwind

We DO still use a pre-processor - because mixins allow us an abstraction that makes writing CSS just a tiny bit more pleasurable. (and technically - that kinda means we have our own 'framework'...)

 

Aren't you just moving what's not nice to read to another file that needs to be opened and maintained? I guess I prefer the latter because it only requires one file to maintain and chase down when changes are required. Also, if at some point I need to change the "child component" in one module, I can do it safely!

EDIT: Won't you also need a framework to be able to develop components like that?

 

RE: "aren't you just moving what's not nice to read to another file" - YES! Yes. That is what is happening. It's basically the same thing - but just organized differently. HTML is basically a JavaScript object for all practical purposes (The DOM Node etc) - but it's nature is just messy visually. Especially once you start getting some Vue or Ember attributes everywhere.

RE: component / those are totally part of the spec now. You can use them! But beware, they are display: inline; by default. ; )

Component HTML and CSS side by side
This is a PHP template example

There is two files. And in most cases for us - (Vue / Ember) there ends up being a backing controller type .js file too.

We like the one file for each - otherwise, we'd be on the JSX team.

How do you like to do it?

Take a look at any of my projects on GitHub to see my preferred approach.

My biggest problem (and fair warning, it is entirely personal) is that approaches like this lead to really large repositories in terms of the sheer amount of files.

Why I prefer using tools like TailwindCSS is that your template file encapsulates ALL of the styling and markup. As such, you can very easily and safely edit these template files and not worry that you may have broken other markup across an application. I know that in a perfect world, you would use something like BEM to make sure no CSS leaks, but in all reality we know somebody may duplicate markup and styles or extend a component with Sass or Stylus without you knowing about it.

Again, it's all personal preference, but I appreciate being able to discern everything about a component just from it's template file.

We don't seem to ever have problems with leaking. There's a template and declaration of how that template should look - but we use the cascade and we play it a little loose with the CSS file size.

That's why everyone can choose their own style. : )

For example - on overpass (great job! BTW) - there aren't that many things happening that you'd run into major regression problems, right? But - maybe LinkedIn or something for sure. We get to mostly work on greenfield projects / and we're teachers - so, it just makes sense for us to teach CSS instead of a kinda superset.

If pretending to see this project for the first time ever:

Example of wild CSS classes

How would a Junior developer know what any of that markup was for?

vs

<section class='about-us'>
  <picture class='logo'>...
  <h2 class='welcome-message'>...
</section>

What did you use before Tailwind?

Again, had I seen the two code examples for the first time, even as a junior, I think I would still prefer the Tailwind approach, and I will explain why.

For example, say the junior dev was asked to reduce the size of the picture in the about us section. I would expect a junior to directly target the logo class, without first checking the entirety of the codebase to make sure it isn't being used elsewhere.

To safely edit this picture element, the junior would actually need to create a modifier class for this specific picture element, possibly targeting a nested picture inside the about us class, maybe something like .about-us picture.

However, now if anybody ever decides to change the markup structure, for example, changing the picture element to a video element, the CSS will no longer work correctly.

Take by comparison a Tailwind-esque approach. The junior would simply have to change the width and height classes, for example w-64 h-64 to something like w-48 h-48 and BAM, it's done. No worries about breaking anything elsewhere in the project because you only directly edited that specific HTML.

Also, if you decide to swap that picture element out for a video, all you need to do is make sure you pass the same class definitions and it will behave identically to that picture element.

Before Tailwind, I was using Sass. I dabbled in a few frameworks, but I always loved using both Bootstrap and Bulma's grid and spacing utility aspects. When I finally found Tailwind, I knew it was for me.

This is great! It really helps to understand your perspective. This discussion is certainly not meant to be combative. In our case, we would never style .logo in a global or general place. This would lead to duplicate rules - but that's a trade-off we prefer. Even though we don't use Tailwind, we'll be teaching how it works by having the students build their own mini version of a framework - and then they can decide what they like best. : ) Thanks for taking the time to explain! That is really cool.

Thanks for approaching it with an open mind! It's good to talk about different executions of the same thing, especially in web development these days. Thanks for taking the time to talk with me!

Code of Conduct Report abuse