the webpack book by survivejs takes a few hours to read completely, or an hour to read the important parts, and you'll be very comfortable with it.
https://leanpub.com/survivejs-webpack or https://survivejs.com/webpack/preface/
Holy shit, I thought you were kidding.
We're at a point where the bundler, one of a dozen elements required for a 'barebones' modern js application, needs a book.
I'm finding it hard to find motivation to do any kind of web based side projects these days because they inevitably begin with 'which combination of latest and greatest libraries do I need to spend an entire day wiring up before I can do hello world this time?'. Someone make this madness end.
Modern javascript tooling makes 90s C++ look pretty pleasant.
Pick tools which you are comfortable with and which solve problems you actually have. Otherwise, you'll be left complaining about some vague "community" that is "forcing" you to adopt the "modern standard", even though there's nothing "standard" about the apps this "community" develops as a whole.
webpack does a lot so it requires lots of knowledge -- or you could just stick to script tags and basic minifiers built into every server side web framework at this point.
npm (or yarn) for downloading dependencies + webpack to squeeze them into a bundle makes for a very powerful combination if you need it and it takes a few mins at most to setup. Why the hyperbole if you don't understand it?
Now there's hyperbole.
Let's be honest. Unless you do it for a living, at best it takes a few hours to set up boilerplate for any modern js project today.
And let's also be honest that es6 is a must today and script tags are not an option until browser es6 support is ubiquitous.
Last project I set up, grunt and browserify were the thing. You were an idiot if you weren't using them. Apparently now it's webpack and gulp. In another year it'll be some other crap. The first step to dealing with a problem is admitting there is one. I'm not sure labeling comments that highlight the problem 'hyperbole' is constructive in any way.
In the end it's not the new devs' fault of course, but rather the lib authors who don't treat their software as something that needs to be stable among other things.
Personally I try to KISS, but unfortunately on work I have to deal with this mess.
The one with webpack? 1? 2? Now 3?
What about react? And redux. And react HMR. Oh and you probably need immutable.js if you want to use react the 'proper' way not like those fools last year. Your starter script was configured with react-router? That's a shame, because it's no longer the latest and greatest, and everyone knows you should have moved on to React Mini Router. Or is it React Universal Router now? Wait is the particular configuration of webpack in this starter script even compatible with the latest and greatest babel-loader? Hang on, you wanted to use promises? Yeah, that's another plugin for polyfill and more config that interacts with most of the above. Don't worry though, there's plenty of tutorials to get it working with webpack... Oh wait, they're all for webpack v1 and you're on v2.
Is your complaint really that there's new tech out and you have the option to use it? Do you complain every time a new language releases? Do you use Django 1.2 because you don't feel like upgrading to 1.3, 1.5, 1.8?
I don't exaggerate in saying that the comments you've posted in this thread have taken more time than it would take to have a basic webpack setup.
If you just use Typescript with some libraries, you just need to setup your tsconfig.json. Maybe a package.json to track your dependencies, or just vendor them in! The compiler even includes an incremental watch mode!
Almost all projects start off with some infrastructure. There's easier paths than others.
The webpack config is a few lines at minimum, and yes you can type it by hand in a few mins. It's just a bundler which is completely separate from the actual libraries you use.
It takes in a entry file, walks dependencies, gathers the modules together, and outputs a single bundle at the end. It works with JS by default but can handle other file types with loaders. That's it, just a big pipeline of stuff. Use plugins like babili and you can have streamlined source files that are transpiled and minified in a single step with the latest browser compatibility tables.
It's not required yet takes less than an afternoon to learn. Backend development and build steps get very complicated so why is frontend work not allowed to have complexity given the rise of sophisticated webapps today?
Then I found gulp. Uses a more functional streaming style, but for the end goal of [Turn ES6 into ES5]->[Stick it in this folder] it's dead simple and quick.
Angular, React and Polymer are hiding the complexity of modern JS app building behind their own CLI, so it's literally down to 'angular build --prod' or 'npm run build'.
The first was by a developer who had recently moved a sizable codebase to webpack. He had pages after pages of graphs of how he had tuned webpacks code splitting capabilities. The end result of all this work was actually a larger sum of file sizes - and a slower loading speed. But I guess those days / weeks of tuning shave off a few kB when they deploy minor changes.
The second talk was by one of the primary maintainers of webpack. It was completely incoherent. It was a jumble of things that "can be done with webpack" - not one good reason why. E.g. "You can extract CSS from your javascript files with this plugin" - what genius came up with the idea of inlining styles in a javascript bundle to begin with?
I do this in a project and it's terrific. The JS files in question are front-end components (for Vue.js in my case), and the point of having the styles inline is so that components can be a single file, styles can be prefixed to be local to that component, and so on. It's light-years easier to work with than trying to do something similar without a module bundler.
All these, I guess... https://github.com/MicheleBertoli/css-in-js#features