> If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file.

I mean you can but "best practice" all around has been to put them separate and that's reflected in the majority of github repos in the training data of the LLMs.

> Maybe the proximity to markup within the file is important?

that's my assumption, yes. Seems to me LLMs work best when they output the relevant tokens right there with the markup instead of referencing some previous tokens even if relatively close.

styled components was the recommended solution in popular UI libraries like React MUI up until 2023 when chatgpt came out. Tailwind REALLY blew up with LLMs.

The only "smart" thing about it is leaning strongly on using rem.

how can it spill out onto the page? it's inline css. The (rare) inline selectors target only descendants.

Truth is that it's winning over because it works best with LLMs. Inline soup works better than looking for styling on different files in the context of the project, so here we are.

Some units give you different fixed timespans for each. For that reason, I just use the Reverse Osmosis stage and ignore the rest. RO is the last step, and in theory it renders pure water meaning the only reason to have the previous ones is to pre-filter somewhat the water and extend the RO cartridge lifespan. Problem with that is, first, there's no way to gauge when each filter is spent. Second, they're priced the same anyway, so why even bother. Just go straight from tap to RO! Keep the post re-mineralization stage if you want.

> blocky pixel art often is a kind of misdirected, anachronistic nostalgia.

and my point was that blocky pixel art is a faithful representation of an important percentage of games of the era, even though some other games of the era were not meant to be "blocky" many indeed where as the gameboy proves.

> blocky pixel art often is a kind of misdirected, anachronistic nostalgia.

And no, blocky pixel art is a faithful representation of an important percentage of games from the 8bit to 16bit generations.

and the counterexample is easy: the gameboy launched with LCD screens and games definitely where meant to look blocky. The pokemon games are perhaps the most influential nowadays in terms of pixelart style and show all examples of it: the very blocky styles of the overhead view and the more detailed pictures of the pokemon. They also cover the 8-bit and 16-bit era with the gameboy advance.

there's lots of other benefits for GQL: multiple queries per request, mutation/query separation, typed errors, subscriptions support.