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.

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.

Have you read Backend Apps with Webpack?

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

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

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.

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.