Mastering the art of conference-driven development

Hello and welcome to JS Party, where every week we are throwing a party about JavaScript and the web. I’m Kball, I’ll be your host for this episode. I’m joined by the lovely Suz Hinton.

Hi! It’s good to be back!

Good to have you, Suz. We have an extra-special guest with us today. We are joined by Ashi Krishnan, who is a visual poet and senior software engineer at GitHub.

Hello there!

Awesome. Ashi, thank you so much for taking the time to join us today. Why don’t you tell our listeners a little bit about yourself and the kind of stuff that you’re working on?

Yeah, so right now I’m at GitHub on the editor tools team. We make the editor integrations for a number of different editors. I’m gonna say editors a few more times; editors, editors.

[laughs]

Some other folks on my team work on the Visual Studio extension, or – we have a Unity extension, which I think is pretty cool. I am on the Visual Studio Code extension. If you’ve used the GitHub pull requests extension for VS Code, that is partially me. I am also working on a talk right now that I’m pretty excited about, for React Amsterdam, and I’m working on a secret project at GitHub that I will say no more about… No, I’ll probably say a little bit more about.

I was gonna say, you’re gonna tease us like that…?

[laughs]

Give us some clues, or something.

I sure am doing a lot of GraphQL with this.

Hm…

I haven’t used it, but I heard the latest version of the API is all GraphQL.

That is true. In fact, I think we are one of the largest APIs that are in GraphQL, because whenever I go and look for GraphQL documentation or examples, 90% of them are “You can hit the GitHub API…” And it’s very surreal, because it’s literally exactly what I’m trying to do, so I’m like, “Are you inside my head, tutorial writer?”

I’d be interested to hear a little bit more about this concept of visual poetry that you’re playing around with.

Yeah, I’m still trying to come up with a good name for it, but by that I mean – I’m referring to my talks, basically, where I create talks that are stories with intense visuals, and some kind of poetic component to the language, usually. I think learning from machines and living things are a couple of the best examples of this.

[03:57] I have to ask, since we’re talking about words and naming things, a particular fascination of mine is the way people name themselves online and how that influences the way they present themselves. You have two different, distinct usernames that I saw. On Twitter, you are @rakshesha…?

Rakshesha, yeah.

And then on GitHub, and then on GitHub queerviolet. Are there any stories behind those names?

There are small stories behind those. Queerviolet is the older one, and I picked that one because I’m a strange flower, and sort of more seriously as a way to be visibly linguistically queer in a space that doesn’t always make that obvious. It is, as my friend has pointed out, a little bit on the nose, so I started to kind of lean away from it with my Twitter handle and my Instagram handle. And for those I picked Rakshesha because – so I might butcher this now… The Rakshasa are creatures – they’re kind of an Indian analogue of the faith where they are creatures who are other than the gods, but they are like the gods, in some sense. They were there before, and now they have gone away because the gods vanquished them. So Rakshesha is sort of a female demon that lives in the lands beyond creation, and sometimes comes in to do mischief.

[laughs] And have you found that having those names has kind of changed the way that you present yourself publicly?

That’s a good question. I’m gonna say no, but it’s sort of impossible to say all of the forces that shape us into what we are… So I would like to think that by choosing that name I’ve invited a little bit more trickery and a little bit more subversiveness into my online personas.

Nice. So you mentioned this briefly and I wanna bring it up - one of the reasons we got this opportunity to have you on is because you’re gonna be speaking for React Amsterdam and we’re coordinating with them - we’re gonna have a live JS Party at React Amsterdam. So for any of our listeners who are over or able to make it out to that, it should be a great conference. It’s happening on April 10-12th in Amsterdam, and there’s a really cool opportunity associated with that that they asked us to highlight, and I think it’s very relevant to our audience… They’re doing these open source awards, where you can submit your open source project and they’ll shine a spotlight on it; and since JS Party and the Changelog are very open source focused, you need to definitely take a look at that. We’ll have a link in the show notes, and I’ll drop one in Slack now. Put your projects in, so that you can get highlighted.

I kind of wanna ask you - you’ve teased the talk a little bit, but what is it gonna be? Is it one of these visual poetry talks?

It is gonna be pretty visual. Whenever I’m writing a script for a talk, there’s always a little bit of something like poetry in it. I try to find clever turns of phrases, at a minimum. So at React Amsterdam it’s going to be about WebGL and React, and kind of heavy on the WebGL front.

I got an iPad - the first kind of iPad that worked with the pencil, the first-generation pencil; I got that when it came out, or a little bit after it came out, and then it got stolen about a year later. So I got the iPad Pro the first day it came out, and I’ve just been doing a lot of sketching and working with the stylus, so my talk is gonna focus on how to take data from the stylus in a web app and render it with WebGL, and do so in a React context. It’s heavier on the WebGL part than the React part, to be honest, but there’s gonna be some React in there.

