One difference between the two is that css-loader allows you to use normal css files with classes and selectors, while ReactCSS inlines all properties.

For example, with css-loader, you can use much of your old toolchain for css. You can use sass, less, or newer tools like postcss, but you still get the benefit of local styles.

Here is a nice articles that touches on css-loader and postcss: https://medium.com/@olegafx/frontend-welcome-to-the-future-9...

Second, I find this idea to be conceptually very interesting, especially compared to the inline styles people are playing with. It works with the existing CSS tooling, knowledge, frameworks, browser optimisations, etc we already have. There's no real workarounds, edge cases, weird hacks, whatever. It's normal CSS, but scoped to your component, which makes reusing components across a project or between projects MUCH easier.

It's not a magic bullet; you have to be smart still about organising your CSS. But it's really quite clever. I'm using it on a decently large project right now; too soon to tell how it'll work out but it's been good so far.

Inline styles can't modify psuedo-elements or psuedo-styles. You'll need to define styles for :before, :focus, :active, etc. in a stylesheet. These selectors are really important if you want to make appealing forms, e.g. http://blog.circleci.com/adaptive-placeholders/

Vendor prefixes are difficult to do with inline styles. If you're using a map to represent your styles, you can't define multiple values for the same key. For example, if you wanted to use flexbox, you'd need "display: flex" and "display: -webkit-flex". Solving that with inline styles is going to get messy. It's much easier to use less's auto-prefixer plugin to do that for you.

You need a stylesheet to define keyframe animations.

There's probably more I've missed, but those were the problems I ran into when I experimented with inline styles. In the end, the vender prefixes problem made me move all of my styles to a stylesheet. The good news is that the problem could probably be solved by applying a runtime equivalent of less's auto-prefixer.

This is why I think there is a place for a hybrid of javascript styles which are processed by build tools to generate style sheets.

https://github.com/teal-lang is an interesting approach

Yes, you can end up with unmanageable CSS. Yes, it is very easy to end up with a website that is hell to maintain if you have no idea what you are doing.

The real solution is to hire someone who is an expert at managing CSS in enormous websites.

You don't see people saying "Oh? OOP programming? That's too hard! Write all your code with this insert unconventional project instead!".

That being said, this project is impressive, and I love that people are working toward making CSS better.

Actually we do. OOP makes a lot of things hard to implement and maintain. That's why functional programming of front-end matters and new approached emerge (reactjs/virtual-dom + immutable data).

You can deal with it if you're careful and don't let anybody touch the code, but you've solved nothing and as an engineer, that should make you feel bad.

I've gone down the path of doing similar things to this, and in the end I find it's more complex than simply using less (or scss)... While I appreciate the effort actually inheriting styles in/out of react components, based on parent/child relationships is a lot harder to manage when dealing with your react components directly imho.

this becomes very quickly hard to manage

the core idea is to do what react did in js (global namespace => components) but for css

that being said i believe stuff like https://github.com/css-modules/css-modules will be a more correct solution (you can also use scss to precompile eg)

For very simple layouts, CSS is good enough, and it perhaps makes sense to split out the css into a separate file, so long as it's pretty clear what each class does, and the classes are pretty much all global so that changing a property of a class will do exactly what you intend (make the font size of all page titles on the site bigger), and not have unintended consequences on other components you weren't aware of, or thinking about.

For web apps built from many complex components, the flat, global nature of CSS becomes very clumsy indeed. The power and flexibility you need to manage styles of these components quickly outgrows the power of CSS.

You start having to rely on splitting the css into files that contain only styles applying to each component, so that the structure is manageable and you can find things and make changes easily. So why not just drop those styles right into the component file where they're referenced anyway? What concerns are you separating by keeping the css out in a separate file?

You also start having to rely on build-time tools like SASS and LESS to introduce the necessary features to handle complexity in a large, component-structured codebase: variables, scope, mixins, etc. All these things are trivial features of JS, so why not just use JS to put in the styles directly instead of doing it with css propped up by a complex tool-chain? What are you gaining by doing so, other than having the CSS in a separate file? And, again, why is this a good thing?

CSS is just a technology for applying styles to your markup. For many apps, it's in inferior technology to JS for doing this, particularly when using a framework like React.

It does make sense to bring css into the mix as well, as css can have functional effects. If you have a React component, for example, which explicitly toggles whether items are displayed or not, it makes sense to tie the toggling of the css display property directly into the component, rather than factoring it out into a separate stylesheet and creating an additional dependency.

Note that I'm not suggesting that all styling should be done this way - I think that would be disastrous - but that there is merit in composing the html, css and javascript together.

You can mess this up, of course. We are really good at making things more complex than they ought to be, especially while the ideas are fresh in our head. We just need to keep that in mind to :)

I'm not saying breaking CSS into separate files is a perfect solution (this is what I do), but at least it allows you to have everything in one place so anyone can pick up and customize.

I work with some pretty complicated enterprise CMS systems and they are already terrible complex. Last thing I want to do is start spreading CSS all over the app.

Inline styles were impossible to maintain. Even if these (reactCSS) are rendered inline, it's easy to maintain, easy to follow, easy to change.

Javascript used to refer to making things move around and handling click/hover events (javascript was the DOM language). Now it's the entire application.

what am I trying to say...? it seems wrong, but try it out and see if your concerns don't just go away.

I can see it getting verrry messy in wider circles - and I bet we'll go through a whole slew of bizarre process workarounds and frameworks until we end up with a solution that is suspiciously like "clear division between JS and CSS"!

And great point - these new inline/generated styles are the opposite of what they meant 10 years ago (copy-pasta hacks). Now they are even more powerful than regular CSS, instead.

