It's based off the premise that content and styling are independent. It works very well when that is true. Often they are not.
If I'm designing a "date-picker" component, it will be completely broken without the corresponding styling. There can be no separation of content and style, the content does not make sense without the styling to produce the actual final output.
Such components require style definitions to function.
You're the first person I've heard wanting to scrap CSS and go back to style tags. Sure people prefer LESS/SASS but having styling in a different file and not mixed into JSX code makes style changes simpler for the way I work.
There are two ways to look at your code: https://i2.wp.com/pbs.twimg.com/media/DCXJ_tjXoAAoBbu.jpg?w=...
React mostly makes you think in terms of components.
Also: React doesn't output HTML.
React renders to the DOM which outputs HTML. It's still HTML that can be styled with CSS independently of React.
What do you think the code you complained about does?
> But scrapping CSS for style tags is a bad idea.
It's not bad in this particular case because these were simple examples to illustrate an entirely different point.
> React renders to the DOM which outputs HTML. It's still HTML
Erm. No. DOM never outputs any HTML. There's no HTML generated when you use React (or any other DOM-manipulation library or vanilla Javascript).
It's the other way around:
- HTML gets parsed
- A DOM (Document Object Model) is created to provide an in-memory, well, object model of the HTML document.
- In order to render anything on screen the browser works with the DOM only
- When something manipulates the DOM directly, the browser reacts to those changes and re-renders the view accordingly
- There's no HTML generated
- If someone does change the HTML, it's re-parsed, go to step 1.
Yes, you can style DOM nodes independently of React because that's how CSS works. However, there is a reason why people hate CSS with a passion: it doesn't scale, it's cumbersome to develop components with it etc. etc. etc. And that's why people ended up inventing ways to include/generate CSS via JS alongside component code.
> these were simple examples to illustrate an entirely different point.
I did accept this in my original post, it could be just because they were examples. But it's trivial to use classes instead.
I've never come across many people that hate CSS with a passion. It's been used to create billions of pages so I'm sure that some people will hate it but it was certainly a step up from individual style tags.
The React docs agree that it's more efficient to use CSS instead of inline styles [0]. And beyond that when talking about CSS-in-JS:
> if in doubt, a good starting point is to define your styles in a separate *.css file as usual and refer to them using className.
There are problems with CSS, but it also solved a lot of problems that came before that seem to have been forgotten about.
Imagine you had a complex database of authors and books, and every time you read from it you want to receive the name of the user or the book in title case. You see that this behavior can be abstracted over, so you say "any time I pull a record from the database, no matter what table it comes from, capitalize its title". This is very convenient.
Well, no one would ever do this in a complex application, because you don't know what sort of implications it might have for future tables that are added - or what if you decide that short words in the title should be lowercase? Now you are making exceptions instead of declarations.
This is effectively what CSS does. it unnecessarily couple's visual state to other visual state, unless it is namespaced uniquely to a specific component.
> However, there is a reason why people hate CSS with a passion
So it seems some people do. Going through some of the talks about CSS in JS it seems Facebook and Airbnb are making good cases for the problems they're hitting with CSS especially around asynchronous loading of CSS files.
But having spent lots of time seeing what a mess developers come up with using style tags on individual elements before switching to using CSS I'm interested to see what happens when there's tons of React components with hard coded styles. It seems like a solution that's ripe for creating more problems than it solves.
The problem is that css scales poorly for large projects, especially when you build many components and mix them together. It is almost impossible to know which css rules are in effect for a specific part when you don't know where that part will end up and it is also hard to create css rules that continue to work since more parts and html may be added later which changes the css rule matching.
If you're worried about class overlap, you can define unique/hash-based classnames on build with css-loader.
If you're still worried about aggressive stylesheets destroying your components, you can wrap them in however many classes you see fit (some people might use `.n.e.a.t.l.i.b .cool-class` instead of polluting component code with CSS).
As far as CSS scaling poorly, that's really up to you. I find that it's an afterthought to most people, and full of weird hacks and `!important`s a few months into a project. That's fine if that's how you want to do it, but it's not an inevitability.
(I say this as someone working on a component library that's used on over half a million sites)