You mean on Iraqi landscapes?

ABAP

Right - it should have been:

document.querySelectorAll('span#copyright_year').forEach((el) => { el.innerText = new Date().getFullYear() })

so that we update all spans with that ID!

Well… No new ones, at least? Though it was around that time that I started hearing whispers in the night… “You can use WASM to ship Client-Side PHP”

I’ve once written a JS decompiler (de-bundler?) using ~150 regex for step-wise transformations. Worked surprisingly well!

Imma do it this evening, so hydrate up, bud

https://github.com/facebook/prop-types/blob/4de0644a10a554d0a556daa39f029369bc007ea5/lib%2FReactPropTypesSecret.js#L10

Crazy what other commenters are coming up with.

Not in my code

I sometimes use n as my loop variable (⌐■_■)

Nah, it’s actually publ;c

It’s not necessarily awful by itself (though this is not a production-ready implementation). shit is the name of the project, Shell Git.

Always read mails really fast

I guess it comes down to preference. I personally don’t mind scrolling down a little bit to see my styles if it means the structure of the component is cleaner. I’ve found that I can iterate faster that way. If things get too unwieldy, that usually indicates to me that I should extract something out into a separate component.

It definitely is, everyone should develop the way they are most comfortable. That’s Tailwind for a lot of people, but it will never be everone.

About point 3. At least in svelte, you don’t have to worry about having unique class names. The styles are scoped to the component. Meaning that the CSS you write in one component doesn’t affect any other components (unless you explicitly want it to). So you can reuse class names on multiple components and they won’t interfere with each other. for small components, I’ll often not even use class names if I can get away with it. I’ll just use element selectors.

I was talking about having to find unique class names inside a scoped context. Even from that perspective, my complaint is nevertheless completely valid - it’s still a lot of overhead and has been my biggest painpoint when maintaining a lot of applications in the past.

It’s not just “opening a website in a browser”. The UI itself is displayed in a WebView, but Electron (and Tauri etc.) also have code running outside the WebView which interfaces with native APIs etc. Just for a simple example - a normal browser application couldn’t open a file on your drive before without showing a dialog (and it still can’t without getting permission first), which Electron etc. can.

And this code is absolutely cross-platform. So how is it rich to call an application with a cross-platform UI and cross-platform functionality “cross-platform”?

IMO, scoped styling removes Tailwind’s usefulness.

It does remove a small aspect of its usefulness, but the other ones I’ve mentioned still exist.

I’ll use Svelte as an example. In Svelte, you can just put a style tag at the bottom of your component, and everything you put in there is automatically scoped to it. I’m not hunting through dozens a CSS files trying to find where a class was overridden and adding !important everywhere. Using vanilla CSS allows me to keep my markup clean and concise so I can better see the actual structure of each component without dozens of CSS class names cluttering everything up.

Several points:

1. You still have to hunt through the file to find any selectors applying to your elements. There’s still a bunch of vertical jumping around.
2. How often do you actually need to see the structure of your DOM without styles? I want to see it with styles much more often than without.
3. You still have to come up with unique class names for everything in your DOM, or you’ll have brittle selectors. This means that for every single component in every single project I have to learn the class names, and they might even change over time. This is a lot of overhead.

In my experience, Tailwind was good as long as I didn’t try to do anything too interesting. What ended up happening in my project was that I would use Tailwind classes for basic styling, then break into vanilla CSS whenever Tailwind wasn’t sufficient. And that meant I was looking in multiple places to see what styling was affecting my component… which kinda defeated the purpose of using Tailwind.

You almost always have to look in multiple places with normal CSS styling, since it’s cascading. If I can solve 95+% of my apps styling needs inline and just break out for special cases, I still remove most of the jumping around and class name overhead and so on. This is still a massive advantage.

Tailwind isn’t any more or less DRY than normal CSS.

First off, it’s rare to use CSS in the intended way these days - scoped styling has become very popular for good reasons, which means component styles are either already separated, or you’re importing things. This doesn’t change with Tailwind, you can still import things just the same.

But where it shines is removing the need for arbitrary class names. Almost every CSS codebase I’ve seen used class names differently, sometimes even for the same thing. How often have you seen .container overloaded with different meanings? Instead of having to come up with individual class names that might or might not actually be descriptive, I connect the styles to the elements that use them. No more jumping around between CSS and JS, no more arbitrary names - classes have well-defined name structures that you learn once, and use for every project after that.

Sure, some people will have that reaction. In my anecdotal experience you’re part of the absolute minority though, at least 80% of devs I know who have tried Tailwind love it.

I’ve seen plenty of people say what you’re saying - though they usually change their tone once they’ve actually tried Tailwind.

Only for the null case. For other cases it doesn’t function identically, since it also treats "", 0 and undefined the same as null.

Not strictly equivalent, since || tests for truthiness, not just null.