The Changelog: Software Development, Open Source - Firefox Debugger and DevTools (Interview)

Episode Date: April 17, 2017

Jason Laster joined the show to talk about Firefox Debugger and DevTools. We talked about the backstory of Firefox, Firebug, the new Debugger.html, why React and Redux made a good fit to develop Debugger as a standalone application, community efforts, and getting started.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. I'm Jason Laster, and you're listening to The Changelog. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 247, and today, Jared and I talked to Jason Laster about Firefox Debugger and DevTools. We talked about the backstory of Firefox, Firebug, the new Debugger.html, why React and Redux make a good fit for developing Debugger as a standalone application, community efforts, and also how to get started. We have three sponsors, Linode, TopTow, and GoCD. First sponsor of the show is our friends at Linode.

We host everything we do on Linode servers. Head to linode.com slash changelog. Get one of the fastest, most efficient SSD cloud servers, SSD storage, 40 gigabit network, Intel E5 processors. Use the code changANGELOG2017. 20 bucks in credit. Head to leno.com slash changelog. And now on to the show.

All right, we're back with a fun show today, Jared. This time talking about something from Firefox, debugging dev tools, this fun thing. Jason Laster is coming on, kind of peeling back the layer of the history of some things for us and hopefully sharing with us where they're going. Yeah, well, we're all excited because if there's one thing that developers love,

it's tooling. And it's dev tools specifically because they're approachable. You can dive deep into them. And of course, they help us do our jobs better. So very excited to talk about this. Jason, thanks for joining us. And real quick, a shout out to Brian Clark, who teed up this conversation.

He, in fact, said have Jason on and have James Long on as well. Which we did. Because we opened this issue on Ping back when he worked at Mozilla. And Brian is the technical product manager for the firefox dev tools over there so thanks brian and jason thanks so much for joining us yeah i'm thrilled to do it so i'd like to start off with a little bit of history because i feel like firefox has a rich history uh in dev tools specifically you know firebug which we all know as a third-party add-on released by, who was it? It was Joe Hewitt, right? Back in 2006. Really kind of kicked off tooling inside

of the browser before that. It was just, you throw an alert in there and then you see object, object pop up and you just want to pull your hair out. But a rich history and a lot has changed over the years. But before we get into that, Jason, tell us about your, you work for Mozilla. Give us a little bit of just the background of you at Mozilla. Sure. I've been at Mozilla for one year now. And prior to that, I guess it all began for me when I graduated college. And I did this program called Recurse Center, which is just this magical place where you can go for three months and contribute to open source,

explore new language, anything like that. And I knew- That used to go by a different name? It used to be Hacker School, which was a totally bad name. Yeah. Why did they rename it Recurse? hacker school which was a totally bad thing yeah i'm not gonna name it recurse uh i think it has this like resonance with a developer like we're recursing into something and frankly hack school just didn't really work well if you were crossing the border

and you wanted to tell a border agent like yeah i'm going to hacker school doesn't work. Very practical problem with that name. I guess that's my understanding of it. Yeah. Okay, so yeah, I've definitely heard of that and people rave about it. Oh, yeah, you meet the most amazing people

who are doing, and they have fellows come in, like Maureen, who works on CodeMirror and ProseMirror, and jose valim who's worked on elixir and i got there and i had just graduated college and done a little bit of programming and knew i hated that feeling when you're working on something and it just doesn't work you're not quite sure why and i thought i could spend a little bit of time just getting involved in open source so that would never happen again and uh that's how i stumbled upon working on repls for

ruby and python and and realizing that you can actually do this stuff it's possible and i was kind of hooked and had wanted to get involved ever since. And then when I started working in the web, seriously, it made sense to go to DevTools in the browser as opposed to maybe like a REPL for Ruby or something. So two years ago, I started working on a Chrome DevTools extension. And I realized then that while you could do a lot in a tab, like the React DevTools and whatnot,

what was really cool was if you could do something in the tools themselves, in the inspector, in the debugger. And the day I figured out that that was open source, was just the rest of the history. It was really neat. So since you're somewhat new at Mozilla and with Firefox, we'd like to cover a little bit of the backstory of where the dev tools have been and where they're going, of course, will be a large meat of this conversation,

specifically the debugger, which is very interesting. But just real quick, do you work on all the dev tools? Are you specifically on the debugger, which is very interesting. But just real quick, do you work on all the dev tools? Are you specifically on the debugger? Or do you cross tooling? Yeah, so most people on the team will cross tooling, work on the console, the inspector. I joined primarily to work on the debugger. And since then, I've been working on this rewrite.

And I'm one of the exceptions in that while the other tools are interesting for me, I really want to stay on the debugger. And I'd like to see a change quite a bit because I think there's a lot we can do. So I see myself staying on the debugger for some time, at least until we make some progress. Until you're done with it.

Yeah. Yeah. Because you're done with it. Yeah. That's a little different. Because you're never done with software, right? That's right. That's sort of a trick question, wasn't it? Yeah. Or a trick statement, I should say. Right.

So let's paint a little bit of the backstory. Even though you just got there, Adam and I will know a little bit. We've been around. So Firefox, as I stated before, um, really broke in for me at least. And I hope this resonates. I think it does with fire bug back in oh six and as it got popular and even other add-ons really the, the, the ability to make add-ons to Firefox really allowed developers to open up the browser.

For sure. Yeah, and to be outside and to actually move beyond the alert debugging that we were tied to. Sure. Yeah, that was my experience as well. I distinctly remember installing Firebug and then everything seemed like it was possible. Like the first inspector, everything was there. So back at that time, Firefox had a huge mindshare with developers and Firebug was it. Like it's what you used and it was, you know, best in breed tooling.

And then I'm not sure exactly when it was. I searched for this real quick. Couldn't find it. Chrome comes out. WebKit begins to have, you know, Chrome and Safari have WebKit. You have the WebKit inspector and the dev tools coming there.

And really the perception of Firefox is that maybe perhaps because it was third party or the first party tooling wasn't really there. And Chrome DevTools really took off and became, at least today I would say in my mind, the juggernaut in the DevTools space. And I'm just curious, your take on that and maybe even insights on why that happened from your perspective. Sure. So Firebug was really, really good. To this day, it has features that we don't have in Firefox dev tools. And frankly, Chrome doesn't have either. So I think there was this mentality at Mozilla that the community is really powerful and can do a lot so firebug

