When your starting with a fresh or very well defined code base sure, you can federated your class names, your animations, your style libraries etc. Though that's rarely the case, what I am saying is with js if you write a function to do something like apply (for simplicities sake) display:none to a Dom element on the fly you can carry that function with you to every project, no worries about conflicts, and if there is a conflict like repeated function names etc it's very easyto debug, more often than not the browser will immediately tell you. If you create a class named .hidden { display:none;} and you hop into a legacy code base, or one that's using x style framework trying to use your little utility class and it doesn't work your going to spend far more time digging to find the conflicting class name. Of course this is a very simple and mostly impractical example but apply it to far more involved things. My comment primarily applies to css, html is what it is whether it's written in jsx, handlebars, dynamically loaded in through a api call whatever. The unfortunate Dom is, the unfortunate dom.
What would happen if you took your JS display:none function to a legacy project with a x style JS framework that has certain kinds of tools to style DOM elements? You seem to know exactly what happens with CSS in this case so I expect you to know the answer to JS things as well.
if there is a conflict like repeated function names etc it's very easyto debug, more often than not the browser will immediately tell you
How about you press F12 right now, open the console, and declare two JS functions with the same name into the window. Let me know what the error message says.
I don't get your point. HTML is way more resilient than JS and it keeps doing what you tell it to do even when you partly get it wrong?
Reusability is good with just HTML and CSS as well, or are you talking about installing shit with a package manager?
When your starting with a fresh or very well defined code base sure, you can federated your class names, your animations, your style libraries etc. Though that's rarely the case, what I am saying is with js if you write a function to do something like apply (for simplicities sake) display:none to a Dom element on the fly you can carry that function with you to every project, no worries about conflicts, and if there is a conflict like repeated function names etc it's very easyto debug, more often than not the browser will immediately tell you. If you create a class named .hidden { display:none;} and you hop into a legacy code base, or one that's using x style framework trying to use your little utility class and it doesn't work your going to spend far more time digging to find the conflicting class name. Of course this is a very simple and mostly impractical example but apply it to far more involved things. My comment primarily applies to css, html is what it is whether it's written in jsx, handlebars, dynamically loaded in through a api call whatever. The unfortunate Dom is, the unfortunate dom.
What would happen if you took your JS display:none function to a legacy project with a x style JS framework that has certain kinds of tools to style DOM elements? You seem to know exactly what happens with CSS in this case so I expect you to know the answer to JS things as well.
How about you press F12 right now, open the console, and declare two JS functions with the same name into the window. Let me know what the error message says.
So I tried it, and JS is alot easer to debug than css.
Easier how? I am not certain how that example should be read or executed to validate your point?