Hacker News Reader

Comment by jorblumesea | Hacker News Reader

Personally found Webpack to be really heavy handed for what most developers need it for. Gulp on the other hand seemed easier to just build exactly what you need. Webpack felt like an overly complicated poorly documented black box that seemed to work by sifting through github issues and comments. You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue. Gulp just...worked, and with very little fuss. Sadly React seemed tightly tied to webpack so if you want React you're tied to that toolchain.

In general I think tooling needs to improve, and neither Webpack nor Gulp are painless. Neither is maven, I suppose...

View on HN

Hey thanks for the candid opinion!!! Sean from the webpack team here!!! Maybe it's been awhile since you have taken a look at our documentation! (webpack.js.org)!

I think something that individuals who try to make comparisons to their backend tooling that "just works" is that none of these tool have ecosystem constraints like the Web. I wanted to really talk about something that is important to understand about tooling, and why webpack might have some of the features it does.

In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download. From there, you should be "dynamically" delivering JavaScript asynchronously in bundles/chunks. In addition, there are multiple module types that exist in the JavaScript ecosystem that libraries are published in. Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all, and there is no consistency or way to know this about those modules without looking at their source code. Therefore, webpack out of the box supports the ability to load all of them. Not only that, but we employ a set of plugins that help optimize code using complex topological sorting, (aka things you'd probably never want to implement or hand optimize yourself) to ensure that your delivered code is the smallest possible.

Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc. Think if there was 5 ways to write C++ Modules/Java Modules, etc. and you had to apply the same constraints as the Web. (You'd probably see a lot more webpack's or a lot more convention tools that wrap things like webpack).

Anyways, as a maintainer of the project, we can't say this enough: "We are owned by our community". This means that if there are things we aren't doing right, that we owe you to make things easier to use, more conventional, when needed, and progressive in a way that lets you layer features and need on top of an awesome, and fast core product <3.

So if you have great ideas, please let me know. :-D

Why is this still available? It still shows fairly high in Google: https://webpack.github.io/

BTW, your documentation effects inspired me partly for making the documentation of https://serverjs.io/documentation/

> Compare this to C++, or any "build" static toolchains. There are really _no_ size limits for the amount of dependencies or code that needs to be linked together. Therefore, there is no care in the world for application developers if they are generating 600GB Video Games, 10MB-100MB Applications, etc.

Huh? Seriouosly? Embedded devices can be any size people want? Some software I develop uses C, Go, etc. and it would be nice to not have to worry about built artifact sizes. Admittedly I find it kind of fitting and funny that someone who maintains a popular JS library thinks that the web is the only (?) platform with build size (and possibly other) constraints, haha.

Anyway, I do appreciate your work in helping maintain an open source project, so keep that up.

But on embedded devices, do they download the whole artifact again and again? On the web this is a real issue

No in embedded if it is to big it can't fit, full stop. One byte too much means corrupt firmware.

Hey Sean, I just want to say thanks for all the work; I'm not sure the complaints from others but webpack has helped us quite a bit by making development life closer to what it should be!

> In the web, you should only ship no more then ~<200kb of JavaScript (uncompressed), for your initial download

Man I wish it was easier to convince people of this. I'm fighting with some teams at work who are shipping 2mb+ compressed with several seconds just for parse time...and all of the webpack tooling and features are needed just to keep it there (when it should be used to bring it down within that 200kbish threshold). And they feel its normal.

As Webpack user, I can affirm that the documentation and the error handling is way better than it used to be. Webpack, by it's nature, is not an easy to use tool.

I don't think all developers should have to deal with Webpack directly, for most developers a generic Webpack config generated by something like create-react-app should be good enough.

Of course this doesn't mean that Webpack itself should not try to improve, however users should be mindful of what a hard problem the tool is trying to solve.

> Sadly, some of the most popular libraries are being published with AMD Modules, or CommonJS, or no module system at all

Not being current on JavaScript for the past couple years (which is about all it takes to be totally out of date - but I digress), I guess these are out of style, in favor of ES2015 import statements? The webpack docs [0] really don't say anything about that, just that they're supported.

As a consumer of webpack and $random_library should I care? Should I prefer a library with import over AMD or does webpack make that irrelevant?

I can't tell from these docs, but previous experience tells me this is the kind of thing that has the potential to trip me up later when it's a huge pain to switch everything.

[0] https://webpack.js.org/concepts/modules/

Yes, it does make a difference, in a few ways.

AMD modules can effectively only be consumed by a browser, or a browser-focused bundling tool, since AMD was designed for the "cascading waterfall" loading approach. Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules.

CommonJS modules are intended for synchronous loading under Node, and tools like Webpack and Browserify can wrap them up to be used in a browser.

ES6 modules are designed to be statically analyzable, which is a key factor in "tree shaking" to drop unused code out of a generated bundle. However, the ES6 spec only defined the syntax for modules, not how they should be loaded. Major browsers have finally implemented native support for ES6 modules, but there's still a lot of complexity around how they're going to be implemented in Node [0].

There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing. However, that loses out on any possible benefits from tree shaking. See this Twitter thread with discussion from Dan Abramov [1].

For more info on the history and differences between various JS module formats, see the "Javascript Module Formats" section of my React/Redux links list [2].

[0] https://medium.com/the-node-js-collection/the-current-state-...

[1] https://twitter.com/dan_abramov/status/938090483166924800

[2] https://github.com/markerikson/react-redux-links/blob/master...

>Anecdotally, I see no new libraries being written in AMD format, and some that are written in AMD are looking at transitioning to ES6 modules

Quite possibly because one of the biggest backers of the AMD format, Dojo* is now transitioning to ES6 modules.

*I really gotta hand it to those folks. They pioneer quite a bit of tech. Sometimes it sticks, sometimes it falls by the wayside, and sometimes it returns as someone else's "idea".

> There's also complexity around how lib authors publish packages to NPM. The most compatible approach is to author lib code as ES6 modules and whatever syntax additions you want, then compile it to CommonJS and ES5 before publishing.

There's also a growing trend among some major libraries to publish NPM packages only as ESM and use an shim like @std/esm to load them in Node:

https://www.npmjs.com/package/@std/esm

So, just to get my own biases out of the way first: I'm a big webpack fan, with no qualifications. I think it's a fantastic tool, and I've had the complete opposite experience of the OP.

This response comes off as kind of snide, as does the post it responds to; I don't care to tone police, so that's fine, but I do want to try to understand the perspectives here.

I'm imagining you're coming from a place of: you have a (fantastic) tool with unique challenges, and it's incredibly frustrating to have that tool judged a) based on requirements it wasn't designed around and b) (likely?) based on older versions of your tool that has since been improved. Those are fair things to take issue with.

