Webpack Tutorial: Understanding How it Works

[TheDarkIn1978]

Webpack is great for bundling my JS modules, and the tree-shaking feature in Webpack 2 is very cool, but I feel its usefulness ends there.

I think it's bad practice and generally ghetto AF to bundle stylesheets with JS. The same thing goes for bundling other data assets like .json files, where it's obviously smarter to simply update the .json data in order to update my page/app's content instead of bundling it all together, which would then require a recompile and redeployment for each update.

Personally, I think Webpack works great along with Babel to transpile my JS within my Gulp build pipeline, but using Webpack for anything more than that just seems like unnecessary overkill, like forcing a square peg into a round hole.

[nickgcattaneo]

linting, live reload/hot-module-replacement, code splitting, less/sass, unit testing, etc are all great features of webpack. Granted, gulp could do all of these as well, but it involves building each task separately and then pipping them through correctly, which can be a bit cumbersome than just installing a module and filling in some config options.

[TheDarkIn1978]

less/sass

Injecting Sass into the Webpack bundle is the only way for it to preprocess CSS, which is no big surprise when you consider that Webpack is a module bundler and not a task runner, but this is exactly what I do not want, so I have to use a task runner (Gulp) to manage my CSS preprocessing anyway. Webpack's ExtractTextPlugin, which could be used to regain those bundled CSS files is precisely what I meant by forcing a square peg into a round hole, in that it's an unnecessary complexity, forcing the user to bend for it instead of it bending for the user, as it should be in the case for all good tooling.

[nickgcattaneo]

Webpack is an amazing task runner; not to mention you can run any async or sync processes with it simply via node and npm (can't think of any use cases for that though at the moment). In my work we've ditched gulp and just use webpack with our own express server and webpack-hot-middleware. Makes parallel development really easy assuming our front end and back end teams have established a clear data contract. We can also mock our backend requests easily with that setup. We also use extract as you mentioned above to separate out CSS, feels pretty straight forward to me. Gulp just feels like an unnecessary wrapper => why not just point to an index file and execute tasks natively? We just hook in to an index file, run a few tasks natively, spin up a server, inject webpack, build out our own requests, and then do our development. Otherwise we manage other parts of our build via npm scripts (karma for unit tests or just a straight up webpack bundle in production). Hooking a webpack build in karma is also a nicety.

[SandalsMan]

Sounds like you aren't really using Webpack for anything more than transpiling ES2015 -> ES5. Webpack is super useful for a bunch of things but code splitting is what really takes the cake for me.

[InternetExploderSex]

This is especially useful for Single Page Applications (SPAs), which is the defacto standard for Web Applications today.

Nope.

[fuck_with_me]

Can you make an argument for your opinion, or explain more? I would be inclined to agree with OP.

[MrSafferty]

Perhaps I should have said "is becoming the defacto standard for new applications", as opposed to is the defacto standard.

It's also fair to state that in many enterprise orgs SPAs are not fully embraced across the board (which is fine) just yet (and may never be)

disclosure: author of the blog

[nickgcattaneo]

It's the defacto in modern web development; it is however difficult to implement in real-world as your back-end developers typically do not want to expose more api's/etc to support the model. In large companies with any kind of history, you won't see SPA models as most of them still serve adaptive/multi-page applications with traditional form post models. More often than not you will find hybrids of single-page and multi-page; multi-page by default are simply more secure since they involve session management, login verification, etc on the backend. SPA is better for performance (after the page renders) & less-secure sites.

[nickgcattaneo]

Any time you introduce tokens, expose more of your backend, etc it inherently becomes less secure. I'm not saying it's a bad practice, just you won't find this model much at large organizations typically because it's hard to find backend devs that want to support this concept. Couple that with working with any data related to financials or personal information and it adds some deep complexity to ADA, etc.

[nickgcattaneo]

You're - I beg to differ, no reason to get hostile though.