https://t.co/IsSXUUaj2t versus https://t.co/dZ21dSbcEc is kind of depressing. Both “sides” have valid concerns but neither is listening.
— Zach Leatherman (@zachleat) May 9, 2018
I share Zach’s concerns.
Be cautious over dogmatic “one way” approaches. Context is key.
Approach the solution based on the teams skill-set and their desired objectives within the context of time and money.
HTML’s primary purpose is to add context around content. That content is then styled using CSS. Due to the nature that we all think in different ways. We need to share content in ever differing approaches. Some areas may be standardised but even subtle differences can change context entirely. This uncertainty in delivery leads to the fact that CSS must adapt in many ways to accommodate content in a design that can be entirely unique. Now layer interaction on top and it can alter the context of the content further.
In a scenario where a team must deliver unique content in an innovative way (because marketing) with fixed time and money constraints, there will never be “one way”.
Best practice approaches only become best practice when X and Y and Z all align. Which is not always the case.
We need to move the conversation away from “which is better”.
Code has a limited shelf life.
Instead think about the following when starting out:
- Is it easy to maintain by our team?
- How easily can we hire new team members with the required skill-set?
- Can you add new features simply?
- What are the code base pain points. Can you live with them?
- How quickly can a junior learn their way around the system and is this an acceptable time frame to you?
- Are any of the primary dependencies likely to stop being supported or go out of business anytime soon?
Remember tools are exactly that. Tools. Use the right tool for the right job at the right time.