<i>>For example, hot module replacement allows you to change a module and update the existing instance live. This is the juice within react-hot-loader and this is the kind of stuff we need to be building. You'll never look back after experiencing this.</i><p>I second this. (Disclaimer: I wrote React Hot Loader.)<p>Webpack's live reloading system is not browser-specific, does not depend on attaching debuggers or doing anything else invasive.<p>All it does is represent module cache as (id) -> (function) map and give you the tools to “handle” module updates, as if modules were Observables and you subscribed to “new versions” of them. If update is unhandled, it bubbles.<p>This is what allows Hot Module Replacement to work for React components, CSS and Markdown files, and even classes on backend.
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:<p><pre><code> * 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.
</code></pre>
Anything else?
I don't know why the title was changed to "back end", that's the worst way to say it. If you don't like "backend", at least use "back-end".
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.
I'm also trying to wrap my brain around what webpack <i>is</i>, 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.<p>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)?
I've been playing with this a for a few months now. Thanks to webpack / react starter (<a href="https://github.com/webpack/react-starter" rel="nofollow">https://github.com/webpack/react-starter</a>), you get that for free (with server-side rendering of your apps).<p>What I'd like to see is for webpack to add features from Pants like self-bootstrapping executables (PEX) or run tests based on which part of the code was affected by a commit. For the executable part, I guess Docker kind of solve that issue. See <a href="http://pantsbuild.github.io/" rel="nofollow">http://pantsbuild.github.io/</a> for more info<p>To be continued :)
Webpack is pretty nice, but it feels so 2014.<p>In 2015, we have ES6 modules now. Instead of define/require, we have import/export and it is standards based now, which is nice.<p>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 matter where you grab your dependencies from (npm/github/bower/etc).<p>I agree with the authors comment about gulpfiles being hacky and not very DRY (don't repeat yourself). That said, his examples felt very hacked together as well, there is too much programming in there. Do I copy that build file across every new project I create?<p>gulpfiles are great because they provide extra functionality that is missing, like only re-transpiling files that change. For large projects this can really be a time saver. webpack has that by running a separate server process, complicated! Projects like gulp-helpers [3] try to bring a tiny bit of sanity and re-usability to gulpfiles by making things a bit more DRY and configuration based. It is just an example of one way to do things, but hopefully you see my point.<p>[1] <a href="https://github.com/systemjs/systemjs" rel="nofollow">https://github.com/systemjs/systemjs</a>
[2] <a href="http://jspm.io/" rel="nofollow">http://jspm.io/</a>
[3] <a href="https://github.com/lookfirst/gulp-helpers" rel="nofollow">https://github.com/lookfirst/gulp-helpers</a>
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?<p>I use the following regexp: /^[a-z\-0-9]+$/<p>Any reason to get the full module list over just using this regexp?