What happened to the separation of concerns between CSS and JS? In my experience most developers dont want anything to do with CSS. They want a designer who can code to do that.
The React way is different and I was hesitant, but it is better. It combines the best parts of native app development with the best parts of web development, then improves on them. The old way of doing CSS was crazy and unmanageable because CSS was intended for documents. Cascading styles are useful for publications, but they are unwieldy for UI components. There aren't many native app designers clamoring for global cascading styles.
The React way of separating design concerns from logic is to build container components[1] that handle the logic and pass props down to simple components that just display the data they're given. I would expect designers to spend more time in presentational components and CSS modules[2] while developers would build container components. (I'm a one-man shop doing both.)
> The old way of doing CSS was crazy and unmanageable.
That's a bit of a stretch though, we've had good success with using normal CSS files, included in each component with webpack CSS-loader[1]. CSS is displayed in head as needed, but without an all-JS approach like this
For that matter, it's not so hard to setup sass-loader with custom default locations... I'll usually have my own copy of bootstrap's variables.scss, a mixins.scss that points to bootstrap's... from there, I have a copy of bootstrap.scss included higher up pointing to the local mixins/variables, and the rest from the node_modules/bootstrap(-sass)/ path...
And have all of bootstrap's variables/mixins to work with... I can update variables for those bits of bootstrap I want changed, components also update based on those values. It actually works really well, and it's not hard to setup.
I should really write a current article on using Bootstrap@4 from source... There's a little bit of boilerplate, but so worth it.
That said, I do appreciate the inline options, and feel that future React apps in particular should probably go in that direction. It really just depends on how you are working with.
Ultimately it depends on what your concerns are, and how you want to separate them.
I'm not just being silly either. Separation of technologies (e.g. HTML/CSS/JS) is just one of many ways of splitting things up. The component paradigm is essentially a fractal version of separating by feature. Ultimately it's an architectural choice and as such any best practices should be strictly scoped to the problems they're solving.
The reason why many of us in React-land are looking to bring everything related to a single component into one file, is maintainability and strict encapsulation. Some of this is to do with developer-experience (DX), i.e. adopt patterns that make our lives easier and ultimately minimise hard-to-fix bugs. But we're also trying to adopt patterns that benefit the user (i'll be the first to admit we're not there yet). To that end, a component architecture also makes it easier to let build tools automatically take care of the nasty problem of making sure users only download exactly what they need for what they've asked to do.
The component paradigm that react is built around is all about working with very small objects, where everything you need for that component is in one file. It's a fantastic model when you are working with a complex interface that has many components to it. It's a paradigm that needs to be managed and used carefully though, otherwise you'll end up with massive 2000 line files.
I never thought there was a separation between JS and CSS, that sounds a little outdated, to be honest. As a front-end developer, I would be expected to do JS and CSS.
Where I work, we're a small dev team of a few full stack developers and a designer. Our designer does the CSS, and the devs the JS. The separation works well enough for us. YMMV.
So anytime the designer makes a change to the structure of the application, where HTML element changes are required, do they send you a request so you can change it?
It seems odd to only allow the "designer" to manipulate properties of elements and not the elements themselves. If they are allowed to modify DOM elements then in the React world, that is manipulating JS. For us the important separation is at the component level, which includes everything that component needs to render and function (HTML, CSS, JS).
The React ecosystem seems to be geared towards masking HTML/DOM/CSS behind Javascript/code, such as when developing mobile apps. I do not think "separation of concerns" is a priority.
(Not agreeing with this BTW, but there is a subset of developers who seem to think this is just great.)
I can go almost either way... I often find it more natural to include a (s)css file in my component's .js, and have webpack bring it in... then in the component's rendering set the className to a matching container in the scss. With scss, I can start with my variables/mixins include, and keep the more hierarchal stuff straight... It works pretty well, but I see the appeal of things like this library, aphrodite and the like.
That bridge has already been crossed when they put the HTML into the JS. Any designer changing CSS is going to want access to the HTML, so they're already mucking in the JS anyways.