Sunday, April 28, 2024
HomeCSSIn Defence of Dangerous Code

In Defence of Dangerous Code


I noticed a tweet the opposite day from Christian Heilmann of Microsoft (previously of Mozilla), an enormous title within the internet trade and tech convention circuit:

It wasn’t the tweet itself that rankled – I personally have rolled my eyes at related chunks of code every so often, and Christian didn’t explicitly make any additional touch upon it. It was the replies within the thread beneath that obtained to me. As a result of they have been practically all (on the time of writing), alongside the traces of “Oh my god, that’s disgusting, how may somebody write code like that”, and naturally, the sanctimonious “I personally by no means noticed the purpose in [utility classes, BEM, etc – insert here]”. Individuals appeared to take vindication from the unique tweet, as if it proved that that they had been proper all alongside, and that it was all the time inevitable that these new-fangled CSS methodologies have been all the time going to steer straight to hell – and naturally, they’d by no means write code like that themselves.

Leaving apart for a second the truth that we’re speaking about A BUTTON – and customers don’t give a crap what number of courses a factor has, so long as it appears to be like like a button and behaves like a button – it’s all too simple for me to think about how this poor little component’s code may have gotten thus far. And I’m fairly positive I’m not the one one who can recall writing code like this at a while or one other.

Image the scene, if you’ll:

Dev 1: Hello, welcome to the staff! We use BEM right here. Anyway, right here’s a UI to construct.

Dev 2: Okay, cool. Nicely, I can see that this factor right here goes to be a button, so I’m going to name it button. That manner at any time when somebody makes use of it they’ll have a factor that appears like a button. Even after we need to model an anchor tag to appear to be a button (which occurs rather a lot), we’ll be capable of use this class.

Later…

Dev 2: This button wants an icon, which requires me to model the button a little bit in another way, however I need to hold my code as DRY and reusable as attainable, so I’m going to create a modifier class referred to as button–withIcon.

Nonetheless later…

Dev 2: We’ve been utilizing icon fonts in every single place, however it seems this button’s icon must animate a little bit bit, so I’m going to make use of an SVG for that as a substitute. I’ll add this class, button–withSVGIcon so I can model the icon’s animations in my _button.scss file, since they’re particular to buttons solely. I need to hold all of the types from button–icon and simply layer these animation types on high, so I’ll depart each courses in there.

Nonetheless later…

Designer: We’ve obtained some suggestions from the consumer, and this explicit button’s going for use on a lightweight background, so we have to make the color a bit darker right here so it’s extra user-friendly. We don’t need to have an effect on any of the opposite locations the button goes for use on the location.

Dev 2: Okay, I’ll add a modifier class: button–dark will give a darker variant of the button, for gentle backgrounds.

Designer: We additionally need to eliminate that chrome impact right here, it’s not proper for this explicit button.

Dev 2: Nice, button–chromeless will likely be helpful for after we need flat-style buttons.

6 months later…

Dev 3: Proper I must do some fast amends to this video element with the button right here. I don’t need to mess with these current courses as they’re in all probability getting used elsewhere, however we’ve been taking a utility-first strategy to CSS recently, so I’m simply gonna add a few utility courses so as to add a couple of little styling tweaks to this one.

It’s too exhausting to think about how that class checklist may get out of hand.

Any what’s so dangerous about this code, anyway? Do these courses resolve the issues at hand? Most likely. Do they hinder the person? Unlikely. The developer who has to keep up it’s possibly inconvenienced, however however, these courses inform us roughly what that piece of the UI ought to appear to be and the place we are able to discover the corresponding CSS, they usually’re reusable too, so possibly it’s not all dangerous.

How typically do you return to outdated initiatives and have a look at your code – any code – and suppose “Ugh, what was I pondering?”. For me anyway, it’s fairly typically. Positive, you begin each undertaking with the very best intentions of holding your code tremendous clear and tidy, and for some time possibly all goes to plan. However in an company setting, earlier than lengthy you’re dashing to satisfy deadlines and get initiatives out the door. It’s a must to weigh up time spent refactoring towards including a fast and soiled hack that solves the issue at hand. And very often, that’s adequate. Don’t really feel dangerous about it, transfer on and attempt to study classes for subsequent time.

In a big, consistently evolving codebase that must be maintained then refactoring might be worthwhile, however typically it’s not.

With the very best will on the earth, initiatives evolve, performance must be bolted on, and sometimes a fast repair with a utility class is preferable to 2+ hours of refactoring, particularly when {that a} undertaking doesn’t should be maintained all that usually. Since I first learn the Twitter thread many individuals have added replies suggesting many alternative methodolgies for enhancing this button’s code. Which form of proves my level.

So let’s not code-shame one another. Every undertaking and every staff has its personal wants. Perhaps you want BEM, or possibly you like SMACSS. Perhaps you favour utility courses, maybe as few courses as attainable. Perhaps CSS-in-JS is extra your bag. All are completely legitimate, every has totally different strengths and weaknesses. So long as you attempt to persist with one and use it constantly (particularly in a staff) issues will likely be high-quality, and if it’s a must to throw in some hacky stuff every so often the world in all probability gained’t finish. We’ve higher instruments than ever earlier than to assist us debug even the messiest code, and whilst you ought to all the time attempt to depart a codebase in a greater state than you discovered it, even that’s subjective.

And, if doubtful, all the time bear in mind the golden rule: Remark The F*** Out Of It.

Thanks for studying this far. As a side-note, this Twitter thread from Rachel Smith says all this far more concisely.



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments