12
Sep

Debugging The Web (Chrome Dev Summit 2016)


[MUSIC PLAYING] PAUL IRISH: All
right, so today I want to talk about
debugging the web. And I want to
share with you some of the work that we’ve been
doing in the Chrome Developer Tools. We’ve been working
hard on a lot of stuff, and I want to share
with you today. And just to step
back for a moment, I just want to point
out that really our goal here, with the
chrome dev tools, is that we want to maximize your
productivity as a developer. We want to make
sure that you are as effective at developing
experiences for the web as you want to be. Not just that, I think we
all enjoy web development because we get to craft this
experience that users consume. And we get to bring them joy. And we want, on
the dev tools team, to make sure that you
have that joy too. So we want to maximize your
delight as a developer. So I’m going to be sharing
with you a few things today, some big features that I’m
really excited about, also some smaller things that just
are smaller, subtle changes, but all targeting your
experience and your workflow as a developer. So we’re going to go
through a few things, from debugging and authoring,
bring up some web apps, and then some auditing stuff. And we’ve got a
lot to get through, so let’s get right into it. Debugging, I’m talking
about JavaScript debugging. And so JavaScript debugging is
how we understand the execution flow of our code, and it’s how
we remove all the bugs that we added to our code accident. So it’s a really
important thing, and we spend a lot
of time doing it, so we want to make
sure that it’s good. So let’s start out small. This is the call stack. It’s the humble call stack. This is what it looked
like about six months ago. And we spend so much time
here that we want to make sure that it’s as good as possible. So we’ve done a little
bit of UI refresh here. On the right-hand side
is the new call stack. So small changes, just
a little bit more clean. Not as much zebra striping. The asynchronous hops are
a little bit more obvious. Where execution
sits is very clear. And up at the top,
of course, you’ll see exactly why you’re paused. And this is called
out very clearly, because sometimes
you’re not really sure. Also sometimes you just
pause on a break point, it’s kind of clear. But other times you
pause on an exception, so it tells you exactly what the
exception message is right up there at the top, so you
don’t have to go and figure out and open up the console. Or you’re on a
promise rejection, you’re on an XHR breakpoint,
a DOM breakpoint, whatever the reason,
we want to make sure it’s very clear to
you on why you’re sitting there paused on execution. So some changes there,
but also on the call stack, and some other things. Now here, I have the
dev tools fairly– let me bring that back. Yeah. Uh-huh. Mm-hmm. Uh-huh. It’s good. Ha, it’s great! The dev tools in this
case are pretty big. It’s not all the time that we
have the dev tools maximized on the screen. And sometimes it’s all over
there, squished to the window, but we still want
to be effective. So this is what the call
stack looked like a while ago. As you kind of reduce the
size of the call stack, everything’s going
to shrink down. My function names, I can’t
even read them anymore. So navigating between the call
frames when I’m done blogging is kind of rough. We decided we could make
this a little better. So this is the experience now. So just as you have less
screen real estate, we go in, we stack the function
name and the location. And when we run out of space,
we just elide the location and take the text
away from that. So making sure that whatever
the screen orientation– and you know we’re
always changing it– it’s going to be readable
and usable for you. So again, these are small
changes, but important. Now a lot of us
are authoring, not just in plain old JavaScript,
but we’re using JavaScript Next ES6 2016– whatever. And we might be using tools
like Babel or TypeScript to transpile them down to
code that can be deployed across a variety of run times. I just want to point out the
dev tools works great with all these new language features. In fact, we use them ourselves. This is the dev tools
inspecting the dev tools. I’m using the black dev
tools to view the other one. And this is just
some of our code in some of our layer profiler. We use a lot of
these new language features ourselves
in our JavaScript. In here is a bunch of stuff. There’s promises and error
functions, template literals, the new array
methods, good stuff. And this allows us to make sure
that the experience of working with this new language
features, whether it’s debugging or in the console, is great
for everyone who uses them. So the console itself is
actually a really nice thing. So if you’re using Babel
or something to transpire, if you’re like, what
exactly is happening here? Just come on over to the console
and try it out in place here. Works great with all the new
features and const and let. Here in the screenshot, we can
see I’m using the async/await. This stuff is great. You can toss in a little
debugger statement right there and understand exactly
how it’s moving. This is a lot of fun. So while we talk
about the console, let’s spend a little bit
more time here and talk about the console read line. Now the console read line
is– how did I do this? OK, come on over here. So opening on up dev tools on
my favorite site example.com, it’s a good one, the console
read line is this thing here that we type on. And usually we type things
that are just one-liners, but not all the time. Sometimes you actually
want a few more than just one line
that you want to type. And this has been a pain before. You have to hold Shift-Enter
to write a new line. It’s kind of tough. So I’m going to write up–
just thought of a function. And as I hit enter now, we just
immediately say oh actually, I don’t think you’re done here. [APPLAUSE] Now this, some folks
call a smart return. In fact Safari kind of
paved the way on this one. They have this feature,
and we really like it. It’s fantastic. So let me just finish
the rest of this guy. I’m just going to
log out my args. I enter again, it still knows
that we’re not done yet. I add a brace and
it’s like, oh yeah, I’ll re-indent that
for you back there. And I’ll hit enter again and
it’s like yeah, you’re done. We’ll execute that. Cool. So as I had that too,
you’ll see that we are matching the braces too,
so very clear brace-matching. And in fact, this is
now syntax highlighted, whereas that is pretty new. Even things like multiple
cursors, and select next match, all these features
and these keyboard shortcuts that use
Sublime Text or whatever, they also work here too, so some
nice upgrades to the console read line. And the other thing is that
we use the console as a way to inspect objects,
and understand what’s going on with them. So actually having
the completions as we type and explore things
is really important. So on this site, let’s
see, document.head, I’m just going to look at
child nodes real quick. So as I open up
the square bracket, I do actually see
immediately all the indices that I can use in child nodes. So I know that there is 11 child
nodes, and that’s kind of cool. I’m going to choose one. And one in pain point that’s
happened in the console before is that any time that
you have an array, and you grab something from
the array, and you hit dot, and you’re like oh, am I not
seeing– I can’t– what is– there– I want
those completions, and it didn’t work. Anyways, it works now,
so we’re all happy. [APPLAUSE] So in addition to
that, you kind of want a little bit more power. And you’ve only been
able to see what starts with what you typed. And so now if I want to see what
the content is of this child node, I might type
content and then text content– yeah, actually
that’s the text content. So sub-string completions
work now, too. In fact the
sub-string completions work not just here, but
also in elements panel. So in case you forget
something like border color, you can type color and you’ll
eventually see where it is. All right, so some
nice improvements there on the console. Again, small things, but nice. Sometimes you’re writing
some code and, to be honest, three lines of code
isn’t cutting it. You want a little bit more room. And you could go over to
something like JS Bin, and that’s great for
sharing, but sometimes you just want to play around. The snippets inside of sources,
it’s just kind of a place where you can noodle around,
try out a few lines of code, put breakpoints try
things out, execute it. These are persisted into
your Chrome profile. In this case, I was just
playing with the battery API, seeing how much battery
I was just discharging, and how much time is left,
cool stuff, and just save it. There’s a few things,
like a little debug helpers that I keep around. And if you Google
dev tool snippets, you’ll actually find a
bunch of great debug helpers and performance monitors
that people have written. Just take them, save them,
throw them into your snippets. Good stuff. All right, now one more thing
to kind of finish up debugging. So this line of code that
we’re looking at here, asynchronous code–
I’ve got promises and some thens– this is
actually a really tough thing to debug, currently. In fact, if I place this
breakpoint here on line 16, I pause before adding this, but
there’s really no way for me to pause inside of
my error functions and see what’s happening
inside of them. And if I try and pause here,
because this is chained, it just doesn’t work. That’s not great. We want to make sure that
debugging asynchronous code is as easy as
debugging synchronous code. So we’ve been working on
this, and thinking that there must be a better way. So I open up a snippet
that I have here and– OK this is good. So we’ve been
thinking about this and working– let me bring
that back here, there here we go– working with the
V8 team to see if we can improve this experience. So what I have
here is some code, and we are going to ask
GitHub API for some data. We’re going to fetch it,
and then turn it into JSON, and then get some stuff
and hopefully log it out. And let me just try
this real quick. OK, well looks like
there’s a problem. OK, great, problems are good. Now before, it’s been pretty
hard to understand what’s going on because, again,
I could only pause in the very first line of this. But now what I want
to do is, I’m going to place a breakpoint here. In addition to that, we’ve
also found all the candidates along that line
of code where you can place in-line breakpoints. All right, yeah, and nice. So now that we have
that, let’s see– I’m going to run this again. So what just happened
is I ran it again. Right now we’re paused right
here at this first guy, but I’ll let that continue. All right now, cool. We’re paused halfway down
the line, right after JSON. Now I do see that this
response up here is here– Whoa, forbidden. That’s going to be
fun to figure out. And I even see the return
value, this promise, this is actually the return
value of this call right here. Now I think you
can go for– yeah, OK, yeah I go for it again,
and well, to be honest, it looks like data
is coming back. So the problem with
this demo is that I’m hitting the GitHub
API, and turns out that for whatever reason,
our IP in this building has already exceeded it’s
rate limit, which kind of rigs the demo. So thanks for the people
that are using the GitHub API unauthenticated right now. Luckily I have a
backup piece of JSON. This is with the payload was. That’s just sitting there. So let me just shut the– OK. How’re we looking? Let’s clear out these guys. Uno momento. OK great, so run that again. I do have a problem,
and we can inspect exactly what is going on. I kind of think I know. We go forward, I was
asking for a data avatar which doesn’t exist. Avatar URL, yeah
that makes sense. Let me finish this
so that we don’t have to worry about it anymore. And uno momento– all
right, there we go. After URL, enter, really? [LAUGHTER] What did I do? No. [LAUGHTER] Guys. I really– there we go. So yeah, a console image,
a little-known thing. Just tosses an image
into your console. Why not? [LAUGHTER] OK to be honest, the
implementation is down here, and it’s some cool– [LAUGHTER] [APPLAUSE] Anyways, in line-break points,
I’m really excited about this, really introducing a
much better development experience for asynchronous
code, and all sorts of code. It can really break
anywhere you need to. All right, moving
on to authoring, and we’re going to start
with the front-end. And I’m going to head
back into the browser. Over here, we have a PWA that me
and Sam Saccone have worked on, it it’s called
Caltrain Schedule. As you can imagine, it shows
the schedule for the Caltrain. And now we’ve been
developing this– and it’s always on when
you want to make changes. Now a typical way
of making changes, like we can try out some new
colors– and if we like them, usually the method
is Shift-Selection, and Copy-Paste over
in your editor. Now we don’t really
like this workflow, and we think it can be better. In previous talks,
you might have heard us talk about
features like workspaces. And workspaces allows you to
bind your local development folder with the actual
site that you’re looking at in the
browser, allowing you to save to disk the
things that you’re working on. And it’s some powerful stuff. But to be honest, there’s been
some configuration about it, getting it set up. If you’ve tried it, you know
it’s like- is it working? I don’t know. So we wanted to make
sure it’s really straightforward and simple. So I’m going to come
back over to sources, and clear this out of the way. And in sources, we
see this is the code. I have a service worker here,
and some JavaScript, and CSS. Right, but I want to be
able to process the disk. So the new experience
now is a lot easier. So I want to take actually
just my development folder. This is my Caltrain
Schedule folder, locally. I’m just going to drag and
drop it here and say yeah, you can access that. And then immediately you see
little, green check marks light up. And it says oh yeah, the CSS of
the file, I know where that is. That’s right on disk. And over here, I’m going to
show you on the Filesystem. Here’s the entire folder, like
my editorconfig and things, my service worker,
but everything that is coming in
from the network has a little check mark to it. So this is a nice thing, because
we automatically find out for you how things map. In fact, it’s not
just the basics, but if you have a
more complex setup, like you’re transpiling
your JavaScript, or you’re compiling SASS to
CSS, that should work too, without configuration. So I could explain how we made
it– to be honest, I don’t. It’s like magic. [LAUGHTER] So things like
this TypeScript, we are able to map
it back and forth. As long as you have a source map
for the actual compiled code, we will figure out where
it goes and map it, so that any changes
you make persists. So let’s make a change or so. This title could
afford to be bigger. That’s nice. It’s a little too
strong, I’m going to change the foreground
color a little bit, dial it back, get in the gray. That’s good, needs some shadow. I’m going to use the
new shadow editor. [LAUGHTER] Little too black, but
if we’re playing it up, oh, that is some classy stuff. Yeah. I’m liking that. Now one thing that you might
see, right here, this green check, it knows that this
is actually the one on disk. And if I click through
to view back-end sources, we have the diff saying,
oh yeah, you actually change these lines right here. And if I come back over to
see my editor, or my terminal, and I just check my diff, yeah,
that’s the diff of the changes that I made. So automatically,
this is the diff. [APPLAUSE] So I see this
isn’t looking good, but we’re not really
talking about CSS. So the original styles
of the site, Sam actually was pretty
responsible for, but I don’t even know if–
there’s a lot of styles here, and I don’t even know if
we’re using all of them. I imagine that we’ve all
been in this situation. You’re chipping an
app, and you’re just like– are we even using these? I’m not going to try and remove
them, because that’s crazy, but I would like to know. [LAUGHTER] This is hard. The browser kind
of knows, right? We’re like, maybe we
should– actually, yeah. As of today in a canary
near you, might find this, a little checkbox up
here called CSS coverage. Now I’m going to try it
out and just hit record. In fact that’s it. It’s kind of done. I’m going to head
back to sources. And now, in the CSS, we’re going
to mark on the left-hand side if these styles were never used. Yeah, so actually,
this is pretty good. [LAUGHTER] Down here at the bottom, looks
like there’s all this animation stuff that wasn’t used. And I just want to
verify that this is good. Animation is– actually, these
little bars that animate out. Looks like there’s just
two here, and if I can, yeah I’ll try and
trigger all of them. Let’s just switch
this over there. Yeah, that’s a few animations. And come back, and yeah. OK, so we are using all those. Not that, but– yeah, this
is looking pretty good. So excited about this,
because it gives us much better tools to
understand what of the code that we’re shipping
are we actually using. Yeah, some good stuff. OK coming back. Now, talked about
authoring in the browser. A lot of us are
full-stack developers. We write JavaScript
for the back-end too. And at Google I/O,
we showed some work that we’ve been doing to
bring profiling and inspection and debugging to node.js. We’ve been excited about
this, but there’s always more work to do. So let’s show a
little bit of that. So coming back to this
Caltrain Schedule, I’ve actually been working
on a small little feature to get the live position
of every single train. There’s an API for it, and I
could get the live location. So you’d see down here at
the bottom of my JavaScript, I’m asking my local server
for the position of a train. And I’m just polling
for it because I’ve just started the feature. I’m very early on this one. So let’s kick off
the node, right? So we’ll come over
here, this guy. And what we can do is, we can
hit node –inspect in the app and, ignore that for a moment. We get this URL right
here, and this is the URL, and we can just actually
Copy-Paste it into a browser and start debugging. But in this case,
it’s kind of awkward because I already have a
tab open with dev tools debugging the front end. It would be nice to be able
to look at the back-end too. So I’m actually just going
to allow this to run. But I’m going to come back
over to the sources panel. Now when I open this
up, and in addition to the main thread and
the service worker, down here is node. And it’s like, oh yeah, you’re
running node, aren’t you? Do you want to debug that, too? Yeah, actually, I’d
be down with that. OK, good. So now we’re connected to node. And I know this because,
if I switch over here, and I’m looking at
just the node context, that error that I
was getting over here is still also exploding
my screen over here. So that’s great. OK, train is not
defined, apparently. So let’s see what’s up. So there is my app.js. This is my node code, and
apparently there is an error. Let’s just pause on exceptions,
it just paused right here. Train is undefined. Right. Yes. Good. And train, train–
trainID, yes, mistake. My bad. trainID is just train. I’m just going to
hit Control-S, and I think that takes care of it. And we’ll know if we
ceased any API request. It’s paused. Who said that? They get two extra
points in the quiz. OK, paused. All right. Yeah, good. Yes. OK. And in fact, coming back to
my other context in my page, I went from a bunch of– 500s
internal service areas to 200s. And that’s what you like to see. Good, OK. So really excited about this
because this allows us– [APPLAUSE] Yeah, sure. Yeah. They’ve got to clap on the 200s. We’re excited about
this because this allows us to use a
single dev tools, and speak to both the
front-end and the back-end at the same time, keeping
your attention in one place while managing multiple
contexts, which is good. All right, moving on. We’ve heard a bit about
progressive web apps today, and there’s some nice tools in
the dev tools to talk about. Now briefly, just
review some of them. Over in the application panel,
there’s some great stuff. First up, the manifest
view will tell you what’s in your manifest. And in fact, if the
browser finds anything and it’s not so sure, and it
issues a warning or an error, you’ll see them shout it out
right up here at the top. Then the service worker
pane tells you everything. The state allows you to
manipulate the service workers. And then I really like
this, the clear storage pane allows you to not only on
register your service worker with one click, but
take care of your cache storage, your AppCache,
and your local storage. Just wipe it out
and start fresh. I use that all the time I do want to spend a little bit
more time on the service worker panel itself. And there are two
things that I want to point out for you,
really helpful tips when you’re doing
this debugging. Up at the top or
some check boxes. The check box in the
middle, update on reload. This is a super helpful guy. You can think of it
as a disable cache, but for the service
worker JavaScript itself. It’s great for
when you’re working on sw.js, the serviceworker.js. And you’re making changes to it. And you want to make sure that
you load in the new version every time. It will just make sure
that as you reload, it pulls in the new version. Now I don’t have to worry about
some of the caching stuff. The other checkbox,
bypass for network, basically says hey
service worker, you love to intercept requests,
and surfing the cache, and all this stuff, but I’m
working on my site right now, and I’m updating my styles,
and my page is JavaScript, so I really don’t want
you to be serving things from the cache intercept. So just chill with
the network stuff. So what this allows you is to
iterate on your page’s content, your styles, and JavaScripts
without the service worker getting in the way. So definitely check those out. And as you work
with these tools, and find things that are
making you question stuff, feel free to just
holler at us and ask us if there’s a better way
that the tools can represent what’s going on, because we’d
love to make sure we can help. Now there is a lot of things,
in doing progressive web apps, that you have to keep track of. And especially if it’s your
first time just getting your manifest and your service
worker set up the right way, it’s a little tricky. And so we’ve been working
on better ways for us to understand if we’re
hitting all the right marks, and if there’s
anything else that we can do to make sure that
what we’re building is great. A lot of that work
and that investment has gone into a project
called Lighthouse. And Lighthouse is a
guidebook for helping you turn a web app into a
great progressive web app. And more than that, it analyzes
any web page and any website, and not only collects
performance metrics, but helps identify
all sorts of developer best practices that you can
be doing, and making things better. So as an example, it audits for
a number of different things as far as– can the user
be prompted to add it to home screen, does it
have a custom splash screen, but other things like are you
using passive event listeners when you should? Are you avoiding mutation
events and document write? And over 40 different audits
checking for just developer excellence. On the other side, it
also does a great job of having performance
metrics that capture the user-perceived
performance in the most accurate way possible. So you’ve heard a little
bit about First Meaningful Paint and Time to
Interactive, Lighthouse measure those and helps
illuminate what is actually happening when things are slow. So Lighthouse is available
as a Chrome extension. You can see a little
bit of it here. See over here, I can run
it from the command line. It’ll just kick off a new
version of Chrome itself, and just run all the
same tests there. And this works well. Lighthouse is just a
node module and, in fact, a number of other tools are
already using Lighthouse and building on top of it. So feel free to check
it out like that. It works well with
a headless Chrome in a continuous
integration environment. So if you want to
set up progression tests for performance or audits,
you can definitely do that. And the other thing
is that we’ve really been happy with how doing these
checks to see– going along the right path– this has
been working out for us. Well we want to make sure
that’s even more available. So I’m going to show
you another new thing. I’m going to come over
to our Caltrain Schedule. And here in the dev tools,
we’re like– maybe we should have it
available, not just here as a Chrome extension. So open this up, more tools,
and we have a new Audits 2.0. So this Audits 2.0 is
powered by Lighthouse. So as I– I’ll just make this
tab right– yep, there we go. So I’m just going to
go ahead, and this is using the same
Lighthouse that is in the extension,
the command line, running on the same checks. So it’s looking for things
like usage of document write, usage of
blocking style sheets, and helping you understand
what’s going on. So pretty soon, it’ll
give me a report. I’ll be able to browse that. And yeah, looks pretty good. Fast, the site is fast. Good job, Sam. OK. But scrolling down–
this is interesting. Check this out. Site opens external
links using rel noopen– and in fact, we have two
links on the site, which are external, open in new
window, and not using this guy. You’ll have to read about this. And this– I saw this
and honestly, we really need to do this. So this is super– yeah. So I’m going to fix that like
right after I get off stage. But I encourage you
to check this out. The nice thing here
is that, because this is using Lighthouse, Lighthouses
just sitting on GitHub. It’s a bunch of JavaScript. So if there’s anything that
you’re interested in auditing for, or just want to
check, just please come by. Drop by. We’ve had a bunch of people
collaborate on the project so far. So come check it out. Talk to us if you
have any ideas. We’d just love to
work on it with you. So what did we see here today? A few things, we
walked through looking at stronger debugging
with modern JavaScript, and I got to show the
inline breakpoints. Love it. The parallel debugging with
node.js in the browser, at the same time,
a single window. The persistence, saving
to disk really painlessly on a magical mapping
between everything. The CSS coverage to find
what CSS you are not using, and new auditing functionality
available in all the right places. If you’re not,
follow us on Twitter. Our docs are there. And just please grab Canary. Turn on some of the dev tools
experiments if you want, and if anything, bugs certainly. But even just feedback or ideas. Go to see our bug. It’ll be like do you
want to report a bug, don’t file feature request. But just ignore that, and
just file a feature request. Just like, hey guys,
what about– you know, what do you think? That’s fine, we’d
love to hear from you. That’s it for me. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

