3 ms·

IMHO main issue is that you suffer from the same problem that killed jQuery. By separating html and the logic affecting that html (css in this case, and event h

IMHO main issue is that you suffer from the same problem that killed jQuery. By separating html and the logic affecting that html (css in this case, and event handlers for jQuery), you might make it look cleaner, but you also make it much harder to track what is affecting what. You need to scroll up and down to follow what's going on, you might miss that there's say 3 buttons with this class you defined and not just 2, etc. And as the complexity grows, it gets exponentially harder to manage it and it quickly can turn into a mess. Components help keeping the html short, so this approach is certainly working better than with the old monolith pages, but it's still more work to have single .button and then look up its styles, then to have all the utility classes directly on it. Also on bigger project you're almost guaranteed to have someone on the team who will insist on naming their classes in totally unintuitive way, or you'll end up with .big-blue-button that will at some moment end up red actually because they've been in hurry and forgot to rename the class. One of the biggest benefits from using the frameworks is the standardization and uniformity, you're guaranteed that everyone on the team now or anytime in the future will know exactly what classes/mixins/variables are available and will have a documentation on how to use them. You need extra people to meet the deadline, you just hire devs who know the framework and you're good to go, no extra onboarding needed to explain where the buttons variables are located, and where to apply which, and how to name their classes, etc.

rglullis 6y ago
Respectfully, I disagree about the comparison with jQuery. On the technical grounds, you are right that the biggest thing against jQuery was that it operated on the global context and that made large codebases messy, and that CSS alone might lead to a similar experience. But I am not talking about CSS, I am talking about having an organized SASS framework, which can provide the utility classes (mixins) and which then your code would be organized by "base elements/components/pages" along with variable definitions. The approach I am using and suggesting does require a certain discipline. It will also require that the whole team conforms to the idea that no class should represent presentation directives. But in my view this discipline not only would be beneficial in the long term, the separation of concerns would improve the chances of making reusable components and design systems that are easier to improve on its own, separate from the specifics of each underlying website/webapp that tries to adopt it.

rglullis 6y ago

Respectfully, I disagree about the comparison with jQuery. On the technical grounds, you are right that the biggest thing against jQuery was that it operated on the global context and that made large codebases messy, and that CSS alone might lead to a similar experience. But I am not talking about CSS, I am talking about having an organized SASS framework, which can provide the utility classes (mixins) and which then your code would be organized by "base elements/components/pages" along with variable definitions. The approach I am using and suggesting does require a certain discipline. It will also require that the whole team conforms to the idea that no class should represent presentation directives. But in my view this discipline not only would be beneficial in the long term, the separation of concerns would improve the chances of making reusable components and design systems that are easier to improve on its own, separate from the specifics of each underlying website/webapp that tries to adopt it.