7 ms·

Back End Apps with Webpack: Part I

67 points by jlongster 12y ago

jlongster 12y ago
I don't know why the title was changed to "back end", that's the worst way to say it. If you don't like "backend", at least use "back-end".
- dominotw 12y ago
  back end == node/io.js ?
  - jlongster 12y ago
    Yes!
liviu 12y ago
Webpack is awesome but I prefer gulp with babeljs and browserify.
coderzach 12y ago
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]
danabramov 12y ago
>For example, hot module replacement allows you to change a module and update the existing instance live. This is the juice within react-hot-loader and this is the kind of stuff we need to be building. You'll never look back after experiencing this. I second this. (Disclaimer: I wrote React Hot Loader.) Webpack's live reloading system is not browser-specific, does not depend on attaching debuggers or doing anything else invasive. All it does is represent module cache as (id) -> (function) map and give you the tools to “handle” module updates, as if modules were Observables and you subscribed to “new versions” of them. If update is unhandled, it bubbles. This is what allows Hot Module Replacement to work for React components, CSS and Markdown files, and even classes on backend.
juliennakache 12y ago
I've been playing with this a for a few months now. Thanks to webpack / react starter (https://github.com/webpack/react-starter https://github.com/webpack/react-starter), you get that for free (with server-side rendering of your apps). What I'd like to see is for webpack to add features from Pants like self-bootstrapping executables (PEX) or run tests based on which part of the code was affected by a commit. For the executable part, I guess Docker kind of solve that issue. See http://pantsbuild.github.io/ http://pantsbuild.github.io/ for more info To be continued :)
latchkey 12y ago
Webpack is pretty nice, but it feels so 2014. In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice. For systems that do not support ES6 syntax directly, this is provided today with tools like SystemJS [1] and jspm [2]. SystemJS is great because it supports all of the module formats for backwards compatibility. jspm is great because it doesn't matter where you grab your dependencies from (npm/github/bower/etc). I agree with the authors comment about gulpfiles being hacky and not very DRY (don't repeat yourself). That said, his examples felt very hacked together as well, there is too much programming in there. Do I copy that build file across every new project I create? gulpfiles are great because they provide extra functionality that is missing, like only re-transpiling files that change. For large projects this can really be a time saver. webpack has that by running a separate server process, complicated! Projects like gulp-helpers [3] try to bring a tiny bit of sanity and re-usability to gulpfiles by making things a bit more DRY and configuration based. It is just an example of one way to do things, but hopefully you see my point. [1] https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs [2] http://jspm.io/ http://jspm.io/ [3] https://github.com/lookfirst/gulp-helpers https://github.com/lookfirst/gulp-helpers
- untog 12y ago
  In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice. Wouldn't using something like Babel remove that issue?
  - latchkey 12y ago
    Yup, babel does it too. http://babeljs.io/docs/usage/modules/ http://babeljs.io/docs/usage/modules/ The problem is supporting dependencies. You need something that can load everything, which is the functionality that SystemJS provides.
- jlongster 12y ago
  The syntax for specifying dependencies is irrelevant -- webpack aims to support all of them, and as far as I know has experimental ES6 import/export support. I'm definitely going to transition to ES6 modules soon. The infrastructure is the important piece, not the module syntax. Webpack provides this infrastructure, and it's easy to provide it for ES6 modules as well. For example: how do I hot reload modules? How do I eval code inside a module? Webpack allows you to do all of this, and is more advanced than anything out there. SystemJS and jspm are nice but I still find webpack to support way more features. What do you mean "hacked together"? Look at how small my config is! Do you know how much you get from that small config? The only thing hacky is the `node_modules` hack, and as far as I know, you'd have to do something similar with anything else (I don't see anyone using SystemJS/jspm on the backend). Also, re-transpiling files that change? Just fire up the watcher (`webpack --watch`) and webpack automatically does this...
pichalsi 12y ago
OT: anyone can teach what this construct is useful for? ['.bin'].indexOf(x) === -1 Same as '.bin' === x?
- jlongster 12y ago
  Good point, I probably should just use that here, but in my project the array actually has a few more elements. I do this because there are a few modules I don't want to ignore for various reasons.
  - pichalsi 12y ago
    oh right... I thought I will learn something new :)