A couple things, though: "Hey thanks for the candid opinion!!!" - This seems pretty obviously disingenuous. "Maybe it's been awhile since you have taken a look at our documentation!" - Comes from the position that OP is simply out of touch, and that their issues aren't valid. They may or may not be, but this is "Maybe you're wrong!" and not "Maybe there's been a misunderstanding!" "So if you have great ideas, please let me know. :-D" - In context with the above, this is more like "Let me know when you actually have a great idea" than it is like "Please open an issue or pull request so we can actually fix it". The OP does clearly have an issue with Webpack - "You spend 2 days getting it into some semblance of a working state, and never touch it for fear of introducing a new issue" - and that issue can be addressed, if developed into something more actionable, or may already be solved by the improved documentation of 2.0 & 3.0. As it stands, though, it seems more likely to me that nothing comes out of it, which is a shame.

Not trying to put words in your mouth, I just expect you're more frustrated and want to make a better tool than you are trying to necessarily defend your tool, and I'm not sure you're communicating the former over the latter. Would love clarification if I've misinterpreted something, or correction if I seem totally off the mark. And again, lest I come off more aggressive/dismissive than I intend - thank you for all your work developing and maintaining Webpack. I imagine it's a relatively thankless task for the breadth of what it offers.

The overwhelming majority of space taken by games is HD or 4K assets, not code in any language or plaintext script. I can't even think of a single game that is 600GB off the top of my head, the latest huge AAA: Doom, Halo and Witcher are all under 100GB I believe and still considered too heavy on users in Australia, users with bad connections, etc. (and again - vast majority of that is assets, not any code). The biggest game I actually have on my HDD now is around 60GBs and the exes and dlls take under 50 MBs, it's FFXII with both English and Japanese in it and there is a guide on Steam on removing one of the languages content to bring it down to 30GB. And the latest "don't worry about it, CPU/RAM/HDD is cheap" framework for "native" applications lately was not Qt, GTK+, LCL, etc. but actually a 'JavaScript' technology - Electron - notorious thanks to shenanigans of Slack and Atom.

Between the multiple exclamation points, emotes, PR fluff and the content itself I was actually unsure if this is a parody account or not but it seems to be a genuine Microsoft person.

