I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
It also cost readability. It's ok if you end up writing simple semantic markup (but then, everything's ok if you do that). If you rely on multiple nested divs with obfuscated class names then it'll be harder to debug and you'll annoy a lot of "tinkerers"... tinkerers like you and me.
It's the sort of thing people do to prevent the use of ad blockers, or stop people from re-skinning a site with user styles.
Personally, I want people to be able to change the look and feel of any page I make, because people have different needs, abilities and limitations.
Not sure what you mean here, the thing with the class names getting garbled is something every styling solution (that supports scoped styles) does, because it's the only way to automatically avoid class name collisions without resorting to something like shadow DOM.
Unfortunately, the only way to avoid this is either to go back to unscoped CSS with something like BEM to avoid collisions, or to manually add stable identifiers to your components (for UI tests, supporting user styles, etc.), as either class names or data attributes.
I think he means it in relative terms. You can still make sense of CSS modules scoped styles, they're just same names with some junk appended here and there, where with styled components, there's no chance you could ever guess what this class stands for
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I mean it in "why not go back to regular CSS" terms.
Because "regular" (unscoped) CSS is incredibly cumbersome for large projects, and it gets even worse if you add more devs to the team. BEM and other CSS methodologies took us some of the way towards fixing this, but they're cumbersome in their own right, and only help so much. CSS-in-JS and CSS modules are the first solutions we've come up with that make CSS work well at the scales often we write it today.
... to do things the way they were designed to be done?
CSS (and most web technologies, for that matter) was never designed to be used for many of the things we use it for today. Using everything as it was originally designed isn't really compatible with modern webdev.
It also cost readability. It's ok if you end up writing simple semantic markup (but then, everything's ok if you do that). If you rely on multiple nested
divs with obfuscated class names then it'll be harder to debug and you'll annoy a lot of "tinkerers"... tinkerers like you and me.It's the sort of thing people do to prevent the use of ad blockers, or stop people from re-skinning a site with user styles.
Personally, I want people to be able to change the look and feel of any page I make, because people have different needs, abilities and limitations.
Aye!
Not sure what you mean here, the thing with the class names getting garbled is something every styling solution (that supports scoped styles) does, because it's the only way to automatically avoid class name collisions without resorting to something like shadow DOM.
Unfortunately, the only way to avoid this is either to go back to unscoped CSS with something like BEM to avoid collisions, or to manually add stable identifiers to your components (for UI tests, supporting user styles, etc.), as either class names or data attributes.
I think he means it in relative terms. You can still make sense of CSS modules scoped styles, they're just same names with some junk appended here and there, where with styled components, there's no chance you could ever guess what this class stands for
I mean it in "why not go back to regular CSS" terms.
... to do things the way they were designed to be done? I don't see this as so much of an unfortunate reality as I do a code smell.
Because "regular" (unscoped) CSS is incredibly cumbersome for large projects, and it gets even worse if you add more devs to the team. BEM and other CSS methodologies took us some of the way towards fixing this, but they're cumbersome in their own right, and only help so much. CSS-in-JS and CSS modules are the first solutions we've come up with that make CSS work well at the scales often we write it today.
CSS (and most web technologies, for that matter) was never designed to be used for many of the things we use it for today. Using everything as it was originally designed isn't really compatible with modern webdev.
🙌🙌🙌🙌🙌