Tags: , , , , , , , , , , , , , , , , ,

50 Comments

  • Joshua Graham says:

    2016 and interlaced video is not dead yet. Nice.

  • Pablo A. says:

    amazing new features

  • Luke Moll says:

    is there a way to debug Node apps running on a remote server? (I guess that would require SSH, SFTP implemented within Chrome so probably not)

  • puppeteer701 says:

    Is it possible to use any linter with ChromeDev Tools?

  • Aman Miezan Echimane says:

    In Case anyone else wonders how to enable those experimental features in canary.. https://developers.google.com/web/tools/chrome-devtools/settings (In the Enable Experiments section)

  • Dante Delos Angeles says:

    Amazing content, but panning away from the screen while a demo is happening is quite annoying : (

  • Junil Kim says:

    inline breakpoint is awesome!

  • Brameshmadhav Srinivasan says:

    30 minutes of Dev tools awesomeness !

  • Stéphane SALLES says:

    Pour une vidéo de démonstration on s'en fou un peu de voir le publique applaudir on préférerai voir constamment le code changer 😉 Mais merci pour cette trés bonne vidéo ! ^^

  • Jayden Pearse says:

    Had to rate down just because of the camera. A demo doesn't work if I can't see what's happening

  • Denis says:

    hm aha uhu aha that's good HA THAT'S GREAT! 😀

  • Balint Fulop says:

    Would love if changes to a source file would persist after page reload. If on reload, Chrome would use the local mapped file.

  • Christopher Vicuña says:

    Nice!

  • Grzegorz Bielak says:

    Which version of Chrome this is going to be?

  • Leo M says:

    4 people didn't open DevTools

  • fake farm says:

    You da man, Paul! Please tell your team that we YouTubers appreciate their great work! lastly, I like your management technique to build a web app to know where Sam is on his daily commute.

  • fayekhelmi says:

    i love this guy…. the thought process sounds exactly like mine when coding hahaha… we're all a lil silly <3

  • Jay Scott ANDERSON says:

    6:12 Safari cred. I like it.

  • vitvad says:

    Every year I wait dev summit only for this part with dev tools 🙂

  • Jordi Tanta Diaz says:

    There is some article or documentation about accuracy, validity or reliability of Chrome DevTools?

  • Jon Gale says:

    Good content, poor delivery. Sorry Paul but you need to work on your public presentation skills.

  • Chris Gabler says:

    Ok, Chrome 55 is out, but it seems this css coverage-tool isnt included yet?! Cant find it – just in Chromium?

  • Francisco Ramos says:

    This guy is one my favourite speakers

  • b j says:

    nice presentation. I'd love to see cold folding in sources.

  • Ido Green says:

    Excellent stuff Paul! All the important updates of devtools in 30min 🙂 very cool!

  • Attamjot Singh says:

    loved the video alot. The one thing that I liked about you Paul is simply annotating the big things into small . hats off. one day will be part of your team Paul .

  • Beany Vu says:

    Reallu love Paul. He is my inspiration developer!

  • thierry rene matos says:

    "problems are good", this guy is awesome!

  • hbb says:

    This guy looks like Sherlock Holmes. Investigating JavaScript issues 🙂

  • Adel Jojo says:

    Paul is growing old too quickly! Great talk! Thank you.

  • Adam Acosta says:

    Anyone get the workspace persistence to work? Is it only in chromium or Canary? I've had no luck getting it to work.

  • ThunderousGlare says:

    Summary:

    1. Better side menu in source pannel, resizable
    2. More ES6 Support like arrow functions
    3. multiline editing with functions in console
    4. array[2]. now will do auto completion just like obj. does
    5. inline debugging capability instead of just perline breakpoint
    6. drag and drop work folder instead of creating workspace then edit css/js right in browser
    7. ability to find unused css via recording in timeline > css coverage, then interact and stop recording. Unused will be highlighted.
    8. start node –inspect url and connect without opening url, right from console using frame select option.
    9. Bunch of Progressive Web Apps stuff you don't care about right now
    10. Lighthouse aka page speed is built into chrome.

  • Adarsh Konchady says:

    Why can't the cameramen be educated to focus well on the slides throughout the talk. Excellent content but poor coverage !

  • Ribsletics says:

    This guy sounds like a douchebag prick. But nice presentation though.

  • ndstephens says:

    Worst editing i've ever seen. Why are we looking at him or tracking across the audience while important actions and changes are happening on the screen? We completely miss what he's doing several times. I eventually stopped watching. Never use that video editor/director again. What a waste

  • Layton Miller says:

    I clicked through to 1) congratulate the good presentation and 2) provide the feedback that whoever edited this keeps cutting to Paul Irish right when you need to see what's on screen. Can we get some technically savvy camera folks next time so they know when it's appropriate to show his face? Kind of defeats the purpose otherwise.

  • John Vandivier says:

    "Gotta clap on the 200s" 🙂

  • Paulo Griiettner says:

    Jesssseeee… why the guy take away the screen while he is showing the stuff.. I literally lost few very important things, because there is someone that does not know what they are doing when editing the video…

  • Michael Scott-Nelson says:

    Is there a version of this where it doesn't pan away from the screen at critical moments?

  • Stephen Richardson says:

    Your my511 api token is visible!

  • Khamyt Sharipov says:

    Переведите плиз на Russian Lang

  • Shifter says:

    15:57 Оторвал бы руки тому кто переключил камеру >_<

  • kingluke2 says:

    Ugh. The "automagic find all your files" "how it works is really complicated I won't even talk about it" workspaces 2.0 feature explained starting 14:28 broke my entire dev workflow. It doesn't find my local stylesheets and scripts correctly (even though they're a simple flat folder that matches the network structure) and now that it's "magic" there's now no option to "map to file system resource" like before. Really frustrating when programmers break the tools you rely on.

    If Microsoft Office Autoformat and Clippy was any indication: software that tries to guess what you want to do and eliminates manual options almost always ends up getting it wrong and becoming more frustrating to use the end.

  • Wilker Lucio says:

    Come on, stop taking the demo away!

  • Dmitry Astapkovich says:

    I've got here after clicking on What's New link for Workspaces 2.0. I'm on Chrome 63.0.3239.132, but I still can't make Workspace working even for just local CSS and HTML file.
    What am I doing wrong?

  • Varun Sharma says:

    How to get the watch window, call stack etc. at the bottom of the screen? On Win 10 it's on the right side. Can we move it down??

  • Álvaro Lagos says:

    No puedo realizar "custom mapping" ahora en workspaces 2.0 🙁

  • Sergey V. says:

    Peace of crap! Now source -> live editing complete broken! Thank you for this mr. i know how to broke things that worked before just perfectly !

  • James Monroe says:

    16:56 I'd appreciate if you actually did attempt to explain how. Somewhere. Anywhere. Calling it magic doesn't help us debug WHY it isn't working for those of us not blessed enough to have it work automatically.

  • javi garcia says:

    so nice, precise moment when he links folders and the video goes to his face… please show the console!

Leave a Reply

Your email address will not be published. Required fields are marked *