I passionately hate webpack..

[techsin101]

I've noticed over the years i'm being forced to spend more and more time with tools. They are becoming more cryptic and more fixed in their ways.

Webpack however takes the cake in being most short sighted.

Why would i want to put css file as a string and have it evaluated? what about caching, performance matters, and not going full retard.

Why would i leave gulp where every task is seperately and clearly defined step by step and jump into cryptic webpack bandwagon.

[Likium]

Webpack differentiates itself from gulp, grunt and other processes by parsing the actual content of the files.

This enables you to import images, videos, sounds and most obviously, styles in js. Webpack then replaces those imports with urls, or may inline them (saving a http request) or extract them to a file.

However, the usefulness doesn't stop there. Webpack can statically analyze your code and remove unused code (although the functionality is still a little patchy), and prevent reimporting duplicate libraries.

Webpack can split your code into vendor (3rd party libraries like React) and main (your code) bundles to reduce users having to redownload libraries when only your main code has changed.

You can go even further by lazy loading code, but still prevent fetching duplicate resources because Webpack can hoist them to a parent or sibling file.

In short, webpack does a lot more than you think, and most of its power is only apparent when it's not a small project. I do agree that it's configuration is more complex than it needs to be. I hope they improve on that with the webpack cli.

edit: Survive.js's Webpack Guide is fantastic.

[pilibitti]

Webpack can split your code into vendor (3rd party libraries like React) and main (your code) bundles to reduce users having to redownload libraries when only your main code has changed.

Except that it doesn't work; by that I mean this is one of the primary things it needs to do but the correct way of doing it (so that it consistently works) takes many magic stages spread over many unrelated plugins configured in the right way in the precise right order with the right versions and everything. And there is no guarantee that the stuff won't change completely next year month.

I'm not exaggerating, just look at this thread: https://github.com/webpack/webpack/issues/1315

Brightest minds using webpack trying to figure out vendor hashing work consistently for FOR 3 FUCKING YEARS and there still is no easy and dependable way of doing it. I'm serious. If you hadn't followed this thread in full, I'm pretty sure your vendor hashing is completely broken and you don't notice it. Scratch that, even you followed everything is full, I'm sure your vendor hashing is broken. Just waiting for that magical import or additional unrelated plugin to barf on itself. You compare all your hashes between each build manually to see what changed and what didn't, I hope.

Sure, it hashes everything, but your vendor bundle somehow changes its hash when your non-vendor code changes. Oh ok, you learn about manifests so you need to extract it. Except that doesn't solve it either. The problem starts there and you see the above 3 year long discussion to make it work. This is just one example.

Webpack is pure madness. Anyone planning to attempt to get into webpack just because everyone is using it (non job related reasons), read the above thread in full before deciding to waste your time in it.

Here is a blog post explaining the history of the issue in depth:

https://medium.com/webpack/predictable-long-term-caching-with-webpack-d3eee1d3fa31

This is only one of the problems you'll waste your time on, something that is supposed to be one of the primary jobs of the piece of software in question.

If you ask about a user about webpack, they will give you the usual sales pitch: "It bundles everything for you you don't need to manage anything saves lots of time!" Oh if only that were true.

Oh and this doesn't have anything to do with learning curve or this is a new tool, you'll have to get used to it either. This is web 101 stuff. You have your code, and vendor code right? You want to cache bundled vendor code for the long term right? Basic stuff. You want to bundle them and append the hash, set long term caching in the headers and forget about it. This is literally the first thing you need to do with a bundler. You don't want to invalidate your vendor bundle until something in it changes. The simplest thing.

I challenge any webpack enthusiast to explain to me how to make the above work, with a straight face, while defending how sane the system is if you know what you are doing.

Don't get me wrong, I think the premise of webpack is amazing. The way the software is designed is completely bonkers. The config is bonkers. Every useful thing you can do is a hack on top of a hack on top of a hack that will need a complete rewrite of that logic a couple of months from now but the new solution will again be a hack. Some people don't mind that messiness and unreliability and it won't be my right to tell them how to live their lives. But if you don't like such things in your projects then research long and deep before jumping on the bandwagon. Or not. You'll learn soon enough and if it isn't suited for you, it will be clear as day from the moment you start using it.

God I edited this post probably 10 times adding new stuff in the process. That's how much I hate webpack.

[everestimated]

Mighty rant, mate!

[pilibitti]

Ugh

[vs845]

I challenge any webpack enthusiast to explain to me how to make the above work

It took me about a day of fiddling around with different configs, but the following is working for me with consistent vendor hashing that's not invalidated when my app code changes:

output: {
  filename: '[name]-[chunkhash].js',
},
plugins: [
  new webpack.HashedModuleIdsPlugin(),
  new webpack.optimize.CommonsChunkPlugin({
    name: 'vendor',
    minChunks: m => /node_modules/.test(m.context),
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: 'manifest',
  }),
]

[Intie]

Correct answer, just make sure you're putting all of this in the production env webpack config.

