Jay Phelps: And they did a little bit of tweaking, a little bit of algorithmic improvements, just basically taking advantage of knowledge of the fact that it’s gonna be compiled to a much more native target… Right now it’s 10.9x faster. I know I appreciate that when my Babel builds, and the DevTools, and all that stuff… But that’s just an example.

Now, certainly, it is possible to create examples that are actually even slower than JavaScript, and that surprises a lot of people. A lot of people say “How can that be possible?” and that’s ultimately just because JavaScript has had a lot more time to be optimized… And because JavaScript is a much higher-level language… This of it this way - when you create a class in JavaScript, the underlying virtual machine has a notion of objects and classes; it knows what a class is and what an object is and can use that knowledge to make optimizations, because it can make assumptions based on that. However, with WebAssembly currently there actually is no object model; there is no knowledge of objects.

You can think of a typed array; I don’t know if you’re familiar with typed arrays, but… Or just a regular array in JavaScript. Think of a regular array in JavaScript, and imagine all you can do is add and remove numbers in that array, and… Welcome to WebAssembly! Because that’s essentially what it boils down to. That’s kind of over-simplifying it a little bit, but it just gives you the example of – the WebAssembly virtual machine has no knowledge of objects and classes, and stuff. If your language you’re programming in has those, they get de-sugared down; they get compiled down to loads and stores into this linear memory, and where the start and the end of a class in memory is is a convention, essentially. The compiler knows just by convention and by keeping track of that at compile time, rather than at runtime… Typically, in most languages.

Emma Bostian: That’s a really great explanation… And to your point about workshops that are essentially just three-hour lectures, and how difficult those are - we did an episode, I think it was called “I do, we do, you do”, or something along those lines… It talks about the different ways that we can teach people. “I do” is like “I show you something”, “We do” is “Let’s do it together”, and “You do” is “Take those skills and now use them to deduce an answer.” So if you wanna listen to that episode, go back through the JS Party archives; we’ll also link it in the show notes.

But that does bring up a good point - I would assume a workshop is a little harder to divulge online, although Egghead is one example of online platform who’s doing virtual workshops… And they seem to be quite successful at it. I’m curious what the differences would be, virtual workshop versus in-person workshop. That’s a whole other topic, probably.

One other area I wanted to touch on before we wrap up - and we did already touch on this - is live talks versus recorded talks, and the benefits of both and the drawbacks of both. Divya, you had mentioned that you were in the chat, discussing with the participants during your recorded talk, which has benefits and drawbacks. The benefit is you can engage with them in real-time as they’re seeing it, but the drawback is – perhaps internally, they’re thinking “Oh, this isn’t as personal, because she had already recorded this.” Did you find that there was any fall-out from that with the audience?

Dylan Schiemann: Yeah… SitePen, the commercial side of what I do - we do a lot of consulting work, whether it’s with Dojo or React or Angular or whatever, and we kind of know the pain points of working with various frameworks and solutions, so it kind of frames our reference on “Okay, what would I do if it was just up to me? I’d create something where these pieces work together and it’s not quite as painful to get started or to upgrade.”

We’ve also done a lot of fairly forward-thinking stuff. For example, one area where the virtual DOM paradigm kind of breaks down at times is when you’re working with something, and in general, you just need to know something about that particular DOM node… So the typical way is to say “Alright, I’m gonna punt on the virtual DOM here, just give me access to the node.” That might be for animating an object, changing its dimensions, setting a focus event on it… Or some of the newer API’s, like intersection observers and resize observers.

So what we’ve done is we’ve provided this pattern called a Meta. What it does is instead of you having to get the DOM node, we provide the properties for those common scenarios, so that you can still work with those behaviors in a reactive manner.

So what makes Dojo 2 pretty interesting to me is we’ve looked at like hundreds or thousands of little tiny, minor pain points or inconsistencies like that, and really tried to refine them and clean them up and make them feel more consistent.

Divya: Yeah, okay. But anyways… But he talked a lot about – we’ll link to it in the show notes, but he talked a lot about how React needs to do a lot of scheduling. And that was kind of the concern at the time. I think this was maybe 2017, or something like that. Or 2018, I can’t remember. And I think there’s lots of frameworks that don’t need to do as much scheduling work… And you think about Preact, you think about Svelte, for example, that doesn’t have a virtual DOM, or a lot of this other kind of internals around asynchronicity… What are some needs that are really driving that on the team for you? Or what were some needs that were driving that when you were on the team? And are those things that – similar to what y’all are doing now with the Chrome folks, should we just be pushing those towards native APIs that will allow you to do the thing better, versus trying to do it in JavaScript? Because concurrency is really hard…

Bharat Sandu: Yeah. Also, I would say AI is a much more mature place than mixed reality or AR software. But yes, I think there’s common– basically, simplifying the developer experience is the common thread, for sure.

The other thing is also, by the way – mixed reality or virtual reality or augmented reality is a really good example of applied AI. So when you’re doing hand-tracking, for example, that we do in HoloLens, you can imagine that it’s literally looking at the hands and saying “Okay, this is fingers pointing one particular way; it’s pointing that way, or it’s grasping my hand here…” And to even create a dataset - of course, you can capture a lot of hand angles, but you can also in a 3D [unintelligible 00:15:51.22] create different 3D orientations of a hand, and have the labeled dataset so you can train your hand detection models, and so forth. And even all these devices in HoloLens - you can speak to it, so there’s a real on-board speech recognition, and so forth.

[16:07] So one is, of course, a very good example of applied AI for us, but the second one is for our customers and our developers, it is actually the simplifying and accelerating the development experience… And really, at the end of the day, helping customers realize more value out of these technologies.

Daniel Whitenack: I don’t wanna put words in your mouth, so give me your thought on this, but it seems like recently people like Allen AI Institute, or spaCy, or even Open AI coming out with GPT-2, and all of these text models, it seems like there is a trend to show visually things like co-reference and visual examples of how BERT, for example, is embedding words, and all of these different visual ways. It seems like people are really seeking after visual tools that they can utilize for example on their next BERT project, where they’re utilizing BERT; they wanna have a tool in their toolset to visualize the embeddings…