Nice.

And this is an incredibly creative talk, and I’ve sort of watched you produce really cool things over the last two years. I think I met you a while ago when we were both on a panel in New York…

Yeah…!

[08:03] …and I’m so fascinated by the fact that you have this really cool origin story of how you first got a foothold in the industry. I’m interested in how you went from that, which to me didn’t sound as creative with the coding side of things, to what you’re doing actually today. Because I know that you got into code in a similar way to me, with the Commodore 64 and println(), but then what made you go into the more creative side of things after you’d been in the industry for a while?

I’d always been very interested in storytelling, and in graphics, and in putting together these interesting, creative, visual things… And I just kind of had a place to put the – and I know it’s like, “Oh, you can make a website and put your things on the website”, and that’s true, but the other part of that is “I haven’t had deadlines or places where it’s like “You’re giving a talk on this day, and you are going to stand there on stage for 30 minutes, whether you’ve prepared a talk or not, so you should probably prepare something…” [laughter] That kind of deadline is really – my friend said this is excellent for my creative process, and I have to agree, because it forces me to actually produce things that are [unintelligible 00:09:17.10] things and put them out into the world.

I’ve kind of always been doing experiments, and projects that I’ve kept to myself, but giving talks really has forced me to finish things, which I think is wonderful.

Do they call it conference-driven development? …I’ve heard people say in certain circles… [laughs]

Yeah, I benefit greatly from CDD. [laughter]

I have definitely done this before. I’ve submitted an idea, and it’s usually like at least six months out, because I would never really give myself too much of a crunch… Because you know, I might be maybe a quarter of the way into the project, but I just need a little bit of a fire lit underneath me to get it done, so I definitely relate to this.

I’ll do that…

One of my favorite talks, “Learning from machines” - I applied to Write/Speak/Code and I applied to Strange Loop, and Write/Speak/Code turned me down and Strange Loop said yes. So I started developing it for Strange Loop, and then Neha, who runs Write/Speak/Code, came back a month or two later, and was like, “Hey, actually we have a spot… Would you like to present to Write/Speak/Code?” I was like, “Oh yeah, great! That’s perfect. I’m already working on it.” And I agreed without looking at the schedule and then I looked at the schedule - I’d just agreed to present this in two weeks. [laughter]

Oh, no…!

So that was a bit of a crunch. But it came out still one of my favorite talks; it came out really well. So I started to understand why my artist friends, some of them have – they’re almost attracted to putting themselves into a crunch mode and just going into this hole of creativity and then coming out and being like “Here, look, I’ve done this thing”, and they’re haggard and they’re bleeding, but they’ve done it. It feels like an accomplishment.

I feel like even if I give myself that six-month buffer and I say “Okay, I’m gonna do it”, and I do a lot of work and I get it 80% done, I redo it again in the last two weeks anyway. [laughter]

I’ve gotten better about that.

I do that with my slides. The actual project is fine, but I will finish my slides, and I’m very good about trying to get them done in advance, so that by the time – if I have to travel to get to the conference, that side of it is done. Then usually 24 hours before, I freak out and I think everyone’s gonna hate it, and that’s when I end up rewriting all of my stuff, even though I was really nice to myself and completed it ahead of time.

Yeah, I can never do that. By the time it’s like a day or two before the conference, basically everything is locked in; it’s done, I’m not making many changes. I’m making changes like “the bug in the corner”, or “tweak the wording on these slides.” By that point, the development is code-frozen, more or less.

That makes sense. And this is not the first JavaScript conference you’ve spoken at. You spoke at JSConf EU last year, is that right?

Yeah, that was probably my most popular talk. I love the JS Confs, they’re just very well put together.

[12:12] They are. They’re a lot of fun. So I wanna dig back a little bit into Suz’s question, because you talked about how you got into that creative outlet, but I don’t feel like we got as much about “How did you get going into programming?”

Yeah, so I have this story that I tell, and I wanna lead in by saying I have kind of mixed feelings about telling it, because it’s very much the “started very young” narrative that I think can be discouraging to people. So I’ll start out by saying that this is how I got into it, but people take many, many journeys and there are many amazing programmers who did not do this.

In my case, as Suz mentioned, my family had a Commodore 64 when I was growing up, which if you don’t know - it’s this big, boxy keyboard that has a computer inside, that you plug into a television. So my dad showed me how to write a program on it. What that program did is it was like “10, pick a random color. 20, print I Love You Mom. 30, Go to 10.” So my first program printed “I love you mom”, and these random rotating colors. I showed it to my mom and she was obviously overwhelmed. From there, I just kept doing it.