Surely this could be done in a smarter way, using one of the many CSS preprocessors to replace the variable mapping done by `classes()`?

After all, the `render()` template just needs to reference variables!

I'd much prefer to see the problems that the JS managed css solves handled during the build phase of the life cycle.

If you already use a methodology like BEM or SUIT, this is just a natural extension of that.

I know one of the larger motivations for managing styles directly in the react components was to solve a desire to have namespaces in CSS. Maybe there are other benefits that I am unaware of which would support handling styling directly in the react component.

But if you only partially implement your app / site in React, you have further complicated an already dense set of develop/styling abstractions. You will now have to think of your styling in terms of pre-instantiated app & post-instantiated app.

If you fully implement your app in React, you will most likely want to do away with traditional css all together with the exception of some base css libraries. CSS without cascades seems like a strange place to be.

    class Header extends React.Component {
      render() {
        return (
          <div className="Header">
            <Logo />
            <Avatar />
          </div>
        );
      }
     }

.Header .Avatar { float: right; }

Unfortunately, this breaks encapsulation. It's basically monkey-patching and makes your components less portable. It causes a lot of problems in larger apps that aren't apparent until down the line.

So you could use BEM:

    <div className="Header">
      <Logo />
      <Avatar className="Header__Avatar" />
    </div>

    const styles = {
      base: {
        // ...
      },
      avatar: {
        float: 'right'
      }
    };

    <div style={styles.base}>
      <Logo />
      <Avatar style={styles.avatar} />
    </div>

Just like my JS requires different JS files, my CSS imports various files too. The preprocessor turns that into 1 css file (or n, if you want).

Then having a proper separation of code and style with class names to bind the two becomes your only sane option at scale.

    import theme from 'styles/theme';

I've been wishing for a nice way to incorporate CSS into that as well. I'm starting to feel like using 3 different languages.. HTML/JS/CSS to achieve a single effect is a bit unwieldy, though I've done it for years.

I haven't yet seen story in JS or Clojure for bringing CSS into the actual programming yet that I'm ready to adopt.. but this is interesting.

<span is="span" />

<CodeSmell is="Stinky" />

Besides, you kinda lose all the advantages of using javascript to style, which is complex computations and co.

    <div is="dialog">
      <h1 is="title">
        { this.props.title }
      </h1>
      <div is="actions">
        <Button is="Cancel" label="Cancel" />
        <Button is="Accept" label="Accept" />
      </div>
    </div>

No, you dont' loose it. You can still script the "is" attribute, also you can escape to regular className in case of advanced cases. So this is a 80-20 solution.

Colin Megill - Inline Styles are About to Kill CSS https://www.youtube.com/watch?v=NoaxsCi13yQ

A higher-order React Component that:

- Makes defining and using css styles in React Components consistent.

- Makes your styles portable with your reusable components.

- Makes overriding styles easy and predictable.

Uses CSS modules.

[1][ https://raw.githubusercontent.com/casesandberg/reactcss/gh-p... ]

I think the main reasons to want a component to do some styling are:

- so the consumer doesn't have to include separate CSS elsewhere to get default appearance

- and so that stuff that is an implementation detail can be relatively hidden (as with the shadow dom) and can expose what it makes sense to expose.

So the ideal styling approach lets a component properly render itself, yet also lets it be customizable with regular CSS.

In all seriousness, I could see a future where the browser is just another user environment. Desktop OS (Linuxes, Mac OSX, Windows), mobile OS (Android, iOS, Windows), and the browser (Firefox, Google Chrome, Safari, IE/Edge).

We compile things against it (there's a standard library/API/ABI), it has a screen that users interact with.

At the risk of sounding more irrationally exuberant than the parent, the browser is an OS in itself. Yes I realize that "OS" and "browser" are actual terms that have narrowly defined definitions, however the sentiment is the same.

It's just another client for our code/binaries to run on and in actuality what's running our code is irrelevant.

I'm intentionally avoiding calling it a platform, though.

Look at the example. Imagine that being one of dozens or hundreds of components in an app. Then imagine trying to re-style the app from a flat-looking interface to whatever's trendy next. I'd much rather do that with a LESS file than muck through however many JS files that would take with this.

They can just take a <Tab><Item/><Item/><Item/></Tab> and expect those components to be designed inside of the components themselves.

This is var more similar to how iOS handles design. You have your own custom views with their own style defined, obviously on some you can override them, but usually they are defined inside the class itself.

It makes sense for Web to take this route, given how hard it is to design on the web compared to iOS. At least for me :)

The point of using inline styles isn't to be hip: it fixes most problems caused by specificity wars, global selectors, monkey patching, code bloat, dead code, and indeterminism. I agree that there is yet to be an implementation that is perfect, but there are some very smart minds working on this problem at the moment.

I mean, specificity wars... isn't that one of the first things we learn to avoid when writing stylesheets?

However:

* Your components will still be spread out among separate files. Button.js, Button.scss. Icon.js, Icon.scss. Just like it doesn't make sense to separate inherently coupled HTML and JS, it doesn't make sense to separate inherently coupled HTML/JS and CSS.

* You have to use two separate programming languages unless your app is simple.

* SASS and LESS can be really problematic. They have ambiguous syntax and are non-standard. There's 9,001 ways to import in LESS. They look like programming languages, but they differ in confusing, bug-prone ways. SASS and LESS's variable resolution are different and confusing. And math is whitespace-sensitive. Yes, whitespace-sensitive math.

* Another build step.

* No easy way to get values statically from CSS files. Instead you have to use comments like "IMPORTANT: keep this value in sync with Button.js!". And if you forget, you will have a difficult-to-debug problem.