2 ms·
yep, the point though is that having a build step during dev adds some overhead (which can easily go into the several seconds range in my experience) into the t
by lhorie 12y ago
yep, the point though is that having a build step during dev adds some overhead (which can easily go into the several seconds range in my experience) into the type-save-reload cycle, which is exacerbated by hit-reload-before-build-finished-so-need-to-reload-again pattern.
My understanding is that this tool removes that entire class of annoyances, and gives a no-hassle live-reload ES6-enabled environment on top.
- williamcotton 12y agoSubstack's essay applies as much to this tool as it does to webpack: https://gist.github.com/substack/68f8d502be42d5cd4942 https://gist.github.com/substack/68f8d502be42d5cd4942 Importantly, overloading require like this: var collections = require('npm:lodash-node/modern/collections'); var $ = require('github:components/jquery'); ... means that you can't publish this module to npm and have the require statements work as expected.
- mattdesl 12y agoThe build step is mitigated by incremental reloading, and the incremental reloading can be tied to a live-reload event. So you end up with the same workflow as shown in this video; but most likely faster for many modules (browser requests 1 JS file rather than potentially hundreds) and also more realistic for production (aside from minification, the dev environment is the exact same as the production environment).