Consider using DllPlugin

gaearon commented 8 years ago

http://engineering.invisionapp.com/post/optimizing-webpack/ https://robertknight.github.io/posts/webpack-dll-plugins/

I don’t quite understand how to integrate it, and community help would be most welcome. It would be ideal if we could make both dev and prod builds faster.

The idea is that we’d only use it for react and react-dom.

gaearon commented 8 years ago

@mxstbr Would be great if you could take a look at it. I saw react-boilerplate uses it but I can’t figure out how to add it. 😢

gaearon commented 8 years ago

(No pressure though! I’m sure somebody will help us after open sourcing if you don’t have time. Thanks a lot for your help so far.)

mxstbr commented 8 years ago

Would not recommend, adds a lot of complexity. The sole benefit is that in dev mode, your builds are slightly faster if you have a lot of dependencies. (in our case it knocked off a few seconds of build time)

In production, we simply use the CommonsChunkPlugin, which basically does the same thing automatically, it's just a bit slower since it has to figure it out, whereas with the DLL plugin we tell webpack what our vendor deps are.

gaearon commented 8 years ago

Oh, okay, not a big deal then.

ro-savage commented 8 years ago

@mxstbr @gaearon I thought the big benefit of DLL was rebuild times. Having a faster hot-reload/rebuild when you make a change is very useful.

I did some quick and rough testing on react-boilerplate taking the commits before and after DLL was added.

Both tested in same order doing and in two different folders, right after one another. Start -> Start -> Change Footer -> Change Footer -> Change Footer -> Change Button -> Change A

Commit	First build	second build	Rebuild 1	Rebuild 2	Rebuild 3	File 2	File 3
PreDLL	8584ms	7740ms	1672ms	745ms	551ms	802ms	742ms
PostDLL	5566ms	6488ms	266ms	156ms	230ms	328ms	362ms

I feel those rebuild times are pretty significant. Its a difference between feeling instant and 'waiting' for the reload. Larger project should have even more benefit.

As this project is, in part about a great dev experience, it would make sense to me that that fast rebuilds is worth adding if it can be done in a not-so-complicated manner (would be a great example for others to follow as well)

gaearon commented 8 years ago

If you can submit a PR significantly improving rebuild times in any way I will be happy to get it in.

ro-savage commented 8 years ago

@gaearon I implemented this in my own (large) project and in create-react-app.

On my own project it took our rebuild times from ~4000ms to ~1000ms.

However in the CRA which basically just has React in the DLL the difference is alot smaller.

Stats

Commit	First build	second build	Rebuild 1	Rebuild 2	Rebuild 3	File 2	File 2 RB
PreDLL	4335ms	4413ms	666ms	322ms	598ms	563ms	353ms
PostDLL	2611ms	2752ms	220ms	183ms	144ms	193ms	313ms

Added complexity

Creating DLL package list The list of node modules to for the DLL can either be automatically generated from the package.json (ala react-boilerplate) or manually added to an array. Automatically going through the package.json makes it easier but I found some packages (react-toolbox) can break the dll build (due to importing of sass files). Manually the user knows what is going in the DLL but has to remember to add files to the array when they add new node_modules (but they know what packages make up the dll). Any missed files just go into the regular bundle.

Weird webpack stuff DLL's aren't used by many project. When you eject and see it, it might be confusing (although my implementation is much simpler than react-boilerplate). It also needs to be run on any update to the node_modules (I believe it can be ran as postinstall)

Reliability React-boilerplate is the only large project I know of using DLLs. It should be getting a lot of user testing now, but as of this moment its largely untested in real world apps.

Worth adding?

I don't have much of an answer if it's worth adding. The 'feeling' between the two rather minimal as is. However if CRA is used for something containin 10+ node_modules, the difference might be much larger.

Large CRA example

Example with larger CRA (imports: redux, react-redux, lodash, react-bootstrap, immutable, redux-saga, reselect, babel-polyfill, react-router. No other changes)

Commit	First build	second build	Rebuild 1	Rebuild 2	Rebuild 3	File 2	File 2 RB
PreDLL	6801ms	7536ms	1489ms	1192ms	816ms	1248ms	1226ms
PostDLL	2965ms	2202ms	633ms	145ms	222ms	230ms	241ms

SimenB commented 8 years ago

IMO it'd be nice to have, even though the gains on the minimal examples are small. It's such a pain to set up if you're unfamiliar with it, so having something working out of the box is really nice.

geowarin commented 8 years ago

Shameless plug, you can look how tarec uses DLLS:

There is a command (tarec dll) that will put all the dependencies in the package.json of the application in the dll. See the webpack config. Dlls will be generated in a .tarec folder, where we can find them
When the application starts, we look for dlls and include them in the page. @SimenB's add-asset-html-webpack-plugin does a nice job for that

So it's not perfect yet:

We assume that all dependencies will be included in the application. I think this is a fair assumption though
Users are responsible for regenerating the dlls when their dependencies change. This step can be automated. We could generate a hash of the dependencies and regenerate the Dlls automatically for example
This is not activated for production builds as I feel performance improvements will mostly be beneficial for hot reload and startup times

But I concur with @ro-savage, in my experience it yields very impressive improvements even on medium size apps with a dozen dependencies. It also improves the debugging experiences on lower-end machines in chrome because the source maps of the actual application become smaller.

ericclemmons commented 8 years ago

I implemented it pretty quickly in a work project with similar performance gains as @ro-savage:

View the diff...

``` diff diff --git a/package.json b/package.json index f8fab95..75541b4 100644 --- a/package.json +++ b/package.json @@ -17,6 +17,7 @@ "prebuild": "rimraf build", "build": "per-env", "build:development": "webpack --watch --config webpack.config.server.js", + "build:dll": "webpack --config webpack.config.dll.js", "build:staging": "webpack", "build:production": "webpack", "deploy": "per-env", @@ -31,6 +32,7 @@ "start:development": "npm run build:development", "start:production": "start-cluster build/server.js", "start:staging": "start-cluster build/server.js", + "postinstall": "npm run build:dll", "pretest": "rimraf build && npm run lint", "test": "per-env", "test:development": "mocha --bail --watch src/**/*.test.js", diff --git a/src/middleware/view.js b/src/middleware/view.js index 8021bfb..e624bfa 100644 --- a/src/middleware/view.js +++ b/src/middleware/view.js @@ -46,6 +46,7 @@ export default router() + Githubissues.

Githubissues is a development platform for aggregating issues.

facebook / create-react-app