Or in this case maybe you’re using an RNN model - maybe for that particular dataset you do try a bunch of different models, but then you kind of have this visualization tool in your toolbox to be able to understand for this particular problem what are the memorization implications of these different architectures that I’m trying. Would that be a good way to utilize and maybe leverage some of the stuff that you’ve done, and say “This is a tool that I can use to visualize these sorts of memory issues for my particular problem”?

Suz Hinton: It’s so true. That’s a really good point. So what are some resources that you really like for people who wanna read up a little bit more? We talked about tools and we talked about the Accessibility Slack, but does anybody have any favorite websites or favorite people that they like to follow for accessibility?

I can start… [laughs] So my favorite people are Jenn Lukas, Léonie Watson, Marcy Sutton, Rob Dodson and Cordelia Dillon. I have a lot more that I’m a fan of and I’m trying to keep it concise. In particular, I wanted to call out Rob Dodson, because he produces a series as part of the Chrome Developers YouTube channel called “A11ycasts”. They’re really nice, bite-sized videos for getting started with addressing things specifically for the web, and I really like how he approaches explaining things, and he has a lot of visual examples also to show you exactly what he means. I love that.

Another resource I really like is the Microsoft Inclusive Toolkit. That gives you some of those Empathy Prompts to consider, but also a solid bunch of resources to go about that mind shift around thinking in accessibility when you’re designing things.

Erik St. Martin: So in the docs that we were sharing you mentioned that you kind of have a love for visual abstractions, and kind of had some examples of things that you found particularly exciting.

Adam Stacoviak: I think the components – being very specific, where you say “A component will be named with at least two words, and then obviously elements are inside those, so we’re gonna name those with one word, and would prefer to use the child attribute for these reasons, the child selector wherever possible…” I think you’re stating some of your core reasons for it and giving visual examples.

I also have to compliment you on doing a great job of using readme’s very well. This is a great example of a project using a readme very well to sell it, as we said in the first part of this show… Which is you give an introduction, what this is, what this isn’t, and you agree with a continue link, and then a continue link from there… Each step just takes you a little further into essentially navigating GitHub readme’s throughout the project. Pretty cool.

Scott Johnston: …then they can just reassemble that experience from the open source tools. And so the monetization was geared not towards monetizing the developer, but monetizing the managers and the security folks who have budget for paying for features to help manage and scale out these development environments in large organizations.

So SSO was an example. Another example, just to, again, be concrete, is support for virtual desktop. So VDI. So VMware has a VDI stack, Citrix has a VDI stack, Azure has a VDI stack… And in large, regulated industries like financial services and healthcare, they don’t allow developers to have laptops; they have VDI, because they don’t want the laptops to walk home at night. And they don’t want the code to walk home at night. And so that’s an example of a manager-facing feature, an enterprise-facing feature that is monetized in the subscription, but most developers don’t care about that. So we’re not trying to monetize the end developer by that.

So I’ll pause there, Adam. Hopefully, that gives a couple examples of the monetization is geared towards managers, not geared towards monetizing the end developer directly.

Lior Hakim: [20:20] What we are trying to do is create positive use cases, and just let people see the positive uses of such things. And actually, in our company we see a lot of people that want to become characters and have their own character, and we communicate in work with our own characters with one on one, sending Slack messages or videos and stuff like that, and having ourselves on the platform and be able to create that. And aside from that, we have a lot of people asking, “When can I be my character?” So those are early adopters.

And I think as things play out and those use cases are out there, and people see other people appear in content, and they see it’s safe, and it’s put to good use, and they are being rewarded for that, I think the general positivity is something that is built gradually, and the trust is built gradually. And I think it’s a good start that we’ve seen the misuses before, so we know what to watch out for. And going forward, we can start to see better and better uses of the technology. It started with a talk with Obama or Tom Cruise, or Trump, or whatever examples of people frightening, and then we can just build from there with the good uses, and people read are already in place that might be fine, but once they see positive uses, I think they might want to subscribe to this notion and join basically this character economy or virtual human economy that is being built.

Priyanka Sharma: Well, just the fact that we can meet in-person… So we’re a hybrid event this time, versus a fully virtual one last time. So that’s a huge difference. And I think it’s a KubeCon EU that has never been done before, because in the past we used to have in-person events and there was a little bit of – you know, within 24 hours we would put videos up, and all of that. But that’s very different from having a simultaneous virtual element. So that’s all new, and I have to say, people are excited.

As of now, we are pacing really well with the attendees who are coming on-site. It’s many, many thousands of people already, and I’m expecting to beat our numbers; fingers crossed. But the excitement is there…

I think that this time around it’s also a very unique location, personally. I don’t know about others, but I personally am just so excited to go to Valencia. It’s not a huge town, but it’s got a lot of culture, it’s got these orange farms… It’s got so much for us to learn and experience. And the way it’s set up, it’s kind of like team cloud-native taking over Valencia. So that should be a really fun experience.

I think the event this time around is also similar to the previous events in many ways, which is important, because we will uphold the quality of our content, we will uphold the code of conduct that we follow. So there are many key things that must remain the same, and that is also happening.

I do think this is the first KubeCon Cloud-Native Con where all co-chairs are representatives of end user companies. So that’s something that you might notice in the talk selection. It’s gonna be a little – what I feel is that it’s skewed a little more towards practical applications for real-world examples of how to utilize cloud-native tech, and it reflects the backgrounds of our wonderful co-chairs.

Stephen Augustus: Well, I think it’s playing to your strengths, too. To your point, everyone learns a little differently. We take SIG meetings, for example - like, I will not go back and view a recording. It needs to be something that I’m building for evidence, that will force me to go back and look for a recording. I don’t like learning that way. I would prefer to see a digest, or something… There are some people who can easily churn out blogs. There are some people who are terrified of being on-stage.

[27:56] Figuring out how to play to your strengths… You know, some of the talks that we saw around kind of like playing with the borders of delivering a talk, because it was now virtual, like you just had more opportunity… People who have video editing experience went crazy with it for a few of the talks. I think both Tabby and Ellen’s talk this time around and Justin Garrison’s talk for NA were just brilliant examples of tearing down the borders of what it means to just give a talk to an audience. They played with it, and I liked that.

Rachel White: No! [laughs] They’re like QR code. Basically, any kind of digital marker is just using image processing with nearest neighbor type of math-y things… I’m great at explaining things technically. Basically, what AR.js does is – unfortunately, if you have an iOS phone it doesn’t work, so I can’t even test it, which bums me out… But if you have an Android phone, you can set it up so that you have your 3D environment that you’ve crafted with A-Frame, and A-Frame is built on top of three.js, because it allows for the 3D objects in the browser.