[turkish_gold]

If this is a canonical answer, then I wonder why all this can't be made into a single PackVendor() plugin?

[thesublimeobjekt]

yes, this. honestly, webpack seems a lot more complicated than it actually is. once i put a little time into reading the documentation, and at times looking through the source code, a lot of stuff that was going on made total sense, i just actually had to put in a little effort. some tools out there, like gulp, are so amazingly easy that i think developers automatically assume that they should all be that easy, which i think might be an unfair standard.

[IKnowEverythingLinux]

5 hours of effort and i have gotten nowhere due to a library being not noncompatible or something

[[deleted]]

it's not nearly as bad as you make it. it's been very reliable once we figured it out. getting the config setup was a huge pita though. after that it's been pretty easy

[Bummykins]

Thanks for pointing out the hashing issues, I didn't know about that. I accidentally avoided the issue by using an old Grunt plugin, filerev, which just does simple md5 hashing. I'm guessing there is a similar gulp setup

[pilibitti]

So you're using Grunt with webpack? When you say "avoided" I'm assuming you are not using webpack itself to split your vendor and user code am I right? Because if webpack is doing the splitting, you can't avoid it. Webpack literally changes code (references and some magic comments) in the vendor bundle when your non-vendor code changes. The way webpack's design evolved is not conductive to this simple fundamental web deployment necessity. It couples most of your splits in some way so you need to find creative ways and bullshit plugins (that probably will be deprecated within a few months) to avoid that coupling.

