Currently amber don't support reloading front-end changes out-the-box
We need to execute amber watch and then in other terminal npm run watch. However, only reload back-end changes, we still needs hit reload button in the browser.
Two alternatives:
webpack-dev-server by default, using port forwarding and handling both, back-end and front-end using Amber::Tasks for watching changes.Advantages: Use webpack, used by front-end developers, no changes in workflow.
Disadvantages: Bind Amber to webpack ignoring other technologies (rollup, browserify,brunch, etc), also need to download even more npm depencencies 100MB+
Advantages: Don't requires new npm dependencies, and uses amber framework capabilities.
Disadvantages: Hard to implement ? without modifying websocket pipeline
shards install and npm installamber watchnpm run watchExpected behavior: Browser is reloaded automatically on changes
Actual behavior: Only backend is recompiled, browser still needs to hit reload button
Reproduces how often: 100%
100%

@amberframework/contributors WDYT?
@faustinoaq - It looks like you've already done most of the work.
For the socket pipeline, I think it'll just take a macro and checking the environment that you are in "development" - and conditionally add the correct pipeline, etc. when needed.
At first glance, I vote for option 2.
anything that simplifies the development cycle is a win in my book
@faustinoaq I think you should go ahead and implement this with Amber Tasks. We can later cleanup the console log output.
@eliasjpr Yeah, I will make a PR on next weeks 馃憤
Client reloading without npm dependencies: https://github.com/tapio/live-server/blob/master/injected.html
Proposed flag:
amber watch --hot-reload
If the command is clever enough to not blow up when assets don鈥檛 exist, just make it the default?
See #457
馃憤