Then it uses the AR toolkit, which was originally elaborated in C, and they’ve made it work with JavaScript. It does that nearest neighbor processing of the hero marker, and it assigns your 3D object so that when you use your phone in a WebGL supported browser and you point it at the marker, either on a computer screen or a piece of paper that’s printed out, whatever 3D object you’ve assigned to that marker in your code will appear on the phone or the device that you’re viewing it through as a hologram type thing.

It’s really cool. A-Frame is really accessible for people that are just starting out in JavaScript. Their documentation is amazing, and pretty much what this AR.js library does is it allows you to take – they basically took all of the difficult steps out of the equation. Everything is built together for you, the documentation on it is pretty good; it says that it runs at 60 FPS on a Nexus 6, which is pretty impressive, and there’s a lot of examples of three.js things that you can do with it, so I’m excited to see what people make with it, because I’m very interested in any kind of augmented reality, virtual reality, mixed reality situation that we can do with JavaScript. It’s super exciting.

Matthew Boyle: Yeah, I think it’s a really good thought. And I think that fits perfectly into the - if we model our system after our problem space well, we should be able to do that evolution. And not just from a code standpoint, but from a business standpoint, too. One of the examples I use in the book is if you go to a coffee shop, and you purchase a coffee, and you get a stamp, you get a virtual stamp, which is if you get 10 of them, you get a free coffee, or you can use that to pay for a coffee… Like, let’s imagine that the rules change; they want to do a special offer that you only have to buy five coffees to get a free drink if they buy certain drinks, or from certain locations. These are all natural evolutions of our system, that we are 100% going to go through as a business over time. And so if you’ve modeled your system in a way that all these things are quite decoupled, and the idea of offers and orders are quite decoupled, and you can evolve these things separately and quickly, it is really powerful. And then when someone from the product management team or the business folks come over and say, “What’s our current logic for how we distribute loyalty stamps?” instead of having to kind of go find some archaic documentation, or trying to read some really difficult code, you can be like “Oh, well, on this line a user makes a purchase, and then if the purchase is successful, then we give them a stamp.” You don’t even need to convert that into common language, if you will, non-technical language, because it already makes sense, because you’ve modeled your system well.

Gary Bernhardt: Yeah, I think it absolutely could work. There’ll be a bit of extra latency, of course, when it’s hitting the backend… So you know, we could build those executor VMs, we probably will build them eventually, because we will want to do courses that involve backend stuff. The bigger challenge is not so much where the code runs, but the sort of nature of the output of the code. Currently, all of our courses have code examples where the code evaluates to a value; like, if you’re in the TypeScript course, either the code’s gonna run and give you a value back, or you’re gonna get a type error. You know, it’s very concrete.

And a lot of our code examples, most of them, you’re actually typing in the return value, as opposed to editing code. Some of them you have to code, but it’s a mixture. The real challenge for us is “How do you do a course on React?” for example. Because there’s no return – I mean, you can’t ask the user to type in the entire virtual DOM that the thing rendered, right? So you have to have some kind of visual mechanism where you show them like, “Here’s what it should have been, and here’s what yours rendered”, or something. I don’t know. We haven’t done it yet. That’s my main, my number one idea. But that’s the big challenge. It’s a huge UX challenge to build this kind of thing, and I don’t know of any prior art for that kind of interaction yet. We’ll get there though, and we’ll get to the executers. They will become real. [laughs]

Kelsey Hightower: Yeah, so the good news is I think 2020 the hype is now just dying off. This is good. We are finally getting to the point where most of the new projects are just remixes of the existing ones. Communities are merging; we saw this with the OpenCensus and OpenTracing communities, to OpenTelemetry…

So now that we’ve done a lot of experimentation, I would probably say the last four years have been just trying ideas, from infrastructure all the way to developer tooling. And now what we’re starting to see is that the buzz is kind of dying down; now people are more focused on production… And I think one good indicator is – probably we can’t extrapolate big, but when Docker canceled their conference coming up in 2020…

I remember 2,5 years ago if you were at DockerCon, it felt like that thing was never going to stop growing. It was at five or six thousand people, and there was just no end in sight… And now they’re moving to a virtual conference. Now, there’s probably all kinds of reasons for it, but my guess is probably the attendance started to drop or shift to other events… But that’s a good signal to me to indicate that now we’re in this other phase. We have all of these tools, let’s just put them to use.

Now we’re getting to that part I think I like… When infrastructure gets boring, something else will become exciting above it. Right now we’re starting to be in that phase. So I think if you’re a practitioner looking at all of these things, you’ve made it. We’re on the other side of the hype curve now. You can stand back and just start to really listen to what people were doing in production, and you’re gonna probably see a lot of good examples in the wild of what people actually are using, versus what’s being said out loud, or inside of that hype cloud that we just came out of.

Raphael Landaverde: If we introduce any sort of build logic and make any assumption like “Oh, if you’re doing any scripting, you’re probably on a keyboard, and using VS Code [unintelligible 00:16:39.17] And that assumption just breaks down as soon as we – we have these community Discords that – we don’t run it; the community runs it, and we just kind of pop in there and chat with them and answer questions. And they’ll give us examples, like “Oh yeah, we’re not using these tools, because we’re just on the phone, and typing with a virtual keyboard, and deploying it”, and it kind of catches us off-guard… Like “Oh yeah, I guess people do a lot of things this way.” And they’re successful doing it, so we’ve got to keep that in mind, but it’s just surprising at first glance.

Ryan Carniato: I built Solid under kind of an experimental idea. I was like “What if Signals or the reactivity was the whole framework?” What if it was every part of it? What if instead of having a separate render, or like a separate diffing thing, we just took Signals and see what we could do with it? Because conceptually, I start from very vanilla JS kind of mentality. I was like “Okay, if I was to write this all with vanilla JS, how would it work?” Well, it would work very quickly, but it would be a little bit verbose, and there’d be a lot of duplication, repetition. You want to kind of generalize stuff. And I decided that what I would do basically would just - almost like jQuery; just write some reactivity that would update the DOM where I needed it to… So I could just like be “When I update this value, have this place in the DOM update.” It seems simple enough. But I wanted to see if I could take that, that kind of scaled down, or simplicity, so to speak, and then also scale it up to be able to handle application needs of modern web applications. And this was primarily client-side focused. I cared about dashboards, and things with a lot of interactivity.

