My workflow v3: full coding stack

I’ve recently been working 100% inside of Chrome’s devtools using the powerful feature “workspaces”. This gives me access to write to any file on the file system. So I’ve recorded another short screencast (6mins) to show you how to enable it, and quick demo of how I’ve been using it on my Node projects.

Updated July 21, 2013: I forgot to say in the screencast, you also need to enable Developer Tools Experiments via chrome://flags. Also make sure you check out Paul’s comment below with even more useful tips.

There’s obviously a lot more to devtools, and I’m running a workshop on debugging in November (that this time sold out in 3 days). If you’d like to hear about when I’m running it again, pop your name on my newsletter list.

Otherwise, I hope you’re able to do a bit less cmd+tab, cmd+r, and a bit more cmd+s :)

22 Responses to “My workflow v3: full coding stack”

  1. Chuck a little live-reload in there and we’re rolling. I wish other browsers dev tools could catch up.

  2. could you share with us your sweet command prompt PS1?

  3. How can I enabled this ? I do not see the “experiments” tab…

  4. Thanks for posting this! I had tried to get this working earlier with no luck, but just got it up and running. Do you use the network resource mappings to tie the two sources together? Seems to save all tweaks from the elements tab, which seems super handy for CSS tweaks. I’ll definitely be rolling this into my workflow.

  5. Very nice!
    You missed an optional step in your workspaces: mapping the local folder to your app. I love it this way.

    What this gets you:

    • persistence for any changes you make in the styles pane, immediately (includes unchecking styles -> commenting out)
    • persistence for any changes you make in Sources (after hitting cmd-s on any file).
    • LiveEdit with JS still works, and it saves it to disk as well.
    • Sass support + workspaces works a champ.

    You don’t NEED to do the mapping, but I think it’s worth it.

    You asked about if we can define the scope of cmd-o to only be your active workspace.. It’s hard if it’s not mapped, so we’ll see. I’m also thinking about some default ignored files for workspaces.. I don’t really want to see node_modules, etc in cmd-o. How’s that sound?

  6. Nice screencast, thanks for sharing. But anyway, as Kenneth Auchenberg mentioned in his blogpost: “Does this mean that the browser vendors are on their way to compete with the editor vendors?”.

    I think that this question needs more attention, otherwise our (webdevs) development stack becomes more & more fragmented.

  7. It’s cool, I’ll give it that. I can definitely see myself making use of the styles pane persistence; but I rarely find myself straying far from the Network and Console tabs otherwise.

    Dev Tools just doesn’t feel like a good editor to me, which is okay – I don’t think anyone approaches it in that mindset. I’ve grown very fond of ST’s multi-cursor, command palette, goto palette, etc.

    Plus, the Chrome Web Store always seems to suck me in for hours at a time. You make it “Package Manager” as well and my productivity is screwed!

    @Paul: I agree on ignoring the “tooling” directories, right along with dotfiles and your standard user-level .gitignore contents. Cmd+O should be focused on the files/directories most developers will be actively working with which.

    For most, tearing apart a library takes second place to `npm uninstall` and try the next.

  8. Great video, good tips. Your terminal window caught my eye, what’s up with it? Is that a plugin or what?

  9. I’m loving some of the stuff happening in chrome itself, as well as some of the devtool extensions. I’d like to see editor level extensions (eg. Emmet, git gutter), as well as some useful editor features like multiple cursors. The additions of these would be pulling me more out of vim or sublime text.

  10. Ever since I started using workspaces and local file mapping I stopped switching back and forth to my editor or having to edit scss files outside Chrome. I <3 that you can edit your styles using the elements panel.

    You can also map a remote file to a local version for debugging purposes. The other day I was working on a website with more than 3000 lines of horrible CSS. Mapped it to a local file and was working on my local version. Saved a lot of time instead of editing, uploading then testing. Now I have to work on my local version and it will be reflected as If I am editing the remote file exactly.

    @Paul the only thing I wish for now is to allow us to create new CSS selectors using the elements panel when I click the (+) button when an element is highlighted. That would be a huge boost. Currently it is added in (inspector stylesheet) with no automatic way to copy it to the CSS file.

    @Alex try going to chrome://flags/ and make sure you are using the latest version of Chrome

  11. You need Chrome Canary for this, since Chrome (at this moment Version 28.0.1500.72 m) does not have this. You turn on the Chrome dev tools experiments in flags, but dev tools settings still dont have those tabs. I had to install Canary for this.

  12. @Danny – that’s incorrect. I point out in the screencast that I *am* using stable chrome, and not carary (you’ll see me switch right at the end). You just need to enable this feature the chrome://flags as pointed out in the update notice in the post.

  13. I got it working with chrome stable with no problem whatsoever. I initially mistakenly opted for ‘Enable apps-devtool app’, in chrome://flags/, the first one I noticed. After seeing no option for ‘Workspaces’ appear, I later noticed the correct selection was listed in chrome://flags/ as ‘Enable Developer Tools experiments’. New to the close and reopen devtools refresh sequence though no problems, here.

    Thanks very much for this. It’s like jsbin finally meets actual working projects.
    Fantastic. Made my day.

  14. I have been trying to figure this out for a long time. Thank you so much for this!
    Two things on the wishlist for Chrome dev tools

    1. Custom fonts (or at the very least, bigger font sizes)
    2. Support for Emmet. I am so used to emmet, that the auto complete is still falling short for me

    Could you let me know if there is an official forum where feature requests can be submitted?

  15. @Vinay – to increase the font size (which I always have bumped up to about 16px), just focus the devtools then cmd+ (or ctrl+ if you’re windows). You can also set custom fonts akaik:

    Support for Emmet – yep, file a feature request here: – I’m doing it all the time when there’s something I want to see land!

  16. Great screencast, nice to see others workflows.

  17. I seem to remember a tweet from you a while ago, about editing the Sass file directly from the inspector that would then save to disk (that would be super awesome). Do you know if this is possible?

  18. @Simon – you can, it’s a bit of a fiddle, and I used this (or similar) technique to edit the Full Frontal site since the root CSS comes from SCSS. Here’s the article:

  19. Thanks, after going over the article, I did a quick screencast on two questions I have:

  20. @Simon – cheers for the screencast and questions. On the first question – I raised a bug with the same feedback: – there’s a reason why it’s not easy right now (as I understand) it’s because they can’t work out the original mapping.

    The second point, I think what’s more interesting is whether a workspace can be linked to a url, so you don’t get everything when you’re on X domain – currently just a tweet:

  21. Cool, thanks, would be so sweet if these got sorted.

  22. [...] compliments our recent Workspaces feature, which makes it possible for the DevTools to effectively be your editor.Some of the things I’ve enjoyed using the extension for include:my git workflow (clone, add, [...]

Leave a Reply
Not required

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