
Back End Apps with Webpack: Part I - jlongster
http://jlongster.com/Backend-Apps-with-Webpack--Part-I
======
danabramov
_> 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.

------
_greim_
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?

------
jlongster
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
back end == node/io.js ?

~~~
jlongster
Yes!

------
coderzach
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
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
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
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).

------
_greim_
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)?

~~~
grayrest
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.

------
juliennakache
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
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)

~~~
jlongster
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...

~~~
latchkey
I know your blog post is only part 1, but your example doesn't show hot module
reloading. Adding that will complicate your build file even more.

~~~
jlongster
I don't know what you are complaining about. Build systems are complex. These
config files are relatively straight-forward. You tell it where to start,
where to output, to use sourcemaps, and give it a few plugins. It can't get
much simpler.

For hot module replacement, sure, it gets a little more complex. You add
another plugin and another entry point, that's all.

~~~
latchkey
You're sounding really defensive. I find it entertaining that in one sentence
you say 'Build systems are complex' and in another 'It can't get much
simpler.'

I disagree that build systems need to be complex. They get complex because
people try to invent too many different ways of doing things instead of
working towards standards. webpack is a prime example of that.

I'd love to see a full demo seed example of your ideal build system. Something
that includes hot code swapping and even more importantly, unit testing.

~~~
jlongster
I don't feel defensive, honestly build systems are boring to me so I'm not
that passionate about it. What I meant was that its simple relative to what it
could be.

Yes, build systems are complex, because people need features, even if you
personally don't need them. Webpack doesn't offer many ways to do the same
thing; it just simply has a lot of features. Whenever we get enough tooling
around ES6 modules to match it (or come close), I'll gladly switch.

You'll see a fuller example later. I'd love to see a matching set up using
systemjs/jspm. You could convince me to switch.

------
TheAceOfHearts
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
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!

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

Same as '.bin' === x?

~~~
jlongster
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
oh right... I thought I will learn something new :)

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

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

