My Workflow: Never having to leave DevTools

At this time of year (Christmas) there’s a lot of tip-like articles that emerge, so I wanted to share what I felt like was the single greatest technical win I have come across in the last few months: using Chrome DevTools for full web dev workflow – so I recorded a quick 4 minute screencast (and even wrote up a few extra bits – because I felt generous this Christmas!).

Actually, truth be told, it’s not the entire workflow (I can’t create new files for instance) – but where I’m up to is: navigating my entire project, making changes and seeing the live impact of that change, testing new ideas and most importantly – actually saving those changes to disk without leaving DevTools.

Although I’m using Canary in the screencast, this functionality is available today in Chrome stable.


For a long while now, you could edit the “sources” to the web page, and hitting save cmd-s and it would update the current state of the JavaScript engine – which is powerful as hell alone.

But in a recent release to DevTools, a feature that previous required an extension, when you save, DevTools will ask you where you want to save the file to. In my case, I’m working on client side apps – which means just a static directory of JavaScript files. That means I can overwrite the existing file (js or css), and when I continue hitting save, it now overwrites that file on disk.

For me, this seemingly simple addition, means I can do a large amount of coding, testing and debugging directly inside the browser – which reduces the workflow loops.

It’s also worth adding that, whilst you haven’t refreshed, you can also get a complete list of all the modifications – right click on the source: local modifications. From there you can see the time of edits but also see diffs of those changes and revert them (though I believe you should be able to revert individual changes – i.e. just the first change through a patch, I didn’t have any success with this and suspect it’s just a bug in Chrome that I came across).

Code with live state

Another big win for me (which I didn’t include in the video) is that whilst I’m working inside the sources panel, and experiementing I can quickly and easily inspect the state of variables.

I’ll add a breakpoint, or a conditional breakpoint (right click on the line) – the code pauses, and hit esc to bring up a console and test code and check variable state or check entire lines of code to see if the result is what I’m expecting.

Space and stretching your legs

Finally, a couple of extra bits that make my workflow more comfortable for me. I always bump the font up on the DevTools (simple cmd-+) – maybe because I don’t like to strain my eyes, maybe because I’m getting old!

I dock DevTools to the right (in most cases) – which used to be under settings (the bottom right cog) but in Canary has moved to click-hold the bottom left “popout” icon.

Then lastly I tend to hide the source navigator (the list of files) and the debugger (the right hand side) using the little collapse icon.

What I’d like to see next

No doubt there’s someone I can direct these to, but equally I wanted to share my thoughts here because either maybe you know they’re coming, or there’s other features you’d like to see too:

  • Ability to edit the “program” file, including the HTML, CSS & JavaScript #167289
  • A comment toggle keyboard shortcut (I keep hitting what I think it is, and instead pausing code execution) #167284
  • Much clearer feedback when saving wasn’t linked to a file on the hard disk (sometimes I’ve hit save and it’ll save in V8′s engine, but not actually to disk, because I hadn’t linked it up yet) #167285
  • Autocomplete whilst editing source (perhaps looking up from the autocomplete in the console) #167290
  • Toggle word wrap on sources #167287

I’m sure there’s more I’d like to see the more my workflow moves inside of DevTools. I certainly hope this is as useful to you as it was to me when I discovered “save as”!

