The Wonderful World of Webpack | Hacker News Reader

The Wonderful World of Webpack

jackhiston.com

79 pointsCyph3r9040 comments

I think Webpack solves a real problem in the web world, but holy cow is it a pain to configure in large applications. Anyone who has had to maintain a larger (and often dynamic) Webpack configuration knows what I am talking about.

I think Webpack is a step in the correct direction, but web bundlers are still in need of improving.

I agree with it being hard to configure. But I think they have come a long way with documentation, and this eases the pain a bit.

True. Several times I have resorted to putting random console.log's into the webpack core and it's plugins as the only way to figure out why the configuration doesn't work.

You can also run your build in chrome canary and step through in the debugger: https://medium.com/webpack/webpack-bits-learn-and-debug-webp...

I've found Rollup easier to configure, fwiw. Ymmv.

Having just tried roll up, it makes a number of assumptions about your code. I couldn't get React 15.x to bundle correctly with my code at the end and switched to webpack.

> I think Webpack solves a real problem in the web world, but holy cow is it a pain to configure in large applications. Anyone who has had to maintain a larger (and often dynamic) Webpack configuration knows what I am talking about.

Maybe I was doing it wrong but for a previous project I was using SystemJS for module loading + bundling and Gulp for SASS + TypeScript compilation and livereload. I've replaced all of this with a much simpler (before I had too many differences between development and production builds) Webpack configuration that does everything. Setting up both configurations drove me up the wall with the usual array of "module not found" and "file not found" problems you have to persist with but the Webpack setup feels more robust now that it's working.

Probably not an easy problem, but it would be amazing if build tools by default gave you a lot of help with debugging errors e.g. "module a/b/c not found, did you mean ../a/b/c?".

I think an interesting reflection when considering the config setup difficulties of Webpack are the so-called 'zero-config' projects like;

https://github.com/insin/nwb

https://github.com/saguijs/sagui

https://github.com/mozilla-neutrino/neutrino-dev

https://github.com/facebookincubator/create-react-app

They help frame this domain's perspective on the timeless tension between usability and flexibility - ie am I prepared to sacrifice some configuration options in return for being able to get quickly setup?

Clearly the answer in a lot of cases is going to be 'no', but nevertheless seeing how difficult it can be to find that sweet spot between usability and flexibility might help one better appreciate the value returned by those difficulties.

Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.

> am I prepared to sacrifice some configuration options in return for being able to get quickly setup?

The best part about create-react-app is the `eject` option. So you never have to ask that question. You can just get going with the defaults, then 'eject' your config files to tweak once you uncover your specific needs.

I am convinced this 'no lock-in' approach is the way to go for scaffolding builders and frameworks in general.

> The best part about create-react-app is the `eject` option

Best part or necessary evil? I'm glad it exists, but ultimately you lose a lot of the benefits of create-react-app (seamless updates to react-scripts, e.g. the move from Webpack 1 to 2) as soon as you eject, which is why it is somewhat discouraged, and why some people have built projects that allow you more config overrides without ejecting.

Webpack (or any other build tool, really) is complex because people's needs are complex.

You don't really need to spend too much time configuring Webpack if you're just trying to bundle a bunch of JS files together. I.e, if you don't need the fancy loaders and plugins and just want an optimized JS bundle, the instructions on this page are all you need: https://webpack.js.org/api/cli/ (see section titled "Usage Without Config File")

But of course, you don't want just that. You want support for ES6, JSX, bundling and optimizing CSS, autoprefixing, bundle splitting, building SVG sprite sheets, etc. etc. At that point you just have to deal with the complexity.

> Personally, I've found the commitment to stick to the conventions enforced by Create React App to have been largely beneficial (at least so far (in one project)). And I've been surprised how willing and able I am to creatively work within those limitations.

I feel the same way. I no longer configure my build system from scratch. I try to work with create-react-app's defaults for as long as possible, and eject if I can't coax it into doing something I need. It's no different from letting XCode or Visual Studio autogenerate a project for you and customizing it as you go along.

At the end of the day, I'd rather write code than configure build systems. But sadly, they're a necessary evil no matter what tech stack you work with. I personally feel that it's not worth spending time learning them deeply, but I'm prepared to pull up that Webpack manual one day because I know I'm definitely going to need it at some point.

I used Brunch for my last project after I gave up configuring Webpack. It just worked and did what I wanted.

http://brunch.io

I had a hard time starting with webpack. Because it's so flexible, there are so many choices.

That's why I made a boiler plate project with React SSR, TypeScript, and Webpack

https://github.com/styfle/react-server-example-tsx

I had the same problem -- after throwing together a few open source front-end libraries, and struggling with each to get webpack, babel, karma, flow, etc. all working seamlessly together, I put together https://github.com/krakenjs/grumbler and now just fork this every time I want to start something new.

Being able to just start writing code without spending forever setting up the perfect environment is hugely liberating. I'd encourage everyone to find good boilerplates for what they want to do (or put together their own if nothing else fits)

in case its helpful to anyone, i was frustrated with this same thing too so i made a webapp to help with the boilerplate search. It also measures the "cognitive load" of a boilerplate to add some sort of cost function.

Here are the two boilerplates mentioned:

https://packagejason.herokuapp.com/krakenjs/grumbler

https://packagejason.herokuapp.com/styfle/react-server-examp...

and you can search others to your fancy.

I could've sworn you guys were joking but you're all serious. This is utter madness!

How much time do we now need to spend trying to choose a boilerplate?

No, now that time is being used to choose a boilerplate comparison webapp.

lol piss taking in its highest form

