Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back End Apps with Webpack: Part I

jlongster.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Back End Apps with Webpack: Part I

#31

Post by jlongster »

latchkey wrote: post #23
jlongster wrote: post #16

Earlier quoted context omitted.

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.

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 ide…

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.

Re: Back End Apps with Webpack: Part I

#32

Post by jlongster »

woah wrote: post #25
jlongster wrote: post #5

Earlier quoted context omitted.

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 fil…

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?

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.

Re: Back End Apps with Webpack: Part I

#33

Post by jlongster »

_greim_ wrote: post #30

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

That's exactly right.

Re: Back End Apps with Webpack: Part I

#34

Post by grayrest »

_greim_ wrote: post #30

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

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.

Re: Back End Apps with Webpack: Part I

#36

Post by lettertwo »

woah wrote: post #25
jlongster wrote: post #5

Earlier quoted context omitted.

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 fil…

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?

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

Re: Back End Apps with Webpack: Part I

#37

Post by [deleted] »

jlongster wrote: post #5
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 fil…

[deleted]
Post reply on HN