And as it turned out, it was quite doable. Taking a little influence from Knockout, taking what we’ve learned in time about how to make more consistent reactivity from things like MobX. I realized that we could just basically use a compiler for syntax. And I didn’t want to invent one of those; a lot of people spend a lot of time on that, and it’s whole stories about the language… Svelte is a perfect example of this, where a lot of care and concern has gone into the aesthetics of how it is to build, and what it feels like…

[00:12:16.18] I just grabbed JSX, basically, the first thing on the shelf; all the tooling works for TypeScript… You know, linting, color, Prettier, all this stuff. And I was like “Can I just compile JSX to DOM elements in a way that I can put the reactivity in?” And that’s basically what I did. I basically took stock JSX and had it output what I would have written by hand, if I was just kind of jQuerying it. And… Yeah, I mean, the results were, as you can imagine, very quick, because writing vanilla code - it’s quick. There’s not much else to it. But the question is, could it scale up to be able to handle all the scenarios that were needed? And that was something that had to be proven. And I believe over time we have.

I started working on Solid back in 2016, and I open-sourced it in 2018. And by that time I had the DOM in a pretty good place, and we started winning at benchmarks, so to speak. But they were a good starting point. But it wasn’t the ending for us, because – for me, the reason I even started this was because I liked the way I developed in Knockout. I liked data flows, I liked, the spreadsheet mentality. I liked the idea that you kind of set and forget it. You create these rules, you update your data, and everything just propagates.

So that’s like the core of Solid, it was trying to be simple. It wasn’t about adoption, it wasn’t about who could get in here. There’s a bit of a learning curve, because you have to learn about Signals to begin with. But at the same time, it gave me complete control. This is something that I liked. I could always go right down to the metal, and update the DOM directly… Because in Solid, a div JSX element is just an HTML div element. It’s just a real DOM node. You always have access. And because it was constructed in this sort of way, our components run once, because they’re just function calls that just create some stuff that will update in the future. So there’s this very simple thing – and in early days, components were really nothing. Now we do a little bit of extra massaging in the reactivity through our props, but generally speaking, a bunch of these elements just kind of came together in a way that even I didn’t understand at first, but ended up being able to not only emulate most things you would expect - everything from context, concurrent rendering, transitions… You know, all the features you’d expect in a modern framework, but even stuff beyond the web; there’s a lot of – you don’t need a virtual DOM to do universal rendering. We have mobile, we have desktop, we have televisions… There’s tons of libraries/frameworks. I say tons, but there’s at least three in each of these categories where you can choose to and use with Solid, purely reactive, and be able to render to a phone natively, or render WebGL 3D scenes. So this ended up being a different model to basically accomplish pretty much everything you could do in virtual DOM, or like a React-like library. And it was just built off this one building block, basically.

Lee Robinson: [28:01] Yeah, so to first set the stage, I have been officially, by my job, doing DevRel now for two years, and then unofficially probably since 2016, I guess. But if we go back to 2011, 2012 – so I started to learn how to code in 2011. And at the time, the DevRel that I really remember was from the new API companies. It felt like a generational change, or a big enough shift in the industry that it required education and awareness to tell people about a different way of doing things. And from my eyes, that was like 2011 to 2015. I feel like there was a massive rise in the number of API companies, or companies providing things as a service. And to do that, they had these members of their community, whether it was called DevRel or not at the time, actually go out, go to in-person conferences, go to meetups, go to anywhere around the world and tell people about how the product works, how the thing works, do a workshop on how to actually use the thing.

And at the time too, another thing I’ve realized in talking to a lot of teams is a lot of DevRel actually came from founders back in the day. The early employees that companies were essentially doing the majority of the product and community side of DevRel. And then eventually, it scales to a point where they have a full-time job to do that.

At some companies that actually turns into the product org; the PMs are just very good about that outreach, and then at some developer-focused companies they really lean into DevRel for that stuff.

So if we fast-forward a little bit and get closer to today, I think the thing that’s been really interested kind of pre-Covid/post-Covid that I’ve seen was the community understanding that virtual or online has a place, if done right. And I think the distinction there is it has to be done tasteful and respectful of people’s time.

I’ll give you an example of where maybe people are a little burnt out about online… Of course, everyone was sick of going to many virtual events, many conferences online in the past few years, and if you were going to do any sort of developer outreach or socializing with your community, it had to be something unique to make them feel like it was not just another Zoom call. And an interesting side effect of this, looking at purely from the viewership or the amount of traffic that you got, a lot of teams realized “Wow, we can actually get more traffic by doing this online. We have a global community. Instead of doing just this one event in New York, or San Francisco, or London, we can actually broadcast this everywhere and be inclusive of our entire global community. We don’t necessarily need to do 57 meetups to get this community activated and engaged.”

And also, you mentioned burnout, I guess, of developer advocates or people who were traveling for their job - it could definitely be a strenuous position to have to basically just go around all year, living on the road, giving conference talks, going to meetups, interacting with the community… Especially – a lot of those people too, maybe that was a viable thing for them to do at that point in their life, in the 2012 era… I think a lot of the original DevRellians, the DevRel folk have kind of evolved into something else.

[32:00] A good example - somebody that I look up to a lot is Kelsey Hightower. I think that he has a very interesting role now, where he is kind of like – he’s evolved from DevRel, and he had obviously done a lot of stuff before doing DevRel, too… But to somebody who really holistically thinks about an incredible product experience. And I think if you look around the industry, some of the other people who were well-known in DevRel - a lot of them have transitioned to do other related things, still in the same arena, but with a little bit more focus.

So the summary of all this is that when I look at DevRel in 2022, you don’t necessarily have to fly to every conference in the world, you don’t necessarily have to do a hundred meetups. You can be a little bit more strategic about when and where you want to do those things, but as we start to now get back to doing in-person events, which I’ve now spoke at (I think) four this year so far, and I have a few more coming up here in the next couple months… So it’s definitely picking up.

There is a reappreciation of just getting people in a room together too, that 1) I think people just missed because of not being around others, in a setting, for some time… But also, there’s something to be said about getting together and just having a casual chat about development stuff. Just talking about tech, talking about development. Sometimes it’s hard to recreate that spontaneity when you’re in an online event.

