Back End Apps with Webpack: Part I

#1

Post by jlongster » Mon, Mar 16, 2015, 3:45 PM UTC

Back End Apps with Webpack: Part I
jlongster.com

Re: Back End Apps with Webpack: Part I

#2

Post by jlongster » Mon, Mar 16, 2015, 3:56 PM UTC

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".

Re: Back End Apps with Webpack: Part I

#3

Post by coderzach » Mon, Mar 16, 2015, 4:00 PM UTC

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.

Re: Back End Apps with Webpack: Part I

#4

Post by danabramov » Mon, Mar 16, 2015, 4:05 PM UTC

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

Re: Back End Apps with Webpack: Part I

#5

Post by jlongster » Mon, Mar 16, 2015, 4:15 PM UTC

coderzach wrote: post #3

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.

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.

Re: Back End Apps with Webpack: Part I

#6

Post by dominotw » Mon, Mar 16, 2015, 4:42 PM UTC

jlongster wrote: post #2

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".

back end == node/io.js ?

Re: Back End Apps with Webpack: Part I

#7

Post by jlongster » Mon, Mar 16, 2015, 4:45 PM UTC

dominotw wrote: post #6

jlongster wrote: post #2

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".

back end == node/io.js ?

Yes!

Re: Back End Apps with Webpack: Part I

#8

Post by juliennakache » Mon, Mar 16, 2015, 4:46 PM UTC

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

Re: Back End Apps with Webpack: Part I

#9

Post by latchkey » Mon, Mar 16, 2015, 4:52 PM UTC

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

Re: Back End Apps with Webpack: Part I

#10

Post by untog » Mon, Mar 16, 2015, 4:54 PM UTC

latchkey wrote: post #9

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…

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?