uh had employed some people um my manager now uh it was one of the first people to work on firebug which is unbelievable wow and and so i tell them ideas i have for the future he's like yeah we did that and it's really hard to stump them. That's got to be awesome. So they experience around. Yeah. Yeah. I had to confess like a couple months into working with them that he was kind of my hero.

And that was a nice moment. We're both drinking and you have a lot of people around when you're at Mozilla who have done things that just blow your mind, like the history of computer science kind of blows through some of these people. Right. So, I mean, we can go into that later on, but source maps and even E-max and version control and whatnot.

But Firebug was really successful. They had a great contributor team lots of contributions and i think that fit the mentality at the time that this problem was mostly being handled uh probably up until chrome dev tools got started and started really refining it. So maybe two, three years ago, a larger team got formed, that's my understanding, around dev tools in the browser as a thing that employees would work on and build out. And the other piece of this was Firefox OS. So because Mozilla was working on both a desktop app and a mobile operating system that was built on the web platform, there was a split focus. So there's this amazing tooling built out called the Web IDE that allows you to work on a mobile app or OS even through this tooling in Firefox.

But I would wager to bet that because of this split focus, it was harder to keep up. And with Firefox OS becoming less of a focus and then not becoming a focus at the beginning of last year, we've been able to make a lot of progress, just improving the quality of the UI and the experience within Firefox dev tools. So the,

the refocus makes a lot of sense, I guess. Uh, and maybe this question is in court, you know, quote unquote above your pay grade, but like the decision to reef to refocus, you know,

maybe you don't have insights on this, but maybe you do to reef, to refocus, you know, maybe you don't have insights on this, but maybe you do. Um, was there kind of a, it seemed like, was there like a holy crap moment? Like everyone's using Chrome now and, and like, where'd all of our, where'd our core audience go? Because developers and techies and nerds like our, us are we're firefox's you know bread and butter and they're they're it's champions and for years and years and years and there had to be a moment where it's like everyone's using chrome dev tools now what are we going to do yeah you think that happened sure

i think i mean uh i i think you have that recognition internally i think you have that recognition internally. I think you both put out really exciting tech, great features, and it doesn't resonate. And on the flip side, you look at the larger product and you realize, you know, we really want to think through some of these experiences. So I'm not sure if it was 18 months ago or two years ago, but Brian Clark joined the team. He'd been at Mozilla for some time. And we really got a product mentality, design, full-time design. And just internally, there was a recognition that we could do better.

And I think that's true for dev tools at large. Products like Atom and Nuclide and VS Code and Chrome DevTools has a full-time designer, but that wasn't really a thing three years ago. Yeah. Sorry, about the same time, years ago. We're like, hey, you know, these tools built for developers

aren't any different than like tools built for other humans let's apply some of the same practices and really focus on what the experience that will help beginners but also help advanced programmers do what they're trying to do and that's been a welcome change recently that i've noticed is a like you said treating these things as if they're designed for humans and not like it's okay they're developers they'll put up with whatever just focus on design and tooling even down to like to compilers and to like error messages and these kind of things that we're seeing out of like the elm community and that's starting to you know move its way through where it's like the the compiler and these things can be like human usable and that's starting to move its way through where it's like the compiler and these things can be like human usable

and that makes people like them. It kind of seems like duh, but at the same time, it speaks a little bit to the maturation of our industry, I guess, but it's definitely welcome. Yeah, I'm one of those people who believes that things

could be radically different in two to five years. So I tell my parents that I'm working on Photoshop for the web. I don't mean Dreamweaver, but I just mean that there's going to be this degree of fluidity when you're working in a language that has type checking and with error messages. And the way in which you can design a page will feel more fluid. And hopefully the same thing as like developing a new widget for your app or component for your app. Like that's where I see us going.

But with that mentality, like we still have a long ways to go to really nail it. So while we're still kind of camping out on the history, I have to bring up 3D view because at a certain point I switched to Chrome and the Web kit side and i used chrome dev tools even to this day i use chrome dev tools yeah and there was one reason why i always fired up firefox and that's because 3d view was like a fun gimmick uh it was like not

even useful kind of useful which is maybe why it's gone now but it's gone for those who don't recall 3d view yeah 3d View was this cool part of, I think it was a first-party part of your guys' tooling, where you could basically tilt the web page on its side and see the DOM built out kind of based on the nested tree structure. You could see it in 3D. And so it was helpful, like, kind of,

to, like, sometimes you see something's too far nested or it's not actually inside the element you thought it was going to be. But it was really, like kind of, to like sometimes you see something's too far nested or it's not actually inside the element you thought it was going to be. But it was really a cool tech demo. And I was just, I was recalling that as Adam and I were prepping for this. And I thought, what happened to 3D View? It's no longer there.

Yeah. So I recently saw a screenshot from, I think it was Firefox 17. And I'm not sure when that was released, but it was one of the earliest versions of a dev tools that we built it wasn't firebug and you're looking at the inspector and you see the markup view which that dom tree and then on the right in content is the role view like we just it didn't have a debugger i'm not even sure if that our console but it did have 3d view

in the bottom. So I just have to believe that it was one of the first things that was built. I was like, hey, this is pretty rad. Let's get a topography view of your page. And I think it's a great example of something that's cool, but it didn't help people in the same way that probably a more focused tool would like for instance i was talking to one of the people who works on the inspector the other day about just z indices can we get a sense of like if we have three elements that are all the same dimensions on top of each other yes can you see the two below it be below the top one you can't really see that and even if they overlap a bit can you find a way like with our tooling to inspect or put a magnifying glass on that second layer it's kind of difficult

without something like tilt view which i don't know that's probably not the solution but when people are still explaining the box model too you know and i think i don't think it exactly clearly identifies the box model because it's not particularly trying to show the padding and all that stuff but you can see the layering and so you can see the hierarchy and you can see you know what's above one another and that to me seems very very useful but maybe as Jared said it's sort of just a gimmick but not really well it's it's like like like Jason said it's like kind of useful but not useful enough to be like something you grab all the time right yeah but i actually like that idea of the z-index view because yeah let's face it like people when they want to crank the

