jail is not that bad.
39 karma · joined January 30, 2016
It may be hard to see now how it will bite you now, but I promise you, it will. It would take hours to explain why, but I am speaking from years of experience here.
There is a reason large organizations have abandoned this approach, and it isn’t just personal preference.
This talk gives a pretty good explanation, Airbnb.design, Netflix, Facebook, and Instagram have many others
these inconsistencies compound, especially across teams.
I like to say, that with components, you encounter “a new level of bugs.”
With Functional CSS, you deal mostly with incidental bugs. “This container has margin 10 and this one has 15!” or “This text-red is overriding all my text!” Individually, these are annoying, but together they can compound into unfuckable problems. Right now I’m working on rebuilding a header that was styled with this approach, and ultimatley wound up unable to remove certain classes without breaking other elements. Something as simple as moving the text from one side of the screen to the other involves building an understanding of how they work individually, which is very challenging in a site as large as ours.
Enter my new header, a component. Its got a parent of .HeaderComponent and everything is scoped inside of it. If I delete, say, a .Link here, it doesnt affect links elsewhere on the site. And since I include re-usable mixins for base styles, like text, its easy to (say) @include BodyFont; or HeaderFont; without affecting the page or the site as a whole.
What I mean when I say “a new level of bugs” is that how and why you build things becomes more important. If I build a header component, but a large change happens elsewhere on the site, its unlikely I will change my original component. I’ll make something new and call that, instead.
In this process you can wind up with poorly built components, things that wind up not being used as much as you thought, etc. But the beauty of it is that getting rid of them is SIMPLE. I made a lot of mistakes when I started building doggos.com with components, but I’m really excited about how easy they were to remove. If you just make something new when you need something new, you wont have a bunch of legacy code following you around everywhere.
That probably isn’t a greaaat explanation, but I’m very happy to expand further or give you some links. In particular, Airbnb.design has some great lessons on why they ultimately went this direction, and they do a much better job of explaining it than I!
In general, with component CSS, you will tend to avoid the cascade, except within your component. This is actually where utility classes have some value - if they're scoped very tightly to the parent, and their effects are well-understood - then your single purpose class can add an easy way to do simple updates.
That being said, for my part, and on my own website (doggos.com) we do not use any form of utility classes whatsoever. The entire website depends upon isolation, and through this isolation, I have a degree of control that I've not found in applications that have opted for other methods.
In short, it's worked very well for us.
As for your dark mode example... you should take a look at how Apple made dark mode a reality with their new Mojave update. I think you will be surprised at the level of isolation their interface demands and, although we're no longer talking about the web here, just how easy it was for them to implement...relatively speaking.
In short, I can make a site go dark with components, no problem.
When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly.
Over the years, however, the site got more popular, and now the demands of the interface are increasing. At one point, it was perfectly OK to do, say, “container mt-5 mb-5 p-20 text-green” etc. This flexibility allowed the site to grow, and while the CSS did bloat, the impact was seen as negligible for years.
Now the site sees 50-80k+ DAU, and seeing as the business is very established, it makes sense that we would want to add bells and whistles to the UI that wasn’t on the roadmap those years ago, like theming, widgets, or simply making a previously non-responsive page responsive.
In Tachyons, and in Tailwind, the abundance of utility classes means that even the best, most organized authors will create inconsistencies. The original container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5” in others.
It may seem trivial to just add and remove classes at will, but it isn’t. Removing a margin-bottom from one element inevitably affects the position of another on the same page, and trying to reconcile these inconsistencies _usually_ means an override, because figuring out how to rearrange functional classes without breaking anything else is a time suck.
Removing this style of CSS from the project has been tedious, but necessary. Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. And you avoid the unexpected inconsistencies created using utility classes by, well, avoiding them. As someone that used to love BEM, tachyons, Atomic CSS, etc., the lack of scope, unpredictability and huuuuge bloat created by overrides steers me away from it even for the tiniest of projects.
What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms?
Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.
Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster fire of styles that is objectively worse than just writing regular CSS.
<sarcasm> But it's convenient, right? So who cares! AirBnB, Facebook, Walmart, Github, and Twitter are all probably wrong anyway. </sarcasm>
With this method of CSS it will take years to consolidate, update and redesign your application. Ask me how I know. :-)
In my experience working on a web app that sees +80k DAU, the most difficult updates to our UI are ALWAYS in the cases where somebody wasnt cogniscent of the cascade. Or was, and used it when they shouldn’t have.
IMO, theres a lot of pushback to this technique and not a lot of questions into its benefits, but plenty of questions as to why its “just like this” so “why should I use it.”
I encourage you to consider the benefits of an isolated approach to UI, or perhaps try building something with it and see how the method compares to your current approach.
Or, we can all go on assuming that Airbnb, Facebook, IG, et al, have all opted into this approach for no reason
I see no reason why ESPN/NFL/et al., can't provide comprehensive health insurance to every current & former player for life - as reducing the violence of the sport doesn't really seem to be on the table, broadly speaking.
For example, the pebble bed reactor system eliminates the risk of a meltdown by no longer storing spent fuel in rods; it also makes the process for extracting fuel significantly more efficient. Presently we can only extract about 4% of energy contained in nuclear materials, with a PBR system the "pebbles" stay in circulation for longer, meaning we can extract more energy and pursue new designs that could ingratiate these systems into our cities without the catastrophic risks we face today.
The more people focus on this technology, the better it will get. But we can't improve if we don't try.
All breeders (in theory) are breeding to the "breed standard," which means if the standard says to breed unhealthy dogs then that's what they do. Because of the existence of the standard in its current state, even 'pet owners' (rather than dog showers/breeders) will be forced to buy dogs that are unhealthy. It is by design. This is precisely why it must be changed.
I am of course referring to the English Bulldog when I say "all" (this variety is overwhelmingly unhealthy) whereas the American variety seems to be significantly better off.
So - YES, we should change the standard to focus on health. But - NO, breeders are not "the minority." Not all breeders show their dogs, not all handlers breed the dogs they show, but because they are the ones doing the breeding, the responsibility begins with them.
On the other hand, I can't for the life of me figure out why someone in their right mind would buy a bulldog. lol. They slobber and fart and cost a small fortune just to keep alive for a reasonable period of time. Not to mention they literally cannot give birth without a C-section which, to me, is just unfathomable to put an animal through just because you like the way the animal looks. But to each their own, eh?
> "Stipulating that you can only get that package of attributes in a health-compromised breed, I don't think you have a very strong argument"
Not sure what you mean by this. Can you elaborate?
If you want an apartment-sized dog that has like, no health issues, adopt a pit bull. Adopt a mutt. Adopt a labrador. If the dog tears up your shit, hire a trainer. If it needs exercise, exercise it more. Etc.
You can certainly choose a breed (or mix) that will have a significantly better quality of life without sacrificing anything personally. In which case, why would you instead choose a breed that is for-sure without-a-doubt no-way-around-it riddled with problems? The ethical negative seems obvious because there are plenty of other dogs that fit the bill without sacrificing their health from jump.
I will agree with you on education being an important factor in choosing a dog. But very few people have the in-depth education required to make that choice in the first place so, like I said, the responsibility ultimately falls on the BREEDER.
I blame dog breeders for knowing better and breeding the dogs anyway.
Never say "ethically obligated" and "euthanasia" in the same sentence. That is asking the wrong question - but for the record the answer is no. Obviously. In addition to such a thing being impossible, there are easier ways forward. :-)
On suffering, the fact of the matter is that the dogs really have no idea that they're suffering. They just exist. They know nothing more than what they are exposed to, and what they perceive.
I feel that if we are obligated to do anything, it is simply to change how and for what purpose we breed animals. Deciding that the pug can still exist - with a longer nose - or that the Dalmatian can exist after they breed out their uric acid problem is attainable. It just takes work. And support, from pet owners and breed lovers, to guide people and to vote with their money.
Some of the founding Shepherd's were white! The foundation stud, Grief, was white. The creator of the breed is on record saying that white dogs have no less working capacity than any other color... So what happened?
Turns out, this was due largely to nazi influence, too. The WWII era really transformed the German Shepherd. From a pastoral sheep-herding companion came a military machine. White dogs, while good at blending in with the flock and being spotted by a Shepherd in the field, were not so good on the battlefield, unfortunately for the same reasons. You can see them coming at night, they are easy targets on a black mountainside.
In other words, the ideas of the time have an ENORMOUS impact on the dogs we create. I don't doubt the Giant Schnauzer story for a second. Breeds evolve to suit the government, the people, and the culture that they are born into...