39 Responses to “My Workflow: Never having to leave DevTools”

  1. Excellent write-up, Remy! I agree that we can be doing a better job on clearer feedback during file-save.

    On autocomplete, we currently have experimental opt-in support for using CodeMirror as the editor in the Sources panel. I know it supports autocomplete for source (see so perhaps we can look into ways of playing around with that to see whats feasible.

  2. Really digging the saving code changes inside the browser part :-) thanks for the post Remy

  3. Excellent demonstration.

    HTML editing is tricky, really you’d be editing the DOM and serializing it back into HTML. (Or alternatively changing the HTML and forcing a refresh with that new markup). Both options are not as smooth as the save/live-update story we have with CSS/JS… but WebStorm’s LiveUpdate mechanism maps HTML into DOM well so if they can do it, DevTools can too.

    The editing environment requests are on point. I know there is a lot of work going on there and the team will be pleased to see these requests.

  4. Would love to see the ability to edit the LESS or SCSS files if there are any within a “local” environment. Being able to live edit and save the edits is great if your using un-processed CSS.

  5. Any reason why CTRL+O sometimes works (go to source) and sometimes brings up the browser’s file Open dialog (Chrome v23, Windows7 x64, in both cases) ? I’m sure the dev tools had focus in both cases too.

  6. @jess – I’m sure if you check that there’s an issue for that – if not – definitely file one.

  7. Remy do you edit while on a breakpoint? When you save this invokes ‘live-edit’ which unfortunately does not work well. I’m hoping this feature will improve soon…

  8. The devtools-save extension has a simple map of URL to files; it shows a notification on success and errors on failure. (If devtools fails to detect devtools-save, then no message unfortunately). I made a small enhancement to support save over WebDAV (really just PUT): Then I use node with jsDAV and never have to think about the file paths again!

    More bug reports about this feature:

  9. @johnjbarton – do you mean directly on the line that paused, or during a break in execution? More the second, but sometimes the first. I have had some trouble in the past where V8 can’t backup properly to re-run the code (though this may actually be inside of setTimeout where I think it has trouble working out what invoked the call).

  10. Which line you edit should not matter. When you save devtools pushes the changed function(s) to V8. V8 compiles them. If the compile fails V8 emits an error message w/o any line or column info. If the compile is successful, it rolls the stack back one frame and pauses. Then you can continue. Or it may abort for various reasons that are not clear to me.

    While this sounds awesome, in my experience it’s actually more annoying than helpful. No pointers to functions are fixed up (eg methods of objects are not updated). If the rollback puts you in a different file, the editor suddenly jumps to that file which is confusing. Once in a while the fix up works well, but by that time I’ve hit control R and started a new run, because the fail rate is high.

    Does that match your experience?

  11. Including Script in Console Please!!

  12. @johnjbarton me personally, no, not at all. But then I’ve found that Chrome bugs can be particular to the machine you run (i.e. web audio api is borked for me, and probably me only).

  13. Second for SASS/SCSS! I think Paul is probably getting *really* tired of hearing this request from me haha I’ll shout it from the rooftops! I know I saw Addy doing it in the BP vids, just canary isn’t stable enough for continual dependence for day to day deving. Still need source mapping via sass/compass then chrome stable integration so still a ways out but very excited for the future!

  14. Glad to see this coming along.

    I’ve always kinda assumed it was there, and I would say to my design inclined colleagues, “just edit the CSS in devtools and send over what you end up with!”

    Unfortunately, when actually trying to do it, it’s a terrible experience… at present in Chrome 23.x.

  15. That literally blew my mind away. Awesome stuff!

  16. Code collapse would be another nice feature to have when viewing files in the Source tab.

  17. For the designer types out there, I just checked and most changes made to the CSS inspector are also applied to the in-memory CSS file, so they will save out just the same as if you edited the CSS file manually. The only thing that I’ve found so far that you can’t do through the CSS inspector is add new style rules, since those are not added to a file (with good reason).

    The CSS inspector is really a great way to visually develop CSS and I’ve been dreaming of a way to save changes directly to the source files for some time. Thank you, Google.

  18. @Chad von Nau – if there’s a new style that I want to save to a file, I just go to the sources panel, open the CSS and manually add the selector. Then I can add properties via the CSS inspector. Though I think I may need to save the file separately…

  19. CMD+S does not prompt me for a location to save an edited JS or CSS file. Instead, the latest stable and Canary versions of Chrome for Mac save the file in memory. Is there a setting that must be activated before this auto-save feature works as it does in the video?

  20. I don’t edit my sites locally but I definitely love using devtools to make changes to css on live sites, then its just a matter of changing the file via notepad++ and putting the file up with filezilla. Still saves me time rather than guessing and loading the changed files up 2 or more times. I can see its exactly what I want make the changes and I’m done…

  21. Awesome, thanks for sharing this, Remy. Totally sped up my workflow today! :)

  22. @Jack B – just right click, then “save as” to create the link. Then subsequent saves will save to disk as well as memory.

  23. Ah, there it is. Thanks, Remy!

  24. Remy,

    Do you recommend having the script file that you’re working from open in Sublime (or another editor) just as a fall-back? Or will the editor automatically update itself when it’s being saved over in Chrome? Thanks!

  25. This is rockin! Thanks for sharing. Interesting to see a lot of powerful features coming through to the dev tools.

  26. @Paul – yeah, I do tend to keep the file open in another editor – but any changes that occur in devtools automatically update in the editor.

  27. That, my man, is heavy-duty hardcore awesome!

  28. Now all they need to do is make a cross browser button. Ah ha…. Is it me or do those cross browser things don’t work very well.

    Nice tip. Can’t seem to get the:

    list of all the modifications – right click – to work. Any hints why?

    “It’s also worth adding that, whilst you haven’t refreshed, you can also get a complete list of all the modifications – right click on the source: local modifications. From there you can see the time of edits but also see diffs of those changes and revert them (though I believe you should be able to revert individual changes – i.e. just the first change through a patch, I didn’t have any success with this and suspect it’s just a bug in Chrome that I came across).”

  29. Dear Remy!

    Let me ask a question. How did you put the developer window to the right side of the browser window from the bottom (In Canary of course)?

  30. Awesome!

    Didn’t know about all the shortcuts, need to learn those for sure.

  31. I think the command+ to zoom Dev Tools Type is possibly the most life changing thing in this post for me! With the new compressed type in Canary, I seriously feel like I’m going blind writing code at 2am. How did I not know this before? :) Major thanks Remy!

  32. Really cool workflow. Out of curiosity (and rather random question), what software did you use to do the screencast? Really well done and I’m looking to put together similar commentary for a not-for-profit.

  33. Nice one Remy, great stuff. (And of course the Dev Tools team, could you be more awesome?)

    I have a hosted server with WordPress loaded and would love to be able to save changes right back to that hosted server. I can’t seem to save to an FTP location out of Chrome Dev Tools. So I’m currently just copy/pasting. I notice your site is WordPress, have you had any luck with this?

    Also, FYI I’ve noticed SASS support show up as an experiment in the current Canary, not sure how long that’s been there.

  34. Hey Remy,

    Mind truly blown!! Thank you for this.

    On issue #167289, in the current stable build (26.0.1410.43), selecting and unselecting the pretty print button while in a html or “program” file allows editing and saving as per js & css files. A save and refresh is still required for it to render, at which point you need to select and unselect the pretty print button again! Not ideal but it works.

  35. Since you still can’t work live w dev tools. I use LiveReload+Sublime Text which does all of the above. No-refresh CSS editing (live) and auto refresh on save. Nice article!

  36. I would love to see emmet (zen coding) support for HTML and CSS editing in dev tools

  37. Vinay – file a new feature request on – I’ve filed a few things in the past that have landed in the editor (like code completion now via ctrl+space)

  38. If it wasn’t already mentioned – text manipulation features. Deleting row, moving row, copying row would all be very nice. I’d say just mirror Sublime texts feature set and you’re off to a good start.

    Oh and if you have some time over – please throw emmet in there as well :)

  39. Canary overwrote my SASS!

    Using the prerelease SASS 3.3 and Canary 34.0.1784.0. I think I know what happened, probably my fault but I guess I intuitively felt like things would work differently. So…

    All was well, got Canary to map my .scss files to my .css files so I’m editing SASS in the browser, living the dream. I was working in the Sources tab from a workspace on the SASS file directly for the most part and would have to save and reload to see any changes. As soon as I made any changes the styles would be gone and I would have to save the .scss file and refresh to see updates.

    Didn’t like having to save so I left the Sources tab workspace and went to edit the styles in the Element inspector for some immediate gratification. I thought, voila, this is how to do it…live SASS edits. Auto-reload was on and I could l see the time stamp changes in my SASS file.

    To my utter disbelief, when I decided to open my SASS file up later on in my regular editor I found Canary had replaced all of my syntactically awesome SASS with the generated CSS. My .scss and .css files were now identical!

    Anyone else run into this? Also, I was emulating a mobile device the whole time though I doubt that has anything to do with it.

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight