Question: Is it possible to use hot reloading with this server?

[aindlq]

Hot reloading can be very useful, especially when working on styling. Is it possible to have hot-reloading with express-systemjs-translate?

[Munter]

My understanding of hot-reloading with systemjs is very limited, so I'm not entirely sure how the interplay between these two will work.

I assume hot-reloading has some independent watcher and a websocket communicating updates to the client, which then purges the outdated files from the cache, requests them again and reinstantiates things through some magic.

systemjs-translate will still work for such a setup, although there might be more work executed than is needed. Since any request by SystemJS will always be bundled with the entire subtree of dependencies, the work needed to bundle, send and parse the payload is bigger than needed if only a single file was updated.

If there is any way to differentiate if a request is initiated by a hot-reloader, say a GET header or similar, then this middleware could switch on that condition and just pass through the raw files. Otherwise I'm not entirely sure how to optimise for this special case.

Any ideas @papandreou @guybedford @capaj ?

[guybedford]

At the moment, jspm bundle x -iw combined with a hot reloading server should work. In theory this project helps with the pre-population of the SystemJS loader registry in the browser, in a way that is completely compatible with hot-reloading.

The hot reloading scenario for a single file change though is different to the way this server behaves, so we'd need some way of knowing in this server that the requesting client already has a primed browser cache, and pushing the dependency tree is not necessary.

There's a few ways of going about this. One option would be to have a stateful server that actually keeps track of all the modules the browser client has requested, and then in hot-reloading cases knows which parts of the dependency tree to send. The above would need to be combined with a websocket approach in order to detect when the browser session starts and ends and maintain the information channel for the hot reloading signal.

[Munter]

So it's more of an optimization thing. Only send what's needed. It's hard to keep track of what the browser has though. A session cookie containing the hash of the latest loaded entry points? I'm not sure that would be helpful on a page reload though. Isn't that still considered the same session so the cookie would remain? What other mechanisms would we have available for the server to get back state from the browser without adding new headers to systemjs fetches?

[guybedford]

@Munter yes I guess a cookie would be the way to handle this. The cookie could be regenerated every time the page loads, to ensure it is page-specific. The code that does the hot reloading could handle this as well as establishing the websocket connection to get hot reload events. The cookie just needs to be a unique identifier, from there the server should be able to construct the state of the modules in the cache dynamically in a reliable way.

This sort of work does move towards jspm-server directions. It is a tough nut to crack though!