So I guess my philosophy and where I’m kind of taking our DevRel team is that I wanna do both. I still think there’s a place for – you know, when we have a global community of developers, it’s not feasible for me or others on my team to be flying around the world all the time, to go to a bunch of events. And I know that some really large DevRel teams solved this by having lots of employees all around the world. We’re not there yet. But I think there’s still a place for in-person as well, too. So we can have online, and we can also still go to some events and conferences.

Kelsey Hightower: Well, you know, there’s this phrase, “It’s easy to predict the future when you’re working on it.” A lot of us at Google Cloud are working on that replacement. When I first joined Google Cloud from CoreOS, lots of people were running their own Kubernetes clusters across a bunch of virtual machines. This was the norm. And then we had a managed service, Google Kubernetes engine; you can now click a button, and then we would automate all the cluster provisioning, and the upgrades, and so forth. But the nodes were still there. You still saw the machines, and it looked like the cluster you would manage yourself.

And then we came out with tools like Cloud Run, that was based on the Knative spec. And for those that are unfamiliar with Knative, there’s this idea that if you looked at just running a very simple application inside of Kubernetes, you need a deployment object, you need some secrets, some configs, you need a load balancer, ingress service, pod disruption budget, a horizontal pod autoscaler just in case you need to scale, and you still didn’t have things like scale to zero. So we looked at that and said “Okay, what is the pattern that the average person running applications in Kubernetes needs?” So things like Knative was born.

[16:04] Now, if you look at Knative and say “Well, if you think that this is the right abstraction, then you may not need the rest of Kubernetes to run applications in that style.” So now what we can do is have a managed service that’s a serverless platform, cloud-run, we take the same containers, we can take the same Knative spec, and just make Kubernetes disappear. There’s this myth that we are running Knative or Cloud Run on Kubernetes. We are not. There’s no Kubernetes cluster involved, at all. All we do is we allow you to give us the specification at the API layer, and we translate that into our native API internally, so there’s no need for a Kubernetes cluster.

And even the people that need maybe more of the Kubernetes API – so if you just think about APIs and not implementation, then things like DaemonSet, and jobs, and all these other things, you can get that via GKE Autopilot. Again, we make the cluster disappear, but we give you more of the complete Kubernetes control plane.

If you fast-forward this over the next ten years, a lot of these patterns will be available in other platforms. For example, Cloud Run has in beta right now (or alpha) the ability to run Kubernetes jobs.

So I think that people have proven that Kubernetes has been a great prototyping ground for workload definitions and APIs. And if you really believe in promise theory, then we know that those APIs and specs are just the promise that you’re making, and any system should be able to converge or keep them. So this is what I mean by something in the future will replace Kubernetes, because we are actually building the ability to.

Evan You: [47:54] Yeah. So for server-side rendering the first thing is if you’re doing it with Node, code needs to run in Node. The challenge is for a lot of projects, you have to compile code differently when you’re targeting either a client, or you’re targeting the server. So there are different code paths. Some code you’ll want to only run in Node, some code you’ll only want to run on the client… And then there’s also, for example for Vue or Svelte, we actually compile our components differently when targeting a client or targeting SSR, because we compile our components into more efficient string concatenation while we’re doing server-side rendering.

So this means for the same set of source files, you actually need to have two different compile outputs, so that you can do server-side rendering. Previously with WebPack the most frameworks do it in a way that you actually just make two bundles simultaneously. So every time you edit something, you rebuild the tool bundles. And that gets really complicated, and is also kind of slow.

So when we’re thinking about server-side rendering with Vite, we want to have this same sort of snappy instant update, even for the SSR. The idea actually originally first was first conceived by Rich Harris. So Rich was working on SvelteKit, so he made this very early version of Transform that can take an Esmodule file, then rewrite it into something that can be instantiated in Node.js, in memory, basically creating a sort of virtual runtime for Esmodules in Node.js.

Alexis Richardson: [23:56] Well, that’s a really good question… One of the key benefits is that it automates a lot of steps that you would do manually when it comes to deploying and managing your stack. If you want to deploy lots of components into Kubernetes, several different GitOps technologies - including Flux, and Weave GitOps, but others as well - will work in this way. They will run an agent inside Kubernetes… In fact, you can do it without an agent too, but the agent example is the simplest to explain. They’ll run an agent in Kubernetes, which is aware of potential updates, and then when it sees that a potential update is available, it will deploy it. And that particular mechanism is what we call a pull, which is, again, something that has been done before Kubernetes came along; it was an earlier idea. But it’s nice, because it has properties like security, it can inherit all of the Kubernetes security and lifecycle and operational capabilities, just by being embedded inside Kubernetes and living inside it. It can also see all the current Kubernetes state securely, which allows it to compare the current running state with the intended state without breaking security. And that means that you can observe whether a cluster is in the right state or not without breaking security, which is very nice.

Another property is that it scales. So this is something that you would be aware of if you had done previous work in Pub/Sub. But as you add more and more copies of a source of information, it becomes more scalable to pull changes asynchronously, than to try to push them all at the same time to the listeners on the remote clients. That’s because some of them get there at different rates, some of them don’t get there, some of them may not be ready, and other reasons as well.

So this matters when, for example, you have the use case like a telecommunications company, where the Kubernetes clusters are running in the mobile phone towers, and you might have three machines running a few clusters… Or another example is restaurants, where they have Kubernetes clusters in the restaurant. Believe me, this is true today. Or aeroplanes, where there’s a Kubernetes cluster in the airplane.

So all of these things are connected back to a centralized controller (HQ) where the decisions are being made. And once a decision has been made, we virtually pushed virtual synchrony out to the remote clusters, in this case in the telco towers… But the actual changes will be pulled in. And the scalability matters when you have thousands of these things, which you do, in this case. So this is about taking Kubernetes to the edge scalably.

Another thing is that nobody touched the cluster, and yet you have thousands of identical clusters. Or they can be different if you want them to be. So you can have complete management of a huge fleet across the geographical area, all in software, which means that now we can take something like the telco infrastructure, which is upgrading to fast comms like 5G, and that could become an extension to the cloud. So that’s like a mind-blowing event; that could be one of the key steps towards the iPhone moment for cloud-native apps. When we have an always connected set of nodes that form a single virtual cloud infrastructure, we’ll be able to run apps wherever we want to, whenever we want to, that do whatever we want to. And that’s pretty cool as well.

