Hey there.
I'm Addy Osmani.
I'm a Developer Programs Engineer on the
Chrome team at Google.
And today we're going to talk about some new Chrome DevTools
features spanning work spaces, snippets,
and an improved Sass.
Debugging workflow.
Now, these features are going to hopefully help improve your
authoring and productivity in the tools, so
let's dive right in.
A typical web app development workflow usually involves a
clever window arrangement of having your editor and the
browser with your dev tools living side by side, and
constantly making this sort of cumbersome context switch
between these tools.
Now, rather than having to do that, wouldn't it be great if
you could spend a little bit more of that time that you're
editing files on directly inside the dev tools, so that
you could both debug and edit your project files?
Now I'm going to talk about Workspaces, which is a new
feature we've been able to facilitate this workflow.
So, I currently have an application open that's sort
of a page level right now.
And what I want to do is actually be able to go and
open up and edit my entire project, so everything that
makes up this project on my local file system.
And the way I'm going to do that is I'm going to go and
I'm going to add this application--
HTML5 Please--
locally.
You should now be able to see that I have two sets of
directories.
I have my page level view of this page, and then my entire
project level view.
And I want to be able to consolidate these, so whenever
I make a change, they apply to both what Chrome is able to
display and what I'm able to experience during debugging,
and the changes I'm making to my original source files.
So I'm going to go and I'm going to right click on any
file, really, inside my project.
I'm going to go and I'm going to map them
to file system resource.
And I'm just going to choose the option which basically
maps it back to the original source file.
Chrome DevTools is going to ask me to restart.
It's gone and it's done that.
And now you see I just have one single view.
This one view consolidates everything, and it basically
represents my entire project, and all the files that make up
my whole application.
And I can go and I can edit.
I can edit my index file.
I can edit any of my build files.
I can go and I can edit my JavaScript.
And the first thing I want to do is I want to make sure that
in this new workspace world, I'm still able to do things
like live edit and life debug, and use my breakpoints.
So let's do that.
I want to locate a specific method called updatesearch.
And I'm going to do that using a keyboard shortcut called
Command-Shift-O. And it's called updatesearch, so I've
typed that in.
It's is gone and it's taken me there.
And what I'm now going to do is I want to change this
application so that--
so the current way this works is I type in a tag.
So it can be video, audio, canvas, or
another HTML5 feature.
And this page will basically let me know whether it's safe
or not to use that feature.
What I want is, whenever I type into the search field, I
basically want it to log to the console.
So I'm going to add a little console log statement here.
I'm going to say, console.log("We're
updating!").
And I'm going to do Command Save, just to save that back.
And using the Escape shortcut key, I'm going to open up a
local console which can be displayed at the same time as
the Sources panel, so I can see my output.
What I now want to see is whatever I type in something,
as you can see, that's logging correctly to the console,
which is great.
So I know that live editing seems to be working fine.
The next thing I want to be able to do is work with
breakpoints.
So we can still use updatesearch for this.
Let me add a breakpoint to classList, and I can do this
by clicking inside the line number gutter.
And I can do that inside a few other places in my code.
And what I'm now going to do is basically go back to here
and start typing it again.
And the first thing you'll notice is that it's triggered
that first breakpoint.
And I can go and I can continue on to the next
breakpoint just by right clicking inside the gutter,
and clicking on the next one and going to continue here,
which will continue execution up to that point.
And I can continue to the next one right after
that if I want to.
So let's kill the stuff that we had in console
there at the moment.
Now, something that I noticed with workspace that's actually
pretty cool is the ability for DevTools--
let me show you this.
I'm going to come to close my script file.
I'm going to close the DevTools.
So let's assume that we've restarted Chrome.
I'm going to open up my Sources panel once again.
And I'm going to go back to script.js, which is what we
were working on.
And what you'll now see is that all those breakpoints
that I created are actually still there.
The DevTools have been able to remember them.
And it can do that for any number of files.
I can have a bunch of different scripts that are
composing my application, and it'll basically remember the
different breakpoint settings for them.
I can actually go and--
I can still add things like conditional
breakpoints as well.
So here, what I want to do is say, if the value of
search.value is panda, for example, I basically want it
to trigger this breakpoint.
So I can type in audio and nothing happens.
But I type in panda, and it's triggered that conditional
breakpoint.
I can actually-- so let's continue working through
there, and let's get rid of that conditional breakpoint.
And let's take a look at our watch expressions.
So I can still add things like objects to my watch
expressions and have those been
watched during my workflow.
So pretty much everything works the same way that you'd
expect it to.
Now if we're saying that you're getting a slightly
better editing experience inside the DevTools, one thing
that we commonly need to do is have access to some sort of
revision history.
Now, you actually get access to this by right clicking on
any file, going to the Context menu, and then clicking on
Local Modifications.
What this will do is-- and let's make some modifications.
Let's say, var test equals some object.
Let's save that.
And what you can see is that I get a complete revision
history where I can go and revert back all the changes
that I've made up to a certain point.
I can apply a specific change at a particular
timestamp if I want.
Or I can apply a specific revision to my original files.
And this is really useful.
So rather than having to just sort of worry that a change
that I'm making during my live editing and debugging workflow
is going to come back to bite me later, I can easily trust
local modifications to save those changes.
And I can go and I can revert back to them if needed.
So I'm to go and I'm going to escape that.
Now, you can actually get some nice mileage using some of the
other buttons that are at the bottom of the Sources panel.
So let's take a look at some of those.
Now, it's quite common when you're working on an
application of some sort to have a few
tiles that are minified.
And these may be outside of your own build process.
So maybe it's like a minified version of jQuery or Backbone
or something else, and you just want to make it a little
bit more readable, because the minified form of this file is
this is just not that easy to work with.
So using the curly braces button at the very bottom,
this one that says "pretty print," I can click on that.
And it'll go and it'll beautify my JavaScript for me.
So I can go-- and this is a little bit more easy to read.
It's much more neatly white spaced out.
It's a lot more easy for me to go Through And I can
go and I can use--
although some of these variable names are going to be
minified, I can actually mostly still use my same
shortcut for displaying all of these methods to access
things, which is great.
Now, if you're working on a project which has really any
number of large files on it, you're going to want to be
able to easily locate things, whether it be inside a
specific file, or across your entire project.
Now, there are some useful keyboard shortcuts which can
help you achieve this, and I'm going to go through some of
them right now.
So we've already gone through one of them, which is finding
a method in a specific file.
So for any of the shortcuts I'm going to go through, I'll
probably be using the Mac specific
version, which uses Command.
But if you're on Windows or you're on Linux, you can use
Control instead of Command to achieve the exact same thing.
So if I want to locate a specific method inside a file,
I want to filter down to a specific method-- or in the
case of a style sheet, a specific property--
I can use Command-Shift-O. And like earlier, I can filter
down to updatesearch.
I can filter down to pretty much any method I want.
And by clicking on it, it will take me to the line number
where that method or function exists, which is great.
Another thing I might want to be able to do is open or
filter the list of files that are
available inside a project.
And I can do that with Command-O. So this will go and
it will display all the different files that I have
available to me.
If I'm looking for my style file, I can start typing.
And as you can see, it's filtered down the list to
those results that are relevant to me.
If I'm looking for all of my JavaScript files, I can just
type in .js and achieve the exact same thing, which is,
again, quite helpful.
Now, if I want to navigate to a specific line that I know
exists inside my file, you can use Command-L to achieve this.
So here, I'm going to go to line number 56.
And as I can see, I'm in the region of my updatesearch
method once again, which is really great.
Now, some of the different panels inside the DevTools
have their own find feature, which works at a context level
on the material that you're working on.
So in the case of the Sources panel, Command-F will bring up
a nice little search box in the very bottom, near the
Sources toolbar at the very bottom of the screen.
And I can start typing in here to look at
things inside this file.
So I can find my updatesearch once again using this.
I can find specific variable names, or pretty much anything
that I want.
And I can use these navigation toggles to go back and forth
between different search results.
I can actually also go and find and replace different
content if I want to, the same way that I would in a normal
text editor, which can be useful.
And this type of functionality is present on a few different
panels, including Network, and I believe Resources as well.
So if you're using those panels, you can also use
Command-F on them.
Typically, we also need to be able to search across all of
the files that form our project.
And we can do this using another keyboard shortcut,
which is Command-Option-F. What this gives me is the
ability to look across every single file in my project.
So let me look for something like document.
I want to see what files in this project on use the word
document in them.
And as you can see, it's giving me a list of all the
different files, as well as the line numbers where these
occurrences are.
And I can go and I can click on any result.
It'll actually open it up inside the
Source panel editor.
And I can go and I can make any changes that I want to
those files quite easily.
So you can expend any of these search results and it'll give
you a preview of where it's found, the instance of what
you've been looking for.
And this feature also supports some nice things like regular
expressions, if you want to use those.
So let's hit escape again to kill the console.
Now that's great.
I'm able to pretty much edit files
directly inside the DevTools.
I can load up local projects, entire projects, so I can see
all the different files.
And if I close Chrome or close the DevTools, that project, as
long as I want it to be, will still be around, so I don't
have to go manually opening up any individual files that I
want to debug or edit.
That's great.
Now, if you'd like to start using Workspaces today, the
first thing you're going to need to do is make sure you're
using Google Chrome Canary, so the Canary release channel.
The next thing you want to do is go to About Flags, and look
for the Developer Tools experiments.
So I'm looking for Developer Tools.
And you just want to make sure that you enable developer
Tools experiments, and then relaunch Chrome.
The next thing you want to do is go to the Settings pane
once you're fired up DevTools.
Go to Experiments, and Enable File System Folders in Sources
Panel, so this option that I have open right here.
You then need to relaunch your Developer Tools.
And you'll get access to a new feature called Workspace that
appears as a tab.
And you can then go and add as many different file systems as
you want, and you even have some configuration options
around the different file mappings that are also set.
And that's it.
You should be able to work with projects directly inside
the tools, which can be nice.
Sometimes you want to be able to save smaller scripts,
utilities, and bookmarklets so that they're always available
to you inside the DevTools.
There's a new feature that can help you
with this called snippets.
So to use snippets, go to the Sources panel.
And in the left hand Nav, find the snippets sub-bar.
Now in the tree view here, you can see that I already have
some snippets that I created earlier.
To create a brand new snippet, right click inside the Tree
View and hit New.
You can then customize the name of your snippet to be
pretty much whatever you want.
In my case, I'm going to call it cornify.js.
You can then paste in the contents of a bookmarklet, or
write any custom script that you want to form your snippet.
In my case, I'm going to paste in my cornify script.
And I can then run this against any local object if I
want-- the Window, the Navigator, and so on--
but I'll mostly be using this against the current page.
Now, there are two ways you can execute a snippet.
You can either use the triangular button at the very
bottom of the Sources bar, which will basically go and
run it, or you can use the keyboard shortcut
Control-Shift-E, which will also do the same thing.
So in our case, we're going to use
Control-Shift-E, run my snippet.
And what you can see is it's gone and it's added a really,
really awesome rainbow to my page.
I can go and I can run this once again.
Boom!
I've got a unicorn.
This page is so much more functional now.
And that's great.
As you can see, I can actually go to any script here.
So I can go to CSS Prettifier, which I'll be
showing you in a moment.
But I can add breakpoints to this page.
I can treat this as pretty much any normal script.
I can live edit it.
I can live debug it.
And that's great.
Another nice thing about this feature is it basically gives
you access to a lovely multiline console with both
syntax highlighting and persistence.
So you can basically go and do anything you want.
And hit to the next line, keep editing this the same way that
you would any other script, which is great.
Now, to show you another example of a bookmarklet, I
created CSS Prettifier.
And I'm currently on a page-- so normally when you're view
sourcing a page, you might be trying to check out the
JavaScript on that page, and the CSS.
And when you try going and looking at the raw version of
that, it's not very easy to do that always.
Because sometimes those style sheets might be minified and
those scripts might be minified too.
So in this case, what I'm going to do with CSS
Prettifier is I'm just going to go and I'm going to run
this against the current page.
And as you can see, it's gone and it's prettified my CSS,
making it much more readable, much more accessible to me,
which is great.
So snippets have got a lot of capabilities.
You can use all the same panels as you would for your
debugging and editing workflows, as we were looking
at earlier with Workspaces.
And to enable them and start using snippets today, all you
need to do is go to the settings cog, go back to
Experiments, and just check Snippets Support.
Now, at the current time, snippets are still in
experimental.
We're expecting for them to sort of come out of
experiments quite soon, so you may not even need to enable
them in the future, and that's the hope.
So we've looked at Workspaces.
We've looked at snippets.
The next thing we're going to look at is an improved Sass
debugging workflow inside the DevTools.
If you enjoy working with an abstraction language like
Sass, your workflow inside the DevTools has probably been a
little bit limited.
The reason is, although you can edit CSS inside the
sources panel or via the Elements panel, none of the
changes that you make will actually go and be propagated
back to your original Sass source files.
And that means that as soon as you run the Sass compiler, any
changes made to your CSS from the DevTools will be
overwritten.
That workflow changes now with some recent improvements that
we've made.
I'm going to go over to the Elements panel and inspecting
the top root of the HTML5 Please page, I'm going to go
and take a look at some of our styles.
So here I see background color 232927.
Now I can actually command and click into this color, and be
taken to the dark variable name, which expresses what
this color is, which is fantastic.
Going back to Elements, I can actually also Command click on
background color, to be taken to the reference where we're
saying, OK, we'll use the dark variable for this
color, which is great.
I'm going to go and I'm now going to inspect the H1 for
this page, so HTML5 Please.
And what you'll notice in this side, is that rather than us
referring to style.css or just the CSS, we're actually now
referring to line numbers for the
original Sass source files.
So I can go, and by clicking on style.css, it will actually
take me to line source for this style, which is great.
And I can now go and start making
actual changes to these.
I have another feature called on which basically allows me
to reload whenever changes are makes my Sass files, and I'm
going to preview what that looks like right now.
So I now want to make a change to one of
my Sass source files.
There's actually a Sass function that I defined
earlier called OMG.
And I'd like to change my text-shadow to use that
instead of what we've got at the moment.
So what I'm going to do is I'm going to go to text-shadow,
type in omg--
let's clean up some of this stuff--
and I'm just going to Command-S and
take a look at this.
Boom!
So what that's done is it's actually gone and compiled my
Sass file into CSS, and it's being previewed inside of the
Chrome without me having to go and use any additional tools
separately.
So I do have my Sass compiler running in the background and
watching everything.
But that's about it.
Now, in order to enable this Sass editing workflow, you
need to go to DevTools Settings, go to Experiments,
and first of all, make sure you have
support for Sass checked.
After that, you'll probably have to relaunch the tools.
Next, go to General, scroll down, and you want to Enable
Source Maps, as well as the Auto-reload
CSS upon Sass Save.
And that's what basically allows us to reload without
having to go and do anything extra like
refresh the page manually.
Finally, make sure that you're running the Sass compile there
was some specific flags in the background.
In this case we're using Sass, Watch, SCSS, Sourcemap, and
then defining the input and output for our files.
And that's it.
If you'd like to stay on top of the latest news to do with
the Chrome DevTools, please feel free to follow us on Plus
on the Google Chrome Developers channel.
On Twitter, you can catch us on ChromiumDev, or you can
watch our regular show, "The Breakpoint," which captures
the latest and greatest in the world of tooling.
Until next time, thank you, and goodbye.