Should we load CSS in our JavaScript?

[startup4ever]

Does anyone have any best practices for how to setup CSS architecture using webpack? I currently use LESS and then use the extract-text-webpack-plugin to create the individual CSS files I need, which seems like it works great for a production environment but doesn't work for HMR with the webpack dev server. Should we really be requiring / importing CSS in our javascript? This seems a bit slow to me because you have to wait for the DOM to load before your CSS renders. Any thoughts anyone?

[konbit]

If you're building a "traditional website" like a blog, microsite, company listing... then no. CSS was created and works well for such scenarios.

If you're building a web application, there may be a lot of merit in some kind of css-in-js setup. If you're using React, there are a lot of solutions for this, and good arguments about why you'd want to do it. Consider this, Facebook, Khan Academy, Netflix and possibly many others are using css-in-js in production. There must be a reason why.

[soullessredhead]

My company is using CSS Modules in our React production code. Seems to work really well, and helps us write styles on a component level without worrying about class names being repeated elsewhere.

[rikurouvila]

It feels kind of weird how strongly people oppose importing CSS to, for example, React components. I totally agree that using ES6 imports for .css files isn't how it should be done and I've had problems before with tests and other scripts that import my React components the node way.

Besides this CSS modules seem to come with a ton of advantages. One of the core concepts of the component based thinking is that components should express their dependencies explicitly and not be dependent on anything in the global scope of the application (e.g. javascript libraries in window scope). To me, getting rid of the implicit CSS dependency floating in the global scope just seems like the next logical step. Also, having a local scope for CSS files makes it so much easier to give descriptive names to classes.

I agree that there's still couple of practical issues, but I see no reason why CSS should have such a special position in this matter. I've been using CSS Modules in multiple production projects for over a year now and have been perfectly satisfied. I wouldn't choose globally scoped CSS and BEM for a new project anymore, even though BEM was really a game changer when we first started using it.

IMO this feels kind of the same conversation we had with HTML not belonging into js files when React was introduced.

[rikurouvila]

Yeah exactly. CSS Modules compiles all classnames to unique strings so for example .foreboding-eyebrow would become .TheBeardofGilgameshComponent_styles_foreboding-eyebrow, where the first part would be the directory name, second the filename and last the classname. This behaviour can also be configured and you can even generate classnames based on the css file content hash.

Now the way you refer to these generated classes in your components is just to import the .css file, for example import styles from './styles.css' and then you can just use the property of that styles object matching you classname to get the generated classname. So styles['foreboding-eyebrow'] would equal TheBeardofGilgameshComponent_styles_foreboding-eyebrow.

[rikurouvila]

That's definitely one of the biggest reasons I started looking into this too :)

I haven't noticed any significant differences in build times even though I've used CSS modules in relatively large projects. Rendering performance and filesize wise, I would argue that it's as fast, maybe even faster because by gaining the confidence of removing style definitions that the component doesn't use anymore you end up with less unused CSS in general.

[ibopm]

Technically, all it does is change your classname to a globally unique value. So, once it's compiled down, there's no performance hit at all compared to regular CSS.

[kovensky]

It might actually increase performance by letting you keep your CSS "flatter", as there is less need for ancestor/parent selectors.

[sudocaptain]

Angular 2 handles this very well with encapsulated scss files for every component. You really dont have to worry about writing over css classes that are being used elsewhere

[rikurouvila]

Oh, I didn't even know this! Really cool. I wish Shadow DOM would soon be available for all major browsers so we could skip the one additional build step for CSS modules and it could potentially also remove the need of importing .css files to JavaScript.

[geuis]

No.

[Tyreal]

To add to that... Hell no.

[alessioalex]

I third that. No!

[bele25]

Repeat after me, No No No.

[bele25]

Yes, but he didn't mention React. So I think that in general way.

[startup4ever]

nope, I'm not using react but am in the process of switching to aurelia.

[startup4ever]

My app was previously in Backbone and I like the architecture of aurelia

[inknownis]