Actually - I just noticed I dropped an I. It's Final Fantasy 13 (FFXIII), not Final Fantasy 12 (FXII). The sizes are correct though.

I'm not sure, my opinion of Webpack is completely different.

We used a ~20 line configuration file found on Gist to replace our ~400 line gulp build. It resulted in better optimisation, less hassle and "Just Worked™".

We wanted to add a few more things to our configuration, literally just took running `npm install some_package`, followed by requiring it in the webpack configuration.

> a ~20 line configuration file found on Gist

Having to find it on gist because the official documentation is so lacking that nobody can figure out how to configure the thing except by following examples is the main problem that leads people to fear webpack configuration and to cargo cult magical config files that they are afraid to touch.

Mature tools can be understood in principle and configured without needing to see "how someone else did it."

The recent rewrite of the doc seems pretty clear and straightforward to me. Did you take a look at it?

I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.

> I think lot of people don't even try to read the official doc and just look for a work-out-of-the-box conf to copy/paste. Probably because they think it's not worth it learning a tool you configure one time and never touch again.

And that's a valid audience for the tool.

Good documentation would support this audience too, with plenty of examples and recipes. Even a repository of documented common use-cases (which must exist for Webpack's automated testing, right?)

It's much much better, but still not very clear in many places. Just the other day I was struggling to figure out what some magical terms were referring to.

I looked at the documentation the last time there was one of these complaints about webpack threads, the usage and benefits of loaders, plugins and modules seemed hard to understand as opposed to gulp where you just have a pipe.

I don't care if I can just plop a simple webpack without thinking in and it will handle everything I need, because I will always need more - and besides which I have my own gulp files I can just plop in without thinking too because I wrote them and I know exactly what will happen.

Thats surprising to me. Even the originally 1.X documentation wasn't that bad for the common cases. The 2.X documentation is pretty darn good.

The only issues I hit back then was complex cases back in the 1.X days. But if all you wanted was an app with prod/development mode that compiled javascript, css, let you import assets, minify in production and hash file names for long term caching, it's pretty simple considering everyone wants these to work slightly differently.

> Mature tools can be understood in principle and configured without needing to see "how someone else did it."

I don't know a more "understood in principle" tool than Webpack. There are no magical invocations just `webpack` and you are done. Plugins are usually just a require and adding to your plugins array.

I also think the maturity of a tool is in being easily understood just by reviewing someone else's config. To me, that speaks volumes for how simple and easy it is to get up and running in webpack.

I’ve been able to do everything I want to with create-react-app which uses webpack internally, giving you a zero configuration experience.

With async import I am able to do code splitting. With react-intl-cra I can pull formatted messages out of my code. I had to add a grunt file to compile LESS into src, but it was easy to integrate with my package.json scripts.

The fact that you had to add grunt, the grandfather of webpack, speaks volumes. Why didn’t you just configure wp to compile less?

That has less to do with webpack and more to do with create-react-app which doesn't allow you to modify the webpack config. The gp didn't really need to use gulp, you can compile less with package.json scripts.

As mentioned, create-react-app doesnt let you configrue anything (ok, almost anything), and doesn't support LESS/Sass by design.

Though you usually don't even need that much. Just using the node-sass or less compilers directly usually work fine. Or use something like Glamor or Styled Components to punt on the problem altogether.

Using this should make WebPack work with LESS files. I'm no expert, but my understanding is that this says "for all files matching *.less, run them through the CSS and LESS loaders, then use the Extract Text Plugin" (which pulls things into their own file; you'll need to configure it in the plugins).

{test: /\.less$/i, use: ExtractTextPlugin.extract(['css-loader', 'less-loader'])}

Edit: forgot a brace.

Thanks! One thing - I'm not using WebPack directly and indeed, I have no access to the WebPack configuration because Create-React-App hides all of that from me.

I can eject the app from Create-React-App and get a normal WebPack project, but I won't do that unless it's absolutely necessary because the huge community of Create-React-App devs are taking care of my config for me.

create-react-app now uses some kind of extensible build scripts in form of react-scripts: webpack files which you can clone and modify and use without ejecting.

here's one for less: https://www.npmjs.com/package/create-react-scripts-less

also here are the official docs: https://github.com/facebookincubator/create-react-app/blob/m...

