Just wondering, is there a reason why Ember CLI uses LiveReload instead of BrowserSync? I’m missing BrowserSync’s scroll and other interaction synchronization, which are invaluable when creating responsive web sites.
I had a similar thought about CSS-only updates. It doesn’t make sense to rebuild and reload everything every time you update a CSS file. Why not just send an updated CSS files to the browser and replace those. It would allow for some truly fast and fluid development. I’m using Brackets.io editor whenever I turn my mock-ups into HTML/CSS and it works like magic, updating DOM and styling as you type.
Open a [FEATURE] request and suggest a PR (have one ready). I don’t particularly think there’s a reason they are tied to liveReload and it hangs so often that deactivating or swapping out liveReload is one of the first things I do now depending on project.
I’ll see what I can do - it may be that this is a bit of a tall order for me given the time I have in my hands, I still consider myself as a newbie to “serious” JS programming, for instance. And know nothing of Broccoli. But at least this should be a learning expreience.
Edit: if anybody can give me a quick list of high-level steps that should be done to create a PR for the swap (to somebody who has never touched or read the Ember / Ember CLI codebase), that would be very helpful.
Once issue #1 is resolved, it’ll be published to npm.