So I think all of those things come from GitOps. But then there’s even really basic things, like “Do you know what stage your cluster is in?” Yes, you do, with GitOps. It’s great. So in the example of Alexis and Gerhard, each start a Kubernetes cluster, we wait a couple of days, we can check if we’re in the same state.

Kent C. Dodds: Like I said, this is one of the things I loved about custom hooks when they were introduced… A custom hook, this is the definition - it’s a function that calls another hook. That’s it. That’s what a custom hook is. So the hook that it calls could either be a react.useState, or it could be another hook, like useQuery, or something like that. So it doesn’t matter what kind of hook it is, whether it’s a custom hook or a built-in one, but it’s actually – it’s very analogous to a custom component. A function component is just a function that returns a React element. A custom hook is a function that calls other hooks and that’s it.

So why would you create one? The biggest and most important use case is for code reuse. So let’s say that you wanted to synchronize the document title - then that’s gonna be a useEffect, and the useEffect will have a dependency on whatever you want the title to be, and then inside the useEffect you’ll say documentTitle = whatever that value should be. So that’s a pretty simple thing… I probably wouldn’t bother abstracting that one, but for our purposes we’ll say “We wanna reuse this in another part of our codebase”, so we’re gonna just literally make a function called useUpdateDocumentTitle it accepts a single parameter that is what the title should be, that is a string, and then you move your useEffect into that function (you don’t have to even return anything) and then you call that function inside of its original place, and you pass in what the title should be, and now you can reuse that all over the place, and update the title willy-nilly, however you want. That’s the primary use case for hooks.

[48:09] The really cool thing about this is because it’s a pretty low-level primitive, it works really well. So I think the best example of custom hooks actually comes from Tanner Linsley. He has just phenomenal libraries that use custom hooks. His React Virtual and React Table, and React Query - all of these things just do a really great job of abstracting things away into a custom hook that you simply call in your function component, and sometimes you’ll get stuff back… Yeah, it’s really powerful.

And actually, Tanner has a talk that he gave at JS Hawaii, that did a really good job of explaining the power of custom hooks too, that I recommend people go look.

José Valim: [08:46] That’s a great question. To give some context - one of the things… Like, going way, way back, it always started because of the Erlang Virtual Machine; the only reason that Elixir as a programming language exists is because of the Erlang Virtual Machine… And the Erlang Virtual Machine was built by Ericsson, which is a telecommunication company for building concurrent, distributed and fault-tolerant software. I don’t want to expand on that; you can check Elixir on the website… But all of these things, my love for the Erlang Virtual Machine – so when I created Elixir, I was like “I want to have as many people as possible building on this platform, because I love it, and I think other people are really going to love it and enjoy it, too.

So I’ve created Elixir, and I’ve always thought – in terms of programming languages, I really think that Python is a really stellar example of tackling a bunch of different problems. I always had in mind that I want that for Elixir and for the Erlang Virtual Machine, for the Erlang ecosystem. I think we can grow diverse to solve all the different kinds of problems. So I come from a web background; I was a member of the Rails core team almost a life ago… When I started with Elixir, I had this obvious web background, and that was the first dimension that Elixir took off, with the Phoenix web framework… People started using Elixir more and more for the web. Elixir was already a good natural fit for building distributed systems, or anything regarding the network due to the Erlang heritage…. But it was like, “I’ve always wanted to try to expand this.”

The first time I expanded this was back in 2016 we released abstractions for data pipelines and data ingestion. So if you need to consume queues, and you need to do that very efficiently, we released libraries for that, and that brought Elixir to a new domain, which was like data processing, and there are some very nice use cases on our website… For example how change.org is using data abstractions that we wrote back then to process – because if you have a petition that one million people signed, you need to send them an update; now you have to send an email to a million people. How are you going to do that?

So we started that segment, and then the community started to grow, so people started bringing Elixir in the Erlang Virtual Machine for embedded. So there is the Nerves framework; people started bringing that to [unintelligible 00:11:12.25] streaming… And then there’s always the question, “Why not numerical computing? Why not machine learning?” So I always had this interest; I feel like it’s part of my responsibility, part of my job to try to broaden the domains and the areas of the language. The community is also doing that a lot for a bunch of areas… But you know, if there is something where I feel like “Hey, this is a good opportunity. We can do it”, then why not? Let’s do it.

And this always started - just to finish giving more context - when PragProg… I always had this interest. Actually, my thesis, my master thesis was in task classification. But that was 11 years ago… So we were not talking about deep learning at the time yet; I think everything was still support-vector machines were kind of state of the art. I never fell back, but I always had this interest.

[12:08] So in October last year, PragProg announced a book, which is “Genetic Algorithms in Elixir.” And then I was like, “Hey, apparently there is somebody who knows things about AI and machine learning in the Elixir community”, and he is Sean Moriarity. I sent him an email and I was like “Hey, I think the platform could be good for us to do everything in machine learning”, and he said “I agree. Let’s work on it.” And we started working on it. So it’s kind of like “Why not? If we can make it happen, let’s make it happen. Let’s build this, and then later we will continue working on how to package and how to sell this to people and say like “Hey, what are the benefits of having those two worlds joined together and working together?”

José Valim: [08:27] That’s a great question. To give some context - one of the things… Like, going way, way back, it always started because of the Erlang Virtual Machine; the only reason that Elixir as a programming language exists is because of the Erlang Virtual Machine… And the Erlang Virtual Machine was built by Ericsson, which is a telecommunication company for building concurrent, distributed and fault-tolerant software. I don’t want to expand on that; you can check Elixir on the website… But all of these things, my love for the Erlang Virtual Machine – so when I created Elixir, I was like “I want to have as many people as possible building on this platform, because I love it, and I think other people are really going to love it and enjoy it, too.

So I’ve created Elixir, and I’ve always thought – in terms of programming languages, I really think that Python is a really stellar example of tackling a bunch of different problems. I always had in mind that I want that for Elixir and for the Erlang Virtual Machine, for the Erlang ecosystem. I think we can grow diverse to solve all the different kinds of problems. So I come from a web background; I was a member of the Rails core team almost a life ago… When I started with Elixir, I had this obvious web background, and that was the first dimension that Elixir took off, with the Phoenix web framework… People started using Elixir more and more for the web. Elixir was already a good natural fit for building distributed systems, or anything regarding the network due to the Erlang heritage…. But it was like, “I’ve always wanted to try to expand this.”