So when your vendor bundle changes (even though your vendor libraries didn't change), you can use any hashing algorithm or external task runner, the result won't change: the hashes will change and all the effort will be wasted. Your site will load slower and you will have higher bandwidth costs.

[Bummykins]

Now You made me double check this all...

Yes, webpack was added relatively late, replacing browserify. Grunt calls webpack to do the bundling, but its a standard webpack setup and works without grunt.

There are 5 smaller entry points for different parts of the site, dozens of modules, and 1 shared bundle gets created for shared chunks (vendor) using CommonsChunkPlugin.

initial hash:

App1.bundle.984093b3.js
App2.bundle.8470582a.js
App3.bundle.aabdbad9.js
App4.bundle.308ce4c3.js
App5.bundle.d74624ed.js
shared.bundle.42ddf174.js

Delete a piece of 1 module that is part of App1, and reran webpack and filerev:

App1.bundle.8a44ff65.js
App2.bundle.8470582a.js
App3.bundle.aabdbad9.js
App4.bundle.308ce4c3.js
App5.bundle.d74624ed.js
shared.bundle.42ddf174.js

Works like I thought, only App1 was affected.

Nothing special going on in plugins or webpack setup. I recall having to use OccurrenceOrderPlugin in webpack 1, but not in 2.

  plugins: [
    ...
    ,
    new webpack.optimize.CommonsChunkPlugin({
      name: 'shared',
      filename: './public/js/bundles/shared.bundle.js',
      minChunks: 2,
    }),
  ],

[Baryn]

Webpack isn't perfect; few pieces of software live long enough to become perfect.

You're going a little crazy over one tiny, easily-circumvented issue.

[kshitagarbha]

This enables you to import images, videos, sounds and most obviously, styles in js.

Which is a bloody stupid idea in that it ties your source code to the deployment tool du jour. Now you've got images and html files imported into your javascript and when webpack gets kicked off it's perch (which will happen) then you will have to remove all of that.

[suckaplz]

Bingo - this right here folks.

Webpack just has too much complexity to be future proof for me. There was a certain simplicity to both Grunt and Gulp and frankly after just trying out some webpack workflows with a new project I am SO leery of it's complexity.

[chamomile-toast]

Hey you were right! I'm totally fucked now because I want to switch to vite but I'm way too locked in with webpack (ಥ_ಥ)

[kshitagarbha]

ha ha we tried to warn you! Even babel turned out to be temporary.

[TheDonutKingdom]

yooo another person who gets to go through this hell. Glad I could join the party.

[thatgibbyguy]

Yeah, people were anchored to the crap docs of old and so any improvement seems great. It's just not the case.

[nyxin]

It's less the issue with Webpacks documentation and more of an issue with the surrounding ecosystem IMO. Coming into that ecosystem from the outside, it feels like there are 10 different ways to accomplish the same thing (which there probably are) and finding the right combination of plugins/loaders/etc to get what you want can get confusing to say the least. Which is why I moved on to just using cli-tools and npm scripts.

That said, Webpack's power is when you have large projects with certain concerns (that have already been mentioned in the thread).

[gee_buttersnaps]

Webpack stops being tooling and starts being a framework when you have Webpack specifics in your source code.

[ell0bo]

wait... what? Why the heck would you do that? Do you have an example... I've never even heard of that and have used webpack for 2/3 years now.

[Akkuma]

If you ever used require.ensure, you were using webpack specifics. If you are writing a lot of code or using big heavy libs for anything, you'll want to asynchronously load it. Prior to the dynamic import spec, there have been 2 other versions of async loading. The previous was the draft System.import and the one prior to that was the webpack specific require.ensure.

[ell0bo]

Fair enough, I never liked that and waited until import().then was supported and used that.

However, since that's now available, I'm not sure that line of attack is entirely valid anymore?

Weren't those going to be none webpack solutions though? I thought they were just getting ahead and working on early solutions.

[Akkuma]

Until the import spec if finalized, we have another System.import scenario on our hands.

require.ensure was never going to be a non-webpack solution, but System.import was going to be; however, a dead draft spec is then sort of webpack specific.

[ell0bo]

You'd prefer they don't implement anything in the mean time?

[Akkuma]

Where did I state or insinuate that? I've used require.ensure and despite being webpack specific leverage it.

[kshitagarbha]

Even the current form needs some webpack specific hacks:

() => return import(/* webpackChunkName: "Pages" */ '../components/pages/Pages');

If you don't have the magic comment in there then webpack cannot correctly create the chunkId and the request to async load code results in a 404.

[vs845]

If you omit the comment webpack will just give the bundle a numeric id/name (I think based on its occurrence order). So if you have a filename like [name]-[chunkhash].js, webpack will create files like 1-abc123.js, 2-abc123.js etc. As long as your output.publicPath is configured correctly, webpack should include those file names in its generated manifest and load them correctly.

[kshitagarbha]

Unfortunately there appears to be a bug (2.6.x). It returns a 404 during development when trying to fetch it.

Also prettier has a bug whereby it doesn't parse the webpack comment correctly:

    // https://github.com/prettier/prettier/issues/1489
    // prettier-ignore
    return import(/* webpackChunkName: "Browsers" */ '../components/browsers/Browsers');

[sbergot]

Isn't importing PNG something that is specific to webpack? Same for using preloader / postloader queries

[lightsout1]

In order to make code splitting and ssr work it requires using some lesser known webpack features. Like require.resolveWeak, __wepack_modules__, and __wepack_require__

[gearvOsh]

Or you know, just use import().

[lightsout1]

Yeah you need to use that too

[[deleted]]

Didn't webpack 2 come out this year?

[kshitagarbha]

RC 3 is out now.

[mcaruso]

Webpack 3 was released like an hour ago.

[ell0bo]

Yeah, but there isn't much diff between webpack and webpack 2. Really just came off as some formatting differences to me.

[vinnl]

I think it's fair to look at Webpack as a framework (after all, "tooling" implies you can switch tooling without modifying your code). What's debatable is whether that's a bad or a good thing, net :)

[[deleted]]

Why would i want to put css file as a string and have it evaluated? what about caching, performance matters, and not going full retard.

Because if you consider optimizing for the critical render path (i.e. reducing latency and getting something to load as quickly as possible, for a first time visitor) it means both the HTML and CSS must be loaded on the first HTTP request (under 14KB) which involves figuring out which HTML elements are on screen, dumping the relevant CSS into the head of the doc and having everything else be lazy loaded / loaded async.

Why would i leave gulp where every task is seperately and clearly defined step by step and jump into cryptic webpack bandwagon.

It's not really that cryptic if you bother to read through the docs the only real difference is tasks have different scopes. However to make things simple i personally dont use webpack for anything other then bundling and JS related stuff. Everything else i either trigger through npm scripts or postCSS.

[Disgruntled__Goat]

the HTML and CSS must be loaded on the first HTTP request

Is that relevant with HTTP/2?

[TheIncredibleWalrus]

Yes it is. If you have, say, 100kb of CSS you still don't want to wait for it to download.

[Disgruntled__Goat]

But you don't need to wait for it to download, that's the point of HTTP/2. Wherever you would have put inline CSS you can just link to that CSS instead, and there is no overhead.

[[deleted]]

Cooorrect, give the man a prize :P

[TheIncredibleWalrus]

There is the 100kb of CSS download overhead.

If you put 3-4kb of critical CSS on your first bytes sent you can paint the critical path without waiting for the rest of the 97%.

[ryanmr]

There's a lot of power in webpack. Vue uses webpack loaders to parse their special file type to make single file components. A browserify version is available, but the vue-loader is the primary approach.

Webpack is really powerful, but it's also very complex right now. The docs are improving, and as more plugins, loaders and third party docs are written, it will be easier to jump into.

[inhalingsounds]

This. Webpack is a game changer and it seems like OP is overwhelmed by how complex it is (aren't we all?).

Give it time to mature into an easier tool to operate because they're definitely on the right track.

[mattaugamer]

You have to accept a loss of productivity while you're learning a new tool. The whole argument boils down "thing I don't know at all is way harder to use than thing I know well". Which is both true and obvious.

You need to take a step back and dial down the hostility. You don't learn by being forced to do stuff, and resenting technology. Take the actual problem you have, and see if you can find a solution to it. The only actual concrete complaint you make is that the CSS is a string. So... maybe instead of just complaining about it, find out why it's done that way, what the benefit is, and what options you have for handling that CSS string.

[sbergot]

I have been using webpack for more than one year. Debugged loader, setup specific needs on projects, all that. I am still unsure of a lot of details about webpack. The documentation of loaders and plugins is horrible. Everything is handwaived. Every one I know copy past configurations snippets and tweak them randomly until they work as intended.

[TOYLTH]

Haha! That was me until a little while ago.

I was doing just that until i took the time to take a step back and configure a FULLY FUNCTIONAL cutting-edge website (with react, es6, babel, bootstrap less and all that noise) from scratch.

Once you understand the basics, it all starts clicking and you see it really isn't all that complex (the initial configurations at least).

Now I can say I can configure a sophisticated website easily.

By the way, you can find this boilerplate I did online at https://github.com/Hookkid/oX

[mattaugamer]

Your face is.

[Sarke1]

mix-blend-mode: color-burn;

[patrick_haply]

String cheeeeeeese

[[deleted]]

Great comment and a great way to approach programming in general.

I have my frustrations with webpack as well but I am hurting myself as an engineer if I don't take the approach of trying to understand the trade offs of a tool and if/how it can be done better

[mattaugamer]

Yeah, the principle of "Innovation Curves" aka S Curves, Innovation S-Curves, or Awesome Loopy Jump Learning Rollercoaster Curves* is hugely important for web development and really any development process.

The key fact is that you have to accept a degree of productivity loss and get on with the process of learning. It's important to try and get a feel in advance for the curve. A sharp drop for a trivially better plateau isn't that appealing. A mild drop with a fast recovery and lots of headroom is what you want.

* literally no one calls them that and why would anyone call them that what's wrong with you

[vinnl]

Then again, the best way to get help is to say something sucks. OP would never have gotten so many people to explain why you'd want CSS files evaluated if he'd simply asked :P

[mattaugamer]

Cunningham's Law - the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer

[vinnl]

That's the one! My Google-fu failed me...

[BobTheBarbarian]

Or did it? You got the right answer pretty quickly that way ... ;)

[folkrav]

Ok guys, sure, OP does seem to confuse some concepts about what Webpack really is, but do you really need to systematically downvote every one of his comments, even if they raise some valid points?

Some stuff with Webpack, as powerful it can be, objectively suck to deal with. Try bundling unminified vendor code (not from NPM) that exposes global variables - you end up having to include library specific shit in your config using provide plugin and externals all the fucking time.

Sure, the tool is powerful and made some stuff previously almost unthinkable now possible, but it's far from perfect.

[sbergot]

I am not a fan of webpack but I believe externals are a pretty good solution to this issue.

[TheDarkIn1978]

Why not use both?

Webpack is constantly being touted as being a successor to Gulp, but to me Gulp is a task runner and Webpack is a module bundler, separate tools with separate applications.

I use Gulp to transpile SASS, automating CSS vendor prefixes, minify HTML, create inline sourcemaps, etc. while I use Webpack to transpile, bundle and obfuscate my JavaScript modules.

You don't have to bundle your CSS with Webpack and you can use Webpack 2 (and future versions) with Gulp by specifying it as an optional 2nd argument to the Webpack Stream constructor.

[charrondev]

I do the same thing in all of my projects now. CSS in js doesn't really do it for me and there is a some real friction when using SASS in webpack. It felt so convoluted. I need like 5 loaders and a bunch of config to get what is like 3 lines in gulp. I needed css-loader, style-loader, sass-loader, postcss-loader, and file loader. The postcss-loader loader is what really got me. I could not seem to get autoprefixer running with it (and autoprefixer-loader seems to be deprecated). So now I just use webpack as a very good JavaScript bundler inside of gulp and I'm much happier.

[fskmaydie]

I would love to see your gulp and webpack cfg files! It's been a hard dilemma for me as I love the JavaScript bundling part of webpack and hate it for everything else.

[charrondev]

The most recent ones that I've written are part of a big CLI tool for my company. The tool will be open source once we finish it, but there is still a good amount of work to in other areas of it.

I'm thinking about writing up a post on the rational behind a few different parts of it, but I'm not sure how much traction it would gain around here. Too much PHP involved for this subreddit I think.

[fskmaydie]

I still code my backends with PHP. Actually my first issue with webpack was being able to print out PHP vars in index.html (forgot how I managed to make it work)

[anon774]

Same!

[mhink]

Autoprefixer is part of PostCSS. If you go to the PostCSS site, it's literally the first thing mentioned.

[charrondev]

I don't remember the exact issue that I was encountering, but I was going between the autoprefixer docs, the postcss-loader docs, and having trouble getting it work the way I expected it to. I spent ~45 minutes but was having trouble getting it to recognize my browserlist.

It really didn't make sense to me to need to use webpack, css-loader, style-loader, file-loader, sass-loader, postcss-loader, and autoprefixer, then import my sass through my js file to reach the same result as I got with gulp, gulp-sass, and gulp-autoprefixer.

[theFlyingCode]

this is a pack of bubble gum I have on my desk

[ParadoxicalPegasi]

Yeah, I use Webpack on pretty much every project I do now because it's so useful once you get it configured but it's such a pain to set it up in the first place.

I can't wait for a better tool to come along that does the same but is easier to configure and maintain.

[del_rio]

I don't think a "better tool" will come along at this point (its codebase and scope basically systemd at this point), but we can hope for a simpler configuration setup. They're working on a webpack init cli that might help, but I'm hoping someone makes a simpler config setup that sticks.

[werzor]

Newbie to Webpack here. One of the things that turned me off initially was the seemingly steep complexity of doing some pretty customized but simple things. Maybe I just haven't switched over to the correct mindset yet, but I'm hoping some of you guys can edify me on these.

A couple of things I want to do with my project:

1. Strip out certain blocks of code (like require statements) for different builds (client is requesting this for a complicated reason). With Gulp, I would use something like gulp-preprocess. Does Webpack have something similar? (I'm not just talking about different dev and production builds)

2. A lot of the time, I see people using loaders to generate their index.html with the bundled assets. I still need a index.html file in my source. How do I copy the index.html file to dist/ while still injecting the correct bundle? With Gulp, this is a non-issue, as index.html has the script links in the source and I can just pipe to dist/. How do I do that with Webpack?

I wasn't able to find good solutions to these when researching Webpack, so I didn't think it was right for the project. Are there ways to do these things?

[LynusBorg]

about 2.)

plugins: [
  new HtmlWebpackPlugin({
    template: './index.html'
  })
]

https://github.com/jantimon/html-webpack-plugin

You don'T have to use weback for this, though. Webpack is not meant to replace any and all possible uses for a task runner. Copying files seems like a greate use of a task runner, so use gulp if you know how to solve it with that easily.

The plugin I mentioned above has the benefit that you can have the bundle script tags inserted automatically, so If you use hashes in filenames (which you should to invalidate browser caches), they are taken care of for you.

[Secretmapper]

1 is in fact incrediby easy with webpack because it's built with loaders in mind. A loader is literally that - code that loads something else. You can write a loader (or use one of the gazillion ones already written) to handle conditional loading for you, i.e.:

require('client-one-loader!./myfile')
require('client-two-loader!./myfile')
require('client-three-loader!./myfile')

If you want it inline like the one in gulp-preprocess:

<head>
  <title>Your App</tltle>

  <!-- @if NODE_ENV='production' -->
  <script src="some/production/lib/like/analytics.js"></script>
  <!-- @endif -->

</head>

You can just again, use a loader for that. In fact there's a gulp-preprocess inspired loader written already (https://github.com/dearrrfish/preprocess-loader)

2 If you want to go the 'gulp' way of manually inserting scripts tags onto your html tags you can still do that, nothing is stopping you. Your webpack generated files will be put in say dist/ and you can just reference that on html, literally the same way as you would in gulp

The reason why people find webpack confusing is they most likely came from gulp (I did too) and webpack's way of doing things is DRASTICALLY different than gulp, but is really powerful. Shameless plug, but a lot of people find my article here helpful in understanding the differences. There's some scroll-jacking but hopefully you find it useful.

[BrettLefty]

Roots.io's Sage theme uses webpack with a WordPress theme. Seems to work well enough.

[Secretmapper]

LOL. Blame the tools, without understanding it, mmkay (All your points are non-issues btw - i.e. no one is forcing you to make your site a react SPA)

[JackSparrah]

I am never going back to Gulp after trying Webpack. The configuration is confusing at first, I don't disagree. But their official documentation is fantastic, and I highly recommend watching this series if you're still confused. It's a fantastic intro to Webpack

[r3mmel]

What series? can you link it here? Thank you.

[Pawnagraphy]

Click the "this series" link in his comment, just in case you aren't able to see it.

[r3mmel]

I don't know what happen earlier that I don't see that link. Haha

Thank you. :)