I dealt with some Webpack issues at my last job, and for my current job, which started around the time that Rollup was becoming popular, I decided to try Rollup. Even though it happened to have some bugs (which I've reported and they were fixed) it seemed to be a lot better than my Webpack experience, partly because it didn't try to do too much and I had more freedom to do what I wanted. Of course the project I'm working on isn't terribly complex, so I don't need a ton of specific configurations, but it does use React and I felt working with Rollup was a bit easier than Webpack when concerning React, especially when talking about speed; I absolutely hated working with Webpack because I didn't want to wait 1.5-2 minutes just to start working, and have to wait 10 seconds each time I save a file. The only thing I hated more was the attitude from some coworkers that my computer was too slow rather than the tool being bad.

Webpack just makes me so sad. It is slow, arbitrary, inconsistent and unstable. Just like gulp and grunt. I seek a proper, fast, consistent, dependency driven JavaScript build tool. Won't somebody share their make rules for .js?

I work on ~1000 lines of GNU make for a front-end build pipeline with dozens of projects with 600 kLOC TypeScript, 400 kLOC JavaScript, 80 kLOC LESS, and a variety of other things (formatting, i18n, Closure Compiler, Angular AOT, etc).

Make is truly a timeless tool. Parallel, incremental, and declarative; it's a well architected tool based on correct principles. Everything else -- Ant, Maven, Grunt, Gulp -- are diappointments by comparison. Unfortunately, however, make wasn't made to compose well; you'll rarely see people (including me) publishing and re-using rules.

If you want a general-purpose composable non-sucky build tool, check out Google Bazel (in beta): https://bazel.build/

Blog post from Google Angular engineer, including thoughts on make and Bazel for front-end builds: https://medium.com/@Jakeherringbone/building-angular-apps-at...

> Unfortunately, however, make wasn't made to compose well; you'll rarely see people (including me) publishing and re-using rules

I'm not saying Gulp, Grunt or Webpack will suit your needs but I find Makefiles quickly become very unreadable and hard to debug. Its syntax for loops, conditions and arithmetic is awkward and hard to remember and the behaviour of variables is confusing. At least with the others the syntax is decent and there's tons of plugins for common tasks.

Why would Gulp for example not suit your use case?

> Unfortunately, however, make wasn't made to compose well

PMake (aka BSD Make) is actually fairly good in this regard- allowing for include libraries (so long as namespaces don't collide). Unfortunately it is not so well known...

A lot of comments in this thread about struggles with setting up a config.

My intuition is that this is because we are using a declarative programming model: a config file, rather than code.

I don't really understand why we would use, say, Ruby to encode a web server, and then use JSON to encode the build process. We choose our programming languages very carefully for their ability to express powerful control structures, ease of maintenance, debuggability.... and then we use a brittle, underspecified language of flags, nested keys, and filesystem tests and side effects to program our build system... Why?

Can someone who believes in this declarative config build system explain why, in the abstract, it's a good fit for build processes, when we'd never choose a language like that for our actual codebase?

I'm influenced here by Jonathan Blow, who designed into Jai the ability to run arbitrary Jai code during the build process, for this exact reason.

I have an Angular 1.x app bundled with Webpack, which allows me some nice ES6 features. I especially like it for imports (which allows much better code completion than Angular's native Dependency Injection).

Configuring Webpack to do this was one of the hardest things I've ever done. :D

Anyone still using Google's Closure Compiler? How does it compare these days?

I am (work at Lucid Software: www.lucidchart.com www.lucidpress.com). We're using in conjunction with Closure Library, Clutz, Tsickle and Angular AOT template compilation to get great code sizes.

And Google has always been a heavy user of course.

Closure Compiler is preternaturally good at dead code removal, inlining, minification. But you have to use advanced optimization mode, and write JS amenable to its static analysis. If you're willing to put in that work, you'll get fantastic minification. If you're not, you should just find another tool.

Scala.js includes Closure Compiler adv optimizations right in the standard workflow, so it's a good bet any Scala.js project will be using it.

May not be the angle your asking for, but clojurescript relies on the Closure compiler.

Every time I start a new web project, I try to find ways to not have to use something like Webpack. I keep hoping the community has finally solved the problem in a more elegant way. The additional mental overhead of a dependency like this isn't worth it.

Sadly, I haven't found a way around the dependency yet.

Modules are now enabled by default in Chrome 60. Hopefully this will be a good first step in making things better.

Have you tried budo[1]? I am the author, so very obviously biased, but the tool has a small following among some creative developers since it’s really quick and easy to work with.

Most of my projects don’t need the scalability of Facebook or Instagram, so I can do without some of Webpacks more nuanced features. My entire dev/build/deploy cycle is just a couple npm scripts.[2]

1 - https://github.com/mattdesl/budo

2 - https://github.com/Jam3/360-image-viewer/blob/master/package...

Still much more a fan of sbt (and sbt-web for bundling just about anything on the web side).

Smaller, type-checked build files, even has a native packager plugin for building RPMs... really very nice.

> What if we could take C# code, and transpile it into JavaScript? What if we could take a YAML configuration file, and create a working program just out of configuration? What if we took an image, and automatically made it cropped and greyscaled?

What?! Image, crop and greyscale? That doesn't sound like a job for a bundler. Is this sarcasm?

Don't think so: see webpack as a builder if that makes more sense. People are using it in place of npm scripts or for example gulp.

Which really is an anti-pattern IMO - but seeing people repeat the same mistakes with new tools over and over is not new I guess - but it is extremely powerful.

It's a valid use case. Think of something like a thumbnail generator for a directory of images. If you include an image in your application, maybe you also want to be easily pull in a thumbnail for it on a different summary page in your app.

This sounds more like a build tool than a code "packing" tool...

In the context of webapps I'm not sure there's much of a distinction...

Take a look at how many crazy variations of a favicon image you need now to satisfy iOS/Android/Microsoft desires.

Reply on news.ycombinator.com