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?
I thought we could have a little campfire here and talk about it as rationally as we can, covering all the relevant points.
We obviously still need to style things
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 and Jed Schmidt said:
The worst things about CSS are the “Cascading” and the “Sheets”
What does anyone have against CSS?
These are the main arguments against CSS:
- Everything is global. Selectors are matched against everything in the DOM. You need naming strategies to combat against this and keep things efficient (which are hard to enforce and easy to break).
- CSS grows over time. Smart people on great teams cede to the fact that they are afraid of their own CSS. You can’t just delete things as it’s so hard to know if it’s absolutely safe to do that. So, they don’t, they only add. I’ve seen a graph charting the size of production CSS over five years show that size grow steadily, despite the company’s focus on performance.
- You can be more dynamic with styles in a programming language. The argument goes something like “we’re already juicing up CSS with preprocessors anyway, might as well kick it up a notch.” You could for instance (if you really wanted to make this controversial) base styles off a User-Agent string or a module’s current width.
What is the alternative to CSS then?
The alternative is inline styles. So instead of:
We’re talking:
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.
React is driving a lot of these thoughts
React is a JavaScript library that helps with view concerns in websites. It’s developed mainly by Facebook, extremely popular, and gaining momentum. It’s had it’s own conference and is even growing into a framework for building native apps.
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:
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.
… the mantra of React is to stop pretending the DOM and the JavaScript that controls it are separate concerns.
React has the ability to manage inline styles built right in. They call them what they are: inline styles. Here’s a basic example:
See the Pen Inline Styles with React by Chris Coyier (@chriscoyier) on CodePen.
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.
Here’s another example by Chris Nager.
The style authoring is still abstracted
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, style.js
instead of style.css
. You’d still be writing key/value pairs and smooshing files together in a build process.
It will be different, but the authoring abstraction is still there.
What do you get out of inlining styles?
Cascade-less
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.
All JavaScript
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.
Dynamic Styles
“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.
In a recent talk at CSS Conf (slides), Colin Megill used the example of the Twitter new tweet input textarea as a dynamic place that changes the state of other elements.

Who’s actually doing this?
I heard Colin Megill say they are shipping literally zero CSS on “big stuff” and not seeing performance problems. I’ll update this with URL’s if I get them. I hear one big project will be live within a month.
I know Jed Schmidt works on the mobile version of UNIQLO, and you can see the inline styles at work there:

