[khalilravanna]

That's assuming you want all your scripts to be loaded on the front end asynchronously which seems to be only for development. For production I think you'd still want to compile this all down for a faster load time. From the jspm page: "For production, use the jspm CLI tool to download packages locally, lock down versions and build into a bundle." So I think you're correct that there'd be no build step for development but you'd still have some sort of script being run, whether it be gulp or otherwise, that builds it for production use.

[lhorie]

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]

Substack's essay applies as much to this tool as it does to webpack:

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]

The 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).

[agmcleod]

I think that's an okay compromise, especially if you typically have a CI process anyways.