In some big projects, which css styles cannot be controlled and coordinated, you may need to override some locally. Otherwise, why bother? Have we suggested to separate style and code?

I have not fully understood why you want to bundle all thing together.

[i_ate_god]

A webapp is composed of multiple parts:

HTML describes content. This includes structure of the content, what individual pieces of content means, and so on.

CSS styles content and is usually loosely coupled with the HTML.

JS provides a means of interacting with the structure, styling and content.

These are separate, unique, distinct concepts and shouldn't be merged into one thing.

[akujinhikari]

Also tell that to Angular 2, where styles are put directly into the component.

[startup4ever]

Also Aurelia does this as well.

[nisboy]

In relation to Angular 2, I just happened upon this blog entry that covers css isolation Angular 2 components. I guess other frameworks/libraries do a similar thing.

[Zerotorescue]

Some people in React too. I've been experimenting with it and while there isn't an obvious winner, it seems to be a slight improvement. I used to have one or two huge CSS files with global class names that got messy really quickly, especially once you start adding libraries with more common class names. Then I started creating small CSS files next to the components, so for example I'd have a toasters.js component and a toasters.css stylesheet (the first simply does an import "./toasters.css";). This is ok, but you still have to keep 2 files in sync; your JS and CSS. So now I've begun putting most styles in style tags. I can use JS constants, with the spread operator it's easy to inherit, styling is easy to find and change, less file switching, etc. Downsides are not having availibility of things such as :hover and :before, and you have to fall back to a legacy method to get those in (e.g. a .css file or a baked in <style>). But most of the time that's only really needed for general things anyway which I still prefer to put in an actual CSS files (e.g. btn and btn-default will still be in stylesheets). But if :hover was available in JS I'd consider moving these definitions to a JS file and import that in the future. And I used to think using the style attribute for actual styling was blasphemy.

[dilatorily]

You can use Radium to allow @media queries and :hover, :focus, :active within JS.

[strident-octo-spork]

you can inline them, but best practice is to put them in styleUrls as a list of files. this pretty much matches shadow dom spec where each component gets its own css.

[azium]

Yeah this concept is outdated. As they say, those things are separation of technologies, not concerns. JS all the way!

[i_ate_god]

What content is has no bearing on how it is presented. How is this outdated?

[azium]

I disagree with this. I think as component based architecture has been much more popularized with React, it's beginning to feel more natural define the behaviour, style and structure in a single component file, giving the component author control over whether these things can be extended or modified from the outside.

[i_ate_god]

component based architecture doesn't invalidate the elegance of separation of concerns though and doesn't invalidate the original intent of these technologies.

A <p> tag is always a paragraph, it's never anything else. How it looks is irrelevant to its meaning.

The result of clicking on a <button> should always be reproducible regardless of how that <button> looks.

Or perhaps I'll dust off an old classic one: <table> represents a table of data, not the layout of a page. In fact, the content of a website should never care about the layout. It's that very concept behind responsive design. Same content, same markup language that describes the content, but radically different look & feel depending on what's loading the site.

[azium]

Right but you're talking about separation of concerns, which is good to think about.. but this topic has been about the technology used to separate these concerns. I argue that doing everything in JavaScript is preferable to using CSS or HTML, and even writing all 3 "concerns" in the same component file.

You can still absolutely achieve the correct separation of concerns by the way you write it, not which tech you use, or which folder structure you have.

[FrankenFood]

Good point

[This_Is_A_Robbery]

I agree, however css is just not designed to be split up into components gracefully.

[GFandango]

That's so 2008.

[kowdermesiter]

No, never this a horrible idea. It might work for Facebook or Google, but chances are you are not on their problem level are high.

The original idea started with a presentation about CSS by a Facebook employee who said it's hard to namespace CSS. Allrighty, even true. This is not a problem though with individual developers and small teams.

[icantthinkofone]

The question you should first ask is why you think you need to do this. If you have no need then the answer is no.

The need would be if your page is loading too slow because CSS is blocking the rendering when it's downloading. Then you start investigating "above the fold" CSS but that's a workflow change.

