3 ms·

This sounds great, but the obvious problem with Webpack & co seems that they are entirely useless for isomorphic code. There's just no way to make require work

• skrebbel 11y ago
  This is just plain untrue. The trick is simply to make Webpack generate a special build for Node.js that doesn't access the DOM. With oldschool webpack style-loader, all you need is the well documented & supported ExtractTextPlugin to save the .css to a separate file, and there's nothing left for node to choke on. I'm not sure whether the same works as easily for the OP's idea though, but at a first glance I don't see why not. The only real disadvantage is that you're feeding Node webpack-generated code, and not vanilla JS files. I've yet to find the real big problem with this, though, other than a slightly slower save-build-reload cycle.
  • 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.
• pygy_ 11y ago
  I'm working on a preprocessor that addresses that issue. It consumes JS objects/arrays and spews out CSS with localized class and animation names and a unmangled -> mangled dictionary. http://j2c.py.gy http://j2c.py.gy The stylesheet can be inserted in the VDOM, very easily in modern browsers (IE9+). The isomorphic scenario is more involved when IE8- support is required because you can't just have `<stlye>{styles}</style>` work out of the box on the client, you must access the DOM element and set its `.styleSheet.cssText` property.
• madeofpalk 11y ago
  Yahoo's Flexible yo generator creates an isomorphic application using web pack. https://github.com/yahoo/generator-fluxible https://github.com/yahoo/generator-fluxible I'm not sure of the details or how it manages to make it work server side (if it does at all), but they do use Webpack for /something/ in an isomorphic app.
• pornel 11y ago
  I use Webpack for isomorphic code. The trick is to hook up loaders in node via: require.extensions['.css'] = loaderFunction
  • pluma 11y ago
    I thought require hooks were deprecated (although they are likely to stick around for a while because legacy support)?