My dad stopped showing me anything, but we had these books that had programs in them, so I’d go and type out the whole program, because you can’t copy and paste from a book, and I would then – so I’d type out a program of a ball dancing around, and then I would tweak it to make it play a sound whenever it hit the corner of the screen. Then I saw a Mac and I was like, “Oh, I’m gonna try and do that on the Commodore 64”, and I tried to make System 7 for the Commodore 64… All of these projects that are incredibly quixotic. Looking at them now, I’m like, “Well, that was never going to work”, but it doesn’t matter if it works, really; I wasn’t trying to start a company… And that’s how I learned.

Nice.

Actually, for my mom’s birthday last year I went and found a Commodore 64 emulator that ran in the browser, and I rewrote that program… Which was surprisingly hard, both because I have forgotten Commodore 64 BASIC, and there aren’t tons of tutorials on it… And also because when you’re typing in that emulator, it remaps your key use to be the Commodore 64 keyboard, so I was like “Where is the quote?” It’s above the 2, it turns out. But it was an experience, to take me back to my childhood. I rewrote the program and sent it to her, and she was, once again, deeply thrilled.

[laughs] I went to the Living Computers Museum recently and that was where I saw a Commodore 64 for the first time in – I don’t know; I’m aging myself, but obviously decades… And I forgot how different they keyboard is to a regular keyboard that we use for the computers now, and I really identify with that… And it took me forever to find that quote on the 2. And also, trying to remember which registers to poke to change colors for the border around it, and everything… I was almost sad at how difficult it was for me, given that I learned that at nine years old, and I was having trouble getting back into it.

Yeah, but when you think about it, it makes sense; it’s almost shocking that we had as good a memory for all those registers and stuff at the time. Now all of that data is stored in Google, as far as I’m concerned. I was teaching my dad Python, and I was like “How do you do FFT or some buffer in NumPy? I don’t remember anything. What is the syntax…?”

I feel like we have this sort of fixed complexity budget of what we’re able to manage, and as things have gotten easier, that means that we are doing more things, but we forget the details underlying. We don’t manage those; we copy them, or use libraries, or what have you.

[15:57] Yeah. Coding on the Commodore 64, or any of those early coding methods, they’re so unbelievably painful. [laughter] You type in the whole line, you need to prefix it with a line number; if you get it wrong, you have to retype the whole thing. There’s no command/ to comment something out. I’m not even clear how you remove a line. The emulator kept crashing… It’s probably the worst programming experience I’ve had in years, and that’s how I learned for like 10-15 years; I was just doing that. It’s amazing to me, honestly… Without Google. There was no Google. How did I learn anything? I actually don’t know; I couldn’t tell you.

Are there any parallels between this and the WebGL work you do? I ask this in a naive fashion, because I know that WebGL is a ton of math, but lower-level it is relatively stateless, and things like that. Did it sort of remind you of any of the early days of programming, when you got into it, given that JavaScript is much more highly abstracted?

You know, writing a shader is a little bit – especially some of the tricks you can do when doing graphics on the Commodore 64… Like, one thing you can do is you can change the color palette; the Commodore 64 has a 16 color palette that you can flip between a few options… So you can change it, and if your timing is right, you can change it in the middle of the electron beam tracing across the screen, so you can get a larger color palette… [laughter]

Racing the beam. [laughs]

Yeah… So there’s not a direct analogue of that technique, but some of the things you do in shaders, where you’re like “This little program is running for every pixel”, they’re slightly reminiscent of that… But to be honest, even that worked. When you’re writing a shader program, you’re writing a fairly large program in C, that’s gonna get compiled and assembled… And even that lower level of tooling in our graphics pipeline is still so much higher-level than what was available on the C64 or arcade machines at the time.

Got it.

Awesome. Well, I think we’re at a good place to take a short break. When we come back, I’m gonna switch up our plan, because we’re talking about learning and stuff, so I wanna dig into – I know that Ashi has done a lot of work at bootcamps, and teaching, and thinking about folks learn, and since we’re already talking about learning, when we come back we’ll be digging into “How are folks learning today? What are the challenges? How are the entry points?” and all the pieces of how you get into the industry today… But first, a quick break.

Okay, welcome back, JS Party people! Let us talk now about another topic that Ashi has been involved with quite a bit; I was looking at this, Ashi - it looks like you worked at at least two different bootcamp or training types of things, and I’m kind of interested to hear your perspective on – we talked about how you learned the industry, but how folks are getting into the industry now… There’s been a lot of talk recently about the entry points into the industry, and there’s this age-old debate about fundamentals versus framework-first, and various other things… So maybe first, starting out, just tell us what it’s like working at a bootcamp.

