[justsomeuser]

OP means you are looking at both the structure of the DOM (JSX) and the CSS (className).

The “tailwind” effect is due to fast feedback and iteration - there is no jumping between two files (DOM file and CSS file).

Of course this also leads components eventually having huge lists of classes.

But I think the fast feedback loop is worth it, because with 2D visual artefacts and the complex CSS language, often the only way to learn/get what you want is change a little, reflect, change a little, … etc.

[nawgz]

> there is no jumping between two files (DOM file and CSS file)

I don't view this as any more difficult than navigating a long file. Maybe I actually view it as more simple upon making that statement. What development environment are you using? Hotkeys to switch tabs is fairly base-level stuff

> often the only way to learn/get what you want is change a little, reflect, change a little

Which surely any person who is arguing for "fast feedback" would do using the browser's dev tools so you can edit CSS and instantly view the result in the same window as your actively painted view...

I would look into getting a proper editor like VSCode, setting up hotkeys, and learning to use dev tools if I was you. It sounds like you are using VIM to make your website

[justsomeuser]

It’s not just the “jumping between files” that takes longer.

It is also mentally computing the “CSS cascade” to determine the final rules for a given DOM element, and keeping in mind all classes that apply.

The dev tools often cannot save styles back to your source code when you use a build step.

Even if I get my file switch down to 16ms, it is 16ms more than 0.

If I can view the JSX and see all the final styles on the element or on a nearby parent, it results in a faster feedback loop.

I am not for or against Tailwind, as I have mentioned this directness causes a lot of classes on single elements which can be hard to read later, but is often faster to edit whilst you are writing it.

[nawgz]

> It’s not just the “jumping between files” that takes longer

This language you've used is imprecise and suggests jumping between files is a problem. The alternative is jumping from your IDE to Tailwind docs unless you are a tailwind expert no? This sounds like I'd measure it in seconds and not make a facile 16ms estimate so I could write 16ms > 0 and look smart...

> The dev tools often cannot save styles back to your source code when you use a build step.

... 5 seconds ago you were arguing about speed of iteration, now the fastest possible iterator is a problem because you have to manually curate what you save in the end. How is this not a problem when you're just slapping classnames onto something and hoping it looks right? You have to go back thru your save history or to git when you fuck up, again something I'd measure in seconds

> If I can view the JSX and see all the final styles on the element or on a nearby parent, it results in a faster feedback loop

> It is also mentally computing the “CSS cascade” to determine the final rules for a given DOM element, and keeping in mind all classes that apply.

I just feel like you must be really bad at CSS to feel this way. CSS should interact with a component's private structure only in that component's CSS file, it should expose styling & sizing variables thru a CSS var API, and its top-level container's style & position are the only legally targetable things by someone else rendering it. This does not leave any room for having to "keep in mind all classes that apply", that is a drawback only to Tailwind.

Anyways, I don't get why you argue in this fashion just to walk it back at the end as "faster to edit whilst writing" when you discarded the fastest possible solution because of externalities to it that you're unwilling to consider here. For example, loading up a normal component, I simply glance at its CSS file to see all styles applied to it; not so many fancy layers. This means it is very fast to resume writing it. For Tailwind, you clearly need to first build the mental model of all the styles applied and any interactions between them, and then second you need to go to Tailwind docs to see what styles are actually being applied in terms of CSS. It has a layer of misdirection that drastically reduces speed if you don't just sweep it under the carpet. "Dev tools can't autosave for you" is an absurd complaint in the face of brushing all this aside

[justsomeuser]

I can work with or without Tailwind to be honest, I was commenting on the principles that are making Tailwind popular.

> The alternative is jumping from your IDE to Tailwind docs unless you are a tailwind expert no

No, as the class names directly map to CSS key/values and the IDE auto-completes the classes. If you know vanilla CSS, you would pick up the Tailwind classes quite quickly.

> "CSS should interact with a component's private structure only"

> "that is a drawback only to Tailwind"

CSS specificity/cascading is part of vanilla CSS.

And what happens to deeply nested components? Are you are using your build step to prevent CSS cascading, giving each of your component classes a UUID?

Instead of using the Chrome dev tools, I am currently using live reload to refresh the page after any HTML/CSS changes.

When you edit your HTML + CSS in the dev tools for fast feedback, are these edits written back to your CSS source files (I assume this is not possible, as they are part of the build process)?

What's your CSS build set up?

[nawgz]

> > The alternative is jumping from your IDE to Tailwind docs unless you are a tailwind expert no

> No, as the class names directly map to CSS key/values and the IDE auto-completes the classes

If true, definitely helpful, but I wouldn't necessarily say I agree with the assertion that it is a direct map. Looking at examples, I see craziness like `w-64` (width?) and `flex-none` (why?), and while I admit it is relatively terse it is quite clearly not just CSS.

> CSS specificity/cascading is part of vanilla CSS.

Yes, of course, but sharing CSS classes between disparate elements is the only time the developer has to consider CSS cascading, and so if you simply outlaw the practice you avoid the mental burden & all associated footguns entirely.

My CSS setup is React components styled with SASS. Each component HAS to expose a `className` hook which blends the consumer-provided className with the component. i.e. <MyComponent className="SomeOtherClass" /> ==> <div class="MyComponent SomeOtherClass" />

The styles are private to each component, using only a few shared classes such as flex-* which behave as tailwind classes, but don't really specify anything fancy. Reuse of CSS if necessary is done thru mixins, but I generally don't find much need for CSS reuse.

When I want to change my CSS, I just directly use the browser's dev tools, and then port it back myself. If my component exposes some structure, let's say like a ConfirmationModal, then the the classes are extremely easy to spot: <MyConfirmationModal className="AnotherClass" title={x} onConfirm={someFn} onCancel={someFn} /> ==>

    <div class="MyConfirmationModal AnotherClass">
      <h3 class="MyConfirmationModal-title">{props.title}</h3>
      <div class="MyConfirmationModal-userMessage">{props.userMessage}</div>
      <div class="MyConfirmationModal-controls">
        <Button text="Confirm" onChange={props.onConfirm} />
        <Button text="Cancel" onChange={props.onCancel} />. 
      </div>
    </div>

No shared styles exist. Very easy to reason about. Editing something in dev tools edits something like MyConfirmationModal-userMessage which is going to be very easy to find in code. I usually write it in the browser and "stage" the text into in my CSS file but without saving if I need to modify multiple not-closely-grouped styles, but this isn't really a common flow so I just slap it into dev tools til it looks right then copy-paste into the corresponding block in my SASS structure

[dimal]

I guess I've never seen the problem with switching files. I have two tabs open and use cmd-shift-] and cmd-shift-[ to flip back and forth quickly. There's no friction at all. The benefits of keeping the concerns separate outweighs any benefits to only having one file open.