class soup is what tailwind is. It's terrible because is just abbreviations of css attributes which you still need to know because you'll inevitably fiddle around devtools trying things out.
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.
> how can it spill out onto the page? it's inline css.
Because people are lazy and don’t make a component for everything. And some people are even lazier and don’t make UI components at all. I’ve seen a project where there was a Button component and that’s it. Well, that was vibe coded probably so makes sense.
> Inline soup works better than looking for styling on different files in the context of the project, so here we are.
Only if you have a separate .css. If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file. Maybe the proximity to markup within the file is important?
But no, Tailwind has been rising in popularity long before LLMs came along.
[I'm assuming styled-components was the preferred css-in-js solution until recently]
> 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.
Yeah, I mean, with either Tailwind or styled-components you want to contain them to “UI components” – e.g. <Button> or <Navbar>. You could mix in some logic, and you’re right, looks like many styled-components folks will split it into two files then – but honestly I would just do in one.
Personally, I’m a Svelte fan, and I think they got it right – you just write <style> in your component and that’s it. I think Vue works in a similar way, too.
> 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.
I saw this on another recent tailwind thread and I’m not sure I agree. LLM might be helping adoption, but I’ve been seeing and using tailwind for years without really going near LLM coding
My take is that, biologically, creating an attractive female is easier than creating an attractive male, specifically regarding facial attractiveness. A symmetrical female child is almost guaranteed to grow up to be attractive, whereas the same isn't true for a boy. The "right" hormonal profile needed to develop attractive male features is rarer than what women require. A symmetrical girl who doesn't develop pronounced secondary sexual traits (such as full lips or prominent cheeks) is still generally considered attractive to both men and women. In contrast, masculine faces that lack strong jawlines or brow width usually aren't. Additionally, high testosterone can backfire in men, leading to overdeveloped brows or nose bridges, which may reduce attractiveness.
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.
pre-filters typically have specified "capacity" in gallons. which is measurable. also if water is very dirty filters get clogged and pressure dropped. it's also measurable.
"post re-mineralization stage" is actually "ph adjustment".
I know pressure drops. The problem is knowing which filter is the one causing it in particular. Also, filters that are spent at different rates are a PITA. What I mean is if you are going to feed it nominally clean tap water, there's no reason to protect a catridge with equally or more expensive cartridges. Just use the RO filter and be done with it.
you can put pressure guages in between or one of $10 flow meters before system.
RO membrane doesn't remove chlorine iirc or vocs. On the other side chlorine degrades membrane. "nominally clean tap water" can have enough dirt to clog membrane if you don't auto backflush it frequently
It isnt merely ph adjustment... You want some amount of minerals in water for your health, plants, and taste. Changing the PH isnt the concern in most cases, its just part of the result.
All those filters are specifically made for PH adjustment (you are welcome to look at specs). There are bunch of different formulations depends on how much PH adjustment is needed.
RO makes water more acidic. if water was somewhat acidic to start with, it can get more acidic or become corrosive.
Are you sure that it makes it more acidic? AFAIK it only outputs pure H20, should be neutral. If you feed it alkaline water you'll get "more acidic" water, but the other way if you feed it acidic water.
True. But have tasted distilled water? Tastes metalic. Probably just my imagination but I feel like it pulls stuff from the mucous in your mouth and tastes like blood.
was the left ever truly anti-immigration? I genuinely ask. Because the last leftwing explicitly pro-union movement I can remember was the late 90s/2000s anti-globalists, the ones that used to protest the G7 summits and the like. But they were in favor of immigration, so it always seemed contradictory.
Anyway, it's not like the right doesn't have its own equally contradictory positions.
I don't think so. You can argue emmigration takes away supply in the labor side. Why would prices go down? Quite the contrary.
I don't think it necessarily raises salaries in India though, because that market seems to have a hard cap somewhere around 36k/year but it sure does opens up positions for newcomers.
yup, honestly this whole take is so tired. Its a factoid pulled out of nowhere.
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.
Your counterexample make me think you've misunderstood the point from the start.
Devs design games to look good on the target platform. Obviously you can achieve gradient effects with a CRT and 16-bit color that are very different from a four-tone LCD. Both things can be true.
> 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.
The author said "often," not "always." The entire point of the article is to explore the details of the phenomenon and show that it's not as clear-cut as people think. What are you disagreeing with?
And your gameboy examples are not counter points to the fact that games were designed around a target screen limitation. They weren't designed around a CRT quirk, but they were designed around their own LCD quirk instead.
The first gameboy's screen was painfully bad, with a lot of ghosting during movement.
There was even a game that exploited the screen of the original gameboy to achieve a transparency effect in a spirit (but not implementation) similar to how Sonic devs created transparency on CRTs on the genesis.
In this case, artificial flickering doesn't look like flicker on the original gameboy screen because it had a lot of ghosting. But it looks terrible on an emulator.
You don't get those effects playing the same games on a modern computer monitor.
The various gameboys, and even the advance, were not as crips as you remember them to be, their LCDs weren't particularly high quality stuff. None of the original pixel art of those times were meant to look the way they look on a modern high contrast, high luminance, high resolution LCD or OLED screens of today.
It's particularly true as soon as movement is involved as the ghosting was intense and it was one of the weakness of early LCDs as a whole as even the best computer monitors that came out when LCDs started to show up on the market looked horrible in motion compared to a CRT or a Plasma.
So, the pixel art era was never about looking at a crisp image.
And many gameboy games look very, very wrong when run crisply on an emulator. They absolutely weren't meant to look like this. That batman game showing massive flickering around water looked fine on the original gameboy hardware.
I currently use GraphQL and have no problems with it specifically, I was merely sharing an experience using REST. Perhaps it adds a bit of latency/overhead due to the implementation/language that's used but with larger requests rounds downward.
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.
reply