Any ambitious project is sooner or later going to have to delve into their tooling, and not depend on examples they found of things that work. I admit it's nice you found something that worked exactly as you wanted, and my experience is I can often find what I want exactly when I start but sooner or later you need to add to it. And then things start to get less pleasant.

I definitely went through the pain of trying to set up Webpack 1.x on a large project. The documentation was probably the worst part (it was adequate as a reference, but really assumed you already knew some of the fairly complex topics).

I also recently went through the process of refactoring our build to use Webpack 3.8. The documentation is a LOT better. Their introductory docs especially. I feel like I finally understand parts of WP 1.x after reading the 2.x/3.x docs.

Gulp and Webpack really are two separate things. Gulp is basically like Ant had a baby with NPM scripts. Webpack is closer to Maven, but Maven really tries to do a LOT more.

For any project, start with NPM scripts for your task running, then include gulp if/when you actually need them. Same goes with Webpack: don't include it in every project just because you think you might need it eventually.

Have you tried webpack since the 2.0 launch?

I felt the exact same way as you, but recently went through their tutorial/docs and was able to get a pretty good (and simple) setup without much fuss at all - a dev build, webpack dev server, and prod build. I’m only a short bit into actually proving it out for myself, but so far I was surprised since my first experience being quite negative too.

It's really not difficult, it just looks more complicated than it is. If you want a good start, try the Webpack book by SurviveJS. You can read most of it in an hour or two and not only create a config but actually understand how webpack works: https://survivejs.com/webpack/introduction/

There are also slimmer/newer/zero config alternatives like:

https://poi.js.org/

https://neutrino.js.org/

https://parceljs.org

Webpack is a dependency-wrangler. If you're using it as a task-runner like Gulp, you may not need it at all.

Personally I use then together - Gulp runs the tasks, one of which is bundling, which gets done by webpack. Of the two gulp was way harder to get working, for me at least.

...you may not need it at all.

Yeah npm can run tasks by itself just fine.

Sure, as long as you can express your entire pipeline as a single shell statement and don't care about Windows.

Does anyone? Doing web dev on Windows means exposing yourself to a world of pain, which is why most are on MacOs or Linux anyway.

Sure. I do, and I'm sure most people in big corps do too.

All modern high level languages have very good cross-platform system libraries and build tools for those languages usually use that language to run. Occasionally you'll run into someone that's still using Makefiles and have to break out msys but other than that it's generally fine.

A world of pain? I've had much more painful experiences trying to get Ruby on Rails setup on a new MacBook.

You've found Ruby easier to manage on Windows? Can you serve it from Windows? (other than Webrick)

I'm not trying to be inflammatory at all. I just never had any luck with any Ruby/Rails type stuff when I was forced to use Windows. I ended up resorting to JRuby.

There's really no need for one-liners - npm can run shell script files just fine.

What complex things are you doing that Windows compat creates problems? (presuming you've got some form of bash on Windows) I tend to tuck any complexity into JS devDependency libraries when using npm scripts which takes care of most cross-platform issues.

If you're using npm to run shell or node scripts, then you're running your tasks with shell or node scripts. Just because you typed "npm test" instead of "./test.sh" doesn't mean npm is doing anything to help manage your tasks.

Scripts + NPM are better together, for example because scripts executed under NPM have the local packages binaries in the path. This makes it very easy to have a fully locally installed build environment with no system dependencies. And if you do use webpack, it also helps in providing a uniform interface (Is "test" a Webpack target or a script? Who cares, just use "npm test", it'll work either way, also if we change it in the future).

And it's not an either-or case in the real world. Our company has a big Webpack config that does a lot, and still we have 15+ scripts as well (static analysis, inserting copyright headers, sourcemap uploads, 3rd party vendoring, release scripts...). Some things are better in WP (building), while some things are just simpler with a shell script.

npm (more specifically package.json) is helpful in this context for a variety of reasons:

- it's a single, central document listing your important pipelines and their purposes - anyone unfamiliar with your setup can look at the scripts property and get a very good idea very quickly

- it's auto-detected and even auto-parsed by some tools (a Ctrl-Shift-B in vscode, for example, will allow me to select a build pipeline - there's no more well-supported central format for arbitrary loose shell scripts)

- it's a consistent entry point. If you edit your npm script to point to a separate shell script, or to run webpack/whatever instead - anything external (IDEs, CI configs) pointing to npm need not change

The above are not unique to npm, but it's a well-supported, well-understood, and very simple setup that does the above.

If you're going to go to all the trouble of writing (and debugging) bash scripts, why would you not just use Grunt to do the majority of it for you?

EDIT: (Asking this in the context of the grandparent comment suggesting getting rid of build systems in favour of NPM scripts)

To clarify, I was specifically responding to the gp comment's point on needing to use one-liners in npm scripts.

The most complex "shell scripts" I've actually written for this specific purpose are simple ordered command lists, with occasional exit code checks, where appropriate. So I'm not so much talking about "writing and debugging" - this is more "replacing semicolons with newlines in a very long one-liner"

I do actually put one-liners into npm scripts instead quite often - it's a trade-off, depending on the pipeline.

> Sure, as long as you can express your entire pipeline as a single shell statement

Single line shell pipelines :) Exactly why I made this - https://github.com/jeswin/basho/