[20:10] Well, it’s pretty intense, because everyone there - at least the bootcamps I was working at, and I imagine this is fairly typical across the industry… Everyone there is making a major life change. They’ve left their job, they’re possibly living in a different city for a few months, and they’re trying to cram a huge amount of knowledge - just facts, but also, in many cases, a whole new way of thinking - into their brain in 3-4 months, and then go get a job. The whole process, and thereby their entire life might collapse at any of those points.

So everyone is under a ton of stress, and you can do your absolute level best yoga, zen, stand on one leg, be the calm in the center of the storm, but you’re still collecting all of that energy and you’re still being [unintelligible 00:21:04.24] around. In every single cohort there’s a student crying in the bathroom, or many students crying in the bathroom at various different times… So it’s an intense experience.

It’s also - partially for that reason - very rewarding. You get to see people go through that process and then actually have their lives changed. For the most part, it does work out. Students do get jobs. In my experience, they are typically happy with them, but my experience is obviously slanted towards the students I’ve kept up with more, which will tend to be the students I connect with more, which will tend to be people like me… So I can’t be said to hold a representative sample, but in my experience it is very rewarding and very intense. And also, after you’ve been there for a while, it’s a little bit like Groundhog Day, because you’re teaching the same material every four months, or every three months even, so you get to know – I didn’t know Rails or Ruby when I started at that bootcamp, which is a Ruby on Rails shop, and I learned it during the course of being there, and then now I’d say I know it pretty well.

And similarly, I didn’t know Angular when I started at Full Stack, and I didn’t know React when we started teaching React, and now I definitely know both of those. I know React a lot better than Angular. So you keep getting better at the technologies, and the students necessarily don’t, which is fine and understandable, but that for me started to get a little bit frustrating - feeling that tension, where I’m like “Oh, we can do this wild thing with contexts and hooks, and this and that”, and students are like “You need to slow down. We learned for-loops a month ago.”

Right.

How is that compared to – let’s say you’re working on a product team and you’re mentoring a junior who’s just being hired? Are there differences in your approach? I mean, I know that this is a strict curriculum, but I know that when you mentor juniors at a company, you tend to be goal-setting with them and things like that, too. Are there any similarities, or is it very different?

There’s definitely a lot of similarities. Right now, when I’m working with or mentoring more junior devs, I find myself doing a lot of similar things. We will goal-set, we will pair together… The way we’ll go through things and the way that I’ll find myself slipping into an explanatory mode – I should maybe check it; maybe this is just annoying for all my colleagues, but I think there are definitely similarities.

[23:40] There’s also some notable differences, where because the timeframe of a bootcamp is so short, there are some aspects of software engineering that you can’t delve into, technically. Testing, for example - we would encourage it as instructors, but it’s really hard to see the benefits of it when the longest project you’re ever gonna be working on is like a week and a half. That’s just long enough to encounter your first “Oh, we broke everything and we don’t know when we broke everything, and everything is falling to pieces”, but it’s not really – it’s actually almost not worth writing tests for a project that’s only going to live that long. So those kinds of engineering practices are a little bit harder to teach, I think, in the context of a shorter bootcamp program.

That makes a lot of sense.

Absolutely. So what would you say, having seen this at a couple different bootcamps, teaching different(ish) curriculum, but it looks like both pretty web-focused, what would you say are the hardest things for folks coming into the industry right now to get their heads around?

Promises.

[laughs] I love that you said this, yes!

At that level, it’s definitely promises. I think async/await will probably help this a little bit… We weren’t’ using a very async/await-heavy curriculum when I left Full Stack. I think that will make it easier to manage, at least, because obviously if you change something to being asynchronous you don’t have to refactor everything that calls into it… I think it will create this different problem though, where people don’t really understand the distinction between what is synchronous and what is asynchronous, which - honestly, people’s grasp on synchronous and asynchronous is fairly loose to begin with, and then won’t understand some of the subtle timing things that come up, where in an async function you can no longer trust the JavaScript bedrock of “No other JavaScript will run between these two lines.”

Right. Interesting.

And eventually, promises have to come back into it as well, because that’s sort of – you know, it’s syntactic sugar on top of that.

Yeah, of course, and you will sometimes end up using promises directly. You’ll see some async function returning – I don’t know why you would do this, but returning Promise.resolve, or calling an async function and then chaining that catch onto it, is a favorite of mine that sometimes throws people for a loop…

Yeah. I wonder how much of the challenge is just “asynchronicity is hard, regardless of how we sugar it up.”

Yeah, there is definitely some of that. I also feel like there’s a sense in which the world would be simpler to reason about if everything were asynchronous. On the other hand, if everything were asynchronous, you’re basically back into the “we’ve got multiple threads going and I don’t know when I can trust anything anymore” land. I think there are models that we are slowly discovering, that will make handling all of this stuff easier.