Update from Jed: This version of the site is all Sass and the inline styles you see there are from JavaScript animations.
Christopher Chedeau has been talking about this and is literally a Facebook engineer, so maybe Facebook a little?
Can this concept be combined with, you know, CSS?
Even if you bought into the concept of inline styles, can it live in harmony with some (do I have to say it) regular CSS? Is page layout appropriate as inline styles? Doesn’t base typography still make sense to do globally? I’m not sure if we’re far along enough in this world to see a best practice emerge.
In the m.uniqlo.com example above, they are shipping a 57k CSS file as well, and you can see evidence of state-based class in the DOM as well (e.g. “is-open”).
A lot of people really don’t like this
Surprise! There are more arguments against this kind of thing than for it. As I was collecting opinions about this, I told Lea Verou “Some people really like this idea!” to which she told me:
You can find people in the world who like eating excrement it doesn’t mean it’s a good idea.
Let’s run through other arguments:
Styling is what CSS is for
This is the “religious” angle that probably isn’t going to take us very far.
The separation of concerns is inherent to CSS
Separation of concerns is a very useful concept when building things as complex as websites are. You get seperation of concerns automatically when writing CSS: it’s a file just for styling.
Inline styles are at the top of the specificity spectrum
Keeping specificity low in CSS means that when you do need to rely on specificity to win a styling war, you have it available as a tool. When you’re already at the top, you don’t have that wiggle room luxury.
The !important
declaration can still win a specific property/value styling war over an inline style, but that’s a slightly different concept and an even grosser war to fight.
Some simple states are much easier in CSS
How do you do :hover/:focus/:active in inline styles? You don’t. You fake it. And what about media queries?
Adding/removing classes is a perfect tool for state changes already
JavaScript is really good at adding/removing/changing classes on elements. And classes are a perfect way to handle state in CSS.
.is-open {
display: block;
}
Plus you can change state on parent elements (by changing a class) to affect the state of lots of elements within:
.tweet-too-long {
.tweet-button {
opacity: 0.5;
}
.warning-message {
display: inline-block;
}
}
Browsers aren’t made to deal with styling in this way
For instance, inline styles are literally data kept in an attribute right on the DOM element. DOM weight is a thing (it can cause browsers to be slow or crash). That styling information isn’t only just kept in the style attribute though, it’s also represented in the DOM in the element’s style properties. Is that the same thing, or is this kinda double-weighted styling?
Are there speed differences between…
var thing = document.getElementById("thing");
thing.style.width = "100px";
thing.style.height = "100px";
thing.style.backgroundColor = "red";
var thing2 = document.getElementById("thing-2");
thing2.setAttribute("style", "width: 100px; height: 100px; background-color: red;");
Has that been figured out to discover what’s best cross-browser? If this stuff takes off, will browsers need to evolve to handle things in a different way?
The browser has this whole concept of the CSSOM. Can we use that somehow more intelligently through JavaScript rather than inline styles?
CSS is successful because of it’s simplicity
CSS is a fairly easy to jump into. A lot of people know it. You can hire for it. It’s portable.
Some of these “dynamic” styling concerns can be solved with regular CSS
- There are demos that include measuring widths and subtracting fixed values from them. CSS can do that with
calc()
. - There are demos that include setting
font-size
orline-height
that depends on the browser width or height. CSS can do that with viewport units. Using JavaScript for this kind of thing is overtooling. - There are demos that dynamically change colors on many different elements. CSS will be able to do that with native variables.
We tried this in 1996 and it was a bad idea then
CSS is cacheable
The network is still the bottleneck. CSS files can be cached so the network doesn’t even come into play and that is smoking fast.
You can still use React
React is pretty awesome. Here’s an article by David Khourshid on Styling React Components in Sass. Mark Dalgleish doesn’t like the global nature of CSS, and has working concepts to localize selectors. Glen Maddern expounds upon this in Interoperable CSS.
Doesn’t anyone care about progressive enhancement anymore?
This is a wider conversation is perhaps out-of-scope here. Because sites (including React based sites using inline styles) can be rendered entirely server-side, it means they can be done with progressive enhancement in mind. Although “can be” and “what it actually encourages” are different things.
I do emails. That’s enough inline styling for me. So, no thanks. I’ll stick with SCSS.
All of the yes!
In react, you don’t actually maintain the style attribute in html – it’s generated for you by nature of the library. So you can still write stylesheet-like modules (in JS).
your not actually adding your styles inline are you? http://premailer.dialect.ca/
CSS is easy. And fast, too. Period.
Javascript is not.
Would Chris need to change the name of his site to “css.js tricks”?
I chuckled. If this were Reddit you would have earned an upvote from me.
Honestly, I decided to comment because if this question. Yes, is Chris going to change the name?
surely if the css is in the html the page is bigger in file size and takes longer to download…
what if javascript is disabled in the browser?
But there’s no CSS file(s) to download, so it actually might speed up the page, depending on how much you repeat styles.
I keep thinking this, too, and I have no clue why people think putting anything in a page through JS is a good idea. If people using screen readers, NoScript, etc., can’t see your site, you’ve got a problem.
Yes! But then again, the whole thing would not work either, right?
What if you’re building an app using webviews where you know javascript will always be enabled, and this content is being used primarily or entirely offline with stored data?
No, you shouldn’t rely on javascript to render a page that’s being loaded over the internet, but HTML + JS is being used for a lot more than that today.
If JavaScript is disabled then a lot of the internet for that user is rendered useless. This is a tired argument imo. When is the last time you turned off JavaScript?
The CSS is not in the HTML. It is applied to the HTML via JavaScript after page load. Either way the browser has to download the styles.
@Kyle I only ever turn off JS to make sure my sites work for users who don’t have JS enabled. There are a few different types of users who generally have JS disabled:
Disabled users who have to use screen readers
Privacy freaks who think that disabling JS will prevent tracking
I care more about the disabled users than the privacy freaks, but the web needs to be accessible. And tossing all of your content into the webpage through JS isn’t accessible.
@Kyle @Zeke You don’t have to have JS disabled for it’s absence to cause problems. A few weeks ago, my connection dropped while hulu.com was loading (at home, on my laptop). Hulu thought I had JavaScript disabled, since it didn’t load.
Yeah, but if they can’t see then it doesn’t matter what it looks like.
to answer your question re: JS turned off: you would have to make sure the app was isomorphic JS: then for each page request, react would apply the CSS styles in Node (server side).
@Zeke Y –
Someone may have pointed this out already, but screen readers have been javascript-aware for quite awhile – so I doubt many disabled folks are still turning it off.
Why don’t people Google this stuff … it’s basically our jobs.
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
@RioBrewster I don’t remember where I saw this, but I was reading something recently that said about 90% of users with screen readers didn’t have JS enabled, even though they could’ve been using JS.
@Brad re:
True. But you forgot about the people who browse with JS turned off:
@Zeke Y
Screenreader user do not turn off JS. JS works a little bit different, in a Screenreader, but again this does not mean, that it is disabled. So please keep in mind: JS off/JS disabled has nothing to do with Screenreader users. This is a big myth.
here is some data:
About 98% off all screenreader user have JS enabled. So make sure that your content including your JS is accessible.
http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/
How about using something like Polymer does? You can style your components separately in different css files and then the system adds them to the header with the scope of the component.
I appreciate the neutral look you’re giving here!
I’m looking forward to seeing how ideas like these develop, but will definitely be staying with “regular” CSS for the time being.
A tear just formed in my right eye when I thought about the web designers who don’t do Javascript.
They’re unemployed! Ask me how I know.
Annie, Annie, Annie, my chuckles got me falling on me fanny
This is all fun and games until someone pokes an eye out… What about browser painting/drawing with each “inline” style change? Crossbrowser compatibility? Do I need to redeploy the whole app when a design change is needed?
Thanks for shedding some light into this, Chris :)
So, for the people who think this is a good idea, how are you doing media queries? Are you doing them kind of like this?:
(code not tested)
if (window.matchMedia(“(min-width: 400px)”).matches) {
/* the viewport is at least 400 pixels wide /
} else {
/ the viewport is less than 400 pixels wide */
}
Summary
Returns a new MediaQueryList object representing the parsed results of the specified media query string.
Syntax
mql = window.matchMedia(mediaQueryString)
where mediaQueryString is a string representing the media query for which to return a new MediaQueryList object.
see more here https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia
http://projects.formidablelabs.com/radium/
When I first started seeing React couple HTML and JS I thought that was nuts, but after using React it makes a lot of sense. I’m sure we’ll feel the same about coupling the CSS as well
I’m probably missing something, but what about maintenance and scalability? In my projects, if i change padding of elements in one list, i definitely want all lists to follow
There is no barrier to this. I think the misnomer is that you write inline styles. You don’t. You write objects instead of classes that are applied programatically. This is a non issue.
These people do not understand what they do… I don’t mean to be a meanie (although I am quite often I can come across as one), but these people are hurting their clients, and good design / front-end developers; because of what can only be classified as complete ignorance!
By moving CSS into JS, or worse still HTML, you remove any potential benefit of caching the CSS, re-using classes, or applying rules to multiple selectors. In big projects this happens a lot!
It’s okay to have the odd bit of CSS in HTML, maybe you are prototyping, the client wants this online now so it has to launch in this sorry state; but you should have agreed to move it out of the DOM / JS as a next-stage. For a high-volume site it does have a knock-on effect in aggregates of bandwidth wasted, and in terms of extra work you need to do to work with the site, when you move code to other areas-of-concern.
It’s not, non-CSS, it’s CSS relocated to a position where it makes zero sense to have CSS! The arguments for having CSS in JS, can be overcome with more specific selectors for add-ins such as sliders, nice-scroll, (insert extra thing here), and the MVS (minimum viable selector) for core theme, or site-specific CSS.
We get it, for some people it’s now a thing to buy everything off of Envato, and cry like a baby when they have to pay a professional “to modify the thing, to do the thing they want”; but as professionals, it’s our job to point out, that every decision comes with a cost (technical-debt), and sometimes, it’s better not to mod a $15 plugin, and just to re-approach the issue.
As well as the above, and the obvious for JS injected; if you don’t have JS they are Foo-barred. Even if they do have JS, the JS file now has presentation code in, you have to look in another file or file(s), to develop a process to move CSS in and out of JS, or accept the limitation of a possibly less knowledgeable JS dev’s CSS styling skill; and the extra machine capacity required to handle the extra code you have to retro-fit.
Chris, punch these people in the face (except don’t obviously), they are killing the web! As an alternative, simply modifying CSS classes in JS is always better than directly injecting CSS, got a class conflict, extend it in sass in a renamed class, then update your JS!
Huge jumps to ‘killing the web’ and not wanting to come across as a meanie while specifically saying mean things aside… Some points that you make are valid, and some that at least seem to come from misunderstanding the concept.
CSS =/= Style. Adding a style tag to an element and that style being inherited to a child is not enough to give it the same meaning as CSS.
Bloating your bandwidth use is possible, yet CSS is a contributor to this in real production anyway. For example “got a class conflict, extend it in sass in a renamed class, then update your JS!”
Keeping style separate from the DOM is great, but does that separation have to be language and location and request and production cycle?
Regarding caching, javascript is cached, crisis averted.
And a “possibly less knowledgeable JS dev’s CSS styling skill” is equal to a “possibly less knowledgable CSS dev’s CSS styling skill” or anyone else possibly less knowledgeable. I’d argue it’s harder to deal with possibly more knowledgeable people’s skills as they make things work in ways we don’t understand, rather than not being able to find where they went wrong.
I think the idea of using a programmatic language to feed the styling to the DOM is a look forward. How it’s implemented here might not be the winning roll, but the concept is worth contemplation. We already use so many tools to try and shoehorn that functionality into our CSS.
I do agree that this is nowhere near the solution to our desire to present the perfect interaction to our audience. Add to that, trying to replicate CSS classes in JS and assuming JS is working, and I think we’re adding a new set of complications. Not going to pull it’s weight yet.
You’re missing the point. Zero-CSS > cached CSS. If the JS building the CSS is cached – you’re getting the same deal, if not better (being dynamic).
And FYI styling multiple elements is totally do-able, and more powerful than regular CSS. It’s just implemented differently. Instead of applying rules to classes/IDs you create objects and give those properties. Those object properties are then injected into whatever DOM elements you associate them with. It’s really simple, and offers a plenthora of capabilities that wouldn’t be available otherwise (at least conveniently), such as: sharing properties between objects and creating complex conditionals.
Note: I’m on the fence with this like Chris.
Modular CSS is already possible through SASS compounded with effective namespacing (SMACSS) which helps to reduce bloat. Tracking where in your project styles are used is sometimes a bear still. It would be interesting to see modularly loaded CSS in web components looking forward (like polymer mentioned above).
I remember when you did podcast on Shop Talk Show with Nick Pettit. A listener had asked that front-end development is moving towards JavaScript side, Should I abort HTML/CSS and go for JS-only.= front-end development. It was only you who said that HTML/CSS are meant for what it does and they’re constantly progressing too, there’s no need to make simple things complicated just because you want to be a “JS-guy” or something. Why is your idea changed now?
I think a lot of issues we have with CSS as a language are already solved via Sass. I think the globalization is a huge issue, but until we move to something like web components, I don’t see inline styles or JS taking the reins. I think web components will also fix our hacky way of defining things ala BEM. Honestly, inline styles are stupid. JS styling is just inline styles with an actual logical way to select elements.
False. At runtime, Sass is only ultimately capable of doing what CSS is capable of doing.
#Colin, it’s only partly false.
zero-CSS is as much if not more about build process, as it is about runtime.
The hard work is in maintaining stable, reliable understandable styling, and that’s about source code (in whatever language / tool / library / methodology you are using).
For what its worth, I’m working on a medium sized React app where we use a combination of inline styles and traditional CSS — we have a lot of dynamic SVG charts that are almost all inline styles, but the more “document-ish” parts of the app are in style sheets. The difficulty of using pseudo-selectors and media queries makes pure inline styles impractical, but I don’t think that those are inherently unsolvable problems.
On the stylesheets side, CSS-modules have helped significantly with the issues around accidental style collisions.
The issue we come across the most with the hybrid approach is that there are a lot of places where we want to have the same variables in both CSS styles and inline styles, and I haven’t found a good solution for that. Maybe there’s a way to have a JSON file with our brand colors etc. that renders into SASS variables and is imported into the app?
Remember that best practices aren’t platonic ideals, they are just the best approach for a given moment in time. “Best practices” used to involve making different sites for Netscape and Internet Explorer, and CSS was once an upstart and frankly impractical way of doing real work. Best practices changed from font tags and table layouts to the world we work in today, and there’s nothing to say that we aren’t now on the cusp of another change. Keep an open mind.
Why would you need JSON for your brand colors when you can just use variables directly in SASS? On our large apps we typically have a branding or variables file that contains the project-wide variables. There really isn’t a need to have any of that in an external data file.
Example: we use a color scale for heatmaps in dynamically-generated charts. In some places, the colors are used in SVG fills or strokes; in others they are used in regular element colors or background-colors. We can’t just create a single modifier class for each color on the color scale because there are different properties that we want to assign the color to. We could use Sass to generate classes for each color on the scale for each component’s need for the color, but that creates a lot of CSS. Its a lot easier if we can just add colors when we are generating the graphic.
Furthermore, using only CSS classes for styling still requires you to couple your JS to your CSS; instead of duplicating the color values, you duplicate the class names. It adds indirection without meaningful abstraction.
Great breakdown of reasons on both sides here, Chris. Some good points I missed in my article, too. :)
I’ve had the pleasure of working on a few React apps where pretty much the entire page was a React component tree. Most of my styles were defined within the CommonJS files and inlined with JSX
style={styles.whatever}
. It’s super handy to have everything for a component in one place, but the simple :psuedo states were sorely missed from classic stylesheet’ing.I eventually settled at a happy compromise where most interactive things (with lots of state) are handled with component inline CSS, but the “read-only” stuff like the general layout and global things were handled with a SCSS build process.
Also, Webpack provides some handy loaders for including CSS (or SCSS to be processed) right inside your CommonJS build.
While I have not worked on a react project for production, I feel that I would come to the same conclusions. I get it, there are great reasons for packaging the CSS with the component, but not at the 100% sacrifice of all common CSS styling practices.
On my current project we are not using Webpack (yet) but instead using a Gulp script that is doing much of the same thing.
I agree, package up the component specific UI with the component. This is a GREAT IDEA. That way you don’t have to load a whole UI library for the sake of getting one component’s styling, ala Bootstrap. But defaulting to inline styles written directly in the JS seems like a cop-out and there is so much awesome lost in that short-sighted process that is needed for larger scale projects.
Great article Chris. Points made much less fanatical then I have done in the past referring to the bleeding edge trend to JS all the things.
App devs and CSS have always been at oods and oh yeah, I remember JSSS all too well.
I spoke with a Facebook dev here in Seattle on this vary topic and he referred to this trend as the ‘radical wing of React.js’. While there are great insights into this way of development and ideas I am more then willing to embrace, there is no evidence in this immature framework that leads me to think that we need to throw out the baby with the bathwater.
Hell, we were all convinced that Rails was going to go enterprise scale too … oops.
If this is where things go I will go back to print design
I think this speaks to something really essential. Designers have occupied a place somewhere between photoshop and application state. That space is going to get smaller and smaller as client side apps get more and more stateful.
YES! Programmers thinking as only programmers can..there’s gonna a whole lot of alienated designers!
IMO, designers should do what designers do best, and stop with Photoshop. Styling components and applications became a development task long ago when pure CSS failed to step up to the needs of the community.
With enough wireframe detail, a developer will always be faster at styling an application than a designer, and can do so while ensuring that the markup and classes are consistent across the application. A designer shouldn’t have to care about namespaces and CSS conventions used across the application, they should simply concern themselves with how it looks. It’s so much easier and requires much less ping pong that way.
then developers should stop calling themselves designers!
I am a designer who started learn code from the early 90s. Why? because as a trained designer and artist I have been taught to understand my materials and processes. Just like understanding how a printing press works and what ink weight is, how different pigments bleed and are useless in underpainting, or how divs and CSS made working in html and php alot easier, its essential that we understand what we work with. Its an old artist term but ‘truth to materials’ I think should apply to any web work. Anyway google has force designers and programmers into a narrow corner and it doesn’t like javascript!
I’m so glad this topic is being dragged into the light. Whatever side of the topic you find yourself on it’s hard to turn a blind eye to CSS’s faults. Hopefully conversations like this serve to improve the language. I think responsive design and the complexity of managing element state in JS will ultimately serve as this technique’s end… but it does solve, what is in my opinion, CSS’s biggest weakness: scoping.
Conventions like BEM can help cover-up the scoping issue but they can be tough to enforce, especially on teams of varying experience. Until we get web components (and more specifically the Shadow DOM) or some new technology that hopefully gains traction quickly, developers are stuck with less than ideal solutions to a major flaw in a pillar of the web.
Me personally? I don’t have a problem with it. I think for web apps it can be a very creative solution which likely already rely on JS for more than your average site. But ultimately, it’s not the long-term solution developers or the web is hoping for.
And maybe this is it!
http://dev.w3.org/csswg/css-scoping/#scope-atrule
CSS Scoping is thoroughly solved with the advancements of the specs that comprise the ability to make Web components on the Web.
If you only have a hammer, every problem looks like a nail.
That’s exactly my thought.
Use the appropriate tool. Learn to write better selectors (Marco’s 2cents among his 10cents). Be responsible for your own code. The real issue behind all of this is aversion to dropping what is comfortable and instead trying to expand a tool to encompass new ideas. For all those who have been around, it’s akin to the argument that Photoshop has too many features now that aren’t related to pixel manipulation and Illustrator has too many features that do not relate to vector drawing. We don’t need to discuss all the other Adobe apps, the concept with trying to make everything possible with as few tools as possible is really hurting more than helping. This whole argument about inline css seems to be a different animal, but it’s not. Let javascript be javascript, css be css and html be html. Many tools available to check what css is being used and what is not. Many syntax checking tools are available, etc., etc. I think more of us ‘behind the scenes’ front-end people need more education in UX/UI than worrying about what tools are going to automate our thinking, cut down on our keystrokes or whether we should use four spaces or four tabs. What hasn’t changed is how important the content is and the experience for a user has when using a web app, visiting a website, interacting with a kiosk, museum exhibit etc. There’s so much more out there than web-apps on a phone and websites…trouble is, there seems to be increasingly more focus on how something is going to be built instead of what’s going to be experienced.
Very well said. UX is much more important for a front-end than where the CSS lies. Also, there aren’t a ton of HTML and CSS developers who are unicorn enough to know JS just as well. Separating style from functionality was fought for for years, why would we want to combine the two again in the name of poor organization?
Validation
Branding/Cobranding
Accessibility
What I see quite often is developers who don’t know any of the standards and they’re just copying/pasting/regurgitating what they see somewhere else. So if you have a good developer who knows all the web standards and can ensure everything is valid and they’re the ones making the initial pattern to copy then ok. But eventually errors will start sneaking into code, and get replicated and introduce more errors, or developers will compose components in a way that produces non-compliant output. By keeping the concerns separate you have the ability to better validate each concern independently as well as validate them together in their variations.
I’m not sure how I would manage a brand presence in react. Would I have to subclass a button and have a different subclass for every branded button and then do the same thing for every component I have in an app that the client wants their logo or specific brand colors on? If I have a 1000 clients who each want some minor variation in branding, I’d rather just have a 1000 small CSS files that I can load dynamically than to have to have a whole application component library multiplied by 1000 to have to maintain. Because I can drop those CSS files into a content management system, whereas I’m not sure I can do the same with the react components or whatever JS files – that might be giving too much control to designer/content authors/brand managers.
So I think this combined approach might be adequate for small focused sites with very limited customization from user to user. I don’t think the approach scales well. For instance just look at the nature of Facebook – where reactjs originates from. You have a single layout/brand. It’s very set and rigid. Users can filter what content is displayed but not how it’s displayed. So it’s always going to be boxes of content in a 3 column blue layout. The other aspect is for facebook the website IS THE PRODUCT. So they can spend the money to really make sure this is all well-defined. In other companies the website is a gateway to the real product or service and they won’t devote that same level of detail or effort to ensuring it’s “right” and in the end they’ll pay for it in later maintenance costs and customer frustration.
First time commenting, this post induced such emotion, it forced me out of simple observer to participant.
If they require JS for “styling”, I think their design is wrong. If they went to the end result of their logic, it should come full circle to the OS and all other systems do. Themes.
Android, Windows, Linux, etc… all went through this, and in the end, you need to be able to change the look and feel of everything from one place. This was the original intent of CSS, was it not?
The fact that people have borked up their apps so badly, and have mismanaged their code for so many years is not a good reason to through out years of knowledge and experience.
Btw, I use inline styles every so often, but in very unique cases in apps where it’s just so inconsequential or a fringe requirement, or in general web design for the sake of saving time (ie, mockups, tweaks to live sites for client review, etc…)
The Answer: web components.
I have made a good living staying a year behind everyone else, never on the bleeding edge, watching the browsers change, not implementing hacks (star hack anyone?), not using polyfils (unless abosolutely necessary), living without shadows until their were supported (instead of adding 4 div wrappers with a pile of sliced images).
Now this. The shadow dom, ECMA script 6 modules, web components will solve these problems.
Just be patient. This is crazy bandwagon, be careful.
Couldn’t agree more. I understand people are afraid to delete unused CSS for fear of cocking something else up, but that’s because a lot of the time people are writing sloppy CSS. As with most other things in the world people are focused on doing things as quickly as possible and not actually doing it properly.
We’ve all worked hard to separate things into Content, Presentation, Behaviour.
And now this. What next, the return of the FONT tag?
Coupled with Google’s insistence that half our CSS should now be separated out and inlined, I worry the future of web authoring is going back to how it was 15 – 20 years ago
I doubt the originators of this approach worked with inline styles in the 90s like some of us. This idea sounds awful to me.
I think styling should be declerative. It will cause an enourmous amount of bugfixing need when doing styling with anything procedural and i think react is inventing a problem which does bot exist.
i’m not gonna change the world now but people should really put the extra effort in learning proper css styling rather than blame it
I know for sure that CSS is a language that needs to evolve but not like that. Not by being engulfed with JavaScript.
I’m not against javascript, actually I love it, but I love css too, and they are like best friends, almost lovers, they holds hands each time a new website or app is deployed, why some one would ever want to break this beautiful relation.
Eventually we will be moving the entire html+css+copy into a js file, then a new structure for this file is going to be needed, you learn this new stuff, and at some point some one will say “This is too much!!”, and then we move content to different js’s, one for the css, one for the html and one for the copy, all modular and portable, just like the way it was, but better, because is javascript, right?, and do everything in javascript is like… cool.
Javascript is great, React JS is REALLY great. I’ve used it for almost a year now. But it will never replace CSS. There is absolutely no reason to not have a stylesheet. Just be smart about it. I use React’s style object only when I know the element will never change, or will only change with via some method in the React component.
First – Déjà vu.
Second – I was thinking js frameworks should uses grunt/gulp or similar modules for decoupling inline css/js from its component and creates files in build process.
What about promoting open standards?… Chris?… anyone?…
Here’s your Kool-Aid back, React.
oh, forgot:
https://www.pandastrike.com/posts/20150311-react-bad-idea
Web components solves this. If you can’t wait any longer then use Polymer.
JS;DR = JavaScript required; Didn’t Read.
http://tantek.com/2015/069/t1/js-dr-javascript-required-dead
Yep, I hope that built pages are still considered to render something without JS?
People have been telling designers they need to understand and write logical, best-practice JS for years (agree); likewise wouldn’t it be a good idea for developers to understand and write logical, best-practice CSS?
React developed primarily by Facebook = never mind JS or CSS — have you ever taken a look at the markup FB uses? What happened to semantics? And why do apps get a pass when it comes to accessibility and progressive enhancement?
If module-specific rules are written in JS and get applied server-side as class names before delivery to the client there is no difference for the user; but if you’re using these methods to inject inline styles on individual elements it is madness.
Struggling with CSS? Read more Chris Coyier or pay a visit to Harry Roberts’ site (http://csswizardry.com/). CSS bashing isn’t something new; people have been moaning about it for years. Likewise, Douglas Crockford wrote “JavaScript: The Good Parts” because so much of the language is bad.
There are strengths and weaknesses to all aspects of web development; learn how to use the standards first and then learn how tools and frameworks can help from there. At the very least, learn enough to know when you don’t know enough and call on someone who does.
Just because you can do something, doesn’t mean you should. CSS is just starting to get to the point where it is becoming truly standardized. Maybe one day the browsers will even agree on a standard.
Chris we really need a voting system for comments in CSS-Tricks. In this types of articles is interesting to read the most popular comments.
And Web Components fixes all this issues you mentioned. Go go Polymer https://www.polymer-project.org/1.0/
Bad frameworks promote bad habits just as good frameworks promote good habits. This is solving a genuine problem with a wrong solution. Shadow Dom and CSS scoping are in better direction, although they’re not backward compatible.
Totally agree. I have worked out a few ways to handle minimizing global pollution and collisions that. Hopefully it’s useful to others here.
For the stuff I’ve been working in it makes a nice bridge between current pre-processor strategies and future web-component encapsulation.
Apparently there’s some kind of iframe embedding thing happening with links from medium.com. Last try.
Semantic Remapping Article
Hey Chris,
I’m surprised you do not mention Atomic CSS or ACSS in this article as I believe it is a bridge between “classic CSS” and “CSS in JS”.
For example, I think it solves the problems you list early on:
Everything is global
CSS grows over time
You can be more dynamic with styles in a programming language
You say the alternative is inline styles but “inlining styles” can be done via the class attribute as well. It is this (pseudo-code):
<div class="padding-20px background-eee margin-0 marginBottom-20px">
instead of this:
<div style="padding: 20px; background: #eee; margin: 0 0 20px 0;">
Unlike “inline styles via
@style
“, values can be uglyfied hence have a much smaller footprint than “inline styles via@style
“. Also, the associated style sheet is cached and it cannot get as big as the m.uniqlo.com example you give (57k
) while allowing for “state-based class in the DOM”.A lot of people don’t like ACSS but that’s mostly because of its syntax as it seems to avoid the pitfalls you list about “styling via
@style
“:Styling is what CSS is for
Atomic CSS is CSS
Inline styles are at the top of the specificity spectrum
Atomic CSS relies on simple classes, hence has low specificity (
0,0,1,0
)–(How is Atomic CSS different than using inline styles?).Some simple states are much easier in CSS
Atomic CSS is CSS (see pseudo-classes)
Adding/removing classes is a perfect tool for state changes already
Yep!
Browsers aren’t made to deal with styling in this way
Yep!
Some of these “dynamic” styling concerns can be solved with regular CSS
Yep!
CSS is cacheable
Yep!
You can still use React
Yep!
Doesn’t anyone care about progressive enhancement anymore?
Documents relying on inline styles (
@style
) can be “rendered entirely server-side” but this means sending all the inline styles over the wire and that’s rather “expensive” (and none of that style is cached).I didn’t list in there “The separation of concerns is inherent to CSS” because I believe this is a moot point for people who author documents very differently than what we used to do years ago.
My .02
If I think about my current work, what about inheritance of work? The great thing about Sass / Less / etc. are the inheritance or developing modular. I don’t know React well but it doesn’t Look like maintaining code long-term is easier. OOCSS, BEM are already great ways to maintain CSS (imho) -> maybe more (boring) conventions instead of doing all in JS would be better.
This confuse me a lot, no CSS, some say no Javascript in the future http://techcrunch.com/2015/06/17/google-microsoft-mozilla-and-others-team-up-to-launch-webassembly-a-new-binary-format-for-the-web/ , then what?
IMHO this is the wrong question.
The most avoided question is “What should replace CSS”.
(style=”~” is still CSS, it solves nothing to just have CSS in modules, decoupling design entirely is not the same as decoupling widget code)
CSS was a good design 21 years ago but it literally didn’t scale for the future. IMHO ;-) CSS is old & crappy, we keep adding more features to it to make it more like SVG which is far more superior but was purposely made incomplete for some reason. If I had to take a guess I would say because big companies have apps to sell (read between the lines)..but that’s irrelevant.
Why are we so complacent with this cascading, restrictive not-real language that is just introducing variables after 21 years.
If we continue for 5 more years without a solution away from the horrific box model, how can we say we take web design seriously. (Flex-box is not a solution)
Why are we not talking about this issue?
Last note: (I think we need to stop associating progressive enhancement with server-side rendering, it’s totally not related)
Maybe I’ll sound a little bit hard… but if CSS global nature scares you or if you’re afraid of managing codes to avoid breaking stuff, you’re probably not writing good CSS. Specially nowadays when we have SASS and Grunt (or any other preprocessor/task manager you like) to help up writing modular CSS and compiling them easily.
Perhaps I’m missing something, but for me quitting the whole CSS structure and replacing it by non reusable declarations applied via JS is just too hardcore…
In React (Or JavaScript) for that matter they are reuseable. Think of it like Sass mixins, they have a single point of source where that code can be injected any place and any number of times you like.
People get confused by what DRY code actually means. It does not matter if your compiled result is DRY, where it matters is your point of source, so like a Mixin you JS style object has a single point of source.
This will never replace CSS, I love writing modular CSS. But CSS in react is useful where we want to encapsulate components with styles that only live within that component. This means a particular component can be shared across a project or even different projects without having to worry about things breaking.
The whole debate of inline styles being bad was because they were not created by JavaScript with a single point of source, maintaining a lot of templates with inline styles was a nightmare. This is not the case with React. There are issues with specificity and in those cases don’t use React for those styles.
-It’s to be used sparingly when needed, not as a replacement for CSS.
What about Print style?
When you Print the page the browser get the inline style and not a dedicate CSS!
Lol, I talked about this in the good old days when preprocessing was the “big thing”:
https://css-tricks.com/poll-results-will-there-be-a-css-competitor/#comment-159847
No one listened to me back then :D
But I really like this idea, I imagine it would open up lots of new possibilities. Styles could be shipped to the client even more compressed:
I would dig this!
I am a big fan of the inline styles approach. ReactJS is a radical departure, yes, but it’s a genuine answer to the modularity problems of CSS. It’s a genuine answer that is performant and available for use right now.
Best practices CSS can be modular, of course, but it is still frustrating to have a component’s code separated among (often) 3 separate files: an HTML template, CSS, and JavaScript.
Styles are driven by application state. Actions, errors, validation, etc. Application state lives in JavaScript. The coupling is real!
I still use stylesheets, but only for truly “global” things like broad layout and fonts. I feel really productive with this approach. :)
Once again the engineers have created a complicated a solution to an “unproblem”.
“Smart people on great teams cede to the fact that they are afraid of their own CSS.”
Its amazing to me that the engineers that create such complicated work arounds can’t understand the simple top-down nature of CSS.
SASS + SMACSS = The way to go.
^ All of this.
Like.
So, all the points against CSS are invalid, they’re just a reflection of bad practice, that’s not an excuse.
Everything is global.
So easily solvable with namespaces I don’t even know why people have issues with this.
CSS grows over time.
Yes, that happens with all code if the product grows, are you inlining your JavaScript in the DOM because you can’t figure out how to handle multiple .js files? Didn’t think so. Basic use of LESS or SCSS solves this (sure, they’re not part of native CSS, but I seriously doubt your JS flow is native either).
You can be more dynamic with styles in a programming language.
What you mean to say is that you can use CSS in certain ways by building you own implementations for when to apply the CSS and at the same time lose out on others since JavaScript can’t target everything CSS does (have fun with ::after and ::before).
I agree… I really wanted to hear this article out but there’s not a single point made that truly necessitates the lack of “need for css”. I could rant, I could rave (believe me I’ve started to many times while reading this article) but the answer to the question is “Yes, we still need CSS. Duh.”
Sometimes I read articles on such problems and all I’m thinking is: Are those really problems?
I totally get that application developers are having a hard time with technologies that don’t run in the same vein as their application framework. But that doesn’t mean that the technology is broken. It actually means it’s not suitable for certain ways of thinking.
I don’t want to be one of those guys that just shoots things down because they are different, but this just seems crazy.
I agree, CSS can be all of those bad things described earlier in the article, but mostly only when written poorly.
Replacing one “problem” with a multitude of new ones.
CSS is not the problem, but the way many developers consider and use it. Let HTML define the structure, CSS define the presentation and JavaScript define the interactions. Let’s not be so religious about Atwood’s law. For example, focus indicator, hover, active state could be easily achieved with using CSS pseudo classes, and applying inline styles by JavaScript on listening to the corresponding event.
Agreed that global CSS has its cons, but it also serves a purpose. Till we have native component ecosystem (w/o react/polymer), global CSS tries to enforce an uniform looks across the application.
Sass is essentially a programming language for css. JavaScript being an alternative is an obvious choice, thought we would have first started with a javascript to css compiler.
Got to face it people want to be able to test their code to ensure correctness and css as yet can’t acheive it and it will evolve until it does.
I respect many of the developers who here doubt CSS, but I’ve also seen much in this debate that stems from a misunderstanding of CSS.
That CSS turns increasingly more complex [1] is one thing, then, driving people into the hands of frameworks and libraries; but we then have a most terrible track record of understanding and (post-) optimizing CSS [2]. Just look at how WET most style sheets are even though (!) they were pushed through pre-processors and such. That’s basic CSS, and few get it right.
The debate often lacks understanding of why Separation of Concerns is so important. And that’s for another poor track record: We tend to just redo instead of reiterate. When we all toss what we built before, instead of trying to optimize, improve, build on it, all we care about is how to work quickly (and dirtily—qed), but not how the “religious” separation is so immensely useful. (Think of the vision of web dev [3]).
There’s more, yes, but the debate is odd, and illumination is not to be found here, right now.
[1] http://meiert.com/en/blog/20150518/fing-up-standards/
[2] http://meiert.com/en/blog/20141009/css-dry-and-optimization/
[3] http://meiert.com/en/blog/20150513/vision-of-web-dev/
CSS for people who don’t understand (or don’t want to understand) CSS. I can think of a number of developers I’ve met throughout my career who will love it.
No. Thanks. I’ll stick with CSS.
Don’t make CSS a programming task.
As someone that has been doing professional web design/development for 19 years, this is absolutely positively the best answer. Well said!
For me CSS has two problems, and none of these are related to its global nature.
The first is that it isn’t really a standard, as all browsers read the code differently. It’s frustrating that development time, which could be spent on building a better user experience, is waisted on ensuring cross platform compatibility (especially with older browsers like IE8-10). You should be able to write once and have it work everywhere. Old browsers should automatically download the code they need to render the page correctly.
The second problem is that the development of CSS is painfully slow and has its priorities all wrong. For example, it’s been around since 1996, and we still don’t have a good, standard way of laying out the whole page (e.g. header, footer, columns). CSS grids will change this, but it’s seems strange that we got rounded corners before layout grids. There’s also multiple ways to implement common UI patterns, such as menus, accordions and sliding panels. These common UI elements should all be built into CSS and rendered with a single line of code (e.g. ul {ui: sliding-menu;}).
If CSS didn’t suffer from these two issues, then I’m sure it wouldn’t get so much hate.
Web components offer a solution, but I think it’s going to be a long time before they are ready for prime time.
Outputting CSS inline is very messy, not easily maintained, and not recommended. I have been in the web design/dev business for over 20 years and have seen quite a bit, and this will cause more issues in the future. I do think that CSS/SCSS has progressed so far that is can be hard to maintain. It may be better to simplify CSS, however, until all the browsers will be on the same page, I don’t think that will happen anytime soon.
I personally think this React style of development would be great for Web Apps and terrible for Web Pages. And that is a line that’s becoming more blurry. When it comes to building Web Apps, where you’re going to be designing logic and functionality that the browser does not natively have and all your work is JavaScript-centric then yes, React is a natural choice.
However when you’re working on Web Pages the quote from Keith Grant (and echoed by some of the commenters here) is absurd. Call me old fashioned but no web page should NEED JavaScript. JavaScript is for adding niceties, streamlining interaction, and building ROFLcopters. If your pages don’t have at least base functionality when working in the confines of browser default behavior, then your job’s not done yet.
Sounds like we’re loosing ground in the progressive enhancement, separation of concerns, simple markup war. Shall we just go back to designing layouts with tables?
To me this sounds like more of the charge of looking for a one-size-fits-all uber language. I remember the “all you need is Java” stance and then applets and swing and awt, then it was flex and air, and then dart and go. I remember developers telling me to switch to GWT because it would just generate everything for you and you didn’t need to write JS anymore. We can admit that CSS has some downsides and even HTML for that matter and find solutions that don’t mean scrapping the concepts altogether or burying them in layers and layers of abstraction that require people to take on a bunch of cognitive load to track. There are a host of issues that react and js rendered styling does not address that keep it from being the uber language. That doesn’t mean there aren’t valuable take-aways. It just means we need to start listing out some of those scenarios and talking through how to solve them in code and how to reshape the standards for better fit.
Where do web components fit into this mix?
Interesting but think I’ll stick with CSS. Also, please correct your “it’s” and “its” right. Made for a hard read in parts!
So basically the React crowd is saying that javascript sucks less than CSS?
I don’t think so.
As someone who has to rebrand websites every 4 years or so, I’ll keep my presentation separate thank you very much.
Just wait till Zeldman here’s about this.
Good article Chris, it’s hard to articulate the reasons why people are moving this direction and what the proposed changes would look like in the end but this is a great overview. The main motivation is better scoping of styles and it’s closely tied to Web Components.
The idea behind Web Components is that you should be able to reuse a chunk of html, css and JavaScript without it interfering with the rest of the app. The proximity of the code here is important, HTML / CSS and JavaScript related to the same components behavior and state should be as close together as possible because it’s simpler to reason about, safer to change etc..
Your final note on Progressive Enhancement:
It’s still important and our tooling will mature to a point where it’s easy for us to do the right thing here(send HTML from the server, even for rich web applications).
The biggest blow to progressive enhancement has been that people have given up on the app entirely without the presence of JavaScript.
“All of your users have JavaScript disabled while your JavaScript is downloading”
This is the worst twaddle I have read in some time. After some 20 years of coding web pages, it is rather sad to see the same tired arguments making rounds. But at the same time I am grateful. Meat bags coding with inline styles and trying to replace css with javascript will probably secure my continued career for another 10 years, and probably a lot of happy clients who realise that they should be more discerning when hiring talents.
Point of the matter is: if you “don’t get” CSS or can’t write it or even bother to write it. Let professionals do it.
This is silly.
This makes no sense at all. All the problems we have with CSS are practically fixed by SASS and LESS. The componentizing of React allows anyone to use specialized SCSS-files for each component. Hell, I’d write my own tooling to generate it for me.
If you have a React component called Post, your Grunt or Gulp process could identify this. If it’s a singular element it’ll create #Post in your SASS-file. If it contains other elements, it’ll create those CSS elements inside the #Post definition.
And if there are multiple posts, it’d change your SASS-file to say #Posts > .Post or something. Add an element inside a post: you’ll get a new pleasantly ordered addition to your SASS-file. Remove or rename an element? It’ll do the same for your SASS-file.
Then things like SCSS and other optimization tasks can remove unnecessary CSS from the eventual output. In the case of prioritizing some CSS-files over others you could setup your components to have a CSS-output priority or ordering.
Anything is better than inline CSS. God, that is just a horrible idea. What’s next? Instead of semantics we’ll just go back to div-soups? And “gosh, most layouts are table-like. Let’s just use tables!”
This seems like the dumbest argument I have heard in a while. Having to point out the many reasons is not worth the time.
Sounds like a bunch of developers who hate CSS are trying to make this idea sound good. Plain and simple it is not.
Currently (in mid-2015), it must absolutely boil down to ‘Can you guarantee the end user has JavaScript available?’
If you can’t guarantee that then you should be building to ensure all data is available without.
It’s almost as if developers don’t care about web standards any more. The very same web standards we all worked towards to unify the web and make it accessible to everyone.
What about page speeds and code maintenance, separation is definitely better!!!
Though I love the power of React and inline-style, I style feel it as dirty.
Beside, one has to learn Javascript before enjoying it fully.
The other thing you should think of is SEO aspect. Christ mentioned browsers that have to review how the RENDER our content if we adopt inline-styling, but we also have to worry about how search engines will READ our “new’ content.
I am not ready for inline-style for now.
Agree! I cannot believe that the un-searchability of javascript hasn’t been mentioned. Honestly, I could only get away with using this technique in less than 1% of the stuff I work on.
Having come from a C++ game development background, I know how hard it can be to create a highly dynamic, well-styled user interface. When I got into web development, I was pleasantly surprised to see how easy it was to create sophisticated visuals via CSS (and now, Sass), so much so, that I’ve thought about using HTML and CSS for rendering in-game interfaces. Creating highly customized visuals via code is a very difficult task.
Now, this idea might work well for strongly modular, application-style websites. The type of websites that you could just build with Bootstrap and not have to worry about CSS at all to begin with.
But, once you get into the deeply creative, highly sophisticated visuals of some websites (not web apps!), this idea breaks down completely.
The perceived problems of CSS aren’t necessarily problems.
Most people like a lot of consistent styling on their sites. You want, generally the same colour schemes, a small number (often 1, rarely more than 2 or 3) of font styles for the headings, links, buttons etc. and their various states. If you do need extra, then you get into needing naming conventions and so on.
CSS grows over time. Show me code that doesn’t?
People write really complex CSS without pre-processors, it’s not compulsory to use them. If you do, a lot of your input and output is still essentially CSS. Most people who write CSS know a decent amount of jQuery to do the necessary tasks for adding inline styles live, and you know what, it’s still mostly CSS with a bit of a wrapper, and it picks up all the cross-browser compatibility for you and if you’re good, you write it to work ‘well enough’ in JS-disabled browsers which are still out there.
I happen to write decent javascript, I wrote it for a long time before I picked up jQuery. If you’ve got an webapp, where you’ve got millions of differently styled things doing different things and changing styles a lot I can see this is one approach that is attractive. It’s nice to keep all the code for “x happens” in the same place together: if you’re writing a game and the pretty balls in a group flash and disappear, as a game dev you usually want that code all there, not abstracted to a different file that covers the balls’ appearance. Of course if you’re writing with a MVC model you’re doing it with a different approach anyway. But if you’re styling the next CSS-Tricks you probably don’t have disappearing balls in a game, do you?
And unless your webapp is fullscreen, it probably still benefits from CSS for the elements around it unless you have a religious requirement not to have them.
This isn’t about making CSS go away. It’s also not about hand-writing inline styles. In essence, it’s really just presenting an alternate way of selecting the elements that get the styles. And this is only a good idea for a subset of projects.
Just because we’ve settled on a particular separation of concerns doesn’t mean that separating along different concerns has no merits. If I’ve got well-defined HTML/CSS/Javascript for a component in my application, it would be great to have that stuff all in one place.
And as for the fear of making CSS into “programming,” the very fact that CSS has so little structure to it makes some kind of engineering discipline essential in large projects. That’s why we have OOCSS, BEM, SMACSS, SUIT, InuitCSS, preprocessors, etc. CSS is deceptively simple if all you do is work on small sites without a lot of functionality. Beyond that, it can be quite challenging.
Using Javascript for everything is not being suggested as a best practice. But it can be a great way to go if you’re prototyping out a new idea that isn’t supported by standardized tools. Maybe the next web styling language will be discovered this way.
Perhaps you should check out GSS — https://gridstylesheets.org. I still prefer CSS, though.
No pseudo-elements (
::before
,::after
) with inline styles. Ditto with pseudo-selectors and media queries, but they were mentioned above.Also, I can’t see how performance is not an issue with this all-JS approach. The DOM has to constantly parse CSS with each DOM mutation, where a stylesheet is only parsed once. In situations where ReactJS’ virtual DOM is being pushed hard (1000+ elements), having the DOM parse CSS as well will definitely hurt performance.
But how does this work with Googles approach to controlling design of websites. Google penalizes java-script usage and inline styles. Also inline styles can then cause a problem with template updates
When someone asks if I could write all styles inline:
So hell yeah we need css!
This comment is in the context of the new poll.
My gut reaction was to select “No, this is a stupid idea.” We’ve come a long way in separating content, presentation and behavior… it’d be a shame to do away with it.
However, I decided on “It kinda rubs me the wrong way, but I’m trying to be open minded about it,” because I know that I get annoyed with articles that are too opinionated.
I wouldn’t say I’m staying open-minded about this, because I think it’s a pretty bad idea, but I’m willing to admit that we might not know the best way to do things yet.
I like your open mindedness think about this for a different perspective. Over the last few years technology changes have allowed backend developers to come to the front as well, however in all the stack css is a vital component that isn’t programable, isn’t testable and that lack of surety is frustrating.
I think the goal is to obtain that last peice do that css or whatever it becomes is reliable, programmable and testable until that happens these post types will continue to occur.
FYI, here is a follow up presentation by Christopher Chedeau (Facebook engineer guy). It addresses some of the questions. Media queries, pseudo-states, etc. React: CSS in JS – React France Meetup
https://speakerdeck.com/vjeux/react-css-in-js-react-france-meetup
So, uh, he’s showing why we shouldn’t be using inline styles, right?
Examples from the slides:
:hover
::after
…Really? Some of these examples are the biggest steps back I’ve seen.
I love SASS, because it allows you to do so many things that you can’t do in pure CSS, but I hate the language itself, SassScript/Ruby etc. is just horible to me and I’ve been waiting for somebody to create a CSS preprocessor that uses JS as it’s scripting language.
Turns out the answer may just have been to use Javascript all along. I see problems with this idea but I’m going to be keeping a close eye on this idea to see if it takes off.
So … CSS is fault tolerant.
Javascript is NOT!
Of course it will be adopted by developers who hate working with design code, but I don’t see it as the future.
This article is way ahead of its time. Thank you, but I love my CSS too much to part with it. And hey, SASS fTw :)
Chris, are you trolling us? It feels like you might be.
I had someone at work tell me that he supports using IDs in CSS because of the “idiot young developers” who would inherit the project sometime down the road and override his styles with their own and…well the rant went on.
I am all about necessary change, but I’m not going to start inlining styles (seriously wtf) no matter how it’s dressed up, just like I’m not going to write more emphatic code (either with #’s or !important) just because some bad dev might inherit my code someday and mess it up.
Also this idea that designers should “just learn JS” needs to die. They are designers and not developers. Just because I can develop a site based on maths doesn’t make me a designer. There’s a lot more to design than the grid system and the golden ratio. Developers make the internet; designers make it beautiful (not just nice to look at but also pleasant to use). Of course, I acknowledge that even that is probably too much of an over-simplification.
But seriously, are you trolling us Chris? Because it sort of feels like it.
Styling with stylesheets is what is intended. Scripting with Javascript is what was intended. Why try and put styles purely into scripts? I personally don’t see the problem with CSS scaling if it is modular, and who is to say you that the same problem wouldn’t persist in this Javascript solution.
Also, in this debatable Javascript solution, are we taking into consideration the ever growing number of frameworks we’ll need to learn just to style stuff? If style is added to a particular project, would you then need to adapt your styles if you change your framework? Or more likely than this, if you are working on multiple projects with different frameworks implemented on each.
Aren’t we just over complicating the simplistic task of styling. I agree with a comment further up, It’s the wrong solution for a present problem. The realistic solution is probably a far more aware DOM with style selectors to match.
It seems a big part of the problem is the lack of the HTTP 2.0 support. Why does CSS grow over time? Because we’re putting it all into one minified and concatenated file.
Why do we do this? Because we’re trying to limit the requests that go to the server. If we could make fifty parallel css requests to the server, we would be able to scale down the amount of css we’re serving up at once.
Also, it should be mentioned that this magical fairy thinking is completely bogus when it comes to React and the Virtual DOM. Reddit tried to use it on their mobile site and took 47 second to load images.
https://github.com/reddit/reddit-mobile/issues/247
Quoting Addy Osmani: “The TL;dr is: The “The DOM is slow, virtual DOM is fast” meme is somewhere between misleading and wrong. Doing any kind of extensive work in JavaScript during page load will kill you and JS size is still important.”
React bloats JavaScript, and that’s going to kill performance.
Did you actually read through that Audit?
They tried to deliver a 1.1MB minified JS core with unrendered SVG graphics through React over MOBILE, instead of using it properly. React is fine on a ton of sites, including Instagram, Facebook, Netflix, Dropbox, etc. but it seems that their deployment was botched from a misunderstanding of unilateral design pattern that both Flux and React use. I also use it in about 10-15 sites right now, and probably will never move back to another way to develop.
TLDR: If you misuse a tool, you will get mixed results.
A couple of things going on here:
It is much easier to teach functional programming to designers/typography people than it to teach design/typography to programmers. (I know this to be true because that’s how I started, and I’ve seen it played out again and again over 20 years.)
I would argue that the best thing about CSS is the cascade. But it’s powerful, so you have to really understand what you’re doing and not try to cut to the chase. This means you need to have a development methodology and a sense of code organization that everyone knows and understands in your own CSS universe. Whether you implement that methodology with a preprocessor or write the code by hand is immaterial. It’s the methodology and the code organization that are the important parts. The important thing is to stick to it… In practice this seems to turn out the way some teams stick to Agile programming methodology concepts though…
If you build your methodology and organize your code around the concept of the cascade instead of attempting to fight the cascade or run away from the cascade, then you wind up with an easy to maintain/change/add to set of CSS that may need the occasional state assist from Javascript.
Replacing CSS as we know it right now with Javascript or React is really an act of attempting throw out 1/2 of the baby with the bath water.
Your mileage will vary based on how many hardcore functional programmers are involved, how many designers aren’t involved, and the general dynamics of your organization.
You don’t know how much you really lose until you try. I’ve had the pleasure of trying React inline styles / react-style in our app recently and I have to say the concept is a little far from a pleasing reality.
Implicit copypaste on every step, low transparency on the resulting code, “the problem” of natural inheritance in the DOM and the lack of pseudos… conditions for applying a hover and/or any other states usually grow the component style attribute to multiple lines of hard to read nonsense. Excluding a border from the last-child li in the last-child ul? Hover parent to change a child’s design? You’re going to loop a lot, you’re going to send a lot of states across component props, you’re going to experience simplicity the hard way again.
At this stage of CSS in JS, I would only recommend it for smaller standalone components as the expressive power of CSS is not being substituted correctly, or at all. One step forward, 2 steps back situation. If this changes, I’m ready for round two.
Maybe it’s just tacit knowledge of some kind, but react, ember, angular, etc… all kind of give me the same feeling as Flash. I was really excited to learn it in 2006, but I wish I spent the effort on almost anything else.
I think coders have lost their way; why? Because when someone from facebook, Google or any other big tech company comes up with something new. Everyone is expected to jump on board and follow the latest thing. Just as lot’s of commenters have stated, what if! and that’s the problem here, We build for the viewers who visit sites, not to see who has the biggest coding balls. Simplicity is key and that’s the first rule of anything in life.
I few, what if’s:
No-script is active?
Coders who don’t know JS takes over your work?
Don’t get me wrong I love JS, but it needs to be used in the right places at the right times. Not because a new library is being glorified.
Awesome!
Lol, gotta love Lea.
I can’t help but agree 100% with her comment. You can’t possibly express this any more concisely and effectively than she did.
It’s like that: The REALLY good CSS frontend guys are non programmers. It’s people coming from a design background. This will never change. If frontend visual quality is a topic, there is always a simple context needed, where styles can be applied without messing with too much dev environments, dependencies and co.
It’s not that the really good CSS frontend guys are ALWAYS non-programmers. Plenty of us have learned to program in order to supplement CSS values with things like function returns among other things. As I said earlier, it’s much easier to teach programming to a CSS design person than it is to teach the craft of design/typography to programmers who write in functional languages.
My experience is that functional programmers are often frustrated by the inability to write functions in CSS. Add in rules of inheritance and the cascade and the fact that programmers don’t think in terms of something akin to Atomic design the driver of the main functionality they are trying to produce and you wind up with frustrated programmers who more often than not, relegate the CSS back to the people who have the patience to deal with the rules of the cascade. BTW – I think Luke W.’s Atomic design is the closest thing to the cascade as any methodology I’ve seen out there.
Jean, I am in the same boat.. I code jQuery stuff, I know basic OOP, I mess around with vagrant, symfony, precompilers, functions, mixins, agile processes and so on. Still I would not consider myself a “programmer”, as I know and meet a lot of “real” programmers in the 14 years I work on this business. The problem is, hardcore backend guys learn CSS/LESS/SASS in a afternoon and then they think they know anything about look and feel or design principles. Doesn’t work like that :) I currently mentored a very big project done by a couple of very intelligent programmers for a big swiss bank. The project was totally stuck. They used tons of very intelligent and complicated LESS mixins as example, everything was totally over structured and over-engineered to the point, they actually completely lost overview. Basically – it was great and would scale in theory, but it was not possible to handle anymore by humans :)
Btw: project was built around atomic design and patternlab by Brad Frost – sadly to say it totally didn’t worked out well for a project that size. I am sure it’s a brilliant concept, but there where endless discussion how to structure things. One reason more the project got stuck. I was hired as a Bootstrap/Frontend specialist. They expected to hear some magic coding tricks from me to solve their problems, but was actually helped in the project was a big chunk of pragmatism.
@André – Your mileage will vary with any methodology depending on how it’s applied, and the inner workings of the people who apply it.
Yes. There are programmers out there who can write beautiful, creative code. No one can read it but them. At least not without studying the code for 6 weeks to figure out what the heck they did.
That’s where the dose of pragmatism and best practices is required. Methodologies need rules around how far you down the rabbit hole you go, and rules about writing code such that developers following your footsteps will be able to at minimum, maintain the code, and at maximum write new code following the same rules.
The most important part of pragmatism is to help people understand why over-engineering or over-building a solution is not going to help anyone in the long run.
The main reason why I keep an eye on CSS-alternatives –GSS, PostCSS— is that I think CSS still feels flawed to me. A lot of stuff is overly complicated (centering stuff, hello?) and it feels like that is for historic reasons only. I’d basically be happy with a CSS rewritten from scratch, but I wouldn’t mind some of the flexibility those CSS-alternatives seem to offer.
Inline styles, doing styles in javascript, changing the DOM from js by adding html elements? Whatever happened to the concept of separation of concerns?
I can see how it could be deemed useful in large applications to work with CSS the “React” way, but I also can’t see past the chaos that would result from writing CSS inline…it just feels wrong!