To be fair, there was no shortage of apps (especially in Win9x era) that did ignore system colors. Which actually took some effort to do, and almost invariably the result would be a gaudy eyesore, but the "it's branding!" people were already around, albeit not as prevalent.
Anyway, the last version of Windows that still maintained this functionality (in "Classic" theme) was Win7; Win8 no longer had the ability to disable Aero.
I'm starting to run into the other end of this as a reviewer, and I hate it.
Stories full of nonsensical, clearly LLM-generated acceptance requirements containing implementation details which are completely unrelated to how the feature actually needs to work in our product. Fine, I didn't need them anyway.
PRs with those useless, uniformly-formatted LLM-generated descriptions which don't do what a PR description should do, with a half-arsed LLM attempt at summary of the code changes and links to the files in the PR description. It would have been nice if you had told me what your PR is for and what your intent as the author is, and maybe to call out things which were relevant to the implementation I might have "why?" questions about. But fine, I guess, being able to read, understand and evaluate the code is part of my job as a reviewer.
---- < the line
PRs littered with obvious LLM comments you didn't care enough to take out, where something minor and harmless, but _completely pointless_ has been added (as in if you'd read and understood what this code does, you'd have removed it), with an LLM comment left in above it AND at the end of the line, where it feels like I'm the first person to have tried to read and understand the code, and I feel like asking open-ended questions like "Why was this line added?" to get you to actually read and think about what's supposed to be your code, rather than a review comment explaining why it's not needed acting as a direct conduit from me to your LLM's "You're absolutely right!" response.
This absolutely has been my more recent frustration as well, specifically this:
> uniformly-formatted LLM-generated descriptions which don't do what a PR description should do, with a half-arsed LLM attempt at summary of the code changes and links to the files in the PR description. It would have been nice if you had told me what your PR is for and what your intent as the author is, and maybe to call out things which were relevant to the implementation I might have "why?" questions about.
If I want to see what the code changes do, I will read the code. I want your PR description to tell me things like:
- What the tradeoffs, if any, to this implementation are
- If there were potential other approaches you decided not to follow for XYZ reason so that I don't make a comment asking about it
- If there is more work to be done, and if so what it is
- Any impacts this change might have on other systems
- etc.
Sure, if you want to add a handful of sentences summarizing the change at a high level just to get me in context, that's fine, but again if I want to see what changed, I will go look at what changed.
If you want something which removes Shorts more thoroughly, or alternatively gives you other options for using them intentionally, like redirecting to the normal video player so you can't get sucked into the scroll (e.g. if you only want to watch specific Shorts from a channel's Shorts tab), try Control Panel for YouTube [1]
It also recently got new options which let you disable or improve the new video player UI, and has options for removing other sources of algorithmic suggestions.
But users of it will also never (unless they're doing something very weird) unintentionally break styling somewhere else while editing it later or have it broken by changes made elsewhere, have to come up with names for one-off element-specific styles, or have to jump between multiple files for their pseudo, colour scheme-specific and responsive styling.
> have to come up with names for one-off element-specific styles
You never have to “name styles”. You have to identify the target element as different from other similar ones. There’s a subtle difference. I wonder if acknowledgement of that difference leads developers to pick different tools to help them manage their CSS.
> have to jump between multiple files for their pseudo, colour scheme-specific and responsive styling.
I’m gonna infer from this you’ve worked on large CSS codebases and know what you’re doing. I’m not trying to discourage you from whatever your doing: use Tailwind if it helps.
I’m just really interested in the problems and mental models that lead people towards Tailwind and similar tools. I’ve never felt drawn to them, despite also feeling the pain of sprawling CSS codebases. (I’ve worked on legacy CSS files so large that versions of IE stopped parsing them; I’ve refactored CSS repeated-but-not-quite across multiple teams’ reimplenetations of the main menu widget, etc).
I'm a big fan of the Tailwind approach, and I'll lay out some aspects of the mental model, or advantages of Tailwind that led me to it.
Here are the big problems the Tailwind approach solves for me:
1. No debugging of cascade/inheritance bugs. Tailwind almost entirely discourages use of the cascade and eliminates and entire class of bugs, possibly the largest and most difficult class of bugs to deal with.
2. Less complexity in css files. Naming the differences between the styles is standardized, so there's less mental overhead to learn, you're not reinventing the wheel between projects or within a single project.
As a bonus that leads to: Less bloat in css files. There is going to be less in there because Tailwind already sets up essentially the minimum number of classes needed to get any visual effect. There's much less css code written by devs to search through, it'll have less entropy.
The big change in mental model when working with Tailwind is that the styling is done in the html, not in the css. This is good! You end up being able to determine where the styles are coming from just from the source code without diving into dev tools. You can tell, at a quick glance, why an element looks the way it does, and can easily figure out how to change it. Not only that, but you can be confident any changes will not have side-effects on other elements throughout random parts of the codebase. Removing or adding a class will only affect the element you want to change.
My only concern when I went down that route (besides the common criticism of how it's ugly) is how difficult it would be to do something like change the appearance of every instance of a certain type of button. I can only say I have not run into a problem with that. And even if I did it has not come up often at all, whereas the problems that approach solved has made development significantly easier.
As for your last paragraph, I can give you my opinion.
I believe it's almost purely a developer experience thing. People want immediate feedback with hot reloading. They want to test out any little change right inline and get feedback without a mental context switch.
It explores the benefits of this. Personally I don't often use tailwind but I do often use inline style attributes just to preview how something would look, before I refactor it into actual classes and rules.
Love the I've seen things you people wouldn't believe tone of that last bit. _"I wonder if acknowledgement of that difference leads developers to pick different tools to help them manage their CSS"_ yes, this, I think. I've landed on components have their own classes but to share styling across apps I use components or css functions/variables, this has been the best balance for the designs I work with, since they tend to treat most elements as a 'bag of reused styles with some custom padding' most of the time, where reused styles are more custom than tailwind but not generic enough to make higher order components.
> I’m just really interested in the problems and mental models that lead people towards Tailwind and similar tools
What a refreshing thing to read compared to the usual language in web development-related topics on HN, where people are so often talking past each other, or just here to stick the boot into the topic in general.
The first thing which comes to mind is an app I worked on which had a sidebar which only a subset of users would see, and which was the only sidebar of its type in the entire app - if you were an insurance agent, it showed you the commission you would earn on the policy you were creating for your client, and how it was calculated. So a sidebar with a couple of different types of sections, headings, an itemised list and a total, some bold text here and there, and the app's "highlight" colour in a couple of places. A true one-off, not a framework for creating sidebars.
Structurally, that meant you had the sidebar container, sections and their contents, conceptually three-deep at worst (but deeper in terms of actual element nesting). This had been added to over time, as new requirements dictated, and I was tasked with adding a new, optional section at the end, depending on the type of policy. Exactly as you said, that requires that…
> You have to identify the target element as different from other similar ones
In this case, the original developer had started out using nested SCSS (so they didn't have to name anything, either! This was in an Angluar app, where styles are scoped to components) - styling was tightly-coupled to the structure of the particular markup which was used, which was probably easy to do given whatever the original requirements were. But as this was added to over time and by other developers, this file had grown into an hilarious nest of conditions. Make this text italic only if it's nested _here_ and directly follows a heading. Use flex justify-between for items nested here and here but _not_ here. Extra wrappers to shake off the existing styling. Patch-jobs to fix up what the existing CSS did to the new elements they needed to add.
This project wasn't even using Tailwind (and still isn't) and neither was I directly at the time, but I recognised that if you looked at the rat's nest of SCSS, _all_ it was doing was setting margins, paddings, colours and font styles, and that utility classes would be a much cleaner approach which wouldn't look any less ugly than what was already there. Tailwind had already done the work of naming things, so I added a new utility stylesheet to the app and copied some of its utilities into it, and recreated the sidebar in one file in one sitting with hot-reloaded styles, using the original as reference. I ended up deleting that SCSS file. That project is now using its own utility styles for one-off stuff like that and non-reused structural styling, regular old CSS for reusable styles for things which don't merit a component of their own, and the company's design system components.
I've seen similar results in free-range CSS codebases and ones using BEM-like or other conventions too, where people have had to invent "semantic" names when they need to do something different, rather than just "look, the designer's Figma says this section needs to have a different background colour and padding". And gods forbid if they tried to DRY up that CSS by moving styles which _happened_ to be common at the time up. It's always been multiple developers over a period of time, with changing requirements, mixed skillsets when it comes to web development, who just want to get shit done and move on. You _can_ hold it right with all of these ways of doing things, but if people are underthinking or undercaring about it, it doesn't tend to happen. Tailwind doesn't have a fix for that either, it just localises the blast radius somewhat.
This is my mental model for why I'm using Tailwind today in a React app, or any other component-based app framework or library: when I get requirements for a new chunk of UI I need to build, I'm immediately thinking about the state and the behaviour, I'm looking at what the designer has done in Figma, I'm mentally breaking down the layout into flexboxes and grids and spacing and our design system components in my mind, and I'm mentally mapping out the CSS for those. I create a new file, I sketch out the state and behaviour, I start creating the structure. I have the file open in my editor, the new component is hot-reloading in the browser. Tailwind is now the most route one way for me to translate what's in my head to the screen and get instant feedback. In the time it would have taken me to think of a name for a new CSS rule, add even just `display: flex;` to it and add the class name to the element, I've already typed `p-2 flex items-center gap-2` and started tweaking those spacings to match the design. Flip the app to dark mode. Tweak tweak tweak with some `dark:` classes and the design tokens we've added to our Tailwind config, all auto-completed nicely in the editor. Dark mode is done. Oh, what should this do on smaller screens? Reduce the size of the window. Tweak tweak tweak with some `md:`, `xs:`, whatever classes. Resize. Tweak. Resize. Tweak... Responsiveness is done. Now it needs to respond based on behaviour, let's `hover:` here and `focus:` this and `focus-within:` that and conditionally apply these properties here based on state. All in one file and one browser window for feedback. Nothing that can't be done perfectly fine in a regular stylesheet, but just so much less friction while implementing, in the same way that I'm also no longer thinking of identifiers to attach event handlers to and sticking code for those in a separate file.
If you want a live version of most of the site (including tracking new comments in items you've already looked at), I made this to improve my React skills when the HN API first came out:
I just wish there was a dark mode.. Let me install night reader to see how well it looks :p
Edit: would've loved if there was a way to sign up or make comments from there, oh well :< I wish there was, I am not sure if that's possible tho but I hope it could be.
[^1]: https://soitis.dev/control-panel-for-youtube
reply