z-index on something they'll put like 10 000 on it right so that raises that element i don't know why but i i do it too i guess or like yeah you can just crank it up bang important right it's like this thing has to be on top so they just and then and then if you want something that's actually going to be you know z index higher than that now you got to go find whoever you know where they put it and it would be cool to have something like that and just pro tip for people out there like one two three works you know yeah and it's like in tilt view you saw that element like way off in like the clouds and then you're like that doesn't really make any sense that doesn't need to be that high like you know one is higher than zero it still it still works but going back to to tilt i was told in the early

days that uh the toolbox which is everything like in its own window, was always V1. And V2 was supposed to be like Photoshop again, where you have those like panels that are all over content. And you can kind of like move them around and play with them and lots of highlighters everywhere. Obviously, that came to be probably for the reasons of it's very hard to implement and not really clear why you do that but i think from the beginning there was this idea of like maybe we can directly uh visualize or like edit manipulate the dom the page you're looking at yeah i really think that your description of the the split focus with firefox os and really because here you have an example of like you said it was v1 they're supposed to be a v2 um you have good

ideas but they're not like fully fleshed out right and they're not yeah explore and so because perhaps because of that split focus perhaps because the thought that community will carry you know certain aspects and so i'm i'm excited to see that Mozilla with Firefox DevTools has doubled back down their efforts and hired people. You work on the debugger, and that's your gig, and that's awesome. So we want to talk about the present, where it's at, the new debugger. It's React and Redux, modern tooling. It can run anywhere.

So they have a lot of questions around that. And we will talk about those after this first break. If you're looking for trusted freelance talent, ready to join your team right now, I mean, like within the week, call upon my friends at TopTal, T-O-P-T-A-L dot com. And as a listener of the show, you might actually be one of those developers or designers looking for awesome freelance, independent contractor type opportunities where you can still be a remote worker. You can still have the freedom you have right now, which means you can travel anywhere.

You can be anywhere and do what you do. That's also an opportunity. We love TopTal. They've been supporting this show for a very long time. They're really good friends of ours. If you want a personal introduction, I'd be glad to give that to you. Email me, adam at changelog.com. Otherwise, head to toptile.com. That's T-O-P-T-A-L.com to learn more. Tell them Adam from Changelog sent you. And now back to the show. All right, we are back speaking with Jason Lester about the Firefox debugger and the dev tools in general.

Got a little bit of the history in the last segment and we've seen this renewed focus over the last couple of years from Mozilla on making Firefox dev tools great and a really first class, first party effort in the Firefox ecosystem. And one of the ways that that's happening is that, of course, you have an open-source project

that makes tons of sense. Like, that's Mozilla-style open-source. But this is not a project inside of the Firefox repo. This is its own thing, debugger.html. We'll have a link to the show notes to the GitHub. It lives on its own repo. This is its own thing, debugger.html. We'll have a link to the show notes to the GitHub. It lives on its own repo and it has its own little ecosystem around it. So tell us about that. So about a month or two in, Brian realized that we could attract more contributors by virtue of being GitHub and our own repo. So initially, it was always about an experiment. Can we move quickly and try this new React Redux architecture? But two months in,

he came to us and said, you know, in the early days of Firefox, it was expected that every engineer would have about six contributors. That was how you got the leverage. And that had gone down over time. But by using these modern tools, React and Redux, which people understood, and being in GitHub, which means a contributor could get started by doing Git clone, NPM install, NPM start, we could really talk to more contributors again.

And that's what we've pulled off. And that's what's been so exciting the past year. We've had over 100 people get involved and help out, which is just way, way more people than we were seeing in the mono repo previously. You have your own org. It's devtools-html. You've got lots of cool stuff there.

perf.html, I'm assuming that's performance. That's spot on. Debug stuff there. Perf.html. I'm assuming that's performance. That's spot on. Debugger, of course. .html. You got DevTools core and a bunch of stuff even here. Even Debugger Docker. You said you primarily camp out in Debugger though, right?

I do. And you also mentioned the old way. Maybe just give us a two minute old way of how it wasn't working mostly for those maintainers out there thinking like i should monorepo this thing you know that's the way to contributors but in actuality maybe it's a more distributed model a more broken down model where you're sort of better defining can you help us understand what was wrong with the old way? So there was a lot of right about it, too. The monorepo would allow you to clone Firefox. And then in one patch, you could change the jobstrip engine, jobstrip debugger server and then the client which was incredibly powerful

uh now the downside and this is a lot like chromium today which is one tree as well is that when you do that clone you're pulling down like five gigs a lot of it history and then when you do the bill you're taking another 30 minutes maybe. And then to see your change, you actually have to do Firefox run, mock run to open your own version of Firefox. So the process was incredibly powerful and allowed big things to change all at once. But it didn't appeal to maybe a contributor who just wanted to get started really quickly and try something before dinner. And if all you're doing is working on

that really cool UI feature for the debugger, you don't need, I guess, to change the DOM directory or you don't need to go into the JavaScript directory and fiddle with some C++. That just isn't helpful. In fact, that's really scary, right? Like most projects, the JS directory is where your JavaScript code lives. And in our project, the JS directory is like the C++

that compiles to something. Well, a web browser is a huge project, huge beast, so it makes sense that you wouldn't want to get the monorepo for new contributors. To be clear, Firefox DevTools has, let's see, one, two, three, four, five, seven top-level

tabs. Adam mentioned performance. You got the debugger tab. It might make sense to say, well, let's have a dev tools repo. That's just the dev tools, but it houses all of those. Was there a conversation around, you know, when you break out of the monorepo, how small do you go? Yeah. You know, because you're just representing a single tab.

Yeah. Initially, it was just, let's see if we can do this experiment. And then, of course, we'll go back to the monorepo. That's where everything lives. At this point, maybe let's say we started in March of last year. Around December, we as a team realized, you know, we can go much faster if we're in GitHub. There's no going back. But how do we bring the other tools to GitHub? And it's a challenge because some of them aren't necessarily

ready for contributors. They haven't been refactored to React. They don't have the documentation ready to get started. And we really built out that infrastructure for the debugger to run in a tab that we would have to apply to the other tools. So we've started doing that. The net monitor obviously runs in a tab, a perfect channel runs in a tab. But other things like the inspector still a work in progress. Console is still a work in progress. So they're essentially isolated apps then.

Within the Firefox, you might treat them as one application but when you split something out you can really say this is one app with maybe some shared libraries and the shared libraries are where things become a little bit difficult but uh so far it's been it's been possible this is a big risk then i mean to to break it down to that level, you're going from what you knew before you to get back to, let's just say mindshare developer mindshare. Let's even throw the word again in there. Cause I think you mentioned it too, but you really took a risk to, to sort of break down your old model that had its benefits, obviously. Sure.

