Concerning brackets’ “Live Preview” some input from a quite experienced (former) brackets user: At a first glance it’s great and it works great with “static” html, css and js.
But as soon you want to
- use custom CSS transforms like sass/less/stylus (Yes, there is experimental support for SASS and Autoprefixr, but it’s still buggy and you’re very limited)
- use custom JS-transforms (es6-transpilers like babel, coffeescript, typescript, jsx)
- basically ANY transformation using a task-runner (gulp, grunt, broccoli, webpack, rollup, …)
- have dynamic templates (any server-side application)
you will face its limitations.
The bottom line is, that editor plugins will probably never be able to catch up with the fast-pacing node-world, where great frontend development tools appear every week. And do developers really want to rely completely on some editor plugins (which therefore require EVERY developer in the team to have the same editor, the same plugins and the same settings).
IMO the way to go is to offer integrations for task runners to enable this live-editing feeling instead of trying to create editor-plugins for every nodejs-plugin. Task runners (compiling jsx, typescript, sass, etc. with custom logic) should do the job, the editor should only offer integrations to start these transformations (without requiring the user to save the file) or maybe send some additional information through the task-runner-chains into the browser (e.g. a css selector to highlight the element in the browser, where the cursor is currently in the editor. IMO atom should just try to enrich existing task-runner-chains instead of trying to replace them
Btw, Takana seems to some similar sort of integration.