4 ms·

I never got how is "context switching" such a problem. I mean, can't you have like, two files opened side-by-side in different IDE panels? Is it really that har

I never got how is "context switching" such a problem. I mean, can't you have like, two files opened side-by-side in different IDE panels? Is it really that hard to "look jump" from one another? This justifies the amount of overhead added by a library like this? If I can be blunt: I find this "argument" to be lazy as **. Sorry but "context switching" is just a fancy name for "having two files opened at the same time", which shouldn't be a problem, no? PS: And almost all the other stated advantages of this approach seem to be as low value as this one considering the implied costs.

ofcourseyoudo 3y ago
You've never had to search through multiple stylesheets and Inspect to figure out inheritance and cascading for a CSS rule that is resisting editing? I recently had to work with another developer's codebase that had four different CSS files influencing the HTML, only to find in a fifth file an !important that was mucking everything up. If you haven't experienced costly context switching working on FE then consider yourself fortunate.
- emmacharp 3y ago
  Well, this is bad CSS indeed. But it does not have to be that way. A little linting with Stylelint can make sure this does not happen. As an added bonus there are less dependencies and complexity.
- nhinck 3y ago
  No, the element inspector will tell you what css file the rule is coming from.
  - yurishimo 3y ago
    Assuming you work with a build system that can generate source maps...
    - emmacharp 3y ago
      This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.
      - for1nner 3y ago
        "should" is often the enemy of "speed" even when it's the _correct_ way to build a system. I think most of us here have experienced that at businesses of varying sizes.
        emmacharp 3y ago
        As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.
      - ofcourseyoudo 3y ago
        Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.
        emmacharp 3y ago
        Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps. I may be wrong, though. Don't hesitate to correct me if that's the case.
        ofcourseyoudo 3y ago
        I'm not particularly interested in arguing the specifics of a solution, my point is that on a larger team especially where an individual does not get to define the approach, I'm surprised that you haven't run into issues with context switching or hunting. But regarding one of your specifics, for example you said "the kind of help/solution that should be implemented first" before frameworks are added. On the teams you've been on, was it easy for a developer (especially a junior) to say "Hey, we should really be implementing X, and we should have done it before I joined the team, can we restructure at this point?"
jonwinstanley 3y ago
I suppose one of the good things that Tailwind does is it stops you having to name every element and all the different variations. So you don't end up with wrapper, container, container-thin, image-wrapper etc etc.
- emmacharp 3y ago
  But you really don't have to do that. Naming components only (as you already are) really is sufficient. And yes, specificity and flexibility can easily be managed/included with CSS, particularly now, with all the new widely supported features/selectors. These solutions to an old "problem" are lighter, simpler and easier to maintain in the long run. If you're curious, I'll be pleased to give you more concrete examples!
  - haswell 3y ago
    Most of my HTML/CSS skills were formed when these things did not have good built-in solutions. As someone who just wants to hack together a responsive blog that looks nice, the things that are now “simpler and easier in the long run” have not been easy or obvious to come by when looking for resources, and while I’d love a deep knowledge of CSS, the investment in time doesn’t make sense given my use case. This is why I gravitated to Tailwind - learn the conventions of the utility classes (only took a few minutes) and the rest mostly just works. I’d love something like http://vanilla-js.com/ http://vanilla-js.com/ but for modern CSS. Something that paints a crystal clear picture about what can be done, and how to do it without bringing in $framework.
    - emmacharp 3y ago
      I understand this perfectly and is maybe the argument I have the most sympathy for. And, because you are absolutely right, I'm working right now on something like what you propose. The only way to convince people that CSS is a better (as in lighter, simpler, more efficient, etc.) solution than a framework like this, is to show and prove that it is. Arguments can only go so far... So, as the saying goes, I'll be putting my money where my mouth is. Hehe.
marcosdumay 3y ago
It's worse than that. Tailwind imposes a ton of context switching by putting the style inline with you data. It's just that this switching happens when working on the data, instead of on the style.
- naasking 3y ago
  > It's just that this switching happens when working on the data, instead of on the style. You mean you have to think about how the data you're styling looks while actually looking at the data you're styling? Sounds terrible. /s
  - marcosdumay 3y ago
    You have to think about how the data looks like while you are editing the data. But I do think my comment was clear.
    - haswell 3y ago
      Your comment was really not clear to me at all, so I think I’m missing something. Where is the context switch here? To me, context switching is about changing what I’m currently looking at on the screen and going somewhere else to define something in some other context: a different source file, a different system, a config file, etc. If you’re continually leaving the context of the HTML that will render your data in order to manipulate that data, that sounds like a different problem that can easily be solved by using mock data or by hooking up to a real data source. This is true regardless of CSS approach.

ofcourseyoudo 3y ago

You've never had to search through multiple stylesheets and Inspect to figure out inheritance and cascading for a CSS rule that is resisting editing? I recently had to work with another developer's codebase that had four different CSS files influencing the HTML, only to find in a fifth file an !important that was mucking everything up. If you haven't experienced costly context switching working on FE then consider yourself fortunate.

emmacharp 3y ago
Well, this is bad CSS indeed. But it does not have to be that way. A little linting with Stylelint can make sure this does not happen. As an added bonus there are less dependencies and complexity.
nhinck 3y ago
No, the element inspector will tell you what css file the rule is coming from.
- yurishimo 3y ago
  Assuming you work with a build system that can generate source maps...
  - emmacharp 3y ago
    This is easy and should not be a problem. It also is the kind of help/solution that should be implemented first, before any librairies or frameworks are added.
    - for1nner 3y ago
      "should" is often the enemy of "speed" even when it's the _correct_ way to build a system. I think most of us here have experienced that at businesses of varying sizes.
      - emmacharp 3y ago
        As I said below, I don't understand how the number of team members can impede our capacity to activate source maps. Again, I may be wrong so go ahead and tell me if that's the case.
    - ofcourseyoudo 3y ago
      Have you worked on a FE team with 5 or more people? There's a lot that is easy and shouldn't be a problem when you get to define the scope and technologies and shared conventions used.
      - emmacharp 3y ago
        Yes, I have. And I don't see how it can impact the feasibility and easiness of activating source maps. I may be wrong, though. Don't hesitate to correct me if that's the case.
        ofcourseyoudo 3y ago
        I'm not particularly interested in arguing the specifics of a solution, my point is that on a larger team especially where an individual does not get to define the approach, I'm surprised that you haven't run into issues with context switching or hunting. But regarding one of your specifics, for example you said "the kind of help/solution that should be implemented first" before frameworks are added. On the teams you've been on, was it easy for a developer (especially a junior) to say "Hey, we should really be implementing X, and we should have done it before I joined the team, can we restructure at this point?"

jonwinstanley 3y ago

I suppose one of the good things that Tailwind does is it stops you having to name every element and all the different variations. So you don't end up with wrapper, container, container-thin, image-wrapper etc etc.

emmacharp 3y ago
But you really don't have to do that. Naming components only (as you already are) really is sufficient. And yes, specificity and flexibility can easily be managed/included with CSS, particularly now, with all the new widely supported features/selectors. These solutions to an old "problem" are lighter, simpler and easier to maintain in the long run. If you're curious, I'll be pleased to give you more concrete examples!
- haswell 3y ago
  Most of my HTML/CSS skills were formed when these things did not have good built-in solutions. As someone who just wants to hack together a responsive blog that looks nice, the things that are now “simpler and easier in the long run” have not been easy or obvious to come by when looking for resources, and while I’d love a deep knowledge of CSS, the investment in time doesn’t make sense given my use case. This is why I gravitated to Tailwind - learn the conventions of the utility classes (only took a few minutes) and the rest mostly just works. I’d love something like http://vanilla-js.com/ http://vanilla-js.com/ but for modern CSS. Something that paints a crystal clear picture about what can be done, and how to do it without bringing in $framework.
  - emmacharp 3y ago
    I understand this perfectly and is maybe the argument I have the most sympathy for. And, because you are absolutely right, I'm working right now on something like what you propose. The only way to convince people that CSS is a better (as in lighter, simpler, more efficient, etc.) solution than a framework like this, is to show and prove that it is. Arguments can only go so far... So, as the saying goes, I'll be putting my money where my mouth is. Hehe.

marcosdumay 3y ago

It's worse than that. Tailwind imposes a ton of context switching by putting the style inline with you data. It's just that this switching happens when working on the data, instead of on the style.

naasking 3y ago
> It's just that this switching happens when working on the data, instead of on the style. You mean you have to think about how the data you're styling looks while actually looking at the data you're styling? Sounds terrible. /s
- marcosdumay 3y ago
  You have to think about how the data looks like while you are editing the data. But I do think my comment was clear.
  - haswell 3y ago
    Your comment was really not clear to me at all, so I think I’m missing something. Where is the context switch here? To me, context switching is about changing what I’m currently looking at on the screen and going somewhere else to define something in some other context: a different source file, a different system, a config file, etc. If you’re continually leaving the context of the HTML that will render your data in order to manipulate that data, that sounds like a different problem that can easily be solved by using mock data or by hooking up to a real data source. This is true regardless of CSS approach.