My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs!
I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.
Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.
[0]: For example, https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble
When I google for "webpack someproblem" then the the first results are usually pointing to the webpack 1 docs. I often don't even find documentation for webpack 2 on the first page, unless I explicitly search for "webpack 2". It took me some time, but now I'm always appending the version number to all my searches. I think Angular has/had the same problem.
Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.
This is (annoyingly) common in a lot of software packages. Protip: Keep your documentation's links canonical. Currently running into the same thing for Polymer. Just keep the old links and do a permanent redirect to Polymer 2.0, with a clear indication of what version you're on. Also looking at Angular here.
I'm kind of surprised how cold reactions are against Webpack here on HN. I consider Webpack by far the best module bundler. My path was: scripts, stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of them are pretty awful. Try one of those and you'll realize how amazing Webpack is. For example one of the newer bundler - SystemJS pretty much force you to use jspm package manager. Jspm changes SystemJS configuration on every new package installation, so you can be never sure, if build is failing because jspm changed something. You can forget on imports without providing correct extensions (js,jsx,...), or prepare to fill you config will lot of defaultJSExtensions/file mapping. Also import Module from './module where module is folder with index.js file doesn't work out of the box and mapping has to be added. etc... The only thing I'm personally missing in webpack, is option to provide custom chunk loader, so I can load chunks with any other AMD loader, something similar to requirejs+almodjs or SystemJS static SFX builds, which was the reason I've tried SystemJS at first place, but it wasn't worth the pain.
Have you tried rollup? Webpack's tree shaking is broken and doesn't work properly with libraries structured like d3, while rollup's works properly. I've managed to get trivial 150kb minified size reductions by switching.
Rollup looks nice too. As far I understand rollup, it's generating more human readable and shorter bundles, so it's more suitable for libraries. I didn't tried it yet, but I feel somehow that if I do, I will find bad parts there too. Like limited (comparing to webpack) module format support...
Yeah, it's pretty common (for the tree shaking case) to make a custom d3/whatever library bundle with Rollup and use it with Webpack for your app, but it's a formidable alternative to Webpack regardless.
I'm sure it's ok when utilised by skilled hands. But unlike a lot of tools it's just too easy to get things wrong. Possibly by a lack of good documentation or design.
I'm still feeling bitter after seeing it introduced on my last project, a Rails app. Build times went from seconds to 15 minutes. After experiencing that I will make every effort to argue against it's inclusion on my current project (should anyone propose it).
I use Webpack in a couple of projects, but it only seems to fit well for single page applications that fit their near-standard configurations.
We tried to replace Gulp with it at work for some relatively complex software but it was an absolute nightmare; Webpack is highly opinionated and to get it to build multiple different targets with different configurations requires jumping through a lot of hoops or worse, having to have separate Webpack configs and different build commands for each different asset target.
The last straw for us was how messy it got trying to build our LESS at the same time. Packaging all the LESS into your compiled JS, then having to extract it to put it in other files is absolutely ridiculous.
That is something I forgot to mention. Webpack is great for SPAs and not so great for classic site with lot of html files. You can have multiple entries (html files), but share common chunks between them might be difficult in some special cases.
> You can have multiple entries (html files), but share common chunks between them might be difficult in some special cases.
This is what I'm trying to do at the moment -- create a static site that's just a bunch of HTML files, while still taking advantage of Sass, CSS modules, and Vue.js components. (God, I love scoped CSS so much.) I'm sure there's a way to get Webpack to do what I want, but I haven't found it yet. prerender-spa-plugin has been a huge help, though.
It seems very similar to when I was learning Git: I know what I want to do, but Git's interface uses a level one layer lower than the one I'm operating on. "Undo the last commit", not "Reset the working tree to the previous commit's, but leave the staging area intact". Webpack's interface seems too abstract for what I want. I want to think in terms of individual pages, not of entry points; components, rather than chunks. Hopefully in five years when flat HTML files are vogue again there'll be a friendlier interface on top of it all.
Edit: I don't mean to be 100% negative in my comment! Webpack has certainly helped me solve problems that, previously, I haven't been able to solve. That alone is great. I just wish it'll go "click" so I can "get" it.
If I understand you correctly. You basically want to create completely static website with no javascript (or very little). Something like server side rendering, but without server (or to be precise with only http server) :-). And you've already found webpack module for the job.
Yeah, you got it. I have a webpack.config.js that compiles everything, bundles it together, and spits out a bunch of HTML files. But what I don't have is the confidence that I'm doing things the right way and not using Webpack inappropriately!
Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags.
Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure.
Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! https://github.com/substack/node-browserify
webpack is just more complicated, which means it takes longer to start - it also has some bad naming and quirks which happens when design-by-committee decisions take place.
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.
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.
You can write a book about anything and it's also a great way to learn so not sure why that is an issue.
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?
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.
I work with JavaScript and related technologies every day and I am still annoyed to setup new projects because if half a year had passed, everything seems to be different - especially in the React ecosystem (at least from my POV).
Exactly, I think one reason why this trend hasn't stopped while most of the fellow devs I know are sick of it, is that JS attracts a lot of new devs.
Being new they start developing on JS/React, but they don't have the painful experience and thus have more tolerance until they too get sick of it and try to keep things minimal, but then more new devs start which fuel the never-ending circle.
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.
What exactly do you think the problem is? Especially since you dont have to do anything.
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?
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.
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.
So don't upgrade to the latest and greatest tech? Find something that works and use it just like anything else.
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.
I think your hyperbole is unwarranted; if you're building a "hello world" application, you don't need to use a bundler, or any of the "latest and greatest libraries".
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.
Hello World is only your first test case to get all the tooling up and running. The real work starts after Hello World and is expected to become more complex. Within minutes you will grow tired of manually running transpilers, minifiers, tests, adding each new js module to index.html etc. You will want to automate all of this. At least this is my experience every time I start a new project.
Have you ever tried Gulp? Honestly I had the same feeling with webpack, I like it for my "professional" day job project that's grown to huge size and webpack can chop through it quickly; but for side projects, probably not.
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'.
It's bullshit. I'm half tempted to go back to make and just cat'ing JS files together. It was so much faster, easier, and it wasn't always constantly broken.
It really is. Back when I was trying to get excited about learning yet another way to bundle things (YAWTBT(TM)) I attended two tech talks that concerned webpack. I really wanted to 'get it'. I left the second one having decided to never touch it again if avoidable.
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?
> 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.
Because there are instances where one doesn't want to block rendering with large CSS file downloads? For above the fold content, inlining makes perfect sense.
> I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config
I am pretty much confident that everything worked well before you have made any modifications in the webpack config. So, the negative effects, that you are describing after, is a result of your efforts, but not anybody else.
And why did you want to eject in the first time? Most popular use-cases are already covered into create-react-app by default.
Here's my Makefile, which includes all the configuration: react, babel, etc. (I do not have any dotfiles in root except for linter). `watch` recompiles on changes and has sourcemaps. You can require any node modules and calls to `fs.readFileSync` will be replaced with `Buffer` objects.
What it doesn't have is any kind of automatic page reload or code swap and you can't `require` non-js files. There is also no minification for production build. I believe you can have those after couple of minutes on npm, but I haven't tried. Dependencies:
In semver land, every major release is a tragedy. I love that they're really doing hard (and free!) work to make the transition as smooth as possible, but I still wish the JS ecosystem culture would be more conservative about releasing breaking changes.
Migrating from webpack 2 to 3, should involve no effort beyond running the upgrade commands in your terminal. We marked this as a Major change because of internal breaking changes that could affect some plugins.
So far we’ve seen 98% of users upgrade with no breaking functionality at all
Your point being? The plugin interface is a public interface too, right?
Again, I really appreciate all the work done to make this smooth, but there's still a little underlying "compatibility matters less than features" sentiment here.
> The plugin interface is a public interface too, right?
It didn't say 'plugin interface'. It said 'internal changes' that could affect some plugins. The way I read that is some plugins could be relying on internals (that they technically shouldn't, they may have good reason ofc).
Having gone through script tags -> Browserify -> Webpack, I now have the sneaking suspicion that Google's Closure compiler was the right thing all along, and that I should have learned that to begin with.
Thanks to the Webpack people for focusing on ease of use, ease of migration and avoiding breaking changes.
react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.
Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not ideal since there will probably be no future major 3 versions, but no one is forced to make a 'big breaking change' strictly speaking.
> We intend to keep supporting the 3.x branch indefinitely (published separately on npm to aid in migration), although there will likely not be any future major versions based on that code. 4.0 is the future, but we won't leave you hanging if you want to stick with 2.x/3.x.
4.0 is a regression imo. The docs say that if you do server side rendering with code splitting then 'God Speed' (their words not mine).
I don't see the benefit of switching if v3 allowed me to ssr and code split while v4 doesn't allow me to do both.
From the user pov it went from instantly displayed page with minimal js required to choosing one of those options.
What benefits could exist that supercede giving the user the best possible experience? (Genuine question).
I can't imagine huge speed gains going from one page to the next from this change and indeed changing pages in SPAs are essentially instant. So what could possibly be better that makes it worth getting rid of ssr and code splitting? Imo I won't be using react-router in future products because they are too fickle with their codebase.
I'm huge fan of React Router v4. It works great with webpack and it's worth upgrading. Forget about static router configuration in one component. With v4 you can do router delegation, when router component can delegate routing to another. This allows you to split your app into chunks in before impossible ways with webpack.
Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0 in the project I was working on, but I guess it was a little too soon and I ran into dependency errors.
Here's to hoping that we see a performance increase instead of a performance decrease as was the case with 2.0.
I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.
Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.
[0]: For example, https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble