Easy isn't bad
Judge a method by your goals, not by how hard it feels.
Adam Wathan@adamwathanSo many debates I’ve seen in my career boil down to “if it’s easy, it must be bad.” Active record vs. data mapper, integration testing vs. isolated unit testing, and utility classes vs. semantic class names. “You’ll see eventually, you’ll regret taking the easy way out!”
Adam Wathan@adamwathan@jody_lecompte @tmcw @AdamRackis What’s the “proper way”? I’ve studied CSS architectures for a decade and utility classes have proven to be the proper way to structure CSS for the goals I have, which is to build custom designs, quickly, in a way that’s easy to maintain years down the road, and is performant.
Steps and rules are counted from the demo's own lists; goals follow the second post.
Add a part, then remove it
Add and delete parts, then read the checks for your goals.
Semantic namesHard way
Utility classesEasy way
<span class="inline-flex rounded-full bg-sky-600
px-2 text-xs text-white">New</span>Why it matters, pros and cons
Why it matters
Effort is not evidence. State the goals, then check what each method does against them.
Pros
- Goals turn a taste argument into checks you can count.
- An easy way that meets every goal has no hidden cost to pay.
- You stop defending the hard way as a matter of pride.
Cons
- Your goals may differ, and then the answer differs too.
- Easy can hide a cost that only appears years later.
- A short list of goals can leave out what matters to you.