The first time I expanded this was back in 2016 we released abstractions for data pipelines and data ingestion. So if you need to consume queues, and you need to do that very efficiently, we released libraries for that, and that brought Elixir to a new domain, which was like data processing, and there are some very nice use cases on our website… For example how change.org is using data abstractions that we wrote back then to process – because if you have a petition that one million people signed, you need to send them an update; now you have to send an email to a million people. How are you going to do that?

So we started that segment, and then the community started to grow, so people started bringing Elixir in the Erlang Virtual Machine for embedded. So there is the Nerves framework; people started bringing that to [unintelligible 00:10:53.25] streaming… And then there’s always the question, “Why not numerical computing? Why not machine learning?” So I always had this interest; I feel like it’s part of my responsibility, part of my job to try to broaden the domains and the areas of the language. The community is also doing that a lot for a bunch of areas… But you know, if there is something where I feel like “Hey, this is a good opportunity. We can do it”, then why not? Let’s do it.

And this always started - just to finish giving more context - when PragProg… I always had this interest. Actually, my thesis, my master thesis was in task classification. But that was 11 years ago… So we were not talking about deep learning at the time yet; I think everything was still support-vector machines were kind of state of the art. I never fell back, but I always had this interest.

[11:49] So in October last year, PragProg announced a book, which is “Genetic Algorithms in Elixir.” And then I was like, “Hey, apparently there is somebody who knows things about AI and machine learning in the Elixir community”, and he is Sean Moriarity. I sent him an email and I was like “Hey, I think the platform could be good for us to do everything in machine learning”, and he said “I agree. Let’s work on it.” And we started working on it. So it’s kind of like “Why not? If we can make it happen, let’s make it happen. Let’s build this, and then later we will continue working on how to package and how to sell this to people and say like “Hey, what are the benefits of having those two worlds joined together and working together?”

Gleb Bahmutov: No conflict, right? So 99% of the time I’m on a podcast - or even during Cypress workshops - I don’t try to sell you anything, really. I only talk about the open source tool. But then we needed something to actually earn money, so we tried robbing banks, forgery… It’s difficult to make a living, actually, especially in Atlanta and Boston. People are smart around these areas; I could never – anyway. But we decided “Okay, you run the tests, Cypress saves you a video of a test run, it takes screenshots on the failure, you have those test results… All of these test artifacts.” Well, what happens to them? If you are an individual developer or a small team, you can just store those test artifacts on your CI, on your Jenkins box, and if something fails, you can just look at those test artifacts, download the video, watch it on your machine, understand why the test failed, fix it, and so on. Absolutely fine.

But imagine you’re a business, and you’re running hundreds of tests. All the test artifact management, looking at videos, looking at screenshots, trying to understand which test is failing is difficult. So then we decided “Why don’t we build a business storing those test artifacts and allowing to easily view them, allowing you to look at the history, allowing you to see the history of a test? Which test is flaky, which test is slow?” and so on. All the things that don’t make much sense to small projects, but become hard problems in a large organization. And for large organizations - I mean, they can totally do it themselves. Some companies that use Cypress don’t pay us a dime, because they made their own dashboard, where they store results and look at them. But when you do that, you have to think “Money.” An hour of engineering time to just maintain the dashboard. If you spend one hour per week just maintaining or updating a dependency, or redeploying the dashboard, one hour a week four times a month - it probably is at least $150/$200. Just maintenance, not even writing it; just maintaining it.

[28:02] So what happens? Well, our cheapest price for storing your test artifacts and maintaining all that so you don’t have to do it is $99. If you record more, it’s $199, so $200, and then $300, and then there are custom plans for large enterprises.

It’s a no-brainer. If you’re a large organization and you want everyone to just see the test results whenever they want to, understand the test history, understand which tests are failing - no-brainer is to pay us. That’s how we make money, and that’s what allowed us to actually take those earnings and put them into working on open source full-time… Because what happened before was really interesting - we tried for a while to survive not by having a dashboard, but instead providing training and support, which is how many open source projects try to survive. And what happened there was really interesting - we were swamped. Every large project, we’d have so many issues, because we use it across every operating system, every CI provider, every hosting solution, every web framework, and library, you name it.

So obviously there were problems and we were trying to add features, but we could not. Half of the time we were supporting existing customers, which prevented us from having even time to actually solve a problem in the first place for everyone. So for us, moving away from private support towards a subscription model where we do test storage and dashboard for businesses allowed us to put money into solving everyone’s problems in the test runner itself. So I think it’s a really good balance, which we were lucky to discover.

Going back to Chris - the first page feature that actually allowed us to survive, that actually became why people wanted to pay money, was not even the test artifacts and the video; it was parallelization, running tests in parallel. So imagine you have many tests; if you run them one by one, you open the browser, you load things - it takes time. So once you have even a small set of end-to-end tests, imagine you’re waiting for half an hour for all of them to finish on a single continuous integration box.

So one night I was sitting around, playing with Mocha, because I love writing wrappers around Mocha - to randomize order of tests, the load balance, or repeat the same test and figure out flakes… So I was playing with Mocha and I was thinking “How cool would it be to have a little Mocha just sitting somewhere on the internet, waiting? Already running, just waiting for tests to run.” So you don’t have to spin the new thing, you’re just like “Hey, run this test.” You’re already there. “And then when you’re finished, come back; I’ll give you a second test to run.” Kind of like a little Mocha worker. And that was a success, this nighttime experiment.

Then we decided “Well, Cypress is nothing but, literally, a Mocha engine with controlling the browser.” So we’ve written this way of running Cypress with API, that knows all the tests; so every time Cypress finishes a spec, it goes back and says “Do you have another spec for me to run?” And the API can say “Yeah, here’s this next one. When you’re done, come back to me.” So each CI machine doesn’t just run all 30 spec files; instead, each CI machine goes to the API and says “I’m about to run 30 specs. Or should I do something else?” and now API says “wait ten machines already joining this group, for this particular test run; I really gave nine jobs, nine different spec files to nine machines. You are number ten. You run number ten spec.” And we all keep this history of test runs, so we can optimize the order, so it’s optimal… But it all became just like as an experiment around spinning and running tests as fast as possible. And that became a really sellable feature, because people pay for it. It makes sense for organizations with lots of spec files to run them faster, so that developers don’t wait for it.