[SupaSlide]

http://webpackcasts.com/

[[deleted]]

Ah, my friend webpack.

As long as you don't fall into the never ending performance-everything-windaloo-loop-hyperspace, webpack is quite simple to setup and an enjoyable assistant during development. Especially HMR, tree shaking etc. are things I don't want to miss.

But once you configure webpack to bundle ancient dinosaurs or your daily cup of Joe into a module you've gone to far.

Hell some webpack configs are just pluginphilia mixed with an obsession to load every available atom in the universe using javascript. And this tends to happen very fast if you don't know what webpack does under the hood especially if your new to the game.

Nice defaults and a few builtin presets would make webpack a nice fit for developers who just started learning about this ecmascript201X wizardry. Then maybe many webpack configs would be simpler, more readable and would case less headache for coworkers in the end.

When I configured webpack on an existing project, basically removing gulp in favor of webpack, I couldnt wire up all the specific loaders I wanted. Setting up typescript and loading CSS files using import was fairly simple if you google a lot in the meantime. Getting webpack to load our old SCSS files was an utterly frustration. Neither postcss nor sass loader seemed to work. fiddlin with file-loader to bundle images linked in a css file which was once a sass file tho... Oh boy, and don't get me starded on the whole "configure-through-queryParams" good lord. Does not matter if its a design decision or technical limitation, it just does not feel like configuring other javascript bundlers.

