Winamp had live editing of the visualisations - you got immediate feedback. Web dev workflow is now very complicated - boiler plate, pre-processors, frameworks, iteration workflow, performance tuning, build, deploy. Where does our editor fit in?
The browser is our application runtime. We are building an experience that lives in the browser. Browsers used to be black boxes until we got the web developer toolbar in IE - we had a tool to see inside the internals. Firebug is the main reason people moved to Firefox, it was an amazing tool. We now have Chrome and Firefox dev tools, we have profilers and much more. However, we've just added new panels to dev tools - is this what we actually want? Compared to native app dev for example it's still lacking.
Our workflow hasn't really changed, we switch between our editor and our browser. This is what's broken. We've tried to fix this with more tools. These tools have added more complex workflows. We have prototyping tools like JsBin that have a live preview. DevTools are becoming our editor - they are like an IDE. Problem is that these dev tools are tied to a single browser. Are browser vendors in competition with editor vendors?
Our assumptions are wrong - we're not building pages using text editors, we are building apps in a runtime. We live in our editor and we all have different reasons to choose our editor and we're not likely to change this. However, there is a wall between our browser and our editor and our tools go round the wall - not through it.
Keep the editors as editors. We need to integrate our runtimes with our editors, when we make a change in our editor it should change in the browser automagically. Deep integration between editors and browsers is the key to a better web.
Emmet LiveStyle is a plugin for Sublime that enables two way communication with a browser. MS BrowserLink is another tool. However, we are inventing propitiatory protocols for these. We need to leverage the built in remote debugging protocols but they all use their own protocols. As a community we could unify this: remotedebug.org
RemoteDebug is a middleware between the browsers and a common interface for third party APIs. Based on Chrome debugging tools as it's documented and there are already things using this interface.
The open web follows standards but our tools don't follow standards - they should. We have an opportunity to unify these, we need to work together as a community.