I actually think React offers something like a glimpse at how we can handle asynchronous resource management in some future language. I’m being vague… Intentionally.

That’s okay.

[laughs]

Well, yeah, it is interesting, because increasingly we’re seeing frameworks pick up more and more of the things that we might have previously had to manage ourselves, so some of that may be asynchronicity.

Yeah, and my comment about React was kind of alluding to how you have this materialized component hierarchy; you basically acquired all these resources and you have little – almost like an Erlang services, but lines of communication are structured differently. You have all these little services, each of which represents an asynchronous resource, and data kind of flows through them at the pace that each of them are able to accept. So each little microservice – it’s not even a microservice; each little component is managing its own state, and managing its own invariance, and then the framework is structuring how data flows between all of them, and in particular how to set up and tear down those services as we need them or we stop needing them. I think we’re going to start to see that model replicated in different spaces, and towards different ends.

[28:02] That leads into a question that I had - a common criticism of bootcamps is that they end up teaching all about some framework, and students come out not understanding any of the fundamentals… And there are arguments back and forth on that, but I’m kind of curious both what approach the bootcamps you worked at took, and what your take is on how to design curriculum for folks trying to get into the industry after a three-month bootcamp.

So how do design a curriculum post-bootcamp grad curriculum?

Well, kind of the extent to which bootcamps can or should be focused on fundamentals, and if not, how does that feed into sort of “What should you be doing post-bootcamp?”

Yeah, so the two bootcamps I was at had slightly different approaches to this. I think that bootcamp’s curriculum – I did not personally like it quite as much, and it didn’t really have many CS fundamentals. I think there was a workshop on something – actually, there was a workshop where you made an AI that could look at a Boggle board and find all the words on it, and I think there was a chess AI project that nobody every finished… And then at Full Stack, they (to my knowledge) still have a few workshops - the first ones actually are on CS fundamentals; they have you write a list, and a HashMap, and probably some binary trees, and maybe a trie, and some common traversal algorithms.

It’s interesting, because I am still undecided about how useful those workshops were. I think it’s good for people to have gotten that exposure, and most students I think felt like it was probably good to have that exposure, but then they also felt like it wasn’t very connected to the rest of the curriculum… And it’s pretty hard to fault them on that, because the frameworks we use work at such a high level that you very rarely have to find a cycle in a graph yourself. I did that the other day, but it’s not the most common problem that you’re gonna have to solve. Most of these problems have been solved.

So I personally learned from what you would call a “frameworks-first” approach - the framework was C64 BASIC - nobody sat me down and taught six-year-old Ashi “Here’s a linked list, here’s what memory is like, here’s what it means to peek or poke a register”, nothing, none of that. So I learned how things work by poking them, and then through that developed mental models that turned out to be mostly correct for both how things work and then how to structure programs.

I remember in college I wrote some code and the instructor was like “Oh yeah, you’re using the composite pattern here”, and I’m like, “Yeah, that’s what I’m doing…” [laughter] It sounds great, it’s a good name.

That is definitely something that we can relate to a lot, when you’re sort of using a whole bunch of words to describe something, and somebody who obviously knows the terminology is like “Yeah, that’s just a queue”, and you’re like, “Oh. Okay.” I’m sure that happens in bootcamps as well, given that it’s so hard to link what you’ve just learned to “Well, what is React made up of? How do you map a graph of DOM nodes to the graph that you learned about in a very abstract form a couple weeks before?”

Yeah, exactly. I think it can just be very challenging for students to make those connections, especially while they’re in the bootcamp, when everything is still very liquid; nothing fully congeals until after they can cool down a little bit, the stress is a little bit off, and they are able to relearn everything they learned, but in a more solid way. This is their first exposure to all of these concepts, so everything is murky and vaguely connected.

I actually think the students who do best are the ones who are able to look at something and be like “Okay, I kind of get that. Moving on…”

[32:16] That makes a lot of sense.

…which, honestly, is something we do a lot in coding. “Oh yeah, I kind of understand what’s going on here.”

Yeah, “I have to get this feature out the door, so I need to move on for now, but maybe I’ll come back to that later” sort of thing.

Yeah.

Yeah, we’re progressively refining our mental models here. So that kind of raises the question of “What types of jobs does a bootcamp legitimately prepare someone for?” Are they ready for any entry-level job? Should they be looking particularly at companies that have well-established internal training types of programs? Are you at the same level of readiness you would be coming out of a CS degree? Where does this land you?