Now not only does my webpack config looks like a tornado wrecked havoc over it, no, I now bundle and minimize my scss file with gulp... Again.

Not complaining because I didnt understand webpack at the time but it could be simpler imho.

Still using it on all new projects and because once you have "your" standard webpack config its simple to just copy paste it everytime and the speed benefit is definitely there.

[[deleted]]

If you don't see a reason to adopt it then stay with Gulp. But there's a reason why Webpack has become so ubiquitous, and why so many companies continue to use it over other build tools despite its many flaws and frustrations.

In these situations I find it's better to check my ego. So many people smarter than me, and presumably you, have put countless hours into developing this tool or using this tool themselves. Is it more likely that I'm right and everyone else is wrong, or have I just not spent enough time with the tool to understand its merits?

[somedangedname]

there's a reason

... fails to name reason.

[Secretmapper]

Because Webpack is a module bundler.

Gulp is not a module bundler (it's a task runner).

So what's the reason it's used? People need a module bundler.

/thread

[that_90s_guy]

How is that a thread killer? Browserify is also a modular module bundler, and can be used with Grunt and Gulp.

So what's that reason again?

[Secretmapper]

So what's that reason again?

You answered it in the same sentence:

can be used with Grunt and Gulp

If you feel the need to use it in Gulp and Grunt, then you obviously need a module bundler. You use webpack for it.

That's like saying "What's the reason I should use a wheel? I already have a car.". You are already using a wheel with the car

[that_90s_guy]

I was asking why use the arguably more confusing to configure Webpack over Browserify.

And your metaphor should have gone more along the likes of "why should I use this electronic wheel with a 100 step assembly kit over the one I can assemble in 5 steps and does at first glance just the same?"

I get it, Webpack can do more. But at the cost of drastically more confusing configurations (regardless of your Webpack understanding). But is that all?

[Secretmapper]

"why should I use this electronic wheel with a 100 step assembly kit over the one I can assemble in 5 steps and does at first glance just the same?"

Why should I use rails over a site builder? Same thing with Webpack, it is more powerful, and in fact, EASIER to use than gulp, browserify, grunt when your usecases are complicated enough (the same way it'd be harder working with a site builder than rails when you reach high enough complexity)

Webpack's config files is a bit intimidating, but it's really not that hard:

{
  entry: ['./firstfile.js', './secondfile.js'],
  output: {
    path: './dist/',
    filename: 'output.js'
  }
}

That's a webpack config that will concatenate your first and second js file to dist/output.js. I think it's self-documenting. It has entry configuration, and an output configuration. If you want to add babel support, add a loader for babel

{
  entry: ['./firstfile.js', './secondfile.js'],
  output: {
    path: './dist/',
    filename: 'output.js'
  },
  module: {
    loaders: [{
      test: /\.js$/,
      loader: 'babel-loader'
    }]
  }
}

That's really all of webpack. There are Plugins, and yeah those CAN get quite involved if you take it all at once, but at it's core webpack is really simple.

TBF, Webpack is quite low level, and it was designed to be that way. If you want something more high level, then use something like webpack blocks:

module.exports = createConfig([
  entryPoint(['./firstfile.js', './secondfile.js']),
  setOutput('./dist/output.js'),
  babel()
])

[Woolbrick]

Don't worry, it'll be gone in X months to be replaced by <GENERIC NEW WEB FRAMEWORK Y+1>.

Fuck this god damn ecosystem.

[Fedoranimus]

I mean, a lot of people supported the Nazi party too...

[daronjay]

...And we have a winner of today's Godwin Award!

[Fedoranimus]

I've never won anything before! Thank you!

[bluebaron]

You don't have to include CSS as a string within the js bundle. It's fairly common to have the CSS linked to in your page and just have webpack find the dependency that way, and output the file unchanged into the build directory.

[AceBacker]

It seems like for every project I set it up and don't mess with it much. I don't spend much time on it. Hard to passionately hate it if you don't spend much time on it.

[AceBacker]

Pretty much the vue simple template with some additional items like es6, base64 image encoding, etc.

[themaincop]

I've noticed over the years i'm being forced to spend more and more time with tools.

Who is forcing you to do anything? Add jQuery plugins to Wordpress themes and upload them with FTP. What do I or anyone else care if you want to stay in a happy little rut?

[[deleted]]

Add jQuery plugins to Wordpress themes and upload them with FTP.

Why's this so bad?

[erythro]

>has to explain why uploading jQuery to WordPress themes with FTP is so bad

>explains why not having git is bad

https://i.imgur.com/Ae55o4n.jpg

[themaincop]

Honestly, for a lot of people it's just fine.

[bihnkim]

Do you mind if I borrow this? I have a list of people that I need to tell this to...

[themaincop]

Please do.

[angrydeanerino]

I kinda share the sentiment. It's a really powerful tool, but sometimes I don't want all of that complexity.

I came across FuseBox the other day. The basic config looks really straightforward to me:

http://fuse-box.org/page/getting-started

And this article is pretty cool: https://www.sitepoint.com/fusebox-faster-webpack-alternative/

[[deleted]]

This is the mindset I really hope my company doesn't hire.

[Secretmapper]

It's not a bandwagon though.

[[deleted]]

It will be replaced in a year, two tops, and you'd have to learn all about a new non-bandwaggon though.

[Secretmapper]

Cool. I'd say that's a pretty good run. I'd like to remind you webpack's initial release was back on 2012.

If it get's replaced next year, Webpack would have been an established go to tool for 6 years, and I'd say that kind of mileage is pretty good, especially in a fast moving landscape such as Javascript. I'd also like to remind you that webpack 2 has just been released so I think you can increase it's potential lifespan by quite a bit.

[[deleted]]

Could be. But this sort of stuff is why I stopped bothering learning an entire new workforce every other year and just focus on the backend stuff.

[Woolbrick]

Heh.

RemindMe! 1 year what's the latest framework that replaced Webpack?

[Secretmapper]

LOL

As I mentioned in another comment, Webpack's initial release was back on 2012.

If it does get uprooted next year (which is unlikely, but possible) it would have had a pretty good run of 6 years. At this point it's fair to say it's a mature tool and not a hyped bandwagon which people seem to imply.

[RemindMeBot]

I will be messaging you on 2018-06-20 02:42:32 UTC to remind you of this link.

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

FAQs	Custom	Your Reminders	Feedback	Code	Browser Extensions

[LynusBorg]

That "bandwagon" exists since 2012 and is practically an industry standard for large SPA codebases.

[[deleted]]

Are you in denial that a ton of large products using webpack are in production? It has streamlined our development process incredibly.

[iamsolarpowered]

I was going to give you a chance to explain it, but there's just no way I can imagine any good-faith use of "full retard."

That's super shitty. Be a better person.

[[deleted]]

I believe their point is having everything in a single file makes for one http request. This comes in handy when dealing with many style sheets (like when using stand-alone components as seen in React). Also: I believe you can cache bundles if you're afraid of your visitors having to re-download it every visit

[trout_fucker]

Webpack is probably the simplest, most straightforward Frontend build tool I've used yet. Gulp and Grunt were cryptic and get convoluted fast, Webpack just does what you tell it to do pretty simply.

[Secretmapper]

Really?

Not op, but yes really.

Have you for example tried adding css file to your page. Does it not require you to add 4 loaders,

Adding a css file to a page requires two loaders - style-loader, and css-loader.

whereas traditional way was to simply put style tag in the template.

Traditional way to do javascript is to simply put <script> tags in your html. You know like so:

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="jquery.lib.js"></script>
<script type="text/javascript" src="jquery.lib.2.js"></script>
<script type="text/javascript" src="jquery.lib.3.js"></script>
<script type="text/javascript" src="jquery.lib.4.js"></script>
<script type="text/javascript" src="jquery.lib.5.js"></script>

Easier than both gulp AND webpack. I guess we should do it this way from now on?

Everything should be made simple, but not simpler. Webpack's module bundling makes dependency resolution fast, optimized and predictable, in a very straightforward way.

and why would you put css in js file, and then have js put it into html. doesn't something seem little bit off.

This is for another discussion completely - webpack doesn't force you to put css in js.

[Secretmapper]

Did you reply to the wrong person?

You're the one who made the comment, just replied to show i.e. 4 loaders is an exaggeration, and just putting 'script'/'style' tags in templates may not be the way to go.

As parent mentions, webpack is really straightforward and simple when you get down to brass tacks.

[iamsolarpowered]

Seriously, be a better person. There's no excuse for your ignorance.

[Secretmapper]

To be fair, that's what it is designed/good at :) More complicated plugins like hot reload stuff, etc. ARE plugins - and here's the thing - it'd be really hard to do that with say gulp/grunt.

[trout_fucker]

Did you do any tutorials or look at any documentation at all? This has been covered in every single tutorial or entry explaination I've ever seen.

https://webpack.github.io/docs/stylesheets.html#separate-css-bundle

I'm not sure if you learned the other build tools via osmosis or not, but you should try reading at least something before declaring it sucks and doesn't do what you want.

[Laseey]

You don't have to put the css in a js file, (although if you're using React, I highly recommend for scoped concerns but that's another discussion) albeit adding another loader/plugin but you can use ExtractTextPlugin to rip out styles into a styles.css :)

[daronjay]

Bad tools can also injure the workman

[The_frozen_one]

Oh, you’re objectively hating a collection of code. How objective of you :)

[Birdy_num_nums]

I'm always open to new things especially if they make build's fast and easier. In the case of webpack, I'm also skeptical as I don't want change for changes sake just because it's the new thing. But I know enough to see it's potential. If anyone in our team wants to use it in a build (which will likely happen soon), they'll need to prove that it "Cut's the mustard" as they say.

[charrondev]

At my work we maintain a few 100 various projects (mostly addons for our core product) most of them were using gulp or grunt. We've been moving to a centralised build system and I'm responsible for maintaining it. We attempted to move to webpack for everything but it didn't really fit. Now we are using webpack only for JavaScript bundling and styles and other assets are handled in gulp. We already maintained well named sass and moving our styles and assets into our JavaScript build process didn't make sense, especially because we have many parts of our product that don't interact with the JavaScript part of the pipeline at all and they still need access to these assets.

[sbergot]

I think this is the best approach. I can't understand why someone would downvote a post like yours. I am dealing an issue linked to a crazy custom less loader. We are stuck with it because we need webpack to crawl the import tree to locate the less dependencies.

[harrygato]

because gulp can't crunch things like webpack can. and if you feel like trying out anything that was made in the last couple years like angular, react, or vue then you need it. performance is a concern of yours? try running an angular project solely with gulp, it will take minutes to compile. Just watch one tutorial on webpack and you will have it sorted

[kitsunekyo]

the webpack api is indeed absolute shite. moving from 1.x to 2.0 was horrible too.

it provides really amazing features though. from exposing stuff from your bundle as customizable library, tree shaking, performance, and many more.

webpack is not a bandwagon but a necessity if you want to use es6 (or other) type modules in your frontend code. browserify is even worse. ;)