But there were areas where you just weren't attracting the new contributors or drive-by contributors, those who want to just jump in on smaller things or some of the things you mentioned there. You took a big risk to go this route. Was there a lot of discussion about risk versus reward in that scenario? Absolutely. And it's still a contentious discussion. Now, we've had some successes in the past.

For instance, Nick Fitzgerald, maybe three years ago, made the source map library, which is on GitHub. And everyone uses it for mapping from a generated file, like a bundle file, to the original files. So VS Code uses it, I believe. Chrome DevTools worked it. So we have experience doing open source outside the tree, but never at this scale.

And we're still trying to figure it out. What's with the.html piece on all these? Is that to sort of identify to those those passerbys like, Hey, this I can pull down debugger dot HTML. And as you mentioned before, it can run in its own tab. It can for lack of better term, it can be its own application with some shared libraries, but it, you know, when it's inside of Firefox, it's part of a, you know,

a single app basically. Is that what it's supposed to mean? Or what was the, what's the idea there? I'm glad you asked it's it's that but it's uh a lot more than that as well so before the rewrite the debugger was largely written and in two technologies that are so firefox zool and jsm and i'll just take a minute to explain each one and you'll see why it was so important that we go about this uh the history of firefox was uh add-ons a large part like firebug incredibly

successful add-on and other add-ons on well and and zool was what underpinned these add-ons it stands for xml ui library and it was kind of like what you would build if you were a browser and wanted shared libraries before there was maybe like react or angular what what zool let you do as a browser is to find new elements so instead of building your select tag or your input you'd have like a drop down or you might have like a tooltip or popover written in XML with embedded JavaScript. But you wouldn't worry about that because anybody could just use them. Now, this worked really well for the add-on story, which would just run Firefox. but fast forward to 2016 and we've got this really complicated app built largely in Zool. And we didn't know what to do. There wasn't really a path forward. It was very difficult to debug.

You'd be really scared if you had to make a change to one of these components. And so we wanted to do something that was html like web friendly and not like a browser technology and and that's where the idea of html came from the other technology was jsm which is javascript but once again like only runs in the browser behind the scenes in a special context and it's privileged so like this privileged javascript can do all the things you're told you shouldn't do it can create context menus and cross origin requests speak directly to the browser and you just list it out and it's wonderful if you have that superpower but once again you try to go anywhere anywhere and you can't run a JSM file.

That's not going to work. And then you look at your front end and your back end, and they're calling these methods that are only available in that context. So we really wanted to focus on web technologies that could run anywhere. And that's one of the reasons why we did this rewrite. You just brought back a huge amount of memories from my college days, because I remember I looked at Zool, and this was when I was like a fledgling developer, and I wanted to hack on Firefox somehow, like an add-on. I don't remember. But I remember back then, I mean, I was just getting started.

I opened up some XML and was trying trying to follow a tutorial and I was completely overwhelmed by Zool. I remember a feeling of, you know, it wasn't imposter syndrome. It was like actual, I was actually an imposter. Like I did not belong there.

I just forgot all about that until you started talking about it. So that being said, I mean, HTML is much more accessible for people than something that's, I'm not saying it was proprietary. I don't, I'm thinking it wasn't, but specific, right? Like vendor specific tooling. Whereas here it's like, hey, it's HTML. Okay.

That brings with it its own baggage, which we'll talk about React and Redux and stuff. And so it's not like it's not complicated, but it is like, it is kind of signaling, hey, you're welcome here. Yeah. not complicated but it is like sure it is kind of signaling hey you're welcome here yeah i mean it was funny because i hadn't seen any of this until i joined and the existing debugger is written zoo and you're thinking like okay like this is well written it was written by very good engineers and they begin to debugging something and you don't have that separation like if you try to step into function.bind or dot apply you're not going to see the code behind it but you step into a function defined in a context and all of a sudden you're in this xml file but there's javascript there so you never had that separation you never had the polish that would go into something like

a select element so you was like this uncanny valley of like this is incredibly powerful you can just write in html's declarative but you know given the choice i would choose react i think a lot of people well it makes sense when you say things like modern tooling too whenever you describe like a hackable debugger for modern times so like this modern tooling this modern times you have referred to in this conversation also in some of your languages it it makes sense yeah let's talk a little bit about the end product because and debuggers are somewhat controversial amongst amongst developers in fact i was kind of admitting confessing to adam before the call like i'm not a debugger person. I'm very much a,

I guess I go slower in terms of I just do, you know, outputs and log variables to the console and then expose them as global. I'm a console person, let's just say that. Yeah. Kind of a puts debugger if you're in Ruby land. And honestly, mostly because, you know, like GDB was my first run in was a debugger.

And again, like it was an imposter syndrome. I actually did not belong in GDB land. I could not figure it out for the life of me. And so I've always been like not an anti-debugger, but just not I'm just not going to reach for one. Yeah. So maybe give your pitch because you're obviously a debugger person. You're building one from the inside out. Oh, yeah.

And they're definitely powerful, but why would I use the debugger as opposed to kind of the, we'll just call it the old school style that I'm still using in my day-to-day work? I've been working on that answer for probably the past two, three years because. Oh, good. This should be good then. Yeah. No, I have a lot of people come up to me and confess that they're not debugger users. And we've done Twitter surveys and I'd say the majority of people probably use the console right now.

Yeah. You look at, oh God, I forgot what the book was. I think it's programmers at work, which is like, uh, I forgot what the book was. I think it's Programmers at Work, which is like founders at work. It write up some various programmers. And many of them would ask, how do you debug? And I'm like, yeah, I print. And I use my mind. And I do see that split because I'm trying to think about the debugger as a product with users.

And I think half the people would prefer to have a tool that helps them visualize and contextualize this information. That's where I fall. And the other half are more in line of like, yeah, they want something quick. Like, I'm going to print this one thing. I know what I want to find, and that's going to work. Or they want to think about it. And that's a different way of approaching the problem. All valid.

But, uh, what I'd like to find a way to do is blur the two. So what are the best things in the console that come from logging? And what are the things that you can only do in the debugger and find a happy medium? Yeah. So what are some of the things you can only do in the debugger and find a happy medium. Yeah. So what are some of the things you can only do in the debugger?