This is a really fudging answer, but it depends so much on the student… There are students coming out of bootcamps who I think are far better prepared than CS grads. We actually had CS grads come to Full Stack and go through the program, because they were like “I went through the CS program and didn’t learn how to program.” Some of this I think is confidence, and what they feel like they know, versus maybe what they actually know… But they were like, “Yeah, we just didn’t write much code. I don’t feel like I could go and get a programming job right now.” So the bootcamp is really great for that, obviously, because they have the fundamentals and they then get a lot of practice in actually building apps.

But then there’s also students who come in with no experience, and I think would do great, and would probably do better than many graduates from four-year programs who didn’t have a very practical programming component; or maybe graduates from four-year programs who just weren’t that connected with it or didn’t engage/haven’t yet figured out how to engage the material in a way that really lights up their brain.

I’ve had students who go on to do pretty standard web dev engineering with the stack that we taught (Node.js and React, and all that), and I have students who go into working at a hardware startup on C code. And both of those students are, to my knowledge, doing great.

Awesome. Well, I think this is another good time for a break, so let’s take a short break, and then when we come back we’re gonna dig into developer tools, which is your most recent job, and thinking about what needs to be done there, where are we as an industry in terms of tooling, and maybe looking particularly at tooling within the React ecosystems, since we have been talking a lot about React. We’ll be back shortly.

Okay, welcome back! Let us talk about developer tools. Ashi, your new position, you said, is focused on developer tooling. Is that something that you’ve been working on in other places as well, or is this something that’s a brand new area for you?

It is – well, it’s incredibly geeky to call it a passion of mine, but it is a passion of mine. As I think with all programmers to some extent, we work in these highly specialized tools so much, we inevitably develop opinions about them, and we want things from them… Yeah, so I have opinions about developer tools.

Do tell!

Oh, what are they? I think they’re incredible, and they should be better. They can be better, I’ll say. The hardest problem in debugging something, at least - it’s always like seeing how the wiring runs through the different layers, and it’s always something that can be improved… And I wanna say it is getting better. Right now in VS Code you can run a program, attach a debugger and really see within your editor everything that’s happening in terms of the data flow within it. But I think even that can be improved. We can see more integration between the layers, more ability to cut into our application and see a cross-section of like “Okay, here’s where the input event comes, and then here’s everything it triggers” or “Here’s how this variable is changing over time, and here’s a histogram of the values it takes on”, and all these kinds of things.

And then of course, in the WebGL side of things, when you get into the slightly deeper layers, the feeling is not the greatest. Frequently, you will write a shader and you will run the program and you will see nothing. Nothing whatsoever. And there’s no error on screen, there’s just nothing. And that’s the worst. That is absolutely the worst.

Yeah, absolutely.

What do you think are some low-hanging fruit for developer tools that are sort of more general, that you see time and time again when you’re using a developer tool? What are the sort of things that can be addressed, that some people just sort of have a blind spot to if they’re developing a tool for other developers?

Oh, that’s an interesting question… I wonder if I know of any low-hanging fruit. I definitely can see some really delicious fruits up near the top of the tree…

[laughs] I love that.

We can talk about that and then we’ll just all salivate thinking about them, and we’ll pretend they’re low-hanging.

Yeah, let’s do that.

Well, I’ll say that any time that you can make transparent some aspect of the program, that is a great opportunity. I love how in VS Code’s debugger mode you can just mouse over and see the values of everything. I almost wish there was a little sidebar or something that showed me for each line “Here’s the values that each variable is taking on in this line” always, so that without having to inspect each one manually, I could just go and see this list of changes.

I also think anytime you can create extension opportunities, so any time you can offer an – an API sounds so big; what I really want is the ability to write a little bit of code that talks to the program in a meta way. So if I can write a GraphQL query to query mutations that have happened to a particular variable, say, that would be nice. Or if I can write a little bit of JavaScript…

[39:59] Okay, sidebar - I’ve been working on TypeScript a whole lot recently, and I think it’s really cool, I think it’s really great. There are numerous times when I just wish I could tell TypeScript that the type of this variable should be generated by this JavaScript function that runs in the compiler. There’s no way to do that. I can understand how that breaks all kinds of mathematical – this algebraic whatever form is impure if I’m allowed to write JavaScript that goes and computes what the return type should be, but I should be able to write JavaScript that goes and computes the return type of a function, given not the runtime values of the type, but the input types that it was called with.

So I think that kind of meta-ness, where you can write code that describes how this code should be assembled - that is something we’re starting to get into, and I think it’s actually going to be very powerful.

I recently for one of my talks wrote just this little preprocessor that takes a YAML file and parses the keys in that particular way, and if the keys have a special form, it goes and generates a file with a file extension as specified in the YAML, and it creates this JavaScript file that goes and imports all of those, and the YAML tells you how to wire them up. And working in that has been surprisingly enjoyable. You sacrifice some things - you don’t get the syntax highlighting for the embedded fragments, but I can put pieces of five different languages together and describe how they should build, all from one file, which feels very nice; it feels very contained and it feels very powerful. I can see how if I had a little bit of a programming language rather than YAML surrounding this, I would have something where I could do a lot with very little effort, by building on top of this huge ecosystem.

