3 ms·

Tailwind has shown that, absent personnel with expertise and time to focus on a design system separating relevant concerns and/or absent tooling that can give y

Tailwind has shown that, absent personnel with expertise and time to focus on a design system separating relevant concerns and/or absent tooling that can give you read/write changes, inline declaration of a somewhat constrained set of predefined options solves certain specific problems. A lot of the related complaints -- including some in this article -- basically boil down to the old complaint about object oriented programming: "everything happens somewhere else" so what's actually going on isn't something you can read in one place, you either have to wind your way through the various scope/inheritance contexts to build up a picture of the code/rules in play, or you need to have tooling do it for you. Or... you put it inline, mixing concerns, and eventually discover the tradeoff that comes with that choice.

labster 3y ago
The thing about OOP is that you can always trace down the methods as they’re called, or look at the parent class. JS can come from any place, reminding me of PLEASE COME FROM in INTERCAL. It’s not that, the fundamental issue is that the DOM is a big global that everything has access to. But you can’t look at a piece of HTML and know for sure it doesn’t have an event bound to it without reading every scrap of JS (or just running the code). In OOP at least you (should) have some guarantees of encapsulation. But since I don’t see an obvious way to make HTML more OO, I can see the appeal of a declarative style.