Webpack

Webpack is a powerful module bundler. A bundle is a JavaScript file that incorporates assets that belong together and should be served to the client in a response to a single file request. A bundle can include JavaScript, CSS styles, HTML, and almost any other kind of file. Webpack roams over your application source code, looking for import statements, building a dependency graph, and emitting one or more bundles. With plugins and rules, Webpack can preprocess and minify different non-JavaScript files such as TypeScript, SASS, and LESS files. You determine what Webpack does and how it does it with a JavaScript configuration file, webpack.config.js.

Usage within PulseTile

We are using WebPack to create a bundle file from all the src's we do have, to create a single HTML and JS file, that the application uses while built. Example of our webpack.config.js is found within the sources root folder

Q: Why was webpack chosen?

A: Why?:

  • Useful for a modular architecture, because it has the concept of a dependency tree, unlike Grunt/Gulp
  • Performs better than Grunt (the previous choice of build system)
  • Gets rid of the need for RequireJS and tools like Browserify
Q: Why is webpack better than using npm or bower to import Ripple plugins?

A: Webpack is a build tool and its purpose is to transpile the code (like in case with Babel and ES6) and compile bundles for production usage and it does it really well and fast as it has a clear syntax and good documentation

Q: Webpack takes care of a lot of configuration for you, which of course makes things easier, but it means that changing configuration may not be as flexible as desired. Could this present problems if configuration becomes more complex?

A: Related to this point, we discussed whether there are any problems that could be faced from having a complex dependency tree that Webpack may struggle to digest. SliceArt reassured the group that in their experience, they have never gotten to a point where webpack will struggle in this scenario, even with applications that become much more complex.

Q: Are there any performance figures that you’ve recorded that show the difference in loading times using webpack?

A: Webpack performs much faster than Grunt, and is about equal to Gulp, so that is a perfectly reasonable performance gain.

Q: Currently all modules seem to be very standalone, so it looks as though webpack is not being used to its full potential. Is this just part of a step-by-step implementation process, or has it been by design?

A: Related to this point - we discussed how at present Webpack isn't being used in the standard way to send up module bundles to the client, instead of sending the vendor and Ripple bundles in two large files. SliceArt have already noticed this and are planning to send separate, smaller bundles to the client in this way, which will mean less network traffic and higher performance.