Mozilla guys: if you implement this--even partially--I'll switch back to Firefox in a heartbeat.
I've spent some time thinking about the problem. In an ideal world a standardized protocol to push changes to a server would be awesome. I think it's unrealistic though to expect widespread adoption especially for existing frameworks to add code just for doing this. For example, have you ever heard of WebDAV? It was thought up along the same lines and it's virtually dead now.
A better solution for now would be for source maps to tell you the full local path to the original source file. Yes, in a world where we all develop from Chromebook-like devices against files in the cloud, this won't work. We are a long way from that world at the moment.
* The live reloading doesn't support full refreshes. You can only do live updating inside the running page. Chrome has built-in support for this. Works awesome for css. JavaScript support is a little flaky. * It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change.
I'm actively working on fixing both problems.
Instead, why not make something like IntelliJ/RubyMine/WebStorm/etc.'s Live Edit plugin a native part of the browser. Allow the asset pipeline to tell the browser it has changes available, rather than try to have it regurgitate all the processed assets. That would be relatively easy to add and very straightforward to implement.
The simplest middleware that would pop up would be a diff generator. But with source maps, web frameworks could track what exact source files were used.
That would be really something.
http://remysharp.com/2012/12/21/my-workflow-never-having-to-...
For higher-level languages like Coffeescript or SASS, run a local compiler on the file or function so you can push the compiled code to the browser.
A nice side effect of this approach is that you can use a real code editor instead of the Notepad-style editor embedded in the browser.
In that regard, my #1 feature request for the Firefox devs is to finish and implement the remote debugging protocol [3] and, preferably, work with the WebKit devs towards unifying the two protocols.
[1] https://github.com/swank-js/swank-js
I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able to implement this in a way that works without lots of additional/manual inputs. If you think JS source maps are a hard problem to solve, I'd say this one is at least an order of magnitude harder.
I can envision simply using structured CSS comments to pass the needed information to the browser. The browser only needs a structured pushing protocol, baseline comment format, probably handling of comments that indicate file boundaries (used for pushing to the correct resource) and a 'plugin api' to allow plugins to parse other comments in a meaningful way, SASS/LESS could provide a 'Dev tools' plugin to parse the comments and support whatever editing features they wanted. They would also have to support generation of the comments in the preprocessor.
The important bit is a standardized pushing protocol, a standardized way to provide additional mapping information and a standardized 'plugin' style system to allow things like SASS to add to dev tools additional editing support.
Just one theoretical approach, still a ton of work, but I really think there is a lot of developer time spent dealing with this issue so it may well be worth it.
Edit: Should be fixed now.
My kingdom for a '+' button.
Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks.
It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.
This may not be completely true. In Edit As HTML mode every effort is made to retain the original elements. If you move some tags to another location, the real element (and handlers) should actually be retained.
$0.appendChild(document.createElement('tagName'))
* As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard) to watch the source files and automatically compile them
* Used serve (https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too
* Used live.js to pull for changes (http://livejs.com/)
As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.
I'd love to see more tools that enable rapid prototyping, including the ability to craft CSS in a more visual manner.
Here's the post, for any who are interested:
http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-b...
Not that there's anything wrong with that.
Now, if you have the "Support for Sass" experiment enabled, you'll see the "Auto-reload CSS upon Sass save" timeout setting to reload re-generated CSS files after "sass --watch in:out --sourcemap" (or equivalent) has updated them on the local disk.
Edit: Gramer and language improvement.
In FF dev tools?
Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files without manual shenanigans in the middle.
I probably waste more time copying CSS / HTML tweak diffs from the browser back into the related source files than anything else with in browser dev tools. Due to the nature of 'losing changes' if I happen to hit refresh or if the page has some automatic polling mechanism I also tend to do this very often as some sort of manual 'save' action.
There have been a couple attempts to do this (http://www.cssupdater.com/ or https://code.google.com/p/backfire/). But, I'd really like to see a standardized protocol for pushing changes to the server such that server side frameworks can implement it appropriately.
For example a server side implementation for Rails needs to understand the asset pipeline to know how the final file was created so it can work its way back to the correct file to save changes to. This also means you probably need source map style support for LESS and SASS also. Also to change HTML template files the server side needs to know how the page was constructed so it can find the correct partial / template to save changes to. Which is probably really hard depending on how much state based conditional rendering there is in your templates, maybe the server side caches the last response and associated state to work around this.