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.)
[1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
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
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.
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.
(Not agreeing with this BTW, but there is a subset of developers who seem to think this is just great.)
I personally like this way better, easier to find when need to fix something.
I found it to be a great middleman between CSS and JS, with full CSS support.
We have a project like that one of our developers wrote except it will compile the classes back to a CSS stylesheet for you for performance and will unify identical styles to not have duplicates and save space https://github.com/Mosho1/react-style
It's also nice to be able to use classes and integrate with CSS seamlessly when you need to.
vs
<span style={ styles.button }>
Usually React+Redux project min + gz will come in around 200-300KB for a relatively simple app... If you go with preact, and are really judicious in what you bring in, you can hit half that. For most people, if your initial send is under 500kb, it won't be noticed except some mobile connections.
YMMV of course, for comparison, angular apps tend to be about 50-80% bigger, and ng2 apps over twice the size. At least from my own experience and setting up a few boilerplate apps.
What stuff are you bringing in? Preact is 3kb, Redux + bindings for Preact probably bring it around 10kb or less (compressed). Unless you mean images and stuff.
The author either didn't do the best choice in writing his page, or has great plans for it.
[1] https://webpack.github.io/docs/configuration.html#devtool
Even if compressed and minified, that's still a huge amount of JS statements that the interpreter has to go through.
I'm getting about 2 seconds to DomContentLoaded on my iMac and a reasonably fast cable connection. Four seconds to visible content on my Nexus 5X on same connection.
This is the kind of crap that makes the web feel so lame and clunky on mobile (and on desktops too even sometimes).
While 700 Kb is sort-of-acceptable in terms of data usage, the execution of 2.8 Mb of JS is quite taxing on the browser: on my 2010 MacBook Pro it takes 4-5 seconds to show the text on the page, even when bundle.js is cached...
I can then, inside my component...
require('./mycomponent-style.scss')
.... <div class="mycomponent">
@import "variables";
@import "mixins";
.mycomponent {
...
}
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.
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).
We are not using React.
import CSSModules from 'react-css-modules';
import styles from './styles'; // This is a styles.css file in the same dir
const Component = () => <p styleName="welcome">Hello, world!</p>;
export default CSSModules(Component, styles);
Sorry if I misunderstood your question.
Then again, Immutable.js is about 15kb on it's own, and a few other heavy hitters and you'll hit 100kb (gz) load before much functionality. That said, I think a 500kb target for a web app isn't too bad, this does exceed that, but not sure if certain bits (image references, fonts, etc) are part of the actual JS bundle, which will bloat it out a lot.
Often times you will wind up with competing libraries that both get installed... You'll get all of lodash, and all of Ramda... you'll get all of jQuery, and a few other tools because you're bringing in one component. Working on larger applications with people less judicious as to what they bring in results in a lot of bloat... more so when it's easier to bring something in (thanks to webpack/babel), and while I appreciate that, it's a tool that's easy to abuse.
In the end, you can get react+redux in under 100kb, you can get a lot of the app boilerplate for a mid-sized app well under 200kb... I would compare this to angular, or ng2 that tend to be much bigger. In the end it's how you are building.
Beyond this, as I said, I didn't really look into the bundle... depending on configuration it could be including images, fonts and css. Which would mean it's really not that bad, though it should probably be using url-loader for a lot of the assets to break into separate downloads. Also, react-icons is much better when only needing a few icons from the libraries, they're also well normalized to mix/match in terms of size/position than the fonts tend to be.