4 ms·

I guess I'd like to know more about the benefits of this approach. Packaging up a single js file seems unnecessary when you're running on the server.

jlongster 12y ago
Fair question. This post is targeted to people who love webpack on the frontend but don't use it on the backend, and I don't really explain the benefits of webpack in general. Packaging all files into a single one is a side effect that we don't really care about. If you want to build your app with babeljs, you need to compile all your backend files. Who cares what the output is, if it's multiple files or a single file? As long as it's semantically the same (meaning even __dirname and friends work appropriately), it doesn't matter. But what you get is really powerful build system (much better than hacking one together with gulp). Just look how small my config is, and now you can add babel as a loader for JS files and it just works. And you get to use the exact same infrastructure for the frontend.
- woah 12y ago
  So the purpose here is to make it easier to use preprocessors on the backend? Hasn't this been common for a long time? What does webpack do here exactly?
  - jlongster 12y ago
    A good solution hasn't been common. Try to use babel with gulp. You have to just glob a bunch of files and hope you've covered all your dependencies. It becomes a mess once you get into more complicated stuff. Webpack also handles sourcemaps flawlessly, and you get tons of other stuff like http://webpack.github.io/docs/hot-module-replacement.html http://webpack.github.io/docs/hot-module-replacement.html.
  - lettertwo 12y ago
    In my experience, this approach really shines when you are building an "isomorphic" app. When the same code is expected to run in the browser and on the server, having a build tool that knows about both your entire dependency graph and your different build targets is a huge boon. For example, you get hashed filenames (for far-future cache expiration in the browser) for free (no manifests or runtime reconciliation of names to assets necessary).
- deleted 12y ago
  [deleted]

jlongster 12y ago

Fair question. This post is targeted to people who love webpack on the frontend but don't use it on the backend, and I don't really explain the benefits of webpack in general. Packaging all files into a single one is a side effect that we don't really care about. If you want to build your app with babeljs, you need to compile all your backend files. Who cares what the output is, if it's multiple files or a single file? As long as it's semantically the same (meaning even __dirname and friends work appropriately), it doesn't matter. But what you get is really powerful build system (much better than hacking one together with gulp). Just look how small my config is, and now you can add babel as a loader for JS files and it just works. And you get to use the exact same infrastructure for the frontend.

woah 12y ago
So the purpose here is to make it easier to use preprocessors on the backend? Hasn't this been common for a long time? What does webpack do here exactly?
- jlongster 12y ago
  A good solution hasn't been common. Try to use babel with gulp. You have to just glob a bunch of files and hope you've covered all your dependencies. It becomes a mess once you get into more complicated stuff. Webpack also handles sourcemaps flawlessly, and you get tons of other stuff like http://webpack.github.io/docs/hot-module-replacement.html http://webpack.github.io/docs/hot-module-replacement.html.
- lettertwo 12y ago
  In my experience, this approach really shines when you are building an "isomorphic" app. When the same code is expected to run in the browser and on the server, having a build tool that knows about both your entire dependency graph and your different build targets is a huge boon. For example, you get hashed filenames (for far-future cache expiration in the browser) for free (no manifests or runtime reconciliation of names to assets necessary).
deleted 12y ago
[deleted]