TheAceOfHearts 12y ago
I'm using webpack with iojs for an isomorphic react app, why don't you just add a regexp to ignore all non-relative modules? I use the following regexp: /^[a-z\-0-9]+$/ Any reason to get the full module list over just using this regexp?
- jlongster 12y ago
  It feels hackier, and there is a downside: you can't alias non-relative modules because they are simply ignored. I've run into situations where I needed to alias something in node_modules because we preprocessed it and put it somewhere else. But that works too!
_greim_ 12y ago
I'm trying to boil this down to an easily-digestable list of benefits for server-side development, since I'm completely unfamiliar with webpack. So far I have this: * Transpiles code that runs in node, not just code that runs in browsers. * Hot-reloads modules, so I don't have to restart my server a lot. * Does source maps, presumably which are exposed via tools like node-debug. Anything else?
_greim_ 12y ago
I'm also trying to wrap my brain around what webpack is, since I've been thus far conditioned to think of the build runner (e.g. gulp) and the bundle maker (e.g. browserify) as being separate. The article seems to be saying this, but am I correct to come away thinking of webpack as a "module-aware build runner" that replaces both gulp and browserify (for example)?
- jlongster 12y ago
  That's exactly right.
- grayrest 12y ago
  It's primarily a bundle maker a la browserify. The main difference is that it stretches the definition of module beyond just javascript. It can seem like a build system because you can set up rules to run a particular filter on a matching set of files. An example: run files ending with .sass through sassc. The difference is that webpack always starts at an entry point and only walks the dependency graph. If you want to include a sass file, you need to `require('foo.sass')` (without assigning it to anything) from your foo.js. It will then inline the resulting CSS into the single output bundle.js file and you'll have to split out the CSS with another plugin if you want it in a different file. If you're just using grunt/gulp to build assets then using webpack will save you effort/maintenance but if you also need to copy files around, ping servers, kick of CI, or some other side effect then you'll need some shell script or build runner in addition.
djfm 12y ago
Why would you want to combine JS files from the back-end?

67 points by jlongster 12y ago

I don't know why the title was changed to "back end", that's the worst way to say it. If you don't like "backend", at least use "back-end".

dominotw 12y ago
back end == node/io.js ?
- jlongster 12y ago
  Yes!

liviu 12y ago

Webpack is awesome but I prefer gulp with babeljs and browserify.

coderzach 12y ago

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]

danabramov 12y ago

>For example, hot module replacement allows you to change a module and update the existing instance live. This is the juice within react-hot-loader and this is the kind of stuff we need to be building. You'll never look back after experiencing this. I second this. (Disclaimer: I wrote React Hot Loader.) Webpack's live reloading system is not browser-specific, does not depend on attaching debuggers or doing anything else invasive. All it does is represent module cache as (id) -> (function) map and give you the tools to “handle” module updates, as if modules were Observables and you subscribed to “new versions” of them. If update is unhandled, it bubbles. This is what allows Hot Module Replacement to work for React components, CSS and Markdown files, and even classes on backend.

juliennakache 12y ago

I've been playing with this a for a few months now. Thanks to webpack / react starter (https://github.com/webpack/react-starter https://github.com/webpack/react-starter), you get that for free (with server-side rendering of your apps). What I'd like to see is for webpack to add features from Pants like self-bootstrapping executables (PEX) or run tests based on which part of the code was affected by a commit. For the executable part, I guess Docker kind of solve that issue. See http://pantsbuild.github.io/ http://pantsbuild.github.io/ for more info To be continued :)

latchkey 12y ago

