{"id":204067,"date":"2015-06-26T08:23:47","date_gmt":"2015-06-26T15:23:47","guid":{"rendered":"http:\/\/css-tricks.com\/?p=204067"},"modified":"2021-08-03T13:00:19","modified_gmt":"2021-08-03T20:00:19","slug":"the-debate-around-do-we-even-need-css-anymore","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/the-debate-around-do-we-even-need-css-anymore\/","title":{"rendered":"The Debate Around “Do We Even Need CSS Anymore?”"},"content":{"rendered":"
This has become quite the hot topic lately. It’s been talked about at a number of conferences and meetups I’ve been at personally lately. I’ve seen slide decks on it. I know people literally not shipping any CSS in production. Pretty wild, eh?<\/p>\n
I thought we could have a little campfire here and talk about it as rationally as we can, covering all the relevant points.<\/p>\n
<\/p>\n
Nobody is saying we don’t need styles. We still need to style things, what’s being talked about is how and where we do that. I was just on a panel at BrooklynJS<\/a> and Jed Schmidt<\/a> said:<\/p>\n The worst things about CSS are the “Cascading” and the “Sheets”<\/p><\/blockquote>\n These are the main arguments against CSS:<\/p>\n The alternative is inline styles. So instead of:<\/p>\n We’re talking:<\/p>\n I haven’t heard anyone yet argue you should apply these styles directly to HTML you author. The idea is you apply styles to elements through JavaScript.<\/p>\n React<\/a> is a JavaScript library that helps with view<\/em> concerns in websites. It’s developed mainly by Facebook, extremely popular, and gaining momentum. It’s had it’s own conference<\/a> and is even growing into a framework for building native apps<\/a>.<\/p>\n One of it’s core concepts is the “Virtual DOM”. You build the HTML you intend to use right in the JavaScript. Seemingly quite weird at first, but this coupling between HTML and JavaScript is always there and it appeals to people to just write it together from the get-go. I quoted Keith J Grant recently, and I will again<\/a>:<\/p>\n This coupling is real, and it is unavoidable. We must bind event listeners to elements on the page. We must update elements on the page from our JavaScript. Our code must interact bidirectionally and in real-time with the elements of the DOM.<\/p>\n … the mantra of React is to stop pretending the DOM and the JavaScript that controls it are separate concerns.<\/p><\/blockquote>\n React has the ability to manage inline styles built right in. They call them what they are: inline styles<\/a>. Here’s a basic example:<\/p>\n See the Pen Inline Styles with React<\/a> by Chris Coyier (@chriscoyier<\/a>) on CodePen<\/a>.<\/p>\n The virtual DOM thing that React does is also important because of its speed. DOM manipulation stuff is generally regarded as slow in JavaScript, and thus managing styles through DOM manipulation would also be slow. But React has the magic dust that makes manipulation fast, so people don’t worry about the slowness issues when working with React.<\/p>\n Here’s another example<\/a> by Chris Nager.<\/p>\n CSS is the abstraction of style away from anything else. Literally files you open and work on to manage styles. You likely aren’t giving that up when moving to a JavaScript-based inline-style setup. You’d just have, probably, It will be different, but the authoring abstraction is still there.<\/p>\n The scary “global” nature of CSS is neutered. The cascade, tapered. I don’t think you could say the cascade is entirely gone, because some styles are inherited so styles can still be passed down to child elements and that’s one definition of cascade. But the module-ish nature of this style of development likely leads to less overlapping style concerns. A module over here is styled like this, a module over there is styled like that – probably no conflicts in sight.<\/p>\n One sense I get is that some people just like and prefer working in all JavaScript. You could certainly attribute some of the success of Node.js to that fact.<\/p>\n “State” is largely a JavaScript concern. If you want\/need style to change based on dynamic conditions (states) on your site, it may make sense to handle the styling related to the state change along with everything else.<\/p>\n In a recent talk at CSS Conf<\/a> (slides<\/a>), Colin Megill<\/a> used the example of the Twitter new tweet input textarea as a dynamic place that changes the state of other elements.<\/p>\nWhat does anyone have against CSS?<\/h3>\n
\n
What is the alternative to CSS then?<\/h3>\n
<\/code><\/pre>\n
<\/code><\/div>\n
<\/code><\/pre>\n
<\/code><\/div>\n
React is driving a lot of these thoughts<\/h3>\n
The style authoring is still abstracted<\/h3>\n
style.js<\/code> instead of
style.css<\/code>. You’d still be writing key\/value pairs and smooshing files together in a build process.<\/p>\n
What do you get out of inlining styles?<\/h3>\n
Cascade-less<\/h4>\n
All JavaScript<\/h4>\n
Dynamic Styles<\/h4>\n