Interesting.

Do you think there’s a bit of death by config going on right now in the industry?

I think there has been. I actually feel like we’re in a fairly good place right now. I mean, I feel like I am in a fairly good place; I think different projects are in different places, but as someone who’s working on some pretty greenfield development at GitHub, and who often does greenfield development for talks, I actually feel like I can create a project and Parcel that, and it just works these days. And if I want it to work differently, I can write a plugin that honestly probably does some things that the Parcel folks would find terrifying, but… It’s my computer!

That is one of the things I was wondering as you were describing configuring your build with YAML, and then wanting to apply some code… Is this kind of the target that Parcel and Webpack and those folks are aiming at?

I think yeah. The project I was describing just then actually ran on top of Parcel, or ran under Parcel. All that tool did was generate a bunch of files which I then Parceled up, or was Parceling up constantly. So yeah, I think those tools that give us the ability to glue together all these different languages, and JavaScript is kind of a lingua franca of all of them, so your CSS gets compiled into JavaScript, or TypeScript gets compiled into JavaScript… That is creating this very powerful ecosystem that we’re just starting to understand the edges of; we’re just starting to get into how powerful it is to be able to build all of these languages together, and I think that WebAssembly is just going to open up another huge, huge avenue for [unintelligible 00:43:48.00]

[43:50] I do wonder a little bit how we walk that balance between simplicity of use for the vast majority of cases, while still empowering those who really want to mass-configure everything. Because meta-programming is one of those places where it’s like, you’ve got plenty of rope to hang yourself, and if we push everybody to “You’re gonna configure your code in code, and write self-generating code”, we end up in a place where debugging and analysis gets really hard.

Yeah, and this is where I think it’s important to be able to trace a piece of data through all of the layers and understand how all of the different layers have – or at least have something that understands how all of the different layers of compilation worked, and gets you back to some source file. Ideally, you’ll be able to explain the problem that you’re seeing at the end in terms that you as someone who wrote the input could understand… And we’re definitely not there yet.

A huge amount of times I load a module and… I still think this happens - Node doesn’t load source maps for the first tick, or something, and so I get this error in a generated file, somewhere that nobody has ever heard of… And this is definitely a place where I think we could improve a lot, being able to maintain that linkage while adding more and more layers to the stack… Which, as someone who’s tried to write Babel transforms, and Webpack loaders and that kind of thing - it’s not super, super-easy to maintain that linkage as you’re doing everything; you have to write your parsers and write your tooling in a way that understands that what you’re doing is cutting up pieces of another thing that itself might be generated in order to generate something else and maintain those connections through that whole process.

For sure. Let’s talk a little bit about the React ecosystem in particular… Our excuse for talking today is React Amsterdam, and it seems like you’ve been doing a bunch of stuff in React, both on the teaching side and then on the development side. Where do you feel like the holes are in terms of React tooling? Or where are the really cool opportunities that are getting started?

There’s a lot of cool stuff out there. In terms of plopping a component down on a page, and feeding it data, and seeing what happens. Do I think React tooling is just great? I feel like there needs to be better tooling around hooks, since hooks are now going to be the new hotness for the next year or so.

Right now, if you go into the React developer tools and you look at the hookified component, the internal state, you get to see how they’ve implemented hooks, which is cool and all, but not really that useful to me, if you look at the – I guess the props are normal. Yeah, so that could improve, and I’m sure will improve.

Outside of that… I have complaints about the framework in certain respects. I’ve definitely gotten into these states where a component will crash within an error boundary, it’ll crash loop within the boundary because the boundary keeps restarting it. It would be nice if there was some kind of global way to capture failures like that, to see the tree and be like “Oh, this component is in an error state”, and ideally, “here’s why it’s in an error state.” “Oh, I think the props didn’t match.” Be able to get sort of a more readable error message. Prop types help with this a little bit, but sometimes it’s not strictly speaking a type issue.

On that note, something the whole world could benefit from is if TypeScript had a shape operator. There’s no reason on God’s green earth why the compiler can’t see “shape of x” and be like “Okay, whatever I think the shape of X is, I’m gonna replace that expression with that JSON.” That would enable all kinds of things. That would enable you to auto-generate prop types from the typings for a thing, that would enable you to auto-generate GraphQL from the typings of the thing.

[48:09] There’s a number of times when I’ve wanted to just get at runtime the type information for a variable; and I know that there’s a way to do this by turning on experimental declarators and doing some reflect thing, but it seems like there are holes in that. That doesn’t work with free-floating functions and a few other cases, and it would just be nice if I could just ask the compiler to tell me what it knows. “Tell what you know! Sing like Michael Cohen!” [laughter]