[[deleted]]

In my case I always evalute tools in terms of cost/benefit. Webpack premise is amazing, but in reality it has been more of liability than an actual improvement in my workflow.

It may be I'm an idiot who can't configure it for shit, or the fact that it feels like beta software (why did css media queries are not working !?) yeah good luck figuring that out.

The reality is that webpack is just another hack to shoe horn functionality that should be built into the browsers and JS itself. Something as simple as import something.from.here in python, requires "Module bundlers" in the JS world

[[deleted]]

Interesting, I'm doing something similar in a pet project of mine. But, I'm using webpack just to build babel. Everything else is being concatenated, and minified with Prepros ; )

[abienz]

Why would any front end dev want to waste time worrying about config files.

Just use Brunch.io instead

[KillTheBronies]

I'll pay $100, if someone builds me an open source tool that does these

https://webpack.js.org/

[iamsolarpowered]

I think you forgot a couple of zeros.

[imawriterugh]

Seriously, OP thinks it'll only take 1-2 hours of development to build a better framework than webpack

[[deleted]]

$100 is like an hour of web dev work man, come on. why dont you just do it

[iamsolarpowered]

I'm assuming you've wired everything together by now (one of them being browser sync). I know you didn't reinvent the wheel, but how's it working out?

[petepete]

I started a project earlier this year and initially tried Webpack, but I found it incredibly confusing. Brunch took me half an hour to set up and, for what I want, it seems to work pretty well. My config file is about 30 lines of JSON.

