Back End Apps with Webpack: Part I • Hacker News Board

Re: Back End Apps with Webpack: Part I

#21

Post by jlongster » Mon, Mar 16, 2015, 6:26 PM UTC

TheAceOfHearts wrote: post #19

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?

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!

Re: Back End Apps with Webpack: Part I

#22

Post by jlongster » Mon, Mar 16, 2015, 6:26 PM UTC

pichalsi wrote: post #18

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

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.

Re: Back End Apps with Webpack: Part I

#23

Post by latchkey » Mon, Mar 16, 2015, 6:31 PM UTC

jlongster wrote: post #16

latchkey wrote: post #15

Earlier quoted context omitted.

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.

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 ideal build system. Something that includes hot code swapping and even more importantly, unit testing.

Re: Back End Apps with Webpack: Part I

#24

Post by latchkey » Mon, Mar 16, 2015, 6:32 PM UTC

dmnd wrote: post #20

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…

> Webpack is pretty nice, but it feels so 2014. posted March 16, 2015.

I'm glad you get the joke. =)

Re: Back End Apps with Webpack: Part I

#25

Post by woah » Mon, Mar 16, 2015, 6:35 PM UTC

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…

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?

Re: Back End Apps with Webpack: Part I

#26

Post by dmnd » Mon, Mar 16, 2015, 6:36 PM UTC

latchkey wrote: post #24

dmnd wrote: post #20

Earlier quoted context omitted.

> Webpack is pretty nice, but it feels so 2014. posted March 16, 2015.

I'm glad you get the joke. =)

Hah, this was definitely a case of Poe's law for me.

Re: Back End Apps with Webpack: Part I

#27

Post by pichalsi » Mon, Mar 16, 2015, 6:40 PM UTC

jlongster wrote: post #22

pichalsi wrote: post #18

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

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.

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

Re: Back End Apps with Webpack: Part I

#28

Post by _greim_ » Mon, Mar 16, 2015, 6:42 PM UTC

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?

Re: Back End Apps with Webpack: Part I

#29

Post by TheAceOfHearts » Mon, Mar 16, 2015, 6:47 PM UTC

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'm currently setting up something similar to this. It's an app that does server-side rendering. It has the server-side code, the shared rendering code, and the client-side code.

Webpack solves a LOT of problems with application development. Handling assets properly is very difficult, and webpack makes it straightforward.

Build systems are complicated, I'd love to see something that handles the same problems as webpack but somehow manages to avoid the required configuration.

Re: Back End Apps with Webpack: Part I

#30

Post by _greim_ » Mon, Mar 16, 2015, 6:50 PM UTC

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