The document seems to have gotten a little better, lot better than Webpack 1, however the plugin ecosystem is the most frustrating part imo. Webpack gives plugin creator some form of freedom and because of that, and the lack of types in JS, you're at the mercy of proper docs on the plugins you're relying on. Either that or go through the source code to find out what the heck is even accepted as options.

We heard this feedback infact and we wrote the entire plugin system for webpack 4! (https://github.com/webpack/tapable). Take a look at the only PR open which is us working to provide the best Type system possible for our new API (which was infact designed to support it).

Even better is that you can find all the "hooks" on an instance by doing `compiler.hooks` so now you get a far better authoring experience :-D

Would be better if Webpack had defaults that just worked out of the box without configuration.

That's awesome. I haven't played with webpack 4 yet. Just recently started playing with webpack 3. I'd be keeping an eye on it.

There has been some recent buzz around https://parceljs.org/, which aims to also "just work" with minimal configuration.

At what cost :-D

https://neutrino.js.org/ is my go-to, I have no gripes with Webpack as a technology, but I don't think it's what people should use on a daily basis abstraction-wise.

My webpack configs are a magnitude smaller than the equivalent gulp ones.

React really isn't tied to webpack - babel maybe. If you're just using webpack for the basic functionally of babel automation and es6 import resolution it's trivial to setup but probably not the best tool for the job.

People use Webpack because it gives you easy access to NPM, understands module dependency graph and through various plugins, can optimize your code with features like lazy loading, tree shaking, etc. These are things you don't get with Gulp.

Curious what people think of Neutrino as a solution for Webpack's complexity: https://neutrino.js.org

That is fantastic, on first glance it seems exactly what is needed.

I just think it's unfortunate that the tool needed someone to develop another tool to make it truly usable. Good software should be simple to use and configure, not dense and opaque.

I don't think it's unfortunate, I think it's a good abstraction. Webpack being a lower-level tool wrapped by Neutrino. Similarly to git's plumbing and porcelain separation.

React is definitely in no way tied to Webpack. Slightly tied to babel presuming you're using JSX, as everyone is, but otherwise it's extremely easy to use any other tool.

I've built pipelines with rollup and browserify, both which have problems and I'm not entirely happy with but I found an improvement over webpack.

I evaluated webpack recently and found that it worked fine for straightforward projects but the more customized I wanted it the more issues I ran into.[0] I think it’s a matter of configuration as json vs configuration as code. Webpack had all of the component pieces I needed, but they were glued together in ways that I couldn’t compose them. I ended up using rollup, which was a bit better but I still yearn for the composability of Broccoli.

[0] My project allowed users to have a single JS file that would be able to `import` npm modules and the have the bundler compile all of the dependencies into a single tree-shaken vendor.js, while modifying the main file’s imports to be human-readable es5. Webpack’s es6 import code was tightly coupled to the format of its output.

I haven't used Webpack prior to 2.x and Gulp was my preferred option previously as Grunt really was a clusterfuck, but Webpack setups come with batteries included and small extensions to it you need to add are often easy. That's my limited experience anyhow. The only tool I rooted for (but is still behind the curve) is Brunch.

I started with Webpack, but just recently I'm trying Fusebox and so far liking it much better as well.

I have active projects using browersify with reactjs. It's not tightly tied to webpack.

Good that plain JavaScript 5/6 with no framework is still in the top 2 in all related charts. Looking back how many frameworks came and went dodo, I am using only small libraries and stay with plain vanilla JS 5/6.

Writing modern JS is a peace of cake, it's better to understand 100% of the codebase than to use way too much magic APIs. (well I understand the whole computer, all layers, from hardware to operating system, to software - so there is no magic for me, that helps a lot)

Reply on news.ycombinator.com