2 ms·

> The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files. This is what I mean. Normally your chain would be:

by pluma 11y ago

> The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files. This is what I mean. Normally your chain would be: ES2015/JSX -(Babel)-> Node code -(Browserify/etc)-> Browser code With Webpack's "require" magic you end up with this: ES2015/JSX -(Babel)-> Intermediate code -(Webpack)-> Browser code & Node code This isn't necessarily wrong (you can make Webpack use Babel and thus merge the first two steps, I think) but right now it feels extremely wrong to me. I'm not yet convinced Webpack is a good idea either -- especially because the documentation is a sketchy mess at this point. Webpack (like browserify) was written to generate bundles for the browser, not modules for Node. I have been wrong in the past and would be willing to suspend my disbelief if I were able to find any reliable information on how you're supposed to use Webpack for Node, but right now my gut feeling tells me it's a really bad idea and the Node support is a hacky afterthought at best.

insin 11y ago
Have you read Backend Apps with Webpack? http://jlongster.com/Backend-Apps-with-Webpack--Part-I http://jlongster.com/Backend-Apps-with-Webpack--Part-I http://jlongster.com/Backend-Apps-with-Webpack--Part-II http://jlongster.com/Backend-Apps-with-Webpack--Part-II http://jlongster.com/Backend-Apps-with-Webpack--Part-III http://jlongster.com/Backend-Apps-with-Webpack--Part-III
- pluma 11y ago
  I've only just looked into it but Part I seems to confirm my suspicions: the defaults provided by Webpack aren't really geared for server-side code and it still generates a single bundle and you need a hacky addon (`source-map-support` on NPM) to get readable stack traces. Heck, the final configuration file is a convoluted mess and the steps taken to arrive there aren't entirely obvious: http://jlongster.com/Backend-Apps-with-Webpack--Part-I#p28 http://jlongster.com/Backend-Apps-with-Webpack--Part-I#p28 This is also the spectral opposite of what bundling with browserify looks like, which in my projects so far usually consisted of a single line using the CLI. Judging by that, Webpack is to browserify what Grunt is to `npm run` -- and IMO that's a bad thing.
  - Ambroos 11y ago
    I'm pretty sure webpack is tons more powerful than Browserify though. It's a very impressive piece of software, the way it handles code splitting and similar things is just incredibly well done.
skrebbel 11y ago
Ah, I see your point. That said, Webpack works great with Babel indeed, so in practice this becomes: cross-platform ES2015/JSX --(Babel+Webpack)--> Browser code & Node code The only thing, really, is to stop thinking of webpack as something that turns node code into browser code, but of something that turns general code into platform-specific code. I fully agree that this wasn't what webpack was originally designed for, but in practice there's nothing about webpack that makes this intrisically difficult. Personally, I just use DefinePlugin to define a boolean SERVER constant. It's set to true on the node build and to false on the browser build, and then in my code there's just some stuff like this: if(SERVER) { // node-only code } For the browser build, Webpack turns that into this: if (false) { // node-only code } And then UglifyJS removes it entirely. React uses the same trick to differentiate between production and dev builds, so in practice most React+webpack users will already be doing something like this so it's not a complex step to add. I manage the difference between test/dev/production builds in the same way, haven't yet found a downside.
- pluma 11y ago
  FWIW, the React app I would be using Webpack for (currently using Browserify and Babel) doesn't actually do any server/browser checks, the entire difference is handled via two different entry points and a few module swaps for browserify in my package.json file.

by pluma 11y ago

insin 11y ago

Have you read Backend Apps with Webpack? http://jlongster.com/Backend-Apps-with-Webpack--Part-I http://jlongster.com/Backend-Apps-with-Webpack--Part-I http://jlongster.com/Backend-Apps-with-Webpack--Part-II http://jlongster.com/Backend-Apps-with-Webpack--Part-II http://jlongster.com/Backend-Apps-with-Webpack--Part-III http://jlongster.com/Backend-Apps-with-Webpack--Part-III

pluma 11y ago
I've only just looked into it but Part I seems to confirm my suspicions: the defaults provided by Webpack aren't really geared for server-side code and it still generates a single bundle and you need a hacky addon (`source-map-support` on NPM) to get readable stack traces. Heck, the final configuration file is a convoluted mess and the steps taken to arrive there aren't entirely obvious: http://jlongster.com/Backend-Apps-with-Webpack--Part-I#p28 http://jlongster.com/Backend-Apps-with-Webpack--Part-I#p28 This is also the spectral opposite of what bundling with browserify looks like, which in my projects so far usually consisted of a single line using the CLI. Judging by that, Webpack is to browserify what Grunt is to `npm run` -- and IMO that's a bad thing.
- Ambroos 11y ago
  I'm pretty sure webpack is tons more powerful than Browserify though. It's a very impressive piece of software, the way it handles code splitting and similar things is just incredibly well done.

skrebbel 11y ago

Ah, I see your point. That said, Webpack works great with Babel indeed, so in practice this becomes: cross-platform ES2015/JSX --(Babel+Webpack)--> Browser code & Node code The only thing, really, is to stop thinking of webpack as something that turns node code into browser code, but of something that turns general code into platform-specific code. I fully agree that this wasn't what webpack was originally designed for, but in practice there's nothing about webpack that makes this intrisically difficult. Personally, I just use DefinePlugin to define a boolean SERVER constant. It's set to true on the node build and to false on the browser build, and then in my code there's just some stuff like this: if(SERVER) { // node-only code } For the browser build, Webpack turns that into this: if (false) { // node-only code } And then UglifyJS removes it entirely. React uses the same trick to differentiate between production and dev builds, so in practice most React+webpack users will already be doing something like this so it's not a complex step to add. I manage the difference between test/dev/production builds in the same way, haven't yet found a downside.

pluma 11y ago
FWIW, the React app I would be using Webpack for (currently using Browserify and Babel) doesn't actually do any server/browser checks, the entire difference is handled via two different entry points and a few module swaps for browserify in my package.json file.