Why use "new ExtractTextPlugin()" twice and how it works?

[shakaIsReal]

1. I am confused why you choose to use new ExtractTextPlugin('styles/main.css', { allChunks: true })
both on server and client in webpack.config.prod.js. Wouldn't styles/main.css be overwritten by the last execution (2nd one)? As I understand we only need one styles/main.css in our public folder. Why have two? Or do

new webpack.optimize.OccurenceOrderPlugin(),
new ExtractTextPlugin('styles/main.css', { allChunks: true }) 

do something magical together?

2. Can you also explain how ExtractTextPlugin works? Does it only get the style(s) from the entry file or it takes all styles from other components and bundles `em together?

3. Does postCSS/postcss-loader compile sass, so I dont need to use sass-loader?

Thanks :)

[psimyn]

1. I don't think it's needed in both, it'd be in plugins because it's included in common loaders. Can probably be removed if you'd like to make a PR.
2. allChunks: true means it gets styles from all components and bundles them. If you look in the output JS files, there are empty modules with a comment saying "extracted by extract-text-plugin" (or similar).
3. No, postcss-loader does PostCSS => CSS. PostCSS can be used instead of SASS if you want, but if using SASS you still need sass-loader to convert to regular CSS.

[shakaIsReal]

@psimyn Thanks dude. 2 more questions :)

1. ExtractTextPlugin() doesn't get style(s) from components imported with require.ensure(), since they're "separate chunks", therefore they will be loaded on demand through javascript instead. Is that correct?

2 Does allChunks: true options over-rides the behaviour described in 1?

[psimyn]

in this case it will put everything in styles/main.css (the hardcoded path in the config). If you want it to output separate CSS file per-chunk you can use this in webpack config:

  new ExtractTextPlugin('[name].css'), // add [chunkhash] if you want cache-busting

You then need to add the CSS for each chunk on the pages they are needed. this should all be independent of allChunks' value

[alex-shamshurin]

Why not simple inline css styles relative only to current page into the page header? isomorphic-style-loader do it and update styles on page routing.

[shakaIsReal]

@psimyn thanks :)

[ZeroCho]

@alex-shamshurin
I think it should not be inlined because incline css styles cannot be cached. Caching doesn't matter when the app is small, but we should also consider the case when the app grows and gets bigger.
Just my opinion. :)

[alex-shamshurin]

there is no reasons to cache, styles are included into the bundle, so everything already there. But initial loading is faster.

[psimyn]

@alex-shamshurin extract text plugin extracts imported CSS out of the bundle (so it's no longer included).

The potential speedups are:
Smaller js download
CSS is cached
Not parsing giant strings of css to inject into DOM

Including css for entire application in 1 file is not ideal, but you can start module splitting and load on demand

[psimyn]

@shakaIsReal happy for this to be closed?

[alex-shamshurin]

@psimyn No reasons to use extracted-text-plugin, I guess so.

Browser stops rendering when it gets instructions to download css file. Until it finished everything is stopped. When styles are inlined - browser engine have not to wait. Included styles in this case are "critical only" - only for components which are on this page and minified and compressed within a html page.
All other styles are in the bundle and js file can be download async, page loading do not wait for that. After initial loading components replace styles in the head.

[psimyn]

@alex-shamshurin critical CSS as the only blocking script tag is definitely a good option. I think it's possible to extract critical CSS as a separate bundle, and then load other CSS as async.

My main motivation for having CSS completely separate is to keep JS bundle size down - keeping render-blocking CSS out of is good, but not if you are then waiting on 1mb of js/styles before anything is interactive.

Will look some more into critical styles, not yet sure of a way to include in the build.

Example detector/generator:
https://github.com/addyosmani/critical