Show HN: ReactCSS – Inline Styles with Support for React, Redux and React Native (opens in new tab)

IMO it makes it easier for devs that dislike CSS to make sweeping changes due to all of the relevant styles being in one place.

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.)

[1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

[2] https://github.com/css-modules/css-modules

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.

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.)

It's still separated, but they are near each other.

I personally like this way better, easier to find when need to fix something.

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.

It's just a slightly different syntax for CSS but still is CSS.

First off, it's not compressed... that would probably bring it to 1/8 the size, I'm also assuming that the documentation as a project may well expand...

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.

React. If it was a pretty complex and dynamic app it would be just a bit bigger.

The author either didn't do the best choice in writing his page, or has great plans for it.

This looks like the build a typical webpack development config spits out (using its eval devtool [1]), could be that the author hasn't set up a production build yet.

[1] https://webpack.github.io/docs/configuration.html#devtool

I only see a ~800kb bundle.js, which could be smaller if minified, I think, but nothing strangely big.

I don't think that's off-topic in the slightest and have been asking this question myself for ages.

React CSS Modules does not allow you to use props or state to style your component. Say you wanted to use a button <Button color="#aeee00" /> you could map the color prop directly to CSS.

One advantage to keep the style not in a CSS file is that you can handle dynamic value easily withing your component. Bringing back to a CSS file make you loss that capability.

So it translates everything back to CSS, is that how it handles hover and pseudo classes?

One of the biggest differences between ReactCSS and other solutions is that all of the style merging is done in the style object and not in the HTML. This keeps the markup clean and puts all style and style logic in one place.

<span className={css(styles.blue, styles.small)}>

vs

<span style={ styles.button }>