Back End Apps with Webpack: Part I

http://jlongster.com/Backend-Apps-with-Webpack--Part-I

by jlongster • 11 years ago

67 34 11 years ago

jlongster10• 11 years 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• 11 years ago

back end == node/io.js ?

jlongster10• 11 years ago

Yes!

coderzach• 11 years 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.

jlongster10• 11 years 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• 11 years 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?

danabramov• 11 years 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• 11 years ago

I've been playing with this a for a few months now. Thanks to 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/ for more info

To be continued :)

latchkey5• 11 years 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 [2] http://jspm.io/ [3] https://github.com/lookfirst/gulp-helpers

untog• 11 years 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?

latchkey5• 11 years ago

Yup, babel does it too. 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.

jlongster10• 11 years 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...

Touche• 11 years ago

The infrastructure is the important piece, not the module syntax.

That's what makes SystemJS appealing; the infrastructure is the ES6 (now WhatWG) Loader Specification; a spec that browsers will be implementing. So you don't have to worry about learning yet-another-module-loader like you do when jumping from requirejs -> browserify -> webpack -> whatever's next trends.

latchkey5• 11 years ago

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.

dmnd2• 11 years ago

Webpack is pretty nice, but it feels so 2014.

posted March 16, 2015.

latchkey5• 11 years ago

I'm glad you get the joke. =)

liviu• 11 years ago

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

pichalsi2• 11 years ago

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

Same as '.bin' === x?

jlongster10• 11 years 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.

pichalsi2• 11 years ago

oh right... I thought I will learn something new :)

TheAceOfHearts2• 11 years 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?

jlongster10• 11 years 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_2• 11 years 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_2• 11 years 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)?

jlongster10• 11 years ago

That's exactly right.

grayrest• 11 years 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• 11 years ago

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

Back End Apps with Webpack: Part I

Related Stories