Webpack is pretty nice, but it feels so 2014. In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice. For systems that do not support ES6 syntax directly, this is provided today with tools like SystemJS [1] and jspm [2]. SystemJS is great because it supports all of the module formats for backwards compatibility. jspm is great because it doesn't matter where you grab your dependencies from (npm/github/bower/etc). I agree with the authors comment about gulpfiles being hacky and not very DRY (don't repeat yourself). That said, his examples felt very hacked together as well, there is too much programming in there. Do I copy that build file across every new project I create? gulpfiles are great because they provide extra functionality that is missing, like only re-transpiling files that change. For large projects this can really be a time saver. webpack has that by running a separate server process, complicated! Projects like gulp-helpers [3] try to bring a tiny bit of sanity and re-usability to gulpfiles by making things a bit more DRY and configuration based. It is just an example of one way to do things, but hopefully you see my point. [1] https://github.com/systemjs/systemjs https://github.com/systemjs/systemjs [2] http://jspm.io/ http://jspm.io/ [3] https://github.com/lookfirst/gulp-helpers https://github.com/lookfirst/gulp-helpers

untog 12y ago
In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice. Wouldn't using something like Babel remove that issue?
- latchkey 12y ago
  Yup, babel does it too. http://babeljs.io/docs/usage/modules/ http://babeljs.io/docs/usage/modules/ The problem is supporting dependencies. You need something that can load everything, which is the functionality that SystemJS provides.
jlongster 12y ago
The syntax for specifying dependencies is irrelevant -- webpack aims to support all of them, and as far as I know has experimental ES6 import/export support. I'm definitely going to transition to ES6 modules soon. The infrastructure is the important piece, not the module syntax. Webpack provides this infrastructure, and it's easy to provide it for ES6 modules as well. For example: how do I hot reload modules? How do I eval code inside a module? Webpack allows you to do all of this, and is more advanced than anything out there. SystemJS and jspm are nice but I still find webpack to support way more features. What do you mean "hacked together"? Look at how small my config is! Do you know how much you get from that small config? The only thing hacky is the `node_modules` hack, and as far as I know, you'd have to do something similar with anything else (I don't see anyone using SystemJS/jspm on the backend). Also, re-transpiling files that change? Just fire up the watcher (`webpack --watch`) and webpack automatically does this...

pichalsi 12y ago

OT: anyone can teach what this construct is useful for? ['.bin'].indexOf(x) === -1 Same as '.bin' === x?

jlongster 12y ago
Good point, I probably should just use that here, but in my project the array actually has a few more elements. I do this because there are a few modules I don't want to ignore for various reasons.
- pichalsi 12y ago
  oh right... I thought I will learn something new :)

TheAceOfHearts 12y ago

I'm using webpack with iojs for an isomorphic react app, why don't you just add a regexp to ignore all non-relative modules? I use the following regexp: /^[a-z\-0-9]+$/ Any reason to get the full module list over just using this regexp?

jlongster 12y ago
It feels hackier, and there is a downside: you can't alias non-relative modules because they are simply ignored. I've run into situations where I needed to alias something in node_modules because we preprocessed it and put it somewhere else. But that works too!

_greim_ 12y ago

I'm trying to boil this down to an easily-digestable list of benefits for server-side development, since I'm completely unfamiliar with webpack. So far I have this: * Transpiles code that runs in node, not just code that runs in browsers. * Hot-reloads modules, so I don't have to restart my server a lot. * Does source maps, presumably which are exposed via tools like node-debug. Anything else?

_greim_ 12y ago

I'm also trying to wrap my brain around what webpack is, since I've been thus far conditioned to think of the build runner (e.g. gulp) and the bundle maker (e.g. browserify) as being separate. The article seems to be saying this, but am I correct to come away thinking of webpack as a "module-aware build runner" that replaces both gulp and browserify (for example)?

jlongster 12y ago
That's exactly right.
grayrest 12y ago
It's primarily a bundle maker a la browserify. The main difference is that it stretches the definition of module beyond just javascript. It can seem like a build system because you can set up rules to run a particular filter on a matching set of files. An example: run files ending with .sass through sassc. The difference is that webpack always starts at an entry point and only walks the dependency graph. If you want to include a sass file, you need to `require('foo.sass')` (without assigning it to anything) from your foo.js. It will then inline the resulting CSS into the single output bundle.js file and you'll have to split out the CSS with another plugin if you want it in a different file. If you're just using grunt/gulp to build assets then using webpack will save you effort/maintenance but if you also need to copy files around, ping servers, kick of CI, or some other side effect then you'll need some shell script or build runner in addition.

djfm 12y ago

Why would you want to combine JS files from the back-end?