Oh, but then would we be able to trust it? [laughter]

I wanna ask you actually how you feel about integration testing in React right now? How do you feel about where it’s at and where it needs to improve?

Actually, I don’t know. I haven’t done much integration testing in React, which I think is probably a sign that it could improve. I’m actually having trouble even thinking about what it would look like. I guess you have a whole app and you wanna go through some flows with it…?

Yeah, that’s definitely it. I think I really like where we’ve gone with doing snapshot testing and things like that, but that tends to just be very much like the state containment in one component only, whereas obviously none of these components are sitting in a vacuum in that way.

Yeah, so being able to look at how the whole page is working.

Yeah.

Actually, is that something that we should do at the React level, or still at the DOM level?

I think that the snapshot testing that’s come out of this to me has been one of the big unsung heroes of not necessarily React, but just given that we’re doing more and more single-page applications and the JavaScript on the front-end is responsible for more, we had to sort of create more sophisticated tools… So I’m hoping to see some innovation in the integration testing as well, just partially because – you know when you’re on a website and it’s a single-page app, and sometimes you have this funky UX experience, and you know you can feel the actual programming, or you can feel the declarative pathway that led you down there, and it’s just quite jarring, and it’s so unfortunate that you know exactly why it happened? I’m wondering whether there’s any innovation in trying to address those things that happen…

I think if I were working on integration testing for the web, I feel like I would have one layer that is really DOM and assistive technologies-focused; you would express how to do something either by recording a series of clicks and having that get mapped to “Oh, okay, she clicked on the button with this name, and the control with this label, and the link with this label” and so on. And then maybe on top of that having some layer that will connect those DOM elements (again, cross-cutting through layers) to the component that rendered them, and be able to let you address the DOM nodes in the other components, but then also will track down like “Okay, this component didn’t match its expectation on this page.”

I don’t do a ton of production web front-end work these days, so I’m actually not that familiar with the current web page state of the art… But I feel like for integration testing a web page I wanna do something at a deeper level than React. Not quite pixels probably, but at the assistive technology layer of like “Here’s all the things that I think do something on this page, and here’s how I think they should behave.” And then maybe actually have some testing at the pixel there, too.

I think those two levels definitely make sense.

[51:55] Yeah. You talked about dev tools providing transparency - I think having a way to implement testing at each of those level and kind of transparently drilling down through and addressing the tests at different levels of abstraction would be super-valuable. We’ve seen tremendous progress in JavaScript unit test and things like that, but I think, Suz, you’re on to something. Integration testing is still very hard, and maybe there are tools out there that folks have used really well, but they’re not as well-marketed and discussed, or the tooling may just not exist.

Yeah, I think it’s hard, because when you start talking about integration testing web pages, you quickly get towards like “Oh, well I guess we better spin up Chromium, and spin up a renderer.” And once you’re spinning up Chromium, now you’d better test it in multiple renderers; and then you’re in Selenium land, where you have all these different browsers installed, and you’ve got them in VM’s, and it’s all pretty hard. There must be cloud providers that do this, but I can see how it would be hard even to configure those. There’s probably space here for some power provider to come in and be like “We will just do this. We will give you a Chrome extension that records you going through test cases in your app, and we will track what your app does, and you can tell us what you’re expecting, and we will just create all these test cases and then run them on every platform you said you cared about.”

Yeah. I think BrowserStack did something like that, but I haven’t used it…

Yeah, that sounds right.

I’m not 100% sure how it works. I’ve only used BrowserStack for manual testing; I haven’t used their more recent automated stuff.

Cool. So yeah, I think we’ve highlighted why dev tools are really interesting, and a lot of really other interesting stuff. Any last thoughts on dev tools before we wrap up the show?

I have none, I think. No, I have ideas and I have projects, and you’ll be hearing more about them over the next year, year-and-a-half.

Exciting…!

We have exciting things in our features.

Awesome.

Excellent. Everybody follow Ashi on Twitter, @rakshesha. We’ll include a link in the show notes…

Please do.

…and we will listen for those. And speaking of following her, once again I remind you - she will be speaking at React Amsterdam, coming up in April, 10 to 12th. It sounds like they have a few tickets left, so if you hear this and you wanna jump on that, go see if you can still get in; that would be great. But even if you’re not, take a look at their open source awards; if you have a project that you’re working on, they will shout it out and get it more visibility, so definitely take a look at that.

Ashi, thank you so much for joining us today. It’s been wonderful having you on.

Thank you so much for having me.

Alright, and that is it for this week’s JS Party. Take care y’all, have a great week, and join us next week for a party about JavaScript.