EdgeConf 3: Developer Tooling
Articles Blog

EdgeConf 3: Developer Tooling

August 17, 2019

BRAD: Yes, welcome to the second
session of Developer Tool, no longer a phrase that was used
to bully me in the school yard. It’s a key part of
Web development. It’s difficult to imagine how
we survive through a period where all we could do
is play a game of higher or lower with alerts. I mean, that’s how I
first started debugging. And browser error
messages were, at best, indistinguishable from
stoner philosophy. Things like, undefined
is not defined. Thank you for asking. Too many arguments,
just everyone chill out. A goal of the future,
where can we take this? Well, I’m joined by
this panel of developers developing developer tools with
developer tools for developers. They are, Kenneth Auchenberg,
started RemoteDebug, an effort to unify remote debugging tools. Henri Bergius, I’m going to
pronounce your name wrong already, sorry, the
founder of NoFlo, the Kickstarter-based
visual flow based, Web development
environment. And we’ve got NJ, the
instigator of Brackets, Adobe’s code editor built off
the back of Web technologies. Representing the browsers,
we’ve got Joe Walker, who’s working on Mozilla’s
new shiny developer tools. We’ve got Pavel Feldman, who’s
working on the Chrome developer tools. And to start us off with
some words about things, a man who needs no introduction,
a big up to my Chrome boy, it’s Paul Irish. PAUL: Thank you. All right. Brad, thank you. So I want to give you a
brief overview of kind of where we’re at in
Web developer tooling. If we can get my slides
up, we’ll be good. There’s been a lot of
iteration movement lately. But I wanted to first,
kind of bring us back into kind of the history
of a– just a moment. SPEAKER: Click on the big X. PAUL: It’s not me. It’s that computer. [INAUDIBLE] PAUL: Yeah SPEAKER: We adjusted. We’re good. PAUL: It’s right. It’s right. SPEAKER: Here you go. PAUL: Love it. All right. Thank you guys. I’m going to give you a
quick overview of where we’re at with Web
developer tooling. But to do that, I want to
head back and talk again on the history. Back in 2006, Hixie, the
editor of the HTML5 spec, he was kind of testing
out how HTML is parsed. And he wrote a tool. At first, he was
diagramming how DOM is constructed,
based off of HTML. And he’s like, you know, I can
create this live DOM viewer. And so here is the
DOM view of what we’ve constructed with, in
this case, just a quick P tag, right? That’s our DOM. And then it just so happened
that only three months later, this guy basically debuted. Just three months
later, Joe Hewitt released these initial
screenshots of Firebug, leading us to the angle brackets
representation of the DOM that we know, and love,
and see every day. Now, I do want to shout out to
the more OJI developer tool. This is Venkman, the JavaScript
debugger inside of Firefox. This debuted around 2001. So it was really kind
of the first thing. But since then there’s
been a lot of movement. So fast forwarding,
now I want to show you where some of the developer
tools are these days. So first, over on
Firefox, there’s been some fantastic
things happening. I’m going to show a quick
preview of what things look like with the WebGL
Shader Editor. So what we have here
is a WebGL scene. And we are live
editing a GLSL shader, kind of changing some of
the dimensions of this. One of the really nice aspects
I like about this editing environment is, as we live edit
it and make some mistakes, we actually get feedback
on validation errors that we are triggering
in the GLSL. Now moving outside
of that, there’s been a lot of fantastic work. This is a screenshot of some new
upcoming work from the memory tooling inside of
Firefox developer tools. Keep snapshotting
and showing what’s going on inside of the memory. You might have seen this. This is a nice
visualization of what’s happening with CSS transforms. Really fantastic to understand
how exactly the original shape is being modified
through transforms. Also, this is fantastic work. We’re just stopped
here at a breakpoint, but we understand the various
scopes that are active, and see for instance, how
a certain variable may have been available in
a previous scope that has now been overridden. So it gets striked out. And then this was a
fantastic experiment that I don’t think
has landed yet, but I like where it’s going. It’s audio breakpoints. So basically, kind
of like hearing when different points
in your code get hit. I really like this approach. All right. So over on Chrome
DevTools, there’s been some fun stuff happening. You might have seen
screen casting. So this is an effort to
say, hey, we can actually take what’s on the
screen of your device, and show it inside of
your desktop browser. Not only can we show it, but
also have it interactable. Because typing on a
phone is pretty slow, we can just type on your
keyboard, click around, and all those clicks will
be translated into touches on to the device. Then a few more good stuff. This is a flame chart
visualization of the JavaScript profiler, giving you
good insight as far as how, across time, your
JavaScript is executing, understanding what is
sort of the pattern and rhythm of function
execution inside the browser. This is device emulation. So emulating not only
screen resolution, the device picks a ratio,
the view port configuration, touch events, and doing that
all right inside of a desktop, so that we don’t actually have
to even go over to the device. And this is a new upcoming
feature, asynchronous call stacks. So we can actually
see from where we are how we got
there across an XHR and across a set time out. So we can trace all the
way back in that full line. The IE team has
been trucking ever since the new release
of their F12 DevTools. They’ve done some
fantastic work. This is a quick screen shot of
where the new network tool is. Really good looking waterfall,
and a lot of detail in there too. Also, new to the F12 tools is
proper memory-keep snapshotting and memory profiling. So here we could
take two snapshots. We can compare them,
see what’s going on. And one of my personal favorites
is their new UI responsiveness panel, which gives
a lot of insight as far as the operation center
happening inside the browser, how that relates to frame rate. So we can help
identify how exactly we can improve the
performance of the page and reduce the jank. So Kenneth, here, from
the RemoteDebug project, showed this fantastic
demo over a full frontal. RemoteDebug is a fantastic
way to, basically, bridge the gap between
different browsers, their run times, and their
browser developer tools. So we actually have
Chrome’s Developer Tools interacting with
the Firefox browser. And not only can we
inspect elements, but also change the DOM of Firefox using
the Chrome Developer Tools. And there’s a lot more
where that came from. NJ from Brackets. I wanted to show this
quick and fantastic demo. Brackets has long been doing
kind of live CSS development where you can just
change things on the fly. But this is the live
HTML development. Mapping HTML to DOM is
not a trivial thing. But here, we are moving
around to our HTML. Our DOM is updating. And we do a quick view into the
CSS that applies for this H2, and make those
changes on the fly. And make it hot pink because
that’s the right way to go. [INAUDIBLE] PAUL: All right. Another fantastic thing
inside of Brackets is the Theseus JavaScript
debugger, really powerful work. So here we actually see
a log across our code of how it actually executed. We had four calls. That then entered
into the fetch. And we can also see,
of those four calls that entered into the
fetch, two of them went into the ErrorHandler. And then we can
actually see, oh, we went into the ErrorHandler. What was in the error object? We can retroactively look
inside of that error object and inspect that situation. Henry from NoFlo is here. And I want to quickly show
what NoFlo looks like. It’s a new kind of
flow-based visual paradigm for writing JavaScript
applications. Let me see if I can
get that video back up. Barely. But it kind of turns the idea
of looking at code on its head, and introduces a much
more revolutionary idea for building together
rich experiences. All right. So beyond kind of what’s
represented here on the stage, there’s a few other
things that are happening inside the ecosystem of
browser developer tooling. I want to quickly show. The TraceGL project came out
a little while ago, but said, we’re just going
to log absolutely all the operations
that are happening. In this case, we are
logging not only all this, but we inspect retroactively
what happened here. And we can actually see
these if statements. They’re in red
down at the bottom because these
conditions were not met. So visually we see,
oh, these all failed. We skip those conditions. And we skip the associated
context blocks with them. Spy-js is a similar
kind of thing. This has since been
acquired by the WebStorm, and kind of consumed
by the WebStorm IDE. But over on the left-hand
side, we have all the run loops for different events,
and then the call stacks that they triggered. And then we can
identify how exactly we map those call stacks
into the code, really nice useable experience. This is a project
called [? Ear ?] Horn, but you might have
seen a similar thing from the Light Table IDE. Here, we map in the
runtime information of what’s happening
inside the browser and bringing that
right into the code. So we can see [? Un Mouse ?]
move, all this, our client X, our client Y’s live updating. And we can get a good
idea, while looking at code, what the state
is in the browser. This is a quick
shot of looking at, per statement-based,
JavaScript profiling heat map. So we can see at the
statement-level, or even expression-level, where
our code is most expensive. Adobe’s been doing
some fantastic work inside the browser. This is an experiment for a
GUI for editing CSS shapes. So we can move around
inside the GUI. And we update the
CSS-shaped polygon that’s defined underneath it. And we’ve seen a fantastic
amount of innovation when it comes to all the
JavaScript frameworks that are creating better
tooling for themselves. So this is React’s
Chrome extension. It looks like kind
of standard DevTools. But it’s actually
completely representing their kind of applications
state of the world and all its properties. And similarly, this is
Ember’s Chrome extension. They have a fantastic
view of all the promises that are active and
fulfilled inside the browser. And this is inspiring a
lot of browsers themselves, as far as how we can better
supply good information around some of these new things
like promises inside a browser. So to me, like, what is the role
of developer tools these days? Allowing us to develop fast
at the speed of our thinking, letting us go as quick as we
want, making debugging suck less. None of us want to be debugging. Hopefully, tools can help
us avoid the situation when we are debugging. But when we’re there, it
should be easier for us. And Web development is hard. Tools can help keep
us on the golden path, make sure that things
are performant, make sure that things
work great across devices. And tools can help fill in the
gaps of the knowledge that we don’t have and the
things that we forgot. So I think developing for
the Web, for JavaScript, can be better. Everyone on this stage
believes that, has been developing tools. And I’m excited to
see what’s next. Thanks. [APPLAUSE] BRAD: So Paul is
going to duck out now, because he’s got
the dreaded illness. I can hear a few people
in the room have. So we’ve got his stunt double. Pavel’s going to fill
in on the panel for him. Yeah, I can hear a
few people coughing. I had it last week, as well. I’ve managed to trace
it back, talking to some of the employees
of GDS who took a trip up to Newcastle. And I hear that that’s where
this illness first came from. So it’s another
valuable addition to the world from Newcastle. Thanks for that guys. I’m kidding of
course I love Greggs. Right, first question. But before we start, these
guys are developing the tools that are supposed to
make your lives easier. So if they say anything
you disagree with, or there’s anything you want to
elaborate on, then use onslide. If that’s not working
for you, please just raise your hand for now. I’ll pick you out
for a question. The first question comes
from Sebastian Keavy. Where is Sebastian, over there? Will you get Sebastian
a microphone? SEBASTIAN: My question
future, can we expect to do all of our development
within the browser? Will browser DevTools
become a full IDE? Or should browsers concentrate
on interfacing better with IDEs? BRAD: So Micromedia
brought a rendering engine to their IDE 17 years ago. But now it feels like
browsers are bringing IDEs to the rendering engine. And now we have
code editors that are written entirely
in browser technology. Joe, I’d like you
to come in on this. Do you see Firefox’s
DevTools becoming a full IDE? JOE: So I think
nobody would like us to say you’re not allowed
to use Sublime anymore, or whatever your editor is. AUDIENCE: Brackets. JOE: Or Brackets, yeah. So that’s not going to happen. On the other hand,
there are things that the browser knows about
how it’s laying stuff out and what values are inside
the JavaScript engine that you could only
know by being a browser. So there are times
when you will want to edit stuff inside
a browser, as well. So the answer, I think, is both. BRAD: NJ, your answer is
also a browser, right? NJ: I wouldn’t call
it exactly that. I think our goal is to tie
more closely to browsers. I mean, exactly
what Joe said, which is that there are things that
only the browser knows about. And browsers, in
my opinion, should focus on what they
do really well, which is inspection, right? They’re inspecting the runtime. They can tell us all
this information. That information, I
think, for quick stuff, or when you’re really
focused on the browser, it makes sense to have
tools in the browser. And obviously, it’s a
great workflow for that. But there’s times when what
you’re really focused on is your coding, right? You don’t want to live in the
browser when what you’re doing is writing a bunch of code. And you’re just trying
to get stuff working. And you’re iterating
rapidly on your code. The browser isn’t
maybe necessarily the best environment for that. So I think what we
should really be focusing on for that aspect is to
make it so that the browser information is exposed to
code editors and other kinds of tooling, NoFlo, or whatever,
so that we can provide a much richer
development experience outside of the browser as
well, working with the browser. HENRI: I agree with you. That’s the whole reason
why I started RemoteDebug. And Joe, I actually
disagree with you. Because the browser today
has a lot of information that is not exposed
to the outer world. But I think that’s a problem of
the state we’re in right now. And because, frankly, what
NJ is building with Brackets is that he would love
to have that information available to write better
JavaScript debugging, get information about the
DOM, the network stack, all these kinds of things. I assume you would love to,
to pipe them into your editor. But he’s not allowed because
he cannot get the information. So I think the responsibility
of the browser windows is to expose that information. And that’s why I
think we need to start an effort like RemoteDebug
to unify and build an interface to our browsers. So all the tooling vendors
like Brackets, Telemetry, Benchmarking tools can start
accessing that information that, right now, only privileged
tools like built-in DevTools and browsers has access to. JOE: So there’s two
different things there. Firefox developer
tools work remotely. They log in through
a TCP socket. HENRI: I know that. JOE: All of that stuff you
can get at as well as I can. So we’re not keeping
anything private at all. And there’s a self-documenting
API to get a list of everything that we are talking to. There’s a second part to it. And I’m sure there’s going to be
another question on this, which is should there be a standard
protocol by which we debate? BRAD: That’s another question. JOE: I can feel it coming. NJ: We’ll get there. BRAD: Is the browser, because
it has the runtime all built in, is it in a better
position to do things? Like even with code, like
Oracle Complete, I mean, I watch games developers work. And it seems to me that they
just write a comment, to do, make Half- Life free. And then from then they
just hit the Tab key. You know, the best games
developers are also the best at Track and
Field, the arcade game. Is the browser in a better
position to do stuff like that? JOE: Yes. So we’ve got some stuff that
does fairly deep analysis of JavaScript now, and will do
some fairly clever completions that is just landing. I mean, to be honest,
most of that technology is static, which Brackets
could do just as easily. NJ: But I think there is
actually value in doing it. We did some experiments
early on– we haven’t really done it in
Brackets– around essentially querying the runtime
for information. JOE: Right. NJ: Like, if you’re
stopped at a breakpoint– JOE: Right. NJ: –you can just ask
it, what’s available now. JOE: There is more stuff there. Yes. NJ: And again, we could
do that from a code editor as well, as long as it’s
exposed to the runtime. JOE: Yeah. NJ: I guess the other point
I would make– I don’t if I’m getting away from what
you were asking but– is that you also want to
write other kinds of code besides browser code often. And so having one environment
for, hey, you know, now I’m going to do browser
stuff, and now I’m going to do my
Node stuff, and I’m going to do my Ruby stuff, or
whatever, seems a little funny. Of course, if you were
just doing JavaScript, maybe you could re-target the
in-browser developer tools to node. I mean, you can already do that
with node-inspector and things like that. But I think there’s
room for lots of different kinds of tools. People have lots of
different workflows. They have to work with
local command-line tools. They have to do this and that. In terms of, you
know, the browser has its role as a
kind of sandbox-place where you do browser stuff. And I think that, again,
I think the solution is you have both kinds of tools
and they talk to each other. HENRI: Yeah, like,
I don’t think having a contextual DevTool
built into the browser is ruling out having another
tool like your editor. But the kind of problem I think
by having really specialized browser tools for each browser
is that, as a developer, I need to learn a
new DevTool when I’m targeting another browser. So that means my workflow
is kind of broken. Because if I have
to go with Chrome, I need learn how to
use Chrome DevTools, navigate the source
code, set of breakpoints. If I do the Firefox, I
need to learn their tool. And to me that’s
disconnecting my productivity. JOE: So there’s a lot
we can do to help there. So you’ll notice that
in Firefox DevTools now, the key sequence is the
same as in Chrome’s. In our box model highlighter
that just landed then all of the colors to denote
borders, paddings, et cetera, they’re the same colors. And IE is exactly
the same as well. So there’s stuff we
can do to help there. I think there are
many reasons why just saying there should be
only one tool is hard. That’s that old
question again, which we’re going to come back to. I’m sure. BRAD: Before we move on
to the next question, I’ve got a question
from the floor from everyone’s favorite
shaver, Remington Sharp. REMINGTON: On the point of
working with FireFox DevTools, working with Chrome DevTools,
working with IE tools, I haven’t used
the F12 tools yet. And when I look at
the UI responsiveness, I wonder whether
or not that’s going to give me more insight to the
responsiveness of my web page across all the browsers, or
if it’s just for that browser. And that’s something I’m unsure. I mean, I’m quite
comfortable in Chrome. And I can navigate
DevTools very well. But am I debugging
for Chrome, or am I debugging across the platform? In most cases, it’s bugs. Yeah, sure. But for things like
performance and responsiveness, I have no clue. And do we need all
these different tools to target each browser? BRAD: That actually leads
into our next question. So I’m going to get heard,
Shane Hudson to read out. Because it kind of
expands on that. Microphone for Shane? SHANE: Hi. So you rewrote my
question for this. Initiatives like
RemoteDebug look to unify development tools. Is this a good thing or could
it have the diversity of [INAUDIBLE]? JOE: So that’s
this question then. So some people would like
to just have one tool. And obviously, many
tools are being created. And there’s a ton of ways
in which our tools are specific to what we’re doing. So there’s new APIs that
we’re experimenting with. We need developer
tools for that. And we wouldn’t
expect the Chrome team to provide us with those tools. And there are
optimization techniques that will work in one browser
that won’t work in another. I think there are good reasons
why we have an obligation to tell you about the stuff
that is in our browser. The only people that can
tell you about it is us. We have an obligation
to do that. And so that’s what we’re doing. KENNETH: So on that, if
there was a standard way to get that info
out of the browsers, then some third party
interested in building that kind of profiling tools,
specifically given task, could easily go and
grab the same data, feed the same HTML JavaScript,
whatever, to IE, Firefox, Chrome, grab all of those
statistics and show, OK, here’s how this and this thing
performs in that browser. And right now, that’s
something we don’t really have. NJ: We definitely don’t
want to kill innovation. I mean, it’s great that you
guys are doing different things. And you guys are doing
your different things. But as you mentioned
just now too, you’re trying to make some
things the same, right? Because you want them
to always be the same. And for just basic
functionality, I want to set a breakpoint,
I want to do this, I want to do that. Even the more
inspection stuff, it seems like it would
be valuable to have, at least even at the
highest, shallowest level, some kind of just
basically common protocol. Just to make it so that
we can talk the same way. And then this browser might
have certain extensions for the stuff that it does. And another browser might
have different extensions for those things. But on places where
there really doesn’t need to be a huge
difference, at least in the core
functionality, why not? HENRI: Well, I would
say, Joe, first of all, I don’t just want one tool. I really like that we have
multiple tools available. But as a developer, I don’t want
to swap between multiple tools just because I’m
[? tied into ?] another browser. I don’t want to change my
workflow as a developer while I’m crafting a
debug in my application, and learn new
workflows because I’m [? tied into ?]
multiple browsers. And that’s the reality
that’s in front of developers today is that we have a
bunch of different browsers with different tools
that we need to learn. And it’s counterproductive. JOE: So my hope is that your
workflow isn’t that different. You know, setting a
breakpoint, that kind of thing is, basically, very similar. And so I’m hoping that– HENRI: But why do I
need to do it twice, once in Firefox DevTools, and
another one in Chrome DevTools. JOE: Right. So two different use cases here. There’s what Brackets
are trying to do, which is to log into our
DevTools, set the breakpoints, inspect the variables,
that sort of thing. That’s one level of difficulty. There’s a whole different
level of difficulty, which is, make Chrome
DevTools work against Firefox. HENRI: I know. That’s a prototype
I’m developing. JOE: There’s a massive, massive
difference between those two. And what you’re getting
into, trying to do that, is all sorts of
complicated problems about object lifetime in
the browser, et cetera. There’s a multitude
of problems there. HENRI: It’s that simple. JOE: Now as far as the
case for simple debug goes, so just
think about writing an add-on for a browser, right? So we started off
with Firefox add-ons, which will do
absolutely anything. And then there’s a
new API that’s safer, that comes on top of that. And then it looks like we’re
at a state where maybe we could have the Chrome API
and the Firefox, you know, Jetpack API, there’s
some similarity there. And maybe we can
extract that standard. BRAD: Well, we’ve done that
with Greasemonkey, right? I mean, Greasemonkey let’s us– JOE: Right. That kind of approach,
of giving people what they want, you
know, everything, filtering it down to what
they need, standardizing it, that feels like a good approach. And I’m for that
kind of process. But it’s hard. PAVEL: So it seems like we’re
all in agreement with warring, right? We need to compete to innovate. And nobody’s taking that away. [INAUDIBLE] is sorry. 60 FPS is going to be different
on Firefox from Chrome. You need to use
different timelines. You have to use IE’s
timeline, at least for now. Because those pipelines
are entirely different. The [INAUDIBLE] you won’t
see with the Firefox tool. So if you’re going
for high tech, if you’re going for
performance, you need to stick with the tools
for the browser as of today. Now, talking about the
baseline that we’ve all discussed for a single
ID, or whatever, that will use that
baseline, I think that the ball is on your
side at this moment. Most, or all, of
the browsers are exposing their
prodigals as of today. They are different if you try
and bridge them on your side, and prove that there is a value
in bridging them, and talking to multiple
browsers, there would be an incentive for
us to standardize. Otherwise, as browser
vendors, who would always want to innovate first
and standardize later. BRAD: This kind of
standardization effort that you’re doing,
is this something that you see going
to a standards body, such as the W3 or
the [INAUDIBLE]? HENRI: Well, we’ve
been discussing that. And I think it’s too early. Because frankly,
right now, we don’t know how to build for the Web. We don’t know how to
build Web components. We don’t know how
to build DevTools. I think what we need to
start and agreeing upon is the baseline, like,
is our remote debugging, is that going to use HTTP? Is it a [? DIP ?] socket? What is a very
fundamental protocol? And then we can discuss
all the API details, like how is the Firefox API? How is the Chrome API? The problem is if you’re
not a DevTool developer and you want to interface
with the browser, that is so goddamned hard. And what I see when I look at
what Visual Studio or Adobe are doing, and then they’re
sitting and inventing ways to do instrumentation,
to extract information out of the web app, so they can
protect that information and bring it into their editors. And frankly, I think that’s
a complete waste of time. Because that’s the
responsibility of the browser windows. You guys are building
the platform. You should enable the
ecosystem of tooling windows we have out there to
build tools for the Web. Right now, you only allow
yourself to build for the Web. And I think that’s
not good enough. JOE: So can I suggest
a way forward? The way forward here
is that we start off with something like a
JavaScript API, which allows you to do
debugging in a browser, whether that’s
remotely, whether it’s from one web page to another. I mean, that would
be pretty cool, to write a debugger
in a web page to look at the other web
pages, COD issues, obviously. Ignore the protocol
to start off with. Do it via JavaScript API. That’s the way forward. And that is something that
you could build on bit by bit. But that’s going to take time. BRAD: On a related
subject, I’ve got the next question
from Remi Sharp again? So could we get
Remi a microphone? JOE: Can we just wire Remi up? REMI: So my question
was rewritten, as well. BRAD: I just made them more
extreme to be more interesting, right? REMI: So currently
features launch before they have DevTools
for ATA promises, server-sent events,
web audio, and so on. Is this fair to developers? Shouldn’t we be ensuring
we’re developing features that are inherently debuggable. I don’t actually agree
with the question. BRAD: Well, you say your
bit first if you want. REMI: Well, experiments come
before standards, right? It has to. That’s the only way
we make any progress. So it should be
debuggable, but I want to be able to
get in there and debug it whilst the browsers catch
up with me as a developer. HENRI: So you just
answered your own question. REMI: Well, no. Server-sent events is a
really simple example. We’ve got tools for
debugging web sockets. We don’t have a tool to
debugging server-sent events. It’s hard for us to go
ahead and debug that. And why aren’t browsers
making that easier for us? [INAUDIBLE] PAVEL: I don’t think we have
a well-established process of duplicability
for new features. We try to have
everything debuggable by the time it leaves
experiment, or is no longer behind a flag. Shadow DOM is probably
a good example of that. Shadow DOM appeared. Duplicability was there,
also behind a flag. And promises are already there. But there’s no built-in
support for them yet. We’re working on that. So for us, the measure is
be sure [INAUDIBLE] stable. That’s an absolute
requirement for us. But there’s no better process. And it’s an area driven
by our customers. So if you file box about
lack of duplicablity of experimental
features, it gains stars. We will definitely look into it. BRAD: The promises bit
is really interesting because there’s a huge thread
in the spec discussion about promises where they were
saying, we’re not going to have a [? dot-DOM ?] method that
a lot of promises have. Because that method is
just there for debugging. And we shouldn’t
be putting things into the spec that are
just there for debugging. What’s your plan for debugging
things like promises? Is that something
you’re looking at? JOE: Yes. So we’ve got this thing
called tag stacks, which is the thing that you see
in Chrome for looking back through async things. I think it’d be good to
have some way of listing all promises that have been
unfulfilled in some way. That would be extremely handy. Yeah, we’d like to do this. I mean, DevTools are
written in JavaScript. We’d like it for our own
purposes, if nothing else. You know. We’re working on it. I don’t know what more
I can say than that. BRAD: I’ve got a question
more for the audience I guess. Given all these tools we
have like, variable watching breakpoints, who here
still uses console.log as their first bit of debugging? And I do this as well. And I find this crazy
because just writing debugger is less characters. It’s like shaving with
a knife when there’s a perfectly good razor
blade there for you. Why do you think people
like ghetto debugging? NJ: Well I think it’s
because you don’t have to navigate an
interface, right? It’s like, I know the piece
of information I want. So when you just put
it in the log stream I don’t have to go twirling
through things, right? Though, the flip
side is, you have to know in advance
what you want. That was kind of the
idea behind Theseus. And I think this is what some
of the other DevTool stuff is doing. And this kind of
omniscient debugging thing that’s been around, I think
it’s been in the Java world for awhile. You don’t have to think in
advance about what information you need. You just get it. And you can get it. Afterwards, you just sort of
use it and then figure it out. And I think that’s a
really powerful paradigm. The problem is that it has to
capture lots and lots of data. So it will be interesting
to see that go further. Another thing to
Remi’s point is– and this is something
Theseus does and I think other things
do– I think there’s actually a lot of power in
building debugging tools through
instrumentation, right? You instrument the JavaScript. And you can, you
know, like promises, you can instrument
the promises library and figure that stuff out. So actually having
a common library for doing that kind
of instrumentation for debugging just
purely in JavaScript without requiring browser
support would be kind of nice. And Theseus has the
beginning of that. It’s like a generic
instrumentation library. BRAD: I think aliens are
trying to contact us. We’ll just ignore it for now. I wonder if it’s
entirely the UI thing. I mean, it reminds me of an
argument I got into at school. It was typical of my
sense of humor this, because it was about urinals. And I pointed out that
the design flaw of urinal is that they lend themselves to
a certain amount of splashback. And I said, this is
something we should fix. And he said to me, no,no. If you don’t get
the splashback, how can you tell you’re pissing
hard like a real man? This is someone
who doesn’t enjoy being showered with
his own effluent. But he finds it affirms
his masculinity. Is that what we’re
seeing with console.log? I’m just using the bare
minimum of the tools to prove I’m a great coder. It’s proving I’m
not a good coder if I have to use all
the browser’s help. NJ: I’m going to stop
using console.log. I don’t know. [INAUDIBLE] comfortable
from now on. KENNETH: I don’t know what this
console.log thing is, you know. There’s [INAUDIBLE] right? BRAD: Exactly. Maybe that’s a good time
to move on to the, oh no. We’ve got a question
in the audience. AUDIENCE: Just one thing, so
I like the urinal [INAUDIBLE] and the other part is the
element of asynchronicity. So sometimes it’s
quite hard to know what order things
are triggered in. So if you’ve got events
and things like that and we find that often that
it just makes it easier to see the flow and
the sequence of things. So maybe it’s the
element of a lot of things are
asynchronous in a browser. And it’s hard to visualize
that and to reason about that. Is there a way to make
that better in the tools? KENNETH: Wouldn’t it be nice to
have this map where you can see [INAUDIBLE] that’s
flow in the browser. I don’t know. NJ: I mean, that is
an interesting thing about the flow-based approach. I mean, there’s been
flow-based programming like this for a long time. But it’s kind of
interesting that we haven’t seen it for JavaScript. And when you’re dealing with
large amounts of asynchronous, I mean, this is the
number one [INAUDIBLE] I think we have in
Brackets in general is just dealing with
asynchronous crap, right? Having visual ways to trace
that stuff is really important. As I said, Theseus does
a little bit of that. HENRI: One thought, here. What if we enable on
the platform level, like new development
approach, like this to serve as [INAUDIBLE], right? What if we allowed
external developers to build new kind of
tools for the platform. So it wouldn’t only
be the DevTools teams? BRAD: We do have a question
about that coming up. So we’ll save that for now. We’ve got a question
at the back? AUDIENCE: No. It’s just an extension
on the same thing really. I find for mobile
development a lot of the time I don’t want
to jump into the DevTools because I’m working on a
very fine grained, something with focus and blur
events, or touch start, and various things like that,
and jumping into DevTools actually interrupts that flow. So being able to look back as to
what’s happened in the last 10 seconds would be really useful. So that kind of thing
built in to DevTools, just a snapshot of
what has just happened rather than what’s
happening now. NJ: Have any of you guys
looked into omniscient [? to deal with that? ?] AUDIENCE: That’s why I don’t
use debugger most of the time. NJ: In the DevTools,
have you guys though about looking into that? Like capturing this data? PAVEL: Yeah. Outside of DevTools,
tracing has this feature. It can record what’s happening. And it shows you a sliding
window of what’s just happened. It is not traced into the
content world, though. So we don’t operate
nodes, just repair. And in DevTools we haven’t
started doing any of it. BRAD: We’ll move on
to the next topic. We’ve got a question
from Cornell. Where are you? A microphone for that man? CORNELL: Hi. There are lots of deprecated
APIs and practices that browsers could
detect and warn about. How can tools guide
developers towards better code without expecting developers
to run a specific profiler or manually interpret
the results? SPEAKER: I really
liked Firebug for this actually because it had always
visible a little error-counter at the bottom. And knowing that other
Firebug users would see that, so it spurred me on. I don’t want errors on my pages. Imagine the shame of it. You know? Is this a useful thing? BRAD: So yes. One of things that we are
putting serious thought into doing is to splitting
the web console in two. So one part of it would be
logging and one part of it would be JavaScript. So we’re putting lots and
lots of extra warnings into the console at the moment. There are all sorts
of security things like there are calls
errors in there, et cetera. And I think we should
be having more of them. And that basically encompasses
what you’re saying. But it’s going to make a
complete mess of the web console if we do that. So we’ll have two panels. That’s what we’ll do. So that’s what we’re doing. That’s what we’re
probably planning to do. It’s not code yet. That’s what the plan is. PAVEL: We are not quite
splitting the consoles. But we’re also working on
more warnings on deprecations, and not only deprecations,
but the performance issues, and potential
problematics for everything. HENRI: I would love to see
some [? linking ?] tools built in to the DevTools that
are contextual, right? So while the app is
running, then it could say, hey, this API is being
used, just deprecated. This is just this
goes, hey, you’re doing something that
is causing jank, that would be nice to have an
ongoing checklist of seeing stuff, right? Instead of just a
warning in a console. BRAD: Right. So one of the things we have I
think right now on Firefox OS is, on top of the display,
on top of your webpage, you’ve got a little
thing floating over the top, that tells
you about JavaScript. It tells you about jank. It tells you about
that sort of thing. There’s a bunch of little
things that will do that. PAVEL: So there’s
also a lot of things could be done using
instrumenting codes. We have a Prodigal
API that allows installing a pre-processor
that would instrument all the content from JavaScript
and chase it, log it, and do whatever you want with it. So we expect a lot of
innovation to come from there, from the outside, that would be
analyzed and promote the tool itself. NJ: Is that shipping already? PAVEL: It is. It is there for quite some time. BRAD: We’ve got tools like
Timeline and Chrome has as well, are we
seeing users use that? Or do want to be
in that position where we want to
tell people, hey, you have layout
thrashing going on without them having
to go to that and say, this is what layout
thrashing is, this is how you can find
out where it’s happening. But we know, just from
a small little test, that it is happening. PAVEL: It wasn’t the question. It was the answer, right? BRAD: Yeah. Can we have that? And when can we have it? HENRI: But I think that is
the solution to proper bit performance, better
information to developers. Just like YSlow did it for
bit performance, right? Most of the others was just
want to have a checklist to see, hey, I need to
complete these 500 issues, or what I have in my app,
and then I’m good, right? PAVEL: We do want to make
Timeline more popular. We want draw attention to it. And we will do that. And you will see warnings. BRAD: Makes sense. Right. We’ll move on to
the next question. This is from Kyle Simpson. Where’s Kyle? Over there. Microphone for Kyle. KYLE: All right. So disclosure of
bias, a couple years ago I worked with Joe Walker
on the Firefox developer tools team. So you just have to
keep that in mind when I ask these questions. First is, what’s stopping every
browser from providing headless access and automation,
kind of like PhantomJS, but for testing and processing. And that’s not just
JavaScript, that’s the entire stack
with HTML and CSS, but sort of headless
into the tools. So this shifts us away from
what’s happening in the browser to happening
outside the browser. BRAD: Pavel, Joe, ship it? JOE: So the very short answer
to your question is nothing. What’s stopping us? Nothing. There’s a finer question. What actually do you
want from headless? What’s the question behind it? KYLE: I want PhantomJS. But I want it from
the browser itself. I don’t want to have some
forked other project. I want to be able to spin
up kind of like a UI web view, [INAUDIBLE] Firefox, and
the UI web view of the problem. JOE: So it’s testing. KYLE: Some other tools, testing,
regression, performance, All those things. JOE: Right. OK. So yes there is SlimerJS,
which is basically this sort of thing. It’s not 100% headless. It’s nearly headless. It’s kind of maybe here. So yes, I mean, that’s
the most as I can say. I mean, I’m kind of out of
out of my depth here a bit. Because the answer
to this question is kind of like deeper
browser engineering than it is DevTools engineering. We’ve had new APIs recently that
should make this a lot easier. And I’m fairly sure that Slimer
is working on those APIs. PAVEL: We have a new
version of web driver is implemented on top of
the DevTools Prodigal. So you can actually drive
things in the browser. And there’s also a telemetry API
that allows headless operation. And that’s actually
how Chrome team is testing against regressions. So whenever you have a content
that you don’t want to regress in scrolling, you’re
using telemetry to implement the
[INAUDIBLE] script. So it is there. It is publicly available. You can use it. But it’s not standardized. And it’s Chrome. JOE: I mean, WebDriver is
enough of a standard, right? I mean, there’s that
inside Firefox now. Some internal Firefox
tests use that. So that’s becoming more of
a cross-browser standard. So let me come back
to why headless. You want to be able to run
it without touching it, as opposed to you don’t
want to see it, right? Because nearly headless is OK
if it’s not a visual problem. If what you want is
ultimately testing, you don’t matter if the
screen flicks briefly. KYLE: So there is the
testing side of it. JOE: Right. KYLE: There’s the
testing side of it. But there’s also a
functionality side of it. People use PhantomJS to spin
up a headless browser that they can render screenshots
from, or things like that. That’s the sort of thing
I’m talking about, being able to, in the build process,
spin up a tool for regression testing, or pulling out
rendering, or analyzing the way things are working,
all those sorts of things. JOE: Yeah. And part of the problem really
is that PhantomJS is not, you think it’s Chrome or
something, but it’s not. It’s kind of Chrome
from a few years ago with some other weird
bits and minus that. Yes. I think it’d be nice if
we were better at that. KYLE: But if we go to the
developer tools actually do matter here because,
for the testing purposes, a lot of times you want to
extract information that would be available
in developer tools as a part of those components. Because if this is a
part of your test cycle you might want to
audit the things that have not happened in trace. [INAUDIBLE] So it
should be a [INAUDIBLE]. BRAD: Was that something
that RemoteDebug would be able to help with? If we had a headless version
of these browsers could then– HENRI: I see that as a
natural extension, right? If we had a generic
interface with the browser, no matter if a headless
instance of Chrome or Safari. Then we would be able to
interface with the browser. We would be able to take a
tool like Chrome’s telemetry and use it across
browsers to do comparison of browser performance. It would enable a different
generation of tools as I see it. And things that we now
do specific to PhantomJS, and specific to
Slimer, I just want to interface with the browsers. And VIP drive is not
enough because VIP drive is focused only on
automated testing. I want to get information
about Timeline events, and all these other things that the
browser currently has, right? BRAD: We have a question
from the audience over here. AUDIENCE: This is more
a user-perspective kind of question, but with
window.error being so flaky, is it possible for the
browsers to put DevTools when they record an
error, to actually like, ping an endpoint
somewhere, which would– so you might
specify in the head this onerror ping my server
with the error details in the stack trace. So that way if
there’s a complete js failure due to cause or some
other unseen event, that you have an automated
kind of browser would tell you this and give
you user-metrics and statistics. KENNETH: So you want to get
that information from the view? Or you want to get it when
you are running locally? I didn’t get that? AUDIENCE: We had an error
where we put cross origin anonymous on a
Google Map script. And basically, Google
deployed a new version of Maps, which completely
broke all the JavaScript, nothing would run. So there was no error
reporting, no nothing. The [INAUDIBLE]
at Chrome said, we don’t want to run this because
there’s a security error. So would it be possible
for the browser to actually ping, so say,
if you had a metatag, say, onerror ping,
[INAUDIBLE] error reporting. And basically, you would
just send a stack trace. HENRI: Isn’t there
a spec around this? BRAD: This is one of the things
that [INAUDIBLE] people say. native is way better
than the Web at this, is getting metrics on what
the hell’s going on there. We should be better at this. JOE: Well, this goes
back to the point before about do
we build features that have debugging
built into them. I mean, we saw that
promises didn’t. But I think what you
were referring to, CSP has a specific
feature for logging back. Do we need something like
that for error logging? BRAD: A question
from the audience. Sir? AUDIENCE: Just,
sorry, back to that. What was actually your
problem with window.onerror, because at the [? Guardian ?]
we do exactly what you say and it works perfectly. AUDIENCE: No. But like say if there’s
a cause error, that wouldn’t be reported
in [? onerror ?] You will never get that. So basically, you’re saying
you need to pull up the script [? if you’ve got headers. ?]
The window.onerror would then report to you you
had a cause error. AUDIENCE: Yes. I guess so, yeah. AUDIENCE: Or your
basically saying, if you missed a code on it,
your window.onerror statement or something, that would
break your [INAUDIBLE]. JOE: So something
to pipe what you would see as an error in
console to your server. BRAD: The whole of
your [INAUDIBLE] panel, to redirect the whole
of that lot back to you. AUDIENCE: Yes. BRAD: You know, that
would seems like AUDIENCE: So basically because
I think it’s very flaky. It doesn’t really
work most of the time. So it would be quite handy to
have. [INAUDIBLE] to tell you what was going on. BRAD: I feel like there
could be some privacy issue or something. You need to think about it AUDIENCE: Even if you
went through Google. And then they like,
anonymize that. You’ve got to like, [INAUDIBLE]. JOE: Is this helping
privacy, or– Scary. [INAUDIBLE] AUDIENCE: I’ve got a Facebook
[? app to do this ?]. BRAD: A question
at the front here. Can we get a microphone? AUDIENCE: Hi. So I tried to push around
[INAUDIBLE] the performance and [INAUDIBLE] group to do
exactly what you guys were talking about. It’s quite clear that Chrome
has some [INAUDIBLE] telemetry UPIs. So my question is more
or less a call to action. So I tried to push
it into group. But so far, in both of those
groups, the [INAUDIBLE] group and [INAUDIBLE]
performance group– so far nobody was really interested
in going forward with this. If you guys have it and why
just don’t put a first version together with what we all have
there and try to draft of what can be standardized and
what cannot be standardized and start working on it. PAVEL: We were
just waiting for it to prove itself usable
and user friendly. And for now, we’re just
innovating and moving rapidly there. So we just need time. And we need more
initiative from you, from your side, more
pushing from you. AUDIENCE: That was my first way
of pushing you is [INAUDIBLE]. BRAD: Well, we’re going to move
on to our last question, which is a good question to end on. And it’s from Remi Sharp again. So if we can get
Remi a microphone. Just strap it to him. REMI: So I’d like contributing
to developer tools to be made easier, not just
adding a panel or tweaking functionality. How can I get involved? And I had originally
tacked on this. Things like Greasemonkey
made it very, very easy to hack the
page and make it– improve for me as the visitor, or
the user, or the developer. I’d like to see that kind of
super-low barrier of entry for all of the DevTools,
except for Apple because they don’t play ball. SPEAKER: Jake and me
spent an hour yesterday making all these
questions really short. BRAD: Yeah, I know, right? So if a developer wants to get
involved in Chrome DevTools, what can they do? PAVEL: We’re not
particularly good at that. So if you want to contribute
to [INAUDIBLE] the entry bar’s fairly high because we are
a part of Blink source tree. So it’s not good. The extensions API is not rich
enough for your needs, right? And it’s not rich for a reason. We don’t want people
to fight for resources and break each other. So we’re just trying to get
better at that in both ways, in contributing to core and
providing more richer extension APIs. But for now you get
a wiki or something and follow the
instructions and you manage to [? deploy a patch. ?]
I feel a bit sorry for you. But that’s about it
with Chrome as of today. So it’s bad. JOE: So we can do,
I mean, Firefox, you can hack anything on it. It’s all JavaScript
and our DevTool. So there isn’t a limit
to what you can do. The downside is next
month it will break. We are trying to
create some APIs that are more standardized,
that won’t break. And we spent some time with
the other guys working out what they would like. And we’ve done
stuff with Angular to try and have customer
extensions there. If there’s something that we’re
doing that doesn’t help you, then shout to us. REMI: The thing is that’s
more kind of like high level, the experienced developer
can do that kind of thing. I’m talking about, Greasemonkey
is a really good example. People can just pick up
a Greasemonkey script and install it for themselves
to make– I make my banking site readable using Greasemonkey. I want to be able to
do that with DevTools. Like being above the font
was a huge deal for me. Because I don’t like tiny fonts. And now, both Firefox
and Chrome do it. But before I had to
tweak a style sheet, which was a little bit
more of a barrier of entry. It’s kind of making
that easier– BRAD: So you want the
Greasemonkey script to plug into DevTools in effect. That kind of thing. REMI: Sort of,
I’m really talking about kind of the
low-barrier of entry, to make it easy for anyone here,
to make the DevTools better. PAVEL: Well you want a
better deployment for it? Or you want if for yourself? REMI: For myself. Because, yeah, once
you kind of go, right, here’s
Greasemonkey type access, then yes, it’s got to
be a complete cluster. But I’m talking about
for the individual to be able to hack
their own DevTools. AUDIENCE: I’ve got an
example that it is useful. In Yahoo, for example, I wanted
to fix things and make comps and make PhotoShop things,
and never anything worked. But when I bought a
Greasemonkey script and sent people the
link, all of the sudden, they saw the page change,
and basically interact with the change already. So a script that will
interface to developer tools will allow me to
do that as well. We don’t want to
reinvent Greasemonkey, but making it as easy to show
what a debugging step would look like, or a tutorial how
debugging works via JavaScript while you’re
scripting the DevTool would really, really be useful. BRAD: So one thing we’re
trying to do, this is a road, and we’re some way
down this road. What would be very cool
is if you could simply clone Repo on Git,
which is our DevTools. And you could now
say, in your browser, don’t look inside yourself. Look over there. And it’s all just tech files. Actually, there’s quite a few
bits done that work already. Like, you can already say,
don’t look inside yourself. Look there. It’s not a separate region. KENNETH: You can already do that
with Chrome today. [INAUDIBLE] PAVEL: Chrome has it
for a couple of years. But it’s not getting traction. It helps the adoption. It helps getting
more contributors because it’s easier to set
up that environment than hack on dev tools. But people don’t use it for
like on a regular basis. It’s just too inconvenient. AUDIENCE: But if
you advertise it? PAVEL: I think so. AUDIENCE: You’ve been saying
that we have it [INAUDIBLE] uses it, but nobody finds it– PAVEL: It has been
advertised quite some, when the remote debugging appeared. Because remote debugging was
approved by the external front and running as a
web page externally. But we could, Remi, we could
do something like that. BRAD: Yeah, because that’s
a big starting step, being able to just say,
OK, instead of loading up the internal DevTools, point
it to the copy that I’ve got. And then I could start hacking. NJ: You have a
buttoned in DevTools. That’s like fork
DevTools and then it spits all the
code out for you. And it’s another directory. And you can edit it. BRAD: Well, unfortunately,
we’re out of time. I can see a lot of
people have questions. But the very best of
the people on this panel will be in pub this evening. The people who go home early
don’t really care about you. But that brings us onto a break. So you can grab a coffee
before the next session, which is build process. But thank you very
much to the panelists.

Leave a Reply

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