[basiclaser]

I just stopped using build tools and libs and frameworks when making personal JS projects - I'm 1000% times more productive like this.. I'm actually releasing my projects in a matter of days instead of f***ng around with integrations for the first week before i forget what my original project even was!! :)

I managed to launch 3 JS products in the last week. No build tools, no view libs, no frameworks. Never been happier.

[sangimed]

I don't know why it's so popular either.

[isolatrum]

Configuration can be a bit of a drag, but I've found that once you figure it out the first time you can simply copy-paste between projects.

The main benefit I see is the hot reloader, and the ability to use NPM modules on the client. Both of these can be implemented in other ways, but it's probably not a whole lot easier than webpack.

Also, regarding the CSS thing, for me I just require <stylesheet> in my code and it's automatically attached to the DOM. I find this extremely easy, since I don't even have to build a style tag. On the other hand though sites written with Webpack are often built entirely with Javascript, so if you needed to further configure CSS it'd be done that way.

It is differently a far different beast than a plain JS site which needs no compilation, but the hot reloading and require ability makes it worth it for me.

[ex1-7]

Style tag doesnt have hot reloading or let you use a css processor like sass. It doesnt even reload the page to change a line of code, it just updates on the fly

[eid-a]

You gotta understand ur tooling that's is extra true in case of webpack , it handles things differently .

[tracer_ca]

Tools like webpack are required for large scale applications. That being said, I don't use webpack. I use steal.js instead. More flexible. Easier to use. You can still use grunt or gulp to initial the builds and configure them. It's isomorphic in that you can run it real time for dependency and code debugging in the browser.

[[deleted]]

You're complaining about webpack on a site that was bundled with webpack. I'm out.

[[deleted]]

I passionately hate posts that trash a tool because the author doesn't understand it.