 Yes, yeah, welcome to the second session a developer tool no longer a phrase that was used to bully me in the schoolyard It's a key part of web development It's difficult to imagine how we survive through a period where you know all we could do is play a game of higher or lower with With alerts I mean that's how I first started debugging and browser error messages were you know at best in distribution indistinguishable From stoner philosophy, you know things like undefined is not defined Yeah, thank you browser Too many arguments just everyone everyone chill out But what of the future, you know, where where can we can we take this? Well, I'm joined by this panel of developers developing developer tools with developer tools for developers They are Kenneth Ausenberg started remote debug an effort to unify remote debugging tools Henry Berger. Yes, I'm going to pronounce your name wrong already Sorry founder of no flow the Kickstarter based visual flow based web development environment 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 and shiny Developer tools. We've got Pavel Feldman who is working on the chrome developer tools and to start us off with some words About things a man who needs no introduction Okay big up to my chrome boy, it's Paul Irish So I want to give you a brief overview of kind of where we're at and 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 until I kind of the history Just a moment. It's not it's not me That's that computer. Yeah Oh Yeah, it's right. It's right Love it. All right. Thank you guys I'm gonna give you a quick overview of where we're at with propel for tooling But to do that I want to head back and tie down in the history Back in 2006 Hixxie the editor of HTML5 spec He was kind of testing out how HTML5 HTML is parsed and he kind of he He wrote a tool and this tool came out to be First he was like 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 of what we've constructed with you know in this case Just a quick p-tag, right? That's our 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 kind of Leaning us to this 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 og The og developer tool. This is Venkman the JavaScript debugger inside of Firefox. This debuted around 2001 So it's 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 we have here is a WebGL scene and we are live editing a GLSL shader Kind of changing some 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 invalid validation errors that are cause that we are triggering in the GLSL Now moving outside of that There's been a lot of fantastic work This is a screen screenshot of some new upcoming work from the memory tooling inside of Firefox developer tools Keep snap shotting and showing what 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 going to stop here at a break point 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, but it's now been overridden. So it gets striked out And then this was a fantastic experiment That I don't think is landed yet, but I like where it's going. It's audio break points. 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 interactable. So if 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 onto 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, but device pixel ratio the viewport Configuration touch events and doing that all right inside of desktop so that we don't actually have to even go over to the Device and this is a new upcoming feature a synchronous call stacks So we can actually see from where we are where we how we got there across an X HR 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 screenshot 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 heap snapshotting and memory profiling so here we can 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 operations that are happening inside the browser How that relates to frame rate so it can help identify how exactly we can improve the performance of the page and reduce the jank So Kenneth here from the remote debug project Showed this fantastic demo over full frontal Remote debug is a fantastic way to basically bridge the gap between different browsers their run times and their browser and their browser developer tools So we actually have chromes developer tools interacting with the Firefox browser Not only can we you know inspect elements, but also change the DOM of Firefox using the chromes 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 a fly, but this is the live HTML development. So as you know, there isn't a one-to-one mapping Mapping HTML to DOM is not a trivial thing But here we are moving around our HTML our DOM is updating We do a quick view into the CSS that applies for this age to and make those changes on the fly make it hot pink because that's the right way to go All right another fantastic thing inside of Brackets is the the CS 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 entered into the fetch and We can also see of those four calls that entered in the fetch two of them went into the air handler And then we can actually see oh we went into the air handler. What was in the air object? We can retroactively look inside of the air object and inspect that situation Henry from no flow is here and I want to quickly show what no flow looks like it's a new kind of flow-based visual paradigm for For writing Applications to see if we can get that video back up barely But it kind of turns the the idea that of looking at code on its head and Introduces a much more kind of 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 trace to GL project came out a little while ago But said you know we're just gonna log absolutely all the operations that are happening in this case We are we are logging not 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 By the web storm and kind of consumed by the web storm IDE But over on the left-hand side We have all the run loops for different events And then the call sacks that they triggered and then we can identify how exactly we map those call sacks into the code Really nice usable 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 on mouse move all these you know our client extra client wise live updating We can get a good idea of how this While looking at code what the state is in the browser is a quick shot of Looking at per statement based JavaScript profiling heat map so we can see by 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 shape 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 a react Chrome extension on the it looks like kind of standard dev tools, but it's actually completely representing their kind of application state of the world and and all its properties and Similarly, this is embers 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 the browser So to me like what is the role of developer tools these days? You know 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 that when we are debugging But when we 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 our 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 on the stage believes that has been developing tools and I'm excited to see what's next. Thanks Yeah, so Paul's gonna duck out now because he's he's got the dreaded illness. I can hear a few people in the room How so we've got his stunt double pavils gonna gonna fill in on the panel for him I 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 that's where this illness first like came from so it's another valuable addition to the world from Newcastle thanks for that guys. I'm kidding. Of course. I love Greg's right first question Before we start the These guys are developing the tools that are supposed to make your lives easier So if you if they say anything you disagree with or there's anything you want to elaborate on then, you know use on slide If that's not working for you, please just raise your hand and I'll I'll pick you out for a question The first question comes from Sebastian Kiwi was was Sebastian over there. We got Sebastian microphone In the future, can we expect to do all of our development within the browser? Will browser dev tools become our full ID or should we or should browsers concentrate on interfacing better with IDs? So Macromedia brought a rendering engine to their ID 17 years ago But now it feels like browsers are bringing IDs to the rendering engine and now we have code editors that are written Entirely in browser technology Joe. I'd like you to come on this. What do you see Firefox as DevTools becoming a full IDE? So I think nobody would like us to say you're not allowed to use sublime anymore Or whatever your editor is or brackets or brackets. Yeah, so that's not gonna 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 can only know by being a JavaScript And by being a browser So there are times when you will want to edit stuff inside of browser as well So the answer I think is both Enjoy you your answer is also a browser, right? I wouldn't call it exactly that I think our goal is to tie more directly close more close to the browser. 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 there inspecting the runtime they can tell us all this information that information I think for quick stuff or you know when you're really focused on the browser It makes sense to have tools in the browser and obviously, you know, that's a great workflow for that But there's times when you what you're really focused on is your coding, right? You're not necessarily 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, you know no-flow whatever so that we can provide a much richer development experience Outside of the browser as well working with the browser. I agree with you That's the whole reason why I started remote debug and Joe. I actually disagree with you Because because the browser today has a lot of information that is not exposed to the outer world But I think I think that's a problem of the state way and right now 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 dawn the network stack all the kind of thing 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 remote debug to unify and build the interface talk to our browsers So other tooling vendors like brackets telemetry benchmarking tools can start accessing that information that right now only privileged tools like Building if tools and browsers has access to so there's two different things there A Firefox to the top of tools work remotely they log in through a TCP sockets I know all of that stuff you can get out 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 another second part to it and That's I'm sure there's going to be another question on this which is should there be a standard protocol by which we debate Do we want to We'll get there It's the browser is a Because it has it has the runtime all built in is it in a better position to do things I even even with code like like all complete I mean I watch games developers work and it seems to me that they just write you know a comment to do Make half-life free and then from then they just hit the tab key You're 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? Yes, I mean so We've got some stuff that does fairly deep analysis of JavaScript now and we'll do some fairly clever completions That is just landing I mean that to be honest most of that technology is static which brackets could do just as easily But I think there is actually value and we did some experiments early on we haven't really done it in brackets around Essentially querying the runtime from right now like if you're stopped at a breakpoint you just ask it what's available now And there is more stuff there And again we could do that from a code as well as long as it's exposed to the runtime I guess the other point I would make I don't know if I'm getting away from what you're asking But is that you also want to write other kinds of code beyond besides browser code often and so having one environment for hey I'm gonna do browser stuff and now I'm gonna do my node stuff and I'm gonna do my Ruby stuff or whatever seems a little funny Of course, if you were just doing JavaScript, maybe you could retarget the in browser developer tools to know it I mean you can already do that with no inspector and things like that But I think you know 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 do this and that In terms of you know The browser sort of 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 Yeah, like I I don't think like having a contextual diff tool with building to the browser It's ruling out having another tool like your editor But the kind of problem I think by having really specialized browser tools for each browser said I said developer I need to learn a new diff tool when I'm targeting another browser, so that means my workflow is kind of broken because If I develop a Chrome, I need to use learn how to use Chrome diff tools navigate this Source code set breakpoints if I do the firefox I need to learn that tool And to me that's just this kind of my productivity So there's a lot we can do to help there So you'll notice that in firefox dev tools now the key sequences are the same as in chromes In our box model highlighter that's just landed then all of the colors to denote borders Paddings etc. They're the same colors and I ease exactly the same as well So the stuff we can do to help there if I don't I think there are many reasons why just saying there should be only one tool Is hard, but that's that old question again. Yeah, we're gonna come back to Before we move on to the next question. I know we've got questions on the floor from everyone's favorite shaver Remington sharp On on the point of kind of you know working with firefox dev tools working with chrome dev tools working with IE tools so I I haven't used the F 12 tools yet and when I look at the That the you are a responsiveness I wonder whether or not that's gonna 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 if I I mean I'm quite comfortable in Chrome And I can navigate DevTools really well, but am I? Debugging for Chrome or am I debugging across in most cases bugs? Yeah sure before things like performance and responsiveness I've no clue and do we need all these different tools for each to target each browser? That actually leads into our next question, so I'm going to get her Shane Hudson to read it out because it kind of expands on that So you rewrote my question for this Initiatives like remote debug look to unify developer tools. Is this a good thing or could it have the diversity of tool? That's so that's this question So some people Would like to just have one tool and Obviously many tools are being created it and there's a 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 so and there are things you know There are optimization techniques that will work on one browser that won't work on another You know, I think there are good reasons why we have an obligation To tell you about the stuff that is in our browser that we are the only people that can tell you about it Is us we have that an obligation to do that and so that's what we're doing Yeah, 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 feed the same HTML JavaScript Whatever to IE Firefox Chrome Grab all of those statistics and show okay, you know Here's how this and this thing performs. Yeah in that browser. Yeah, and right now. That's something we don't really have We definitely don't want to kill innovation I mean, it's great that you guys are doing different things you guys are doing different things But as you mentioned just now too, you know, you're trying to make some things the same right because you want the guys to be Same and for just basic functionality I want to set a break point when do this I want to do that even the more inspection stuff It seems like it would be valuable to have at least at least even at the like highest shallowest level Some kind of just basically common protocol just to make it so that we can talk the same way And then you know this browser might have certain extensions for the stuff that it does and you know The 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? Well, I would say Joe first of all, I don't I don't just want one tool I really like that we have multiple tools available. Okay, but as a developer I don't want to swap between multiple tools just because I'm targeting another browser I don't want to change my workflow as a developer while I'm crafting a deep bug in my application and learn new workflows Because I'm targeting multiple browsers and that's the reality as front-end developers today Is that we have a bunch of different browser specific tools that we need to learn and it's counterproductive so my hope is that Your workflow isn't that different, you know setting a breakpoint, you know that kind of thing is basically very similar So I'm hoping but why why do I need to do it twice once in five of the tools and now One in chrome Right, so so two different use cases here. There's what brackets are trying to do which is To log into our DevTools celebrate points 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 on against Firefox I know that's that's a prototype of there is a massive massive difference between those two and You know what you're getting into trying to do that is all sorts of complicated problems about object lifetime in the browser And you know, etc. There's a multitude of problems. That's simple Now as far as the the case for simple debug goes so I mean just think about writing an add-on for a browser, right? So you we started off with you know a 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 You know, then it looks like we're in a state where maybe we could have the the Chrome API and the Firefox jetpack API there's some similarity there. Maybe we can extract that standard that feels like with grease monkey Right, that feels like he lets us right that that that kind of approach of you know 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 I'm for that kind of process But it's hard is there So it seems like we're all in agreement. So it's boring, right? We need to compete to innovate and nobody's taking that away Remy, we're sorry 60 FPS is going to be different on Firefox from Chrome You need to use different timelines. You'll use IE's timeline at least for now because those pipelines are entirely different The idea so you won't see with the Firefox tool So if you are going for a high-tech if you are 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 protocols as of today. They are different if you try and bridge them on your side and Prove that there is a value on bridging them and talking to multiple browsers There will be an incentive for us to standardize Otherwise as browser vendors who would always want to innovate first and standardize later Kind of dude this this kind of standardization effort that you're doing Is this something that you see going to a standard body such as the W3 or the WG? Well, 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 way We don't know how to build components. We don't know how to build build the tools I think what we need to start and agreeing upon is the baseline like is our remote debug Is that going to use HTTP? Is it a bit socket? What what is the very fundamental protocol and then we can discuss all the API details? Like how is the Firefox API? How is the Chrome API? But the problem is like if you are if you know not a diff tool developer You want to interface with the browser that is so goddamn hot and and what I see when I look at what visual studio Or adobe are doing and then they're sitting and inventing ways to to do Instrumentation to extract information out of the web app so they can protect that information putting it into into the 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 vendors We have out there to build tools for the web right now You only allow yourself to go for the web and and I think that's not good enough So can I suggest a way forward and that 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 we pretty cool to write a debugger in a web page to look at the other web pages security issues obviously Ignore the protocol to start off with do it by a JavaScript API That's the way forward and that is a what that's something that you can build on bit by bit, but that's gonna take time On the on the related subject the next question from a Remy sharp again Remy a microphone Can we just wire Remy up So my question was rewritten as well I just made them more extreme to be more interesting Currently features launch before they have DevTool support e.g. Promises service and events web audio and so on is as fair to developers should we be ensuring We're developing features that are inherently debuggable. I don't actually agree with the question Well It Experiments come before standards right it has to and that's the only way we're making progress. So I 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 So so you just answered your own question. So that's well, no service centers vent is a really simple example We've got tools for the debugging web sockets. We don't have tools to debugging service events Is that It's it's hard for us to go ahead and debug that and why aren't browsers making that easier for us Which is that question? I don't think we have a Well-established process of debuggability for new features We try to have everything debuggable by the time it leaves experiment or is no longer behind a flag so Shadow DOM is probably a good example that Shadow don't appear debuggability 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 it. So for us the measure is Future heating stable. That's an absolute requirement for us But there's no sort of better process and it's an early driven by our customers So if you file bugs about lack of debuggability of experimental features it gains stars. We will definitely look into it The promises bit is really interesting because there's a huge thread in the in the spec discussion about promises where they They were saying we're not gonna have a done method that a lot of other promises have Because that method is just there for debugging and we shouldn't be putting things into the spec that I just there for debugging So something is a how are you looking to what's your plan for debugging things like promises? Is it something you're looking at? Yes So we've got this thing called tag stacks, which is that 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 will have been unfulfilled in some way that will be extremely handy Yeah, we want we'd like to do this just I mean I mean our dev tools are written in JavaScript We'd like it for our own purposes if nothing else, you know We're working on it. I I don't know what more I can say than that So I Got a question more for the audience, I guess I given given all these tools We have like, you know variable watching break points who here still uses console.log as their first first bit of debugging I find and I do this as well and I find this crazy because just writing debugger is less characters And that would let you in inspector. It's like it's like shaving with a knife, you know When there's a perfectly good razor blade there for you, you know It's why do people why do we think people like ghetto debugging? Well, I think it's because you don't have to negative it navigate an interface, right? It's like I know the piece of information I want So we just put it in the log statement. I don't have to like go twirling through things, right? the flip side is You have to know in advance what you want So that's what's kind of the idea behind these he is and I think you know This is like what some of the other double stuff is doing and this kind of omniscient debugging thing That's been around I think it's been in the Java world for a while Is that 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 you 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'd be interesting to see that go farther another thing to remies point is and this is something thesis does and I think other Things to do is I think there's actually a lot of power in building debugging tools through instrumentation, right? Is that you instrument you instrument the JavaScript and you can you know like promises you could instrument the promises Library and figure that stuff out. So actually having like 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 thesis has like the beginning of that It's like a generic instrumentation library. I think aliens are trying to contact us I won't is I wonder if it's entirely the UI thing. I mean it reminds me of a An argument I got into at school It was you know my sense of humor this but it was about urinals And I point out that the design floor of urinal is that they lend themselves to a certain amount of splash back And I said this is something we should fix and he said to me no no like if you don't get the splash back How can you tell you're pissing hard like a real man? And this is someone who doesn't enjoy being showered with his with his own effluent But he finds it affirms his masculinity and it is that what we're seeing with with console.log is You know Like yeah, I'm just using the bare minimum of the tools to prove I'm a great coder I'm not going to use all of the you know, it's proving. I'm not a good coder if I have to use all the browser's help I'm gonna stop using console.log. I don't know I don't know what this console.log thing is you know, there's alert, right? Maybe that's a good time to move on to the oh no, we've got a question in the audience It's the element of asynchronousity. So it's sometimes it's quite hard to know when what all the things are triggered in So if you've got events and things like that and we find that Often that is just makes it easier to see the flow in the sequence of things So maybe it's the element of everything's it why a lot of things are in synchronous in the browser And that it's hard to visualize that and reason about that Is there a way to make that better in the tools? Would it would it be nice to have kind of this map where you can see That's flow in the browser. I don't know I mean that is an interesting thing about the flow based approach I mean there's been flow based programming languages 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 force of bugs. I think we have in brackets in general It's just dealing with asynchronous crap, right? And so having visual ways to trace that stuff is really important. So the thesis does a little bit of that but One thought here. What if we enable on a platform level like new development approaches like this to surface rock, 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 We do have a question about that coming up. So we'll say that now we got a question at the back Now 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 grain something to do with focus and blur events or Touch start and various things like that and jumping into DevTools actually interrupts that flow So having being able to look back in as to what's happened in the last 10 seconds will be really useful So this is that kind of thing built in so DevTools just a snapshot of what has just happened Have any of you guys looked into omniscient? That's why I don't use debugger a lot of the time In the DevTools, have you guys thought about looking into that? Like capturing state So we Outside of DevTools tracing has this feature. It can record what's happening and it shows you a sliding window What's just Happen it is not traced into the content world. So we don't upgrade nodes and JavaScript there and In DevTools, we haven't started doing it We want to the next topic. We've got a question from Connell. Where are you? There are lots of deprecated apis and bad 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 I really like firebug for this actually because it has always always visible a little error counter at the bottom And and knowing that other firebug users would see that sort of spurred me on I don't want errors on my page because imagine the shame of it, you know Is this a useful pattern? So yeah, one of the 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 And then so we're putting lots and lots of extra warnings into the console at the moment There are there are all sorts of security things like they're at cause errors in there Etc 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 have two panels That's what we're doing Say that's what we're doing. That's what we're probably planning to do. We're you know, we've not Yeah, it's it's not it's not code yet. That's what the plan is We are not quite splitting the consoles, but we are also working on more warnings on Deprecations and not only deprecations, but the performance issues and potential bottlenecks for everything I would I would love to see some limping tools will into the diff tools that is that are contextual, right? So while the app is running, then it could detect. Hey, this api is being used to deprecate it DC assist like this of their hate you're doing something for 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 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 web page you get a little a little thing floating over the top which tells you about javascript It tells you about jank tells you about that sort of thing. There's a bunch of little things that will do that So there's also a lot of things could be done using instrumenting codes We have a protocol api that allows installing a preprocessor that would instrument all the content 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 we analyze and promote the tool itself Is that shipping already in it is it is there for quite some time Do we see that users aren't We've got tools like timeline Chrome house as well are we seeing users use that or do we want to be in a better position where we want to tell people Hey, you have layout thrashing going on without them having to go to that and like 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 it is happening It wasn't the question. It was the answer, right? Yeah, can we have that and when can we have it? No, but I I think that is the solution to to proper bit performance better information to developers just like Why slow did it for for bit performance, right? That you had most of us who is just want to have a checklist to see hey, I need to have complete these 500 issues of what I have in my app and then I'm good, right? Yeah, we do want to Make timeline more popular. We want to draw attention to it and we will do that And you will see warnings Excellent, it's cool right We want the next question. This is from kyle simpson. Uh, was kyle over there my friend kyle All right, uh, so disclosure of bias a couple years ago I worked with jill 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 phantom js But for testing and processing and that it's not just javascript That's the entire stack with html and css but sort of headless into the tool So this shifts us away from what's happening in the browser to happening outside of browser Bubble Joe ship it So the very short answer to your question is nothing What's stopping us nothing? Um There's a fire question, which is what actually do you want From headless is this? Yeah, what's the what's the question behind it? I want phantom js, but I want it from the browser itself. I don't want to have some other project I want to be able to spin up kind of like a UI web view Okay, so it's testing Okay So yes, there is a slimer js, which is Basically this sort of thing. It's not a hundred percent headless. It's nearly headless It's kind of maybe here So Yes, I mean, that's as much as I can say. I mean, I'm kind of out of my depth here a bit because This is a lot of this the answer this question is kind of like deeper browser engineering than as DevTools engineering We've had new APIs Recently that look like they should make this a lot easier and I'm fairly sure that slimer is working on those APIs Um Yeah, we have a new version of web driver is implemented on top of the DevTools protocol 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 a perf test for it. So it is there. It is publicly available You can use it, but it's not Center diced and it's chrome But I mean web driver is enough of a standard, right? I mean does does that inside firefox now Some internal firefox tests use that So that's becoming more of a cross browser standard Um, so, I mean, let me come back to your you know 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 okay If if it's not a visual problem if what you want is automated testing you don't matter if the screen flicks briefly Right there's the testing side of it, but there's also a functionality side of it People use phantom js 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 this And part of the problem really is is that phantom js is not you know, you think it's chrome or something But it's not you know, it's kind of chrome from a few years ago with some of the weird bits and minus that Yes, I think I think it would be nice if we were better at that I want to point out that developer tools actually do matter here because when you do that 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 do not happen trace Right. Yeah. Yeah, so it should be a part of that idea. Yeah Well, is that something that remote evoke would be able to help if we had a headless version of of these browsers could could then I I see that as a natural extension, right? If we had a generic interface to the browser no matter if had this 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 telemetry And use it across browsers to do comparison of browser performance And it would enable a different generation of tools as I see it and things that we now do specific to phantom js and specific to slimer I just want to to interface with the browsers and VIP driver. It's not enough because VIP driver is focused only on automated testing I want to get the information about timeline events and all these other things that the browser currently has, right? We got a question from the audience over here This is more a user perspective kind of question, but we have window error being so flaky Is it possible for like the browsers for the dev tools when they record an error to actually like ping an endpoint somewhere which would So you would make specify ahead this on error ping My server with the error details in the stack trace So that way if there is a complete js failure due to the cause or some other unseen event that you would have an automated It's kind of the browser would tell you this and kind of give you user metrics and statistics So you want to get that information from the field or you want to be ping when you're running locally. I didn't get that No, so say say you've um You've um, we had an error where we put cross origin anonymous on google map script and basically google deployed a new version of maps Which completely broke all the JavaScript nothing could run so there was no error reporting No, nothing because the basic code said we don't want to run this because it's the security error So would it be possible for the browser to Actually ping so say if you had like a meta tag saying on error ping error reporting and basically you'll just send the stack trace Isn't there speak around this this is one of the things that that native people say Native is way better than the web at this. He's getting metrics on what the hell's going on out there We should be better at this Well this goes back to the point before about like do we do we build features that have debugging built into them? I mean we saw that that promises didn't but I think what you're referring to csp has As a specific feature for logging back. Yeah, do we need something like that for for error logging? A question from the audience Yeah, just sorry back to that What's actually your problem with window on error because as a guardian we do exactly what you say and we it works perfectly And we like say there's a cause error that wouldn't be reported on the map error So you'll never you'll never get that so basically you deploy the script when you've got the headers If the window on the error would never report to you you've had a cause error Yeah So it's something something to pipe what you would see as an error in console Yeah, the whole of your lint panel to redirect the whole of that lot back to you, you know That seems like I feel like there's there could be some privacy issue or something I you need to think about it I Of course the other front here So my question is what is it called to action so try to push it in the group But so far in both of those groups the tooling group and the performance group Somebody so far nobody was really interested going forward with this if you guys haven't and why just don't put a first version to gather What we all have there and try to draft the board can be standardized or cannot be standardized and start working on it I think we're just waiting for it to prove itself usable and user friendly And for now we're just innovating and moving rapidly there and So we just need time and we need more initiative from you On your side you're pushing for it That was my first way of pushing you Well, we're going to move on to our last question, which is a good question to end on and it's from rammy sharp again So we can get rammy a microphone strap it to him Okay, so I'd like to contribute to develop a tool. I would like contributing to develop tools to be made easier Um, not just adding a panel or tweaking Current between yeah tweaking functionality. How can I get involved and I had originally taxed on this Things like grease monkey made it very very easy to to hack the page and make it improve for me as the the the the visitor or the user or the developer I'd like to see that kind of like super low barrier of entry for all of the dev tools Except for apple because they don't play ball So what do we need if a developer wants to get involved in in chrome dev tools? What what can they do? We are not particularly good at that So if you want to contribute to core dev tools The entry bars fairly high because we are a part of blink Source tree So it's not good the extensions If I is not Rich enough for your needs, right and it's not reach for for a reason. We don't want people to fight for resources and break each other So, uh, we're just trying to get better at that and in both ways in contributing to core and Providing more richer extensions apis, but for now you get a Weakie or something you follow the instructions and you manage to plot a patch We feel a bit sorry for you But that's about it as of today So it's bad So we can do I mean I mean firefox you can hack anything on it. You know It's all javascript in our dev tools. So you there isn't a limit to what you can do the downside is next month it'll break We are trying to create some apis that are more standardized that won't break Um And we spent some time with the ember guys working out what they would like and we've done stuff too with angular to try and You know have custom extensions there um, if there's something that we're doing that you That is not doesn't help you then shout us and we'll thing is that's that's more kind of Like high level developer the experienced developer can do that kind of thing. I'm I'm talking about The grease monkey is a really good example people could just pick up a grease monkey script and install it for themselves to make I I make my banking site Readable using grease monkey. Yeah, I want to be able to do that with like dev tools I like being able to bump 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 area of entry It's kind of making that So you want a grease monkey script to plug into dev tools in effect that kind of sort of I'm really talking about the kind of the low barrier of entry to make it easy for anyone here so To to make their dev tools better Right. So when you want a better deployment for it or you want it for yourself for myself because yeah Until you kind of go right here's grease monkey access type access then. Yeah, it's going to be a complete cluster Yeah, but I'm talking about for the individual to be able to hack their own dev tool at all So what we For example, I wanted to fix things and made comps and make photoshop things and never anything work But when I wrote a grease monkey script and send people the link all of a sudden they saw the page change And basically interact with the change already. So a scriptable interface to the developer tools would allow me to do that as well We don't want to reinvent grease monkey But making it as easy to show where debugging stuff would look like or a tutorial how debugging works Yeah So one thing we're trying to do, um, this is a road and we're some way down this road What would be very cool is if you could simply Clone a repo on git which is our dev tools And you could now say in your browser. Don't look inside yourself look over there and it's all just tech files We're not I'm actually there's quite a few bits of that that work already like you can already say don't look inside yourself Look there. Um, it's not separate region. You can always do that with chrome today point to another folder Chrome has it for four couple of years, but It's not sort of getting traction. It uses it. It helps the adoption that helps Getting more contributors because it's easier to set up that environment and hack on depth tools But people don't use it for like on a regular basis. It's just too inconvenient Yeah, I think so It has been advertised Quite some when the remote debugging appeared because remote debugging was proved by the external front and running as a web Page externally, but we could we could do something like that Yeah, because that that's a big starting step being able to just say okay instead of loading up the internal dev tools Point is the the copy the icon and then I can start hacking you have a button in dev tools That's like fork dev tools and it spits all the code out for you and it's another directory and you can Well, and that is as important at a time I can see a lot of people have have extra questions But the very best of the people on this panel will be in the pub this evening the people who go home early don't really care about you But that brings us on to on to a break so you can Grab a coffee before the next session, which is build process, but thank you very much to the panelists