[32:30] And again, test artifact storage and faster test runs, all for $99 a month? Sign me up. I wanna discuss it. [laughter] It makes such a good business sense… And I’ll tell you more. In previous organizations where I actually used Cypress, we could not use the dashboard, like external services. We were all about finance, so we kept everything in-house. We hosted our GitLab in GitLab CI, and everything. So we actually manage all this parallelization ourselves. Everytime you commit code, it would regenerate with CI files, so we’d spin our own boxes… We open sourced it as a tool; feel free to use it… But then I was like “Why? Why would I manage that? I can just concentrate on what I’m doing best, and not manage my CI server or my parallelization or my test artifacts.”

In conclusion, here’s my advice to anyone trying to make a business out of open source. As an individual contributor, you can probably support your project a little bit by providing private trainings, workshops, maybe support. And a good example of that is the maintainer of Redis. He just supports one company, gets paid a lot of money, and invests in open source work. But the thing is it only works for maybe one developer at a time, for smaller projects. As soon as you have a group of people, you need something else. Not just support, but additional services.

A good example would be Ghost, the blog editing. Open source project, but they host it for you, so you don’t have to do anything, and so you pay for that. So they provide extra service on top of it. If you can provide a service that makes sense for a company using your open source project, completely complementary; not light versus full version, but instead saying “If your company really loves this tool and uses it a lot, well, you will have this problem, and then we can provide a solution to that.” So all the individual users, smaller plan users can still do everything for free, and yet the companies who really are a big fan, they kind of self-select by being big fans, they can come back and say “Hey, I have these 100 things now. What can I do?” and you say “Well, we came up with a solution for this particular need. We know you’ll love us, because you have 1,000 tests… So for 1,000 tests, here’s a thing.”

So I think we are super-lucky… Because we were sitting around a table - it probably was a virtual table back in the day - and we were like “We know we have hit a home run with Cypress test runner, but we need to hit a second home run with the dashboard. What value can it provide to actually justify our existence, and paying for the whole team?” And that was really scary. We literally were like “Well, open source it. What can we do in the meanwhile?” It wasn’t like we knew what we will do with a dashboard. Parallelization came as an idea later. So it was really scary, but I’m glad we kind of got lucky.

Michael Stapelberg: Right, sure. That’s actually a fun little project that we started at the beginning of this year, actually. So the idea is that I was getting fed up with maintaining all of these little Raspberry Pi’s. Many of us probably have a little Raspberry Pi at home, doing one thing or another in their home network, or a device that is comparable… A little Intel NUC computer, or an Atom-based little embedded device, anything like that. But the Raspberry Pi certainly is the most prevalent of these devices, so I figured it would make sense to just target the Raspberry Pi for now.

The observation was that if I write most of my programs in Go nowadays, why do I even need to maintain this entire Linux ecosystem on each and every one of my Raspberry Pi’s? At the point when I started the project I had three of them running. I looked at them, and I logged in, and because of the custom image that I used on them, I saw that the last build timestamp for that image was in 2013… So at the point when I logged in, I saw that it had an uptime of four years without me changing the base system, and it had – of course, security vulnerabilities accumulated over these four years, and that is a horrible state to be in and I really don’t wanna have that on my home network.

[24:16] I wanna have all of my devices up to date, ideally with an auto-update. Ideally, it goes so far that I have gifted devices to friends of mine and bought a new device where the only difference in operation was that the device auto-updated.

An example of that is the Turris Omnia OpenWRT router, which I would recommend, because it is to the best of my knowledge the only OpenWRT-based Linux router that auto-updates. That just comes from working full-time.

When I was a student, I could of course still spend quite a lot of time administering all of these servers; I was running Debian testing on many of my machines and virtual machines and all of the little devices, and I would auto-update them sort of regularly… But at some point your priorities change and you just can’t do that anymore. So I figured I would go at it from the other direction and be very strict about it.

So I wanna have devices that auto-update, and I wanna have devices that don’t expose a lot of attack surface, both on the network itself and on the internet, of course. And I figured one way to do that would be to look into whether we could actually run a Linux kernel, and ideally, directly execute Go programs without any of the regular Linux distribution in the middle. Gokrazy is an implementation of this.

What gokrazy does is you give it a Go package that you have, be it like a little “Hello, world” program, or distinct bigger programs like the Prometheus Node Exporter if you wanna monitor your Raspberry Pi in Prometheus. You give a Go package to the gokrazy packer program, and what it does is it packs an SD card image with the Linux kernel and the Raspberry Pi firmware, and a minimal init system that comes with the gokrazy project, and then just the Go packages that you provide it.

These four parts are all that you really have in the image, and then you just copy that image onto an SD card and you boot your Raspberry Pi from it, and there is no other moving parts, there’s no Linux distribution; it’s not based on Debian or based on Fedora or anything like that. It has just directly the kernel and the firmware.

Another important part of this project is that all of these parts are auto-updated. For the kernel and for the firmware we have a cron job running on Travis, which every day goes and checks the upstream repositories for newer versions of what we have packaged. If there is, for example, a new kernel release - and I learned that the kernel actually gets quite a few releases; I never paid attention to it, but they do like a little point release… But anyway, so we have this little cron job which looks at what is the latest kernel version, and if the latest kernel version doesn’t match what we have in our repositories, it goes on and downloads it and then builds it on Travis.

Then we have three pieces of automation which I’m not gonna cover in detail - you can just look at an existing presentation about gokrazy if you’re interested - which sort of do this entire dance of “How about I take a pull request, I build a kernel, I amend a kernel into the pull request, I automatically test that new resulting image on an actual Raspberry Pi, and if it boots, I’m just gonna merge it.” Frequently, when I wake up, in my inbox I’m gonna have this little GitHub email thread where it tells me there is a new version of the Linux kernel, “Oh, and by the way, I tested it and it boots. Oh, and also I merged it. And oh, I also deployed it onto all of your Raspberry Pi’s.” [laughter]

That’s the ideal state for me. I wake up, I realize that there was a new Linux kernel release, because I’m already running it. Later on I read about it in the news and read the changelog.