webpack: what it is, what it does, whether you need it
TRANSCRIPT
by Mike Wilcox, March 2017
Webpack what it is what it does whether you need it
Webpack Main Features• Module bundler / loader
• AMD, Common JS, ES imports
• Babel & JSX Transformations
• Dev Server • Hot Module Reloading*
• Task Runner • LESS/SCSS, Tree shaking, optimization, code splitting, etc, etc…
• Server Side Rendering
• Large Community*
*Key reasons for using Webpack
Webpack being relatively new allows it to avoid non-standard loading methods such as AMD or Angular’s global injection.
The plugin system, while sometimes confusing, allows Webpack to grow and be maintainable.
Competitors• RequireJS
• Duo
• SystemJS
• Ember
• StealJS
• Browserify + Grunt (or Gulp)
Competitors• RequireJS
• Duo
• SystemJS
• Ember
• StealJS
• Browserify + Grunt (or Gulp)
StealJS is almost on parity with Webpack and definitely worth consideration.
Browserify + Grunt will get you 95% of the functionality of Webpack - Unfortunately, that 5% is Hot Module Loading
Do You Need It?Pros
It does a lot
ConsIt does too much
Spoiler alert: yes, you need it
Webpack 2.0 Features
• Native ES6 import, export and dynamic import()
• Tree Shaking for ES6
• Uses Promise for module loading • Need polyfill in old browsers (if you’re using code splitting)
• Chunk error handling
• Otherwise, 2.0 is a refactor
Just released 2.0 late in 2016:
Module Bundlers• dojo.provide dojo.require
• RequireJS
• CommonJS / Browserify
• SystemJS
• StealJS
• babel-loader: ES import/export
Task Runners• Grunt
• Gulp
• Broccoli
• NPM Scripts
More Features (we will not cover)• Tree shaking
• optimization
• inlining
• code splitting / chunks
• lazy loading / code on demand
• targeted (multi version) builds
• server side rendering
• long term caching
• offline - service workers List of Plugins
PAIN POINTS
Grunt CSSWhat the config looks like in Grunt:
less: { main: { options: { sourceMap: true, }, files: { 'dist/main.css': 'less/main.less' } } }
Webpack CSS
const cssPlugin = new ExtractTextPlugin({ filename: 'main.css', });
module: { rules: [ { test: /\.less$/, use: cssPlugin.extract({ use: ['css-loader?sourceMap', 'less-loader?sourceMap'], fallback: 'style-loader' }) } ] }, devtool: ‘eval-source-map‘
What the config looks like in Webpack:
Moar Pain Points• Does too many things - essentially violates the single responsibility rule
• CSS HMR setup is ridiculously obtuse
• Documentation • A complete lack of examples (what is a code snippet worth?) • Even the how-to's are lacking • 10 ways to do everything.... sometimes all 10 are wrong • Does not allow custom command line arguments • Wants to own the HTML page • Creates horribly obfuscated code
These are largely observational opinions, not facts
Even MOAR Pain Points• Loads files with ES imports... unless those files are dependencies
• Lack of feedback or errors when things go wrong • If something doesn’t work, it is a HARD STOP • Webpack is (near) impossible to debug
• webpack-dev-server is in-memory, which, while great for performance… • Horrible for debugging server issues • bower becomes worthless • The dev server does not have a relative path to... anything. • Polyfills become painful • Simple static assets are painful
Okay, these are more fact-based.
Benefits• Hot Module Reloading
• Hard to do in any transpiled code
• ES Imports • Not exclusive, but not trivial
• Code splitting • Vendor code splitting is easy - all else, not as easy, but very doable
• “Everything” is supported • If it exists in the world of front end development, you can do it with Weback
Webpack Resources• Create React App
• Automates Webpack config. Great for beginners. Uses an old version and lacks a few critical features.
• Survive JS • “The Book” on webpack. Literally the missing documentation.
• HJS Webpack • A config abstraction that is supposed to make setup easier