Well, the console is great if you know what you're looking for. So, for example, if you're logging a render function and you're saying like, hey, I only want to look at this one value, like this prop and react render console is great because you can see first of all like all right we got 10 logs i probably had 10 renders and my number went from like 2 to 20 and i could see how it stepped so you get this like over time perspective with the debugger if you're not sure what you're looking for like you're not

sure about the api you're not sure like if you can call that function, like user.update, does that take two parameters, three? What happens if I try each one? The debugger is perfect for stopping in time and exploring that space and then moving on. So the ability to stop in time is really the, you set a break point, you can stop at this specific line

and then it stops the world right there. And you can inspect and dork around from there. Totally. And it's not just at a line, although I think that's the most common, but you can say like, stop at this line in this scenario with a conditional break point

or we're trying to do other ways of stopping. So you can pause on an exception or a dom breakpoint where an ash view changes or an xhr breakpoint or like on a click or the one that i really want to do uh is pause when this this value is undefined because like how many times you can undefine it's not a function you're like where is this or like you got your render and you're like, okay, yeah, I didn't expect it to render with false. But when did it become false? And you don't really know the context

of where that thing was set. So if you can help you stop at the right time, then you can probably figure out what's going on a lot faster. Yeah. I feel like you're in a great position to do a lot of good when you're building a debugger, especially if you have an eye for design and user experience,

because undoubtedly there's a lot of power in there, but it's, you know, it's, it's hidden under the covers or under the shroud of mystery perhaps. And, you know, and like invite, I like your idea of kind of blurring

the lines because somebody who's hanging out in the console and they just aren't getting the answers that they need the answers might be over there in the debugger but how are they ever going to know first of all that the answers are there and then secondly how to go about getting them and so are there any efforts from you or even from, you know, uh, I, I'm starting to think about egghead and, uh, uh, yeah, con economy or whoever, anybody else teaching programming or teaching, I know there's dev tools courses, but, uh, are there concerted efforts around education with the debugger and then also, uh, making it more approachable? Yeah, I think so. Going back to the history again,

I think there was this idea of like Firefox versus Chrome versus IE back in the past. And these days there's a lot more collaboration. So we're talking to Chrome team, we're really talking to the Edge team and then we're stealing each other's ideas. So Nuclide has a debugger now. VS Code has a debugger now.

And we can borrow the best ideas. The other way that I think good ideas are bubbling up is that frameworks, they also know more about the running application. Like a lot of these browser debuggers, assume you're running vanilla JavaScript. Here are the variables and all the data here's the file with everything like you have a call stack with maybe 50 frames maybe 100 if you're doing something really crazy but the framework knows a lot more

about your application just by virtue of like having some structure so we're trying to do is is reach out to them and if you're paused and you're looking at a variable and it's an immutable object like hey we can format a little better so you don't see all that like immutable wrapping stuff you just see like here's your record with the values you care about yeah i like the trend of the the JS frameworks, you know, having their own tooling inside of dev tools, whether it's Chrome, Firefox or otherwise, because like you said, they just have that. They can have the intimate knowledge of the way the frameworks works. So it helps expose things at it two ways. Either we're the browser and we're going to build the best web platform, or we're going toux and Immutable and other tools, we have source maps as well with Webpack and Babel.

We're more inclined to work more closely with them. And because we're feeling the pain and we're part of the community, we're going to try to improve that story as much as possible as well. So these days, as we think about 2017, now that we have a new debugger ui and a really good console and whatnot our goal is to say can we take the react development experience and build

the best tools for them not because we don't care about angular we don't care about other tools but sometimes it really helps be hyper focused and say say, hey, we care about this. Can we try out some things that work really well here? And then we can apply some of those learnings. Very interesting. While we're hitting up against our next break,

we have more details to discuss. I think specifically, we would like to talk a little bit about React and Redux, the choice, the implications and what that's meant for the project, as well as look at some of the stuff you're doing with the debugging protocols and kind of this idea of,

as you say in the readme, developing a broader community that wants to create great tools for the web and exactly how you're going about doing that. So we will pause here and we'll discuss those things after this short break. Our friends at ThoughtWorks have an awesome open source continuous delivery server called GoCD. Head to gocd.io slash changelog to learn more.

GoCD lets you model complex workflows, promote trusted artifacts, see how your workflow really works, deploy any version, any time, run and grok your tests, compare builds, take advantage of plugins and more. Once again, head to gocd.io slash changelog to learn more. And now back to the show. All right, we are back. And Jason, modern tooling,

so big choices made at a certain point, probably when the thing got started, was what kind of JavaScript app will the debugger for JavaScript apps be? Turns out you chose React, you chose Redux. We want to talk about that decision as well as what that has meant. Has it been a win? Have you been faster? Kind of the reasons for it.

But before that, I'd like to ask you kind of a meta question, which is, historically, and by that I mean the last five years or so, maybe 10 years, JavaScript ecosystem has moved so quickly and frameworks have come and gone and tools have come and gone. Um, it's difficult to, to pick a, you know, to pick a horse in the race and react in the last couple of years seems to have, uh grabbed the mindshare a little bit. A lot of it.

In fact, I just mentioned this, Adam, in Changelog Weekly, the last issue. Which, by the way, if you're not subscribed to Changelog Weekly out there, what's wrong? Just do it. Changelog.com slash weekly. We linked to a thing called Reactite or React IDE. I don't even know how you pronounce it and the comment that i added is it seems that react has hit critical mass because anytime there's an ide for your for your javascript rendering engine uh it seems like there's like this is a sticky so just your thoughts because you guys you know you guys

jumped on the react bandwagon um and i would be afraid to like go all in on something like that because maybe there's something better coming next but do you think react is like quote unquote winning in the uh the javascript front end space i think it was the right decision for us and i give james long a lot of credit he from the very early days kind of identified this as something exciting and blogged a lot about it and got to know uh christopher chateau and dan abramov quite well so he did the early evangelism and uh planning for for the rewrite he he actually got redux into the debugger before we started.html. So we were in a really good spot

when we started the rewrite of the components. What works really well for us is that the debugger is one application, but it's also a lot of components that each do their own thing. So the call stack is very isolated from the scopes and variables view which is once again like really different in the editor and in the tree and if we do it right then other people might want to use these components as well