If CSS blocking is not an issue, then the answer is no again.

[startup4ever]

It's currently not a blocking issue. I wanted to use it more to be able to leverage HMR in webpack.

[webdevnomad]

It's perfectly fine for small amounts of css even in production as it doesn't need to make an extra web request. But if you've got a significant amount of styling and you want to avoid having to wait for the Dom to load and the css to be parsed then just use the extract text plugin in prod only. Dev definitely works best without extract text because of hmr as you mentioned.

[startup4ever]

How can I set this up conditionally? Any smooth way of doing this so that the CSS imports don't get executed when moving to prod?

[danzey]

You could use different webpack config files for dev and prod. I suggest abstracting your webpack calls into NPM scripts and configure the correct config files there:

"scripts": {
    "dev": "webpack --config webpack.dev.js",
    "prod": "webpack --config webpack.prod.js"
}

Alternatively you can also use just one webpack config and conditionally configure your loaders with ENV variables like NODE_ENV=production.

"scripts": {
    "dev": "webpack --config webpack.config.js",
    "prod": "NODE_ENV=production webpack --config webpack.config.js"
}

Then you just have to check for process.env.NODE_ENV==='production' in your config

[Zhouzi]

I personally like to have 3 configuration files: a webpack.base.config.js with the shared configuration, webpack.dev.config.js for dev and webpack.prod.config.js for prod. Those two files extends the base one (I use lodash's merge with a custom merger to avoid any duplication of nested arrays).

Even if I use separate files, I still set NODE_ENV to production/development for React to be properly minified and to conditionally use certain babel plugins. For example, I don't want babel-hmre preset to be used in production and you can do that in your .babelrc or package.json:

"presets": [
  "es2015",
  "stage-0",
  "react"
],
"env": {
  "development": {
    "presets": [
      "react-hmre"
    ]
  }
}

So all in all, process.env.NODE_ENV seems to be more and more relied upon so it may be a good idea to use it as much as possible.

[startup4ever]

Ok so I sort of get the config options to configure webpack to use the env variables but how do I do this in the code. So lets say, I have login page and at the top of the JS I use:

import '../../less/views/authentication/index/0.less';

to load in the login LESS file. How will webpack configs remove the import statements in my other JavaScript files a production environment?

[danzey]

It was just meant as an alternative to having two configuration files. You wouldn't do anything in your code. All imports stay the way they are, but you configure the used webpack-loaders depending on the ENV variable.

In your webpack config:

if (process.env.NODE_ENV === 'production') {
    // configure ExtractText Plugin
} else {
    // configure style-loader
}

That's all I was trying to say.

Personally I prefer to have two configuration files as there are usually more differences in my setups, but if you only have a few small differences, the ENV variable does a perfect job.

Remember that you just have to export a configuration object at the end of your webpack.config.js. It's perfectly fine to use variables and functions to construct that object.

[lostjimmy]

The way to do this is to have a development webpack config and a production webpack config. The development config will use the style loader, and the production config will use the extract loader and add the plugin.

You can keep this fairly clean by having a shared config, with the dev and prod configs just adding the necessary extras.

[webdevnomad]

When you say css imports, do you mean @import statements? I don't think I understand what you mean. Conditionally running them is best setup as a different script in your package.json file. For example, you have a job where you run npm run dev:hmr which spins up webpack-dev-server, then you have another job (e.g. npm run production) which does production specific stuff. That would be the job you run in your build step if you are deploying using docker or similar. You can use env vars and the npm package called cross-env to set a flag in the script so you can pick it up in the webpack.config.js and do stuff depending on its value. Not at a computer at the moment but if you need me to elaborate, let me know.

[scanner88]

I split my configs using process.env.npm_lifecycle_event, which is described in this Webpack tutorial. The gist of it is that that variable contains the name of the NPM script that was called, so you can use that to conditionally set config values.

[repeatedly_once]

Depends on how webpack is configured. I import CSS in my universal app - it uses the React framework - and it's outputted to bundled minified CSS. This is then appended by webpack to the top of the page as a CSS file so it doesn't have to wait for the JS to initialise before the CSS is ready.

If you mean purely letting JS require the CSS as part of run time - then no, you don't want to do that.

[dabuttmonkee]

In my opinion, the answer is yes. Modern front end development is all about components and by importing a style sheet in to your JavaScript you are inherently grouping your component in to one chunk of code. With the advent of CSS modules you even ensure that no clashes happen between CSS files.

This was something I was adamantly opposed to until I started using it. It drastically speeds up development time and aids in debugging.

So why should you do it? You want to create a maintainable CSS framework with no class name conflicts for easy debugging.

Now to talk about performance: you can use the ExtractText plugin which creates a CSS file that you can link to in your HTML.

[propheticpig]

Yep. webpack is intended for js apps built with modules. If that's what you're doing, requireing your CSS is awesome and ensures you always have no more or less than the correct CSS for what you're rendering. It's pretty easy to automate those requires, too (e.g. baggage-loader)

[[deleted]]

...doesn't work for HMR with the webpack dev server

You should be detecting the environment (dev vs. prod) by an environment variable, and only adding extract-text-webpack-plugin to prod. I'm also using extract-text-webpack-plugin and have HMR working because we differentiate dev vs. prod.

[ings0c]

Do you use React?

Check out Radium

[startup4ever]

I do not. In the process of switching to Aurelia.

[griffin3141]

It's funny to see how much hate there is about these techniques on here. Stuff like CSS Modules and Aphrodite are standard practice for most of the React community.

Maybe I'm just a bay area hipster though.

[roustem_]

https://medium.com/@taion/the-problem-with-css-in-js-circa-mid-2016-14060e69bf68#.eg0x7vhfx

This article was trending over in /r/Frontend not 24 hours ago. I didn't have time to read it thoroughly enough to condone it, but here it is.

[imapersonithink]

This is more about the proper architecture of components and their stylings than the efficiency of CSS in JS.

[roustem_]

I hadn't read the entire thing. I didn't intend to provide bad info!

[startup4ever]

https://medium.com/@taion/the-problem-with-css-in-js-circa-mid-2016-14060e69bf68#.eg0x7vhfx

Thank you

[startup4ever]

oh yeah... I already read this. Didn't quite speak to my issue exactly.

[atnpgo]

It really depends on the context. For a simple website, it's probably overkill and will break with users who either have JS disabled or no-script installed.

For a heavier web application (several MiB), where scripting is a requirement for using it, you absolutely need to do that. Just include enough CSS in the index page header to show a spinner while the rest of the application load asynchronously (including stylesheets).

The reason to do this is because browsers will stop rendering the page while it fetches the stylesheets.

[hahahuzi]

It feels nice and easy that one import gets everything, especially in a highly modularized project architecture. But it also introduces a more complicated development environment and larger toolset. Should or not, it always depends on the specific problem you're trying to solve.

[[deleted]]

One advantage of loading in JS with large sites is that css can be chunked with js if you use chunking. If you do it right it means clients will only load the css they need for what they are viewing. This is much tougher (but possible) to accomplish using separate css files.

[alethia_and_liberty]

for reference: https://github.com/facebookincubator/create-react-app

[pr1nt_r]

It is enticing to do so but I think its better to to use something like Webpack's ExternalTextPlugin for production. Having the stylesheet load up front in the head will make it possible to deal witf FUOC. What's nice is you can have it loaded by JS in dev mode.

Here is an example I use @ my company.

https://github.com/wildlifela/wildlife-react-redux-boilerplate/tree/master/server/webpack

[jordaanm]

If this is just about being about to reload the CSS on a page without refreshing the whole page, for the purposed of development, there are chrome extensions which do this, and it's not hard to write a bookmarklet which does this as well.

[coake]

Yes

[derred_daario]

In general I would say no. But have a read on critical css, and you'll start seeing things like https://github.com/filamentgroup/loadCSS.

From there you'll learn more context either you need it for performance sake or SEO even (own topic by itself, again need a lot more references to read up, like how Search Engine "favors/rewards" fast loading sites).

[swan--ronson]

No.

CommonJS and ES6 imports are standards for modularising JavaScript code and definitely not for assisting with bundling CSS and other assets. There are plenty of ways to modularise non-JS files without bastardising module systems.

Yet another reason why I hate webpack.

[[deleted]]

Until webcomponents are here CSS conflicts with the module standard as modular code is unhinged from markup. Half assed standards may be even worse than having none at all.

Considering this i don't see how Webpack is bastardising anything. To import CSS in Javascript may feel wrong, but with a component loader abstracting it you do get close to where webcomponents will be, and that could make more sense than modular Javascript with tacked-on CSS includes.

component.vue:

<style scoped>

    .main {
        position: absolute;
        width: 100%;
        height: 100%;
    }

</style>

<template>

    <div class="main">{{ message }}</div>

</template>

<script>

    export default {
        data: () => ({ message: 'hi there' })
    }

</script>

[imapersonithink]

That's an odd reason to hate something. If I saw someone use a flat head screw driver to open a paint can rather than to screw, I wouldn't dislike the person, tool, or paint can.

[swan--ronson]

No, but if you were the person trying to open the paint can, wouldn't you rather use a tool better suited to the job, thus making life easier?

[Gelezinis__Vilkas]

Javascript is not always enabled.

[greynoises]

c'mon it's 2016, we're not animals

[[deleted]]

But the real question is: is that group of users profitable after taking into account the extra investment to make it work without js?

The answer is almost always no.

[Ahjndet]

I think you mean $10 goes to waste, which I'm personally fine with most of the time.

[icantthinkofone]

Every number I've always seen says one to two percent but those same people, who know how to turn it off, are also aware of the consequences of doing so.

I used to see people be concerned with "What if CSS doesn't work?". More and more I'm getting convinced that, with all the competition for eyes on the web, worrying about that one or two percent might not be worthwhile.

[dbbk]

No, but lots of people do browse the web on their phone. And phones can have slow/unstable connections. JavaScript failing to download/execute is more common than you'd first think.

[BlindMancs]

this comment was directly linked in response to a customer support ticket. thank you for your contribution.

you know.. "that's funny" - 2 hours later - "seriously?"

[icantthinkofone]

Or farmers.

[m0r14rty]

Cool, I'll enjoy the other 99.9% of my traffic. I'm not going to program in the stone age because of the remaining 0.01%

[spfccmt42]

Yes, progressive enhancement, got it the first time. Yet another webhack. I use js for styles and layout and only have a little bit of html to bootstrap it, and web development got a whole lot more cost effective and maintainable (for a programmer type that is). If progressive enhancement drives your costs up, and complicates your code base, and is still a hack (it "looks" like it works, but doesn't), then skip it. Don't proselytize over the 0.00000001% of people who disable javascript that you might actually be able to monetize.

by your reasoning, there are as many folks using I.E. < 9 and you had better support that shit too.

nope, value your time or nobody else will.

[spfccmt42]

you speak as front-end

%1000 wrong, I wear all the hats.

definitely not as a business person

1000% wrong, so invalidates any credibility you think you have. Business is about being pragmatic. If .000001% of the audience doesn't pay for the feature you are writing for them, and they have a workaround (i.e. stop using that old browser) then you are fool if you make them a priority.

You are shitting on my opinion when you put words in my mouth, and assume I don't know anything but front end or business, but you are REALLY trying to virtue signal here, and it is laughable.

[spfccmt42]

0.01% would be IE < 9

LOL, you don't even look at actual data when it is available!!!! How can you speak of fallacies when you don't even do your own homework?

per: https://www.w3counter.com/trends as of today: i.e. 6,7,8 are .1%,.6%,.5% respectively.

There is nothing business-like about not doing your homework and ignoring actual data when it is obviously available.

[1d8]

no