aridiculous

“The game looks easy, that’s why it sells” - Elliott Smith

I personally think we have this all wrong, and that all species should have to comply with some level of public decorum to be allowed in public human-dominated spaces.

If a dog doesn't make loud noises, physically agitates others, or excessively spread diseases (slobbering all over the place), it seems fine to let them be in the same place. If someone has allergies, an agreement can usually be worked out to create distance, but if it can't we should favor the human.

So in a sense, I agree with you: They should have licenses that can be revoked based on their behavior. I don't really care if they're for service reasons or otherwise, I just care they're fit to be in public. Some dogs are, some aren't. Basically, we should be comfortable with fascistic enforcement around dog's behaviorally. That seems like a healthy middle-ground.

Seems like a lot of the comments are not getting it.

The purpose of tokens is be able to have a single language-agnostic source of truth for the core bits of the design decisions.

Let's say you have a website, an iOS app, an Android app, Figma templates, and documentation. Let's also say your main brand color is currently a certain shade of green.

When your brand evolves to a different shade of green, you update one value in one place. All of the above surfaces are updated at the same time.

This was not a thing with Bootstrap, and it's not a thing with CSS variables and derived values. This is an organizational tool that increases in value as a multi-platform company grows.

It's true that most websites and apps probably don't work this way today. I've worked in a lot of them, and they were not pleasant developer experiences burning up way more developer time than necessary. They become unwieldy at any kind of scale, producing all kinds of visual bugs and incongruencies on every single engineer PR.

An interesting question would be: "how much does it matter that the visual language is consistent across a company's assets?". But the answer to the question of the utility of the design tokens is obvious if you do decide that design systems are important for a business.

Surprising to see Gross involved. He seems to be pretty baked into the YC world, which usually means "very commercially oriented".

Sounds like some low-hanging fruit for screenwriters wanting to make a great movie.

Remembering the old adage: don’t cheap out on anything that touches the floor (shoes, sofas, beds, cars, etc)

Seems to me like bowling rules could use an update. When every pro is so good that they are just competing on mental focus, the nature of the ball, and slight environmental factors like the changing slickness of the wood, it has ceased to become compelling competition. I’d love to see some kind of dynamic interaction between the players: e.g. if you hit your 3 pin, it gets added to the opposing player. Something like that.

I suppose this goes for all sports of this kind where the players actions don’t affect each other.

One of the few un-nuanced takes I have is that every component library/DS should be built on top of Radix or React-Aria or some other thorough but extensible library. If you’re implementing your own tooltips and menus, you’ve lost the plot. We need to stop reimplementing bad versions of commoditized bits of UI that overlook accessibility, appropriately generic prop APIs, boundary detection, composability, documentation, testing, etc.

It pains me to see dev teams spending time on rebuilding solved problems. I understand brownfield constraints, but the greenfield situations are particularly painful.

I’m in that stage now and this was a really good set of insights here (admittedly that I don’t quite fully understand). Open to DM? My email in profile.

The biggest issues I've had with Tailwind:

1) Adding it to an existing codebase with lots of global scope. The techniques espoused in the documentation simply don't work well with existing leaky CSS with varying levels of specificity. Adding important to all TW classes and name-spacing all of them invites new problems.

2) Making your own components with lots of variants: the syntax required feels like you're doing contortions to make it work nicely. There's probably some special techniques but it's a lot easier to take advantage of the cascade in my experience.

3) Dev tooling: the OP I think is dead-on in the criticism that you break a lot of browser tooling when using Tailwind. The right hand side of the Elements tab is a complete disaster. The JIT that Tailwind provides to only include styles you need also makes things annoying: If I want to add some classes on the fly in the Elements tab (which is annoying anyway by having to edit HTML), it won't work if you need any classes not currently not used in the built code. You can mitigate this with modifying your JIT setting for dev to include a ton of classes but it just doesn't flow. The TW documentation is very cagey about how dev flows should work and for good reason.

I actually like utility classes as a concept and if I were starting greenfield projects I might consider Tailwind with an existing component library despite the dev tooling issues. I just think it doesn't layer onto existing codebases well.

There’s nothing like good technical writing.