so i remember getting started on the ruby ripples and i wanted to build a front end but where do you even start there's just so much that you'd want and if we play our cards right these components could be reused in other projects so you could start up faster showing our call stack showing variables the. All these things are very reusable and might not even be tied to a language. Just like, hey, here's some building blocks for building your own developer tools. So it's worked really well for you.

You dodged my question. It was a nice dodge. But, well, I guess we'll leave it there. You put him on the spot. He had to call it a winner. That's the fun. Well, he said it works well for them it just seems like we're it feels like there's a a congealing and i'm not saying like nothing new is going to come out but uh you know just the the excitement you know react is old enough now that if it was a typical hype cycle, it would now be in like, what do we call it?

The trough of disillusionment or something like people would be hating it now. It should be the next thing already, but it's still here. Yeah. And so just as watchers of the community, we start to wonder maybe like React actually is going to be the thing in JavaScript for the next five years or something like that. I think that's a reasonable question, at least. I know as a browser company, we're looking for things that are, maybe there's a different React, but we like these ideas

of rendering out to a component. Right. And that probably would be around. Yeah. Yeah. I think it's too soon to say in some ways, things like Elm are doing so much and ember will really help you if you're building on an application and you care more about the server

piece uh for instance and deploying uh and the cli those are things that just aren't concerns for us so if you're just looking for this component model, then React is really appealing. And you can use 100% of it, as opposed to maybe like 40% of Ember or 40% of Angular. All right. All right, very good. Let's leave that topic there. I think we covered it well enough.

Let's talk about this idea of runs anywhere. So one of your major pitches of why the debugger is interesting is that it runs everywhere. And of course it's the Firefox debugger, but what's it mean that it runs anywhere and why is that attractive or interesting to folks? So our dream is to build one debugger that could run in his own application. You know,

imagine spinning up a debugger, like clicking on an icon and there it is running an electron and pointing it at any javascript runtime obviously you can debug firefox but you can also debug chrome or node or an app on your phone whether it be like ios or android and that's appealing for a couple reasons. One, you don't have to relearn a tool or use a tool you don't want to use just because that's the only way

to debug, like, I don't know, a Node app. The other is you can be customizing that tool a lot. So if you've got a standalone app,

it begins to feel like Hyperterm or Atom, where you say, you know what? I'm using this all the time. I'm going to build out some plugins or use some plugins that are really, really awesome and that customize my experience. So the direction I want to go in is, or we want to go in with these tools to say, how do we build out an ecosystem for this app that's built with React, Immutable, Flow, or maybe TypeScript? And then the team can say, all right, these are the plugins of choice.

And all of a sudden, you don't just have like a JavaScript debugger, but you have a debugger for React, for TypeScript and whatnot. And you can just do so much more in that world the other piece is if you're at a company like fire facebook or if you're i come from etsy or you can be like a stripe you've got a lot of front-end engineers and you've got your own internal tooling and libraries so if we could do something where you could quickly build out plugins

or settings that work really well for your app, now we can make these companies' lives a little bit better as well. Does that mean that this is a standalone app then or it will be? Or what phase are we in with the bugger? So we do the development in GitHubithub and i'm primarily running it in a tab like you would if you built any react app with like webpack development server you name it

and uh you can point it at firefox point at chrome and it speaks over a web socket to these browsers but that's not like how we want to ship. We want to treat Firefox like a deploy target, just like we were to treat that Electron app like a deploy target. So with Firefox, we try to do a weekly deploy where we make a bundle, and then we make a commit into Firefox

where it gets the most up-to-date, latest, greatest stuff. And when it comes time to ship this download app which i've always thought we're one month out we'll see uh hopefully sometime maybe june maybe the summer we'll see then we'll treat that as another deploy target where you're still working with that webpack dev server and whatnot talking over a web socket but we could do continuous deployment to this download app and i go weekly or daily release cycle to firefox

you mentioned hyper as a as a point of reference and maybe even some inspiration it seems like maybe that's around your heading potentially yeah i think they showed that if you build your app with react and redux that gives you a lot of extensions for plugins so it's really easy to put something in the react middleware for instance and wrap a component like a terminal tab or the prompt and it's just as easy to do that with redux where you can have a hook before the actions dispatch or after the actions dispatch to like do some good stuff and I don't know if that would be the direction we're going but that's definitely how I see these plugins being built when we're looking at the going back to I think the second segment of the show talking about the naming schema dot html one it's an invitation but

two it's also saying you know no longer no longer Zul, more modern tooling. Does that mean that the other tabs in developer tools are taking a similar direction? Or is it simply this makes sense for debugger to be potentially a standalone app, run anywhere, have many targets, be shippable with even Electron or something like that? I don't know how applicable that is for the Inspector, for instance. So this is getting into the nitty gritty. The debugger protocol is pretty consistent, like well-established between Firefox and Chrome and whatnot.

The Inspector protocol and some others as well, much, much crazier. So we'll see. I i think perf has a route forward uh to do universal performance measuring and their tool is beautiful and they're doing some really good stuff there uh network monitor probably the same story console probably the same story the inspector probably not right now but maybe it's too soon to say so the way to run debugger as a standalone app now is you're you're cloning the repo you're pulling it down um and you're running a tab essentially and via some background configs you're pointing it at firefox or whatever other

javascript runtime but the future will be different yeah that's that's true um one thing that i'm really excited about is that we can tweet out that we want to work on like dark theme or we want to work on search and people can come in and get clone yarn install we started using yarn recently yeah yarn start and that launches this app which from there you can do all like your settings like turn on some features turn on dark theme and then click a button and that connects to firefox and you see the tabs right connects to chrome so we really focused on bringing people in and getting them started really quickly it's like less than five minutes. So it's UI driven, not so much config driven than this connecting to different.

Okay. That was one question I had in the pre-call with Jared was like, you know, back to the run anywhere thing. I was like, okay, so what does this mean then? So to, it seems like most of the documentation isn't, and Jared said, well, you're a developer, dude. You're going to pull this down.

So I kind of feel like an idiot. I was like, well, I thought maybe what phase of the app figure with the run anywhere, maybe you you're a developer, dude. You're going to pull this down. So I kind of feel like an idiot. I was like, well, I thought maybe what phase of the ad I figured with the run anywhere, maybe you had like a developer focus, like if you want to contribute and push code back or whatnot. But then you also have the user focus. And it seemed like there was some user focused documentation missing, but maybe it was all in one. So I was sort of lost.

How do I actually begin to use this unless I'm in Firefox, basically. Yeah. Yeah, sure. User focus just hasn't been a thing yet. And it's never been as important as shipping the new debugger in Firefox, which has always been the goal. There's just so much UI that every time you think you're done, you realize, oh gosh, hovering on a variable, wow, there's so much more there. Or searching through code and whatnot, there's more you can do.

But yeah, the user focus, I think, is a really exciting angle. In that direction, our goal with Node, for instance, is to add something like a debug command, like debug JS, and that would invoke node on your behalf and open the debugger. So you immediately have the debugger open, you can add your breakpoints, whatever. We might even go down the direction of doing some editor integrations as well. Because we have this Redux backend, entire api for driving the debugger is in redux there's like an action for add breakpoint there's another action for like stepping like step over step in everything you want to do is exposed this way so it'd be really

easy to build out an atom plugin that that just drives Firefox or drives Chrome. You just connect, and then you're connected to a tab, and you get the really beautiful Atom UI you might want, which is totally different than our React components, but shares the utils and obviously shares the Redux backend. James worked with Tom Cholmy, who is on our team and is very involved in the Emacs community. I think he was the guy who built out the initial package manager for Emacs. And last summer, I put together a demo of our debugger running in Emacs with a separate node process. And I had everything from kind of like GDB in a a way where you're using shortcuts dad breakpoints and then you can step and whatnot but it just showed me

that all the stuff would be possible once we once we launch and then we can continue like build out the plugins and uh engages different communities that would like to have a really, really good JavaScript debugger in their editor or wherever. So just last episode, we had Ken C. Dodds on the show, and we were talking all about community around open source, first-time contributors, making it easy for people, rewarding for people to get involved and really building that out. And so maybe I'm more aware of it than I usually am. But just looking at the readme that you have here,

you guys have done a really good job of making the project very approachable. Just in a few ways that I will list out. So you have development guides all broken down into those different sections that you're talking about themes, graphs, flow logging. You have like a step by step, like here's how you get started. And then once you get started, here's how you get started and then once you get started here's how you can actually claim it up for grabs issue for instance we're happy to help very inclusive you have a contributing guide you have a code of conduct you have a slack

you have a community call every tuesday there's a dev tool call every tuesday all this stuff is just right there uh for people to see so i guess not really a question but i just i've noticed that you guys are really putting the observation for sure yeah and hopefully it's being off oh yeah for sure um i look at a couple metrics as often as i can and and one of them is how many contributions come from the community versus Mozilla. And in July, October, that was around one-third, two-thirds. And one-third from the community is a really good ratio. But at this point, it's now two-thirds, one-third.

So we couldn't be here now if it weren't for people getting involved and playing a really, really big role. And that means function search, variable search, even the text search largely came from the community. Our tabs came from the community. use funny ones because in order to hover on a variable and figure out what to show you need to parse the javascript and figure out what the logical expression is so if you're hovering on like var a equals two when you hover on a like okay that's i've got a in scope i can go get that value but if you're hovering on like this dot model and your cursor is on like model, you're like, oh gosh, I need to figure out that the entire expression is this dot model. And that's been a really fun feature to work on because many of our contributors who've

been around for three, four, five months saw some of these features that are described out in our issue list as like, parse the JavaScript and figure out an expression or figure out which scope we're in. And it's possible a variable is shadowed by another variable. So like A is two in this context, but three in that context, let's go get the right one. And they're like, can I do that? Can I please do that? That looks really cool. And all of a sudden we have this preview that i want to confirm this like but i'm pretty sure chrome isn't doing things uh in this space that that we are so for instance it's really neat to say like the shadowing if you hover on a in the inner scope you can get a different value than the outer scope as opposed to like two in both cases

or if you're paused and on click and then you mouse over like i don't know on mouse over which is a totally another function that should be inert but in most cases um you're mousing over the same variable like this in both cases and we're going to show the pop-up because hey we're not checking what the scope is we don't know what the lexical scoping is at that level but because we built out this community all of a sudden we're doing polish because it's cool and that's like the css uh with tabs we don't have the time to like really get in and make sure everything lines up beautifully but they do. And they notice those things. And same there with preview. I got stuck on you said that you have to parse the JavaScript.

You're not parsing that JavaScript with your own JavaScript, are you? I hear Firefox has a good JavaScript parser built in. Yeah, right? I'm so glad you asked this. In fact, I just got stuck there and just was thinking about that for the last few minutes. So hopefully I was the only one. Everybody else followed you.

I followed. No, no, no, no, no. This is like the nerdiest detail that gives me the most excitement at this point. So I'm really glad you asked. A month and a half ago, maybe two months ago, we decided to use Babel on the client. It's like in addition to react

and redux to parse the javascript and that could not have been a better decision right so uh what we realized when we started using it was babel has a plugin for everything like we wanted to parse the code that people are actually writing these days, which could be, I don't know, TypeScript or Flow or obviously all the Babel plugins, new JavaScript features. And if we handed that code to the Firefox parser, it'd be like, oh, you're doing what? Right. No. But Babel gets it and the other thing is Babel's API is such a joy to work with that all of a sudden we're

doing these things like hey your cursor is in this scope but once again we're shadowing another variable another scope and that stuff is just really fun to do so a friend of mine that's pretty rad

pretty cool. It makes things like building an outline view or function search fun again. Probably beats that regular expression you had previously. Yeah, that's what it was. That's the best practice. How'd I guess? You're like, oh, I see a colon.

Maybe that means we're in an object. Okay. I mean, look at the left colon. Oh, that's the best practice. How'd I guess? You're like, oh, I see a colon. Maybe that means we're in an object. Okay. Right. I mean, look at the left colon. Oh, that's the key. Great. What could possibly go wrong? Yeah.

And when we can tweet out that we're using Babel and we recently started using Jest and Prettier and we can get more involved in a community with our tooling. It's just, it's so exciting. Like those are the things that really get picked up. And that's my takeaway from this call is, is, uh, you know, when Jared asked, I think it was mostly in the break there, but this new type of open source as the ping repo mentioned from, uh, you know, team that show up was, was how you've embraced, you sort of let go of older models of how you typically did things to embrace,

for lack of better terms, the community and, you know, go into the trenches, which is something we say around here lots is like going into the trenches with everyone else. Because if you look left, you look right and you're in a trench and no one else is around, you're in the wrong trench, you know? So you've got to be in the trench with the right people to help them otherwise you're just standing alone probably getting shot or ambushed soon not good no it's not the place to be yeah that makes me think of uh when we were getting ready to launch about a month ago uh firefox was on a six-week release cycle. We have nightly edition and whatnot. I personally have never done a good job of keeping track of where I am in that cycle.

So I'm constantly surprised. Oh gosh, I've got two weeks and we got to release this thing? Okay. And we were in that spot a month ago and looked at the to-do list and it was like 30 issues. And you just know that some of these things would become like more issues because that's how it goes when you want to polish.

And I was like, can you schedule 10 days? Like this is not good. And had I sat down and just like worked around the clock, I could have gotten like 12 of those done. But instead, I just began like pinging people who'd worked on the project actively in the past month people would worked on it actively like two months ago but i knew i had like school work or something else like hey can you help out you did some tabs work these are the things we need there you did some search work or god like i remember the source tree needed some stuff where like source maps like the like, mapped well with Webpack.

This is it. Here's the issue. Like, are you interested in helping us get ready for launch? And it was just, it was killer. It was the most fun we had. Everyone came in and shipped in, and it was fun. It was good. And that kind of thing would never have happened had we not put the work in to build out those people who care about the project, who know about it and can help us out, jump in the trench.

That's a good place to ask for a call to action. So speaking of trenches, speaking of the community, you know, where are some good inroads? I know that you mentioned you use a different word versus help wanted, but what's the term you use for certain issues that's like come help out or something like that like how can people step in those who are listening to the show they're like i want to get involved this sounds cool i want to work with jason you know and the rest of the team to make this thing what they're talking about in the show what's the best ways for people to to onboard and help out so we used to call these issues up for grab issues we recently switched it to available issues to be a little bit more international. It turns out that up for grabs does not translate well.

If someone were interested in getting involved, I would love it if they stopped by our Slack room and just said, like, hey, this looks like a good project. We've got a really great team of about five to six maybe i don't know uh community members who are eager to mentor and get involved with like holding your hand on that first issue but uh we've also seen most the people come in and once you do that git clone yarn start you're running a react app and you can use any dev tools you want like you can inspect it and see like oh that's the html or you can use the debugger that ships with a chrome or firefox to debug it so i've seen people get involved in like 20, 30 minutes and immediately help us add flow to a file or pick up a UI bug and run with it. I might want to suggest instead of available, I think that the standard term, Jared, is help wanted, right? Is that a pretty common standard?

Is that not a standard these days for inviting folks to jump in? We use help on it right yeah but i don't know what i don't know what's best or standard i just know that i've seen that i use that but available probably is just as good just as good maybe help wanted translates poorly and we just don't know it very well might it very well i don't know you're saying that i kind of like help wanted yeah then take the advice well that's what i see a lot of people use in the least that's what i thought was a standard and so then when i saw what you all call which was up for grabs i was like that's kind of cool too but yeah you know yeah it's relaxed yeah okay you want to

grab it yeah if you don't grab it i'm gonna you know i know there's a website up for grabs i think dot com oh really list out projects that have issues that are for grabs the reason we went with available was we don't want to say like hey these issues are for the community and these issues are for us we want as many issues as possible to be available to to work on and for us available means you know we've thought through the ux and we have a spec for what we're looking for what that end state is we can even include a patch so you can say a patch you know here's the component and the function we think you can work on here's a solution that we think will work but you know it's just pseudocode so like it may work and may not and a lot of these things uh just come back and make the project better so for instance uh we were trying to do dark theme and we do rtl and translations as well

and it was a really sad day in october when we were looking at the project and we're like man we haven't translated any of the strings and brian was ready to go to his manager like you know i think it's important to ship we'll do translations later but like translating to be international and global is a real value of ours. And when we thought about doing the work, we didn't have a good way of doing translated strings in what we call the launchpad in the local development mode. And so instead of saying, okay, well, for internationalization,

we're going to do it in Firefox in the monorepo, we found a way to get that done in the launchpad and then file like 20 issues like translating the source tree translating the scopes and same thing with the dark theme and that brought people in as well so if we can make things available and have like really good docs like really crisp descriptions then like we all win like it's easier for us to work on it it's also easier for for people to jump in and help out. Yeah. Well, we're, uh, we're getting close on time, but I want to give you a chance to, to give

a final shout out to those listening. Anything else we may have missed, uh, we'll put everything we've talked about in the show notes. Our listeners know about that, but any, any last resource or a piece of advice you want to share back to the community before we tail off? Um, just debug? Just debug. Just debug. Oh, I'll give one tip.

And this is a shout out for Chrome DevTools and browser DevTools at large. If you're interested in seeing how the inspector works or the debugger works in Chrome, you can undock dev tools and then do command option i and it opens another dev tools that allows you to inspect the former one wow and for for firefox you can open up dev tools go to settings and then there's a little check box for browser chrome debugging and you go up to developer and then you can select a menu item called browser toolbox.

And with that dev tools that's opened, you can actually inspect like our tab, like Firefox's tabs UI, and you can change the URL bar to like pink. So as a final shout out, I'd say do one of those two things check out what's happening under the hood how your browser is working how dev tools are doing what's doing you won't regret it it's really fun really accessible and you you won't look at development the same way again there you go make sure you do that those two things. And we'll have your Twitter and Slack, all that stuff in the show notes. So if anyone listening does that, give Jason a shout out. But Jason, thanks so much for taking the time to come on.

Thank you for your passion, for doing what you're doing and turning the Jareds of the world into potentially the buggers. Who knows? We'll see. But thanks for coming on the show, man. Much appreciated. Yeah. Thank you for having me.

All right. That wraps up this episode of The Change Law. Join the community and Slack with us at the changelog.com slash community. Follow us on Twitter. We're at changelog. Special thanks to our sponsors, Linode, Toptile, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to Fastly.com to learn more.

Also, thanks to Breakmaster Cylinder for the awesome beats. If you're one of many people emailing us, tweeting us, asking about our theme musics, and whether or not you can listen to them or download them, we have something coming very soon. It's a mixtape. You'll be able to buy it, which is super cool to support us and these awesome shows we produce. So stay tuned for that. We'll see you again next week. Thanks for listening. Bye.