The Frontend of the Computer
Welcome to both of you. Thank you so much for joining us here on on Retconing Weekly. So, David, I wanna actually start with you because, you were, pretty into a language called Elm.
Speaker 2:Adam, you ever heard
Speaker 1:of Elm? Not the male.
Speaker 2:I think we actually talked about it on the show at some point.
Speaker 1:We talked about Elm here.
Speaker 2:Yeah. I think so.
Speaker 1:Okay. And I I was Elm the language.
Speaker 2:Speak of the deep cuts? Yeah. No. I think so.
Speaker 1:Elm, not the not not the mail reader? No. No. No. No.
Speaker 1:Not the mailer. Because I always think of the mail reader that had a 2 gigabyte limit that forced me to to go to mutt when my mail got larger than 2 gigabytes. I got that that 31st bet. The, so, but Elm so Dave, you were super in Elm, and you've got a great story about something you had developed for Elm based on a new feature of the language. Yeah.
Speaker 1:And can you describe that a little bit? Because I I Yeah.
Speaker 3:Well, it was just a talk that I they that I had, signed up to give at OzCon, the O'Reilly conference, the open source conference, which I'm not sure if they do anymore. But, in 2016, and, it was about this feature of of the language. So Elm was is a is or was. It's a, there's kind of a debate about whether the fact that there hasn't been a commit in 2 years means it's dead or not. But, it it's a functional language for for writing web UIs, basically.
Speaker 3:So, you know, you would think of your UI as a pure function of the state of the program and, it had this neat feature called signals, which was a kind of a stream of data value that would change over time. So, like, the mouse position would be a signal where it has a value at any given one time, but you can also, you know, accumulate over the the a series of values. And you would treat it like you would accumulate over a list of things, you know, with a fold. So it was this very elegant functional programming abstraction applied to UI and it was, I think, very appealing to people who were into functional programming. And so I, yeah, I I wrote this whole talk just kind of explaining it and it was a neat little intro to functional programming, framed around this feature.
Speaker 3:And then the talk was gonna be, you know, mid May. And then May 10th, there's a blog post called, a farewell to functional reactive programming where they were getting rid of signals, from the language. So I that was that was really exciting. I had to rewrite my talk in a week. Mostly, I just kind of crammed it into the middle 30 minutes and gave 5 minutes at the beginning and end about how, they were removing this, but it's still kinda like that.
Speaker 3:You know, it hasn't changed that much. They more it's more they're getting rid of the name and had to kind of explain it. But I learned that, if you're gonna give a talk on something, you better watch the mailing list for that thing.
Speaker 1:This is so ridiculous at so many different levels. First of all, how often I mean, I feel like languages are generally, for a good reason, like, careful about ripping out abstraction. Like, when you introduce abstraction, like, people are gonna build software on it, and they may even write talks around the software they built on it. And you can't really be casual about ripping that out. But they're like, no.
Speaker 1:It's dead. Farewell. Farewell to the thing you're about to give a talk on. How old was it? Couldn't have been that old.
Speaker 3:It was a couple of years old probably. But, you know, it was a it started out as like a kind of a research project, I think, by the creator, Evan and, I just posted the the talk and the post in announcing removing the feature in the, in the chat. Yeah. I mean, it was still evolving pretty a lot at that time. This was early.
Speaker 3:This was not the time we are now. This was 2016. Things were a little bit more fluid in, web, in web world where, you know, TypeScript hadn't really become dominant. So I think the value proposition of these non JS compiled to JS languages was was, stronger than it is now where, you know, you have to have a really strong value proposition in order to justify deviating from the thing that's now, you know, the mainstream choice, which is TypeScript and is really good.
Speaker 4:The days of CoffeeScript and many many many other, interesting things.
Speaker 3:Yeah. I think even by 2016, the CoffeeScript was already kinda kinda on the way out, and it was like, okay. There's TypeScript, Flow, Elm. We're still compiling JavaScript, but we're not doing this weird, pseudo Ruby thing.
Speaker 1:Is Steven O'Grady paying either of you a bounty to mission copy script here? Out of curiosity, maybe that that would be, because I was a, a CoffeeScript malcontent. It was, I think, unlike Elm. I I love I think Elm is really interesting because it was and TypeScript was terrific. I mean, I think TypeScript actually, I think TypeScript is like the it is almost more important than JavaScript.
Speaker 1:In terms of, like, TypeScript, the the am am I understating the importance of type just like TypeScript is a very important development. Am I understating that?
Speaker 3:Yeah. I I don't know how it I mean, I think if if you look at the, you know, language rankings on GitHub and stuff, you'll you'll see it's it's quite high. I'm not sure if it's quite reaching JavaScript yet, but it it's a very significant amount of new web app development definitely is TypeScript rather than JavaScript.
Speaker 4:It definitely reaches an important gap because it's like we had a lot of compile to JavaScript languages in many different ways. So, you know, things like Elm that were grouped more to frameworks, you had things like pure script, which were more functional, but definitely harder to sort of get started with. You had things that were much looser like CoffeeScript, and then, you know, you just had straight, JavaScript compilation of, like, here, let me take, Edith or what, 5 to 6 then became Babble to, you know, make this like language translation as the language was evolving, you know, so heavily from the sort of ES5 to whatever the new generation was. So the language is really evolving. The type world was kind of slow, but when TypeScript came together, it was a really interesting alternative to a lot of these things.
Speaker 4:And then you also had Flow from Facebook, which they just never really got their they never put as much effort into it because Facebook meta has always been, you know, very internally like this is for us and you can use it, but it's our tool. We'll we'll sort of do what we want with it.
Speaker 3:So, yeah. And at this point, they basically said as much that, you know, development is gonna be internally focused on Facebook's needs, and they're not really doing open source stuff with it anymore.
Speaker 1:With Flow. Yeah. I've forgotten about Flow, actually.
Speaker 3:If in a while, they would look like they were it could go either way.
Speaker 1:Between TypeScript. In terms of Flow or TypeScript.
Speaker 3:Yeah. Yep.
Speaker 1:Yeah. You know what's funny is that, Adam, Dave and I were in, in in Aarhus with Lars Bak when Microsoft was announcing TypeScript in 2012. Yeah. And there was a really interesting and we were so Lars Bakkt did the the v eight VM at Google. And so Dave and I were presenting all the work that we had done to Larsen and Casper Lunden, and we're kind of all of our bugging work.
Speaker 1:And the Microsoft guy, Steve Luko was also coming over there to to have, like, a closed door session with that we were kind of, like, literally a fly on the wall for. Like, they kinda didn't ask us to leave, and we had volunteered to leave. So we're just, like, we're just gonna stick around and watch and they were just going at it. They were like 2 cats in a bag. It it because it's kinda like the, you know, like, neither wanted to seed anything to the others.
Speaker 1:Like, Lars, like, why would you do any of this? I'm like, I know why you do any of this. Like, this seems really seems extraordinarily valuable. But, so it was it was really super interesting and a very, very important development because it brought real I mean, Justin, as you were saying, like, I don't think CoffeeScript I mean, it's amazing. It's like CoffeeScript is actually, like, looser than JavaScript.
Speaker 1:Like, how do you do that? But the, I think that TypeScript was really bringing something very important, which is a lot of rigor and type safety into like, types are nice, actually.
Speaker 2:In in in particular to folks, you know, with a certain collection of values building a certain type of software. Like, I think there are lots of folks for whom TypeScript might be overly constraining, like the people who choose untyped languages for the rest of the world. But, you know, certainly, like, if you if you believe in types and think that types are good on the server, like, you might think that they're type they're pretty useful on the client as
Speaker 4:well. Well, you gotta keep in mind too that, like, in the early 2000, JavaScript was a very different language than it was today, you know. It's like really in the 2010s when, especially when Rails was really at its meteor rise. People were using a lot of Ruby and are like, okay, this makes sense. I can write some really terse syntax and do a lot of stuff and throw a lot of code out in the world.
Speaker 4:And I mean, CoffeeScript really hit that era when JavaScript was like getting out of this very painful stage where it was kind of an awkward, incomplete language. And they're like, okay, we can kind of see it starting to move, but we want something better. And I mean the things that a lot of people use coffee strip script for was like, oh, I want arrow functions. I just want a cleaner way to declare a Lambda and small little affordances like that that as soon as, you know, more, you know, as soon as like TypeScript and others came on the scene and, you know, babble and other things that let you sort of compile to get these later functions, then CoffeeScript was was, you know, abandoned pretty quickly.
Speaker 1:Yeah. And and, actually, I mean, in terms of those those early days, so, Adam and I were developing a web app effectively in addition to when for this storage appliance we're developing. Back, it it was, like, immediately post Google Maps, and it was kind of in the era of AJAX. I'm not sure if the children children even Ajax, asynchronous JavaScript, and XML.
Speaker 3:Yeah. I still call them those. I still I still call them Ajax calls sometimes.
Speaker 2:Nice.
Speaker 1:Oh, nice. That's it. That's the the this is like when we we were debugging a problem and Adam's looking sorry.
Speaker 2:Oh, yeah. Thanks. No. Feel free. Go ahead.
Speaker 4:No. No. No. No.
Speaker 1:Do you want me to stop? No.
Speaker 2:I'm I'm gonna go no. Go ahead. I'm gonna go take
Speaker 1:a little walk. No. No. I like this is I thought it was cute. I did that you're asking, like, about a trap always instruction.
Speaker 1:And I'm like That's right.
Speaker 2:I was I was I was like, we're clearly debugging some AMD 64 code and which I mean, I guess it's anachronistic even that I call it that. And I I mentioned the TA 3 instruction, not a trap 3 because on Spark, you had trap always, and I had spark in the brain.
Speaker 1:It just it it there's nothing wrong with that. So and then I mean, you're It's Ajax calls. Like, you're you're among friends, who I'm trying to say.
Speaker 2:That's right.
Speaker 3:That's right.
Speaker 1:We we we sound like, we're we're just we're just venerating, Adam. That's all we're doing.
Speaker 2:That's right. It is remarkable now that I I've been I've been reading a bit more about history of Sun. And the fact that we didn't get strong armed into building that front end in, like, some sort of Java applet, which would have been garbage, but it's sort of remarkable that no one tried to make that happen.
Speaker 1:Definitely no one tried to make that happen. Yeah. We we were definitely and we were the Justin, this is the era of, like, where this is, like, Django and jQuery, and the fact that we were doing things, like, on the DOM. You would think we were writing it in assembly, like, on the DOM directly. It's like well, it's just like I mean, the function calls they make.
Speaker 4:I
Speaker 1:mean, it's not like, yes, on the DOM directly. But the, that world was very primitive, Justin, you're mentioning, and we're in a much, much, much more advanced world. And I think it's part of the reason why. I've been I don't I don't know that when we see the demos that that you all have and the tooling that you're using, it's just, like, jaw dropping. I mean, it is really, really amazing.
Speaker 2:Yeah. I mean, the tooling in particular is outstanding.
Speaker 1:Yeah. So, I mean, the
Speaker 3:the things that we can do are not that different, but I think it's more just sort of the confidence that we have when we make changes that we haven't broken something is the is really the big difference for me, at least, you know, in the experience of developing it compared to how it used to be for me.
Speaker 4:I would say that there the, like, the mature the the engineering maturity of the whole space has really really advanced incredibly rapidly, so there's a lot of stuff to paper over here, but, I mean, even a few years ago, bundling was still a thing that was hard and cumbersome and we had a lot of configuration and we're trying to figure out how, you know, essentially, a software distribution problem of, hey, you know, we have these, these sort of delivery payload mechanisms that we're using in a way that they weren't really intended to be used for, and we're trying to figure out how to optimize this and, you know, just a lot of tooling churn over the years. And I think the thing that gets me excited today about the tools that we're using is, like, like, it's so simple. It's like I can, you know, I can teach someone who is new to programming on a production code base, like, hey, look at this thing, oh, yeah, here's this configuration, and that wasn't the case, you know, even a few years ago, where it's, like, alright, sit down, give me the rest of your afternoon and I'll explain what this webpack config does and and this is no shade on webpack, it was like doing very important things, but I think just talking about the overall maturity of the tooling, it's it's changed a lot.
Speaker 1:So could you just talk a little bit more about what about that bundling problem? Because I think this is this is a part of the space that I never really understood when it was at its height. And I guess now that it's been obviated, it's a relief, and I never have to go under but I think that okay. What was the the the kind of the bundling challenge and problem, and how has that been solved with the tooling?
Speaker 4:Yeah. I mean, so JavaScript, single threaded, you know, has an event loop, so you're parsing top to bottom sort of executing as you go, and it's like putting asynchronous work on the event loop to sort of be popped off and ran over time. And the big thing is, you know, in the early days when you're, like, building something with jQuery, you've got, you know, one file, one JavaScript file that you're including, you know, you're making a call and like including all of jQuery and then you've just got this big one blob. Well, you know, developing software and and big blobs is is not easy. I mean, you know, maybe you might like working on a 20,000 line c file, but it's not a it's not a fun time for everybody for sure.
Speaker 2:Right. Just to be clear, I did not. I did not say Justin to say that. Very, very specific.
Speaker 1:That felt extremely specific.
Speaker 4:Hey, you know, not throwing shade at anybody. I
Speaker 1:Adam is furiously DM ing you, like, getting a wcminusl on ptrace.z.
Speaker 4:I I mean, just the idea that we needed modularity. And so pretty quickly, things like, and this is especially true as as Node was coming on the scene, CommonJS came about, and we're like, okay, well, we have these modules and we need to figure out these relatively hard problems of as soon as you have dependencies and you have modules, then, you know, they have, like, there's a dependency chain here. There's a tree structure in your in your module graph, and you have to figure out, you know, how to organize those and and, you know, really hard problems like, okay, when my client starts, when they start executing, there are, you know, maybe these 20 modules that they need to render something on the page. But we have 200 other modules with other functionality that they will need as they browse the experience, but they don't need right now. And if we delivered all of this upfront, it's going to reduce the performance.
Speaker 4:And, you know, you have all of these things to sort of think about. Like how do we break down the code? How do we ship only what needs to run? And, you know, many other problems. Crespo, definitely feel free to hop in here.
Speaker 4:But that is inherently like it's a compilers problem, you know, it's it's non trivial and then just figuring out things like, you know, what dependencies do we have? What and because you have to think. You also may depend on, you know, some CSS or some other assets, some web fonts or, you know, whatever. You could have a lot of dependencies and, it's just a non non trivial problem especially when you consider that, you know, when JavaScript was designed, it wasn't designed with, like, modules in mind. It's just like, hey.
Speaker 4:Here's this, like, block of code. Execute this, please.
Speaker 3:Yeah. I think that's a great account of of what happened. I the the only thing I would add is that what happens over time, you know, the the complexity of the tooling is a consequence of the there not being consensus about what we need to do. They're, you know, if you think about just, like, the number of web apps that there are tens of 1,000, millions, and, you know, everybody was working on kind of their own custom configuration of of these bundler tools because there wasn't a consensus on what a web app would need, and you really need to go through that process of trying all these things before the, the consensus, you know, core functionality can really shake out. And then that enables these, like, really elegant tools like Vite, which is what we use to to, build the console in local dev and also in production.
Speaker 3:It's a our config file for that. It's like a 100 lines or something, and most of that a lot of that is just like little utility functions that we've written. And so
Speaker 1:Are you saying VEEP
Speaker 3:Vite or Oh, yeah. I should spell it. It's a it's a the pronunciation is French. It's v I t v
Speaker 1:Oh, oh, oh, fast. Oh, yes. I was yeah. Right. Got it.
Speaker 1:Yeah.
Speaker 3:Well, it looks like Vite. So but, yeah, it's pronounced Vite. And it uses so you know, and it uses other tools under the hood. It's, you know, kind of a fancy wrapper for ES build and, roll up. But the fact that there's sort of consensus on how web apps work means that our config file can be very small because we don't have to make all these choices because that's just the way because the way that they do it by default is actually exactly what we want, and so you don't have to do all this really fiddly, configuration.
Speaker 3:And that's that's that's kinda what I think about when I when I think about the maturity of the tooling. It's about, you know, this process of shaking out, what what is actually needed and and what's not.
Speaker 1:Well, in getting consensus, I get to really interesting point. By getting consensus about what the problems are, and then getting consensus that, like, okay, these elements of the foundation are the the kind of the right elements. I mean, this is I'm also gonna kinda show my vintage here. Browser compatibility was such a big deal back in the day. And it feels like it it I mean, obviously, the number of browsers has been greatly reduced, which helps.
Speaker 1:But it feels like that's am I wrong that that's not as much of a problem as it was? I mean, it feels like things
Speaker 3:Inter compatibility? Basically not a problem anymore.
Speaker 1:Yeah. That's amazing. It's great. But it's another one of these things where, like, we need consensus on what that substrate was. So we mean I think
Speaker 3:people will probably say, wait a second. Wait a second. For many people, not a problem. There definitely are people who are who are writing internal apps for companies that are that probably still have people on IE, though. You know, if Microsoft says stop using IE, then, hopefully, there aren't very many companies, like, using, you know, IE 8 to to run their internal apps except when their internal apps require IE 8 because they won't run-in any other browser.
Speaker 3:But
Speaker 4:Well, IE is definitely EOL, so don't use IE, please.
Speaker 1:Don't use IE.
Speaker 4:I mean, this is one of those things, though, it is worth noting that there are still browser compatibility issues. So it's like Opera is a very popular browser in certain parts of the world. So it like depends on your audience. So yeah, by and large you can hit a lot of the same groups with not doing a whole lot of work. This is good and bad though because mostly this is the rise of chromium and it's just like eating the world, which I feel conflicted about, but
Speaker 1:Yeah. Ashish put me to point
Speaker 3:in the chat real quick about, you know, it's not necessarily consensus, but I would say that each tool in the space represents a consensus. And that doesn't necessarily mean that there's a global consensus, but you have this sort of convergence and you have this this plurality of of, consensus.
Speaker 1:Yeah. And I mean, you got, like, at least some agreement on abstractions that are productive for some a a significant enough subset to get to start getting some commonality where you can know that, like, okay. I can go build this next level of tooling and know that I don't have to solve, like, for 18 different ways of doing it beneath me. Maybe you think that that's that's that's important. I mean, you wanna and there's always a tension with that.
Speaker 1:And, Justin, maybe this is what you're getting at with your kind of own complicated feelings about Chromium that, like, we also like, we don't necessarily want monocultures, and Chromium probably is creating a monoculture there. I don't know. Could you elaborate on some of your your conflicted feelings?
Speaker 4:Yeah. I mean, you know, and and to in one hand, chromium is just amazing engineering. You really have to hand it to them. Like V8, the JavaScript execution engine that that that ships with Chromium is just mind bogglingly good. Like, they've done so much work there.
Speaker 4:And then, you know, to the whole execution engine, it's, like, it's great. And there's, proliferation of tools, you know, if you think about Electron. So Electron sort of built off of the legacy of, Chromium. Electron spun out of the Atom team, Atom editor. There's a lot of, you know, power that's come with that.
Speaker 4:But at the same time, this monoculture is is a challenge. It's hard. So for example, this is a minor gripe but the the Chrome team is sort of like pushing this browser extension manifestv3 thing that just infuriates me to no end that you know they're trying to make this, argument about performance and security that I can only half believe because the project itself is of course blocked or backed by by Google. So it's like, hey, yeah, we make money on advertisers. We're gonna make technical decisions that makes it harder to build ad blockers.
Speaker 4:You know, I don't know. Just just stuff like that. It's like, you know, as with over the world, it's less the the technical stuff itself and more the the messy reality of life. There's politics, there's money on the line, and I I don't know.
Speaker 1:Interesting. And and, but fortunately, it's all open source. I do feel that this is I mean, I think, ultimately, this is the the legacy of Firefox and Mozilla was to get us to a world in which our browsers are broadly open source. I assume that that's still true. That's still true?
Speaker 1:Is that not true?
Speaker 4:I mean, yeah. It's broadly true, but but you're talking about very, very, very complex engineering systems. Right? And it takes a ton of capital. So the thing is, these things being open source benefits the corporations by, you know, giving people the opportunity to come contribute.
Speaker 4:But they are so capital intensive to develop them and and to provide all the features and, you know, not to I mean, I like JavaScript the language, but it's continuing to evolve very quickly and all the browsers have to keep up with that and CSS is evolving. Like all these things are happening and it's making these really complex environments, you know, we expect a lot out of the web and we're continuing to expect more, and that does not make this an easier engineering effort. So, really, if you don't have a massive amount of capital to deploy to these things, you're not gonna be able to compete in any real way. And I and I think that that really gets around this whole notion of, like, oh, yeah, open source is gonna save us. And it's like, in this case, I don't think it's going to.
Speaker 1:What's the real tension, right, between that kind of the consensus that you need to build the tooling that you want to advance it, and then avoiding that that monoculture, especially when you've got this kind of questionable, potentially perverse incentive around blocking ads, for example, and kind of blocking ad blocking. So, yeah, that's that seems like I I this would and you mentioned v 8, Justin. I mean, I actually think that that this may be a bit of a a hot take or a controversial opinion. I think v 8, I think, was an extremely important software project because I think there's a certain degree that people had given up on the performance of JavaScript, and v eight showed folks that it could actually be high performing. And I think it it redefined what's possible.
Speaker 1:So I I actually think VH should get an Centimeters system software award. Adam, put me down.
Speaker 2:I I I'm I'm I'm all for that. I think it's a great take. I think not because not only is that applicable to, to JavaScript, but I think people took that lesson and brought it to other languages. I mean, directly, you look at hack and PHP. That that was that was born from the observation from, you know, in part Keith's observation that they could do the same thing as v eight was doing.
Speaker 2:And I think that's been carried to other places. So I I think it took, it it helped, you know, virtual machines of that sort over a very significant hump that had that had sort of slowed the proliferation and let people see what they could be.
Speaker 1:Totally. Very, very important project. And, and it's cast a very long shadow. So in, so, Justin, then what what is your take? So you I think the other thing that it's just I'm you know, I think Adam might can speak for both of us.
Speaker 1:It's blown us away. Is David, your use of playwright has just been amazing. That thing is crazy. Is that as good as it looks? I mean, it looks amazing.
Speaker 3:Yeah. It's it's really great. I mean, I've definitely tried various, end to end testing tools. I all I should say what Playwright is, in answering this. So Playwright is a tool from Microsoft that lets you do browser testing.
Speaker 3:So you, you know, you script the browser to essentially do what, what you would do when you click around the site. You know, every time you you make a PR or you merge domain, you wanna you you have these things in mind or sort of, like, what are the key flows that I wanna make sure that they haven't broken? And as, you know, pretty early on in the web console project, I realized, like, okay. I definitely need to just write tests for those things instead of going and clicking around myself. And these kind of tools have a have a pretty long history.
Speaker 3:I mean, when I started I started as a web dev in 2012, and I think we had something that was, you know, selenium based at that point. Right.
Speaker 1:I was
Speaker 3:just kinda similar. The basic idea is really similar, but somehow, I don't know if it's like you were you know, we were talking about the browsers being standardized and not, you know, maybe the problem of of making these things reliable is, not as hard anymore. Not to discount, I'm sure, whatever is the immense engineering effort to to make these things good, but I just we just find that these tests are not not that flaky. They, you know, figuring out how to select things is is was originally was really tough. Like, you would have CSS classes everywhere, and you would just be selecting things by by, you know, the button class or, like, something that wasn't really relevant to to what it was on the page.
Speaker 3:And, now there's different conventions around that that I think make it a little bit more, reliable. But just overall, the experience of writing these tests is not that of, like, a massive slog. It really it's not very hard once you get used to it. And we have, I don't know, 60 or 70 or something of these in the web console. And they are actually our primary test.
Speaker 3:We have unit tests for things that are, you know, more pure functions like helpers and stuff. But, for the most part, these full end to end tests in the browser running in Firefox, Chrome, Safari, like, these those are our primary tests for the console, and they give us quite a bit of confidence that we are not messing things up when we, when we make a change.
Speaker 4:Did I ever tell you all the story of how I got involved in open source for the first time? No. It's in my it's, it's related. So I was working for this company called Adtran. They sort of a Cisco competitor, make switches and routers, and many other things.
Speaker 4:I'm sort of minimizing their business there. But, so we were using this Python, testing framework, automated testing framework, called Robot Framework. It was by a Finnish developer. I think he'd done it. He'd, like, developed it for his PhD, but we were using that to drive the console to, you know, you'd have a a rack of, like, switches and routers or whatever in different configurations and, you know, drive it, like, drive a BGP test or something.
Speaker 4:But we also wanted to test the web u I for this. So there was a selenium binding, for robot framework and it did not work as well as I wanted and the previous developer had sort of abandoned the project. So I got involved in maintaining, selenium binding for this Python, testing framework, and that was my first major contribution to open source. I I helped maintain that for, like, a year. Yeah.
Speaker 4:So it comes full circle.
Speaker 1:Yeah. Right. Exactly. That that was your your entree into it was around, because when this this has historically been one of these things that has been just rocky is how do you actually automate testing of a user interface of of something that that is gonna ultimately require a a human being moving a mouse and so on. And, did you make because you're mentioning with, like, Selenium, you do these kind of do it with CSS.
Speaker 1:And I I just gotta imagine that, like, you end up with the test itself being brittle or potentially brittle. Was that
Speaker 3:Absolutely. Yeah. And, the convention around that has has changed quite a bit. So, I think this is something I learned from a guy named Kent c Dodds, who is a, I think he mostly teaches, web dev online now. He actually worked at PayPal when I was working at PayPal.
Speaker 3:But it the trick is to use, what's called the accessible name of things, which is essentially like the text that's on the screen. But for things that don't have displayable text, there's also, text that a screen reader would show.
Speaker 1:Oh, it's just
Speaker 3:like Using the, ARIA role, I forgot what ARIA stands for. But, essentially, it's like the the type of of item of element that it is, but it's it's not the same thing as, like the tag, the HTML tag. So, you know, you'll select a button with name, you know, next or something. And so, essentially, what you do is you select by what is visible on screen. So you really just put yourself in the mindset of a user, using the page instead of the sort of developer mindset of, like, what are the classes that I need to select for.
Speaker 3:And, like, if you need to select the button in the dialogue, you can be like, give me the button that says next that is inside of the dialogue as opposed to the button that says next that it's on this other part of the page. And so by doing that, we can actually really exercise the accessibility of the app as well.
Speaker 1:I was just gonna say that is really yeah.
Speaker 3:You get it for free, by by testing this way, and it makes the test much less brittle because, you know, you don't have this mystery about, like, what am I selecting by? What am I changing? Like, when you change the text, you're gonna mess up your selector, but that that's not surprising because you know that you changed the text. Whereas, you know, changing CSS classes might be a much more surprising, thing for a test to break.
Speaker 1:Yeah. That is really that's great. I would just say you've solved this other really thorny important problem that we you had Matt Campbell on, whatever that was 15 years ago on the podcast. Adam, like, I don't how long you've been doing this?
Speaker 2:That's right. Approximately that. Yeah.
Speaker 4:Alright. So this is something near and dear to my heart. The the little caveat here is definitely these, like, using, aria roles and using accessible names is is important and it helps part of the validation, but building an accessible web application is a whole another thing. I mean, that's a it's a completely different design paradigm. Like how you have to think about how someone navigates through a web UI with a keyboard and a screen reader is is very, very different.
Speaker 4:So when I joined, I'd done some, like, early work on just, like, making sure that that experience was good. It's also a very hard thing to validate, because it's it's different than saying, oh, do these things have accessible labels? You know, that's fine, but it doesn't mean that you can navigate it well. So we have actually put in some real work into making sure that that is, a decent experience. I I would say it's not perfect.
Speaker 4:We still have a ways to go, but I I would I definitely emphasize that we've put a lot more work into this than a lot of folks do out of the gate. It has been something that, you know, early on, you know, I've got a Windows machine at home. I use a screen reader just to test it out. You know, I just like wanna make sure, hey, can we get around, you know, doing little things like having a button that's hidden so when you back tab, or tab to the first element, it pops down this button. It's like, would you like to go to the main content?
Speaker 4:So you don't have to tab through every single menu item, you know, in the header or whatever to get to your VPC configuration or whatever you're trying to get to, you know. Like, those kinds of things are important, and they take special care. It takes rigor. It takes, you know, a different mindset. So it's not something that you can ever just get for free, but, definitely using accessible, like, area roles and stuff is is helpful for that for sure.
Speaker 3:Yeah. And something that I love about it is that it it to me, it really just makes the app better for, you know, sighted users as well. You know, you if as in Right. It's it the the structure is the clarity that you that you get in thinking about the structure of application and, you know, being able to use these patterns, in the ARIA guidelines about, what a list box, you know, scrolling picker is supposed to look like, things like that. It really gives you a lot of clarity in in how these things are just supposed to work, for everybody.
Speaker 3:So, it it it's been great. This is the first project I worked on where we've put this much attention into it.
Speaker 1:That is awesome.
Speaker 3:I've learned a ton.
Speaker 1:Well, so in another kind of challenge that it that you both had to deal with is and I which I imagine is, like, not that uncommon in the front end world where you're trying to build something in the back end is maybe it's extremely common where, like, the back end is doesn't yet implement that. In our case, like, the back end weighs £3,000, and we hadn't even, like, pulled the whole thing together, until we needed hardware and software pull against what what were some of the challenges there about having to build a console for a thing that didn't yet exist? Except you've taken a bunch of different approaches at kinda different levels to allow you allow you to to develop the console in time for the software.
Speaker 3:Yeah. The I mean, the main thing was, to me, was avoiding building things the wrong way because there's, you know, this immense weight of the past that, like, that, you know, weighs on you even though, technically, you might get to a point where you've gone the wrong way and you wanna scrap it, but you you feel like you can't. So to me, building the wrong thing was always worse than building nothing. So I always aired, like, very, very strongly on the side of building less, and really being confident that it was something that we would need, and, you know, avoiding coupling and things that would would make it harder to to rip certain bits out, when it turned out that, you know, the the the back end went a different way. Eventually, the back end came, you know, caught up with us, and we were able to sort of build basically as fast as we could, you know, more and more pages in the in the console.
Speaker 3:But, you know, in a web app, there are certain things you need and you wanna get the architecture right. And so that was kind of what we focused on in the in the early time. I mean, when I started, it was March 2021, and I don't I don't think the API was, giving us that much to work with until probably the summer or maybe even in the fall, way around when Justin started. And then we started to have have quite a bit more to work with. And, you know, Justin and I ended up doing, you know, part of part of the solution there was also Justin and I working on the API itself to kind of help it catch up with with what we're doing in the console.
Speaker 2:I was gonna say, yeah, that I mean, a big part of it was you just building the API and building the back end, rather than waiting for it. But then there's tons of stuff you also did to separate, front end development from even having a live back end, and that's been incredibly impressive.
Speaker 3:Yeah. So we, this is actually another thing I learned from Ken C. Dodds. So so this is a lot of shout outs to Ken C. Dodds on this, episode, using, a mock API, to to avoid having to even run the the real back end, during development.
Speaker 3:So I think if you had told me to try this be you know, a few years ago, I would've just thought that's just a ridiculous amount of work and you have this enormous risk of, your mocks deviating from the real thing. That's obvious always a big problem with mocks. But the the real key to making it work is that, we have the open API spec, from the a from the real API, and that tells us what our request bodies look like and our response bodies look like, and it even gives us some validation stuff. Like, you know, this number has to be in this range. By writing tooling that keeps our mock server in conformity with that open API spec, that really, really that mostly solves the problem, I mean, because mostly what you're what you are worried about when you know, in terms of correctness is just like the the shapes of the, request and responses.
Speaker 3:So by writing tooling, that essentially makes that a problem of, you know, if the API changes, you just get a type error in TypeScript and you'd fix it. You you mostly eliminate that problem of of of your mocks getting out of date. So we've used that, you know, really extensively. That's that's actually what we do most of our development with, and we just wrote kind of this fake functionality inside of that, typed wrapper that implements the API in a really minimal way, and and we write most of our our code and test against that.
Speaker 2:Yeah.
Speaker 4:So
Speaker 1:maybe That's really cool.
Speaker 4:Maybe, like, a technical journey here. So this all starts, you know, at Nexus, our control plane. So we're using drop shot which is a HTTP library or sort of a REST API library. Adam described this better for me.
Speaker 2:Yeah. So a HTTP framework for, like, building simple web servers.
Speaker 4:There you go.
Speaker 2:And it
Speaker 4:was one of
Speaker 1:the first things we built at Oxide. I mean, Adam, you got because you and Dave did that, like
Speaker 4:Dave and
Speaker 2:to be clear, Dave did, like, 90% of the work. I just, you know, showed up to scoop up, you know, 50% of the glory on it. But, you know, the one of the key insights that I did bring there was, I really believe in in interface description languages, and OpenAPI is flawed and broken, but I think it's the the best thing that we have. And, I I think the approach that drop shot takes is using open API as an output. So, like, you write all the code and then that is true.
Speaker 2:Whereas a lot of other frameworks, it's easier to get divergence between the code and the spec. And here it's as as Justin is alluding to, we we build the server, it outputs open API, and we know that that is actually what the server is going to do. Yeah.
Speaker 4:I mean, that and that was
Speaker 1:a that was a bit of a big bet, Adam, in terms of, like, the just in the importance of the primacy of OpenAPI despite its flaws was and, I mean, this is a domain that you've got a ton of experience. This is something that you you had spent a lot of time going into different APIs, and how are these things used. And this is something that, I mean, we that you came in feeling pretty certain about, and it was really it was the right call. You know, this is something that has paid a lot of dividends for us.
Speaker 2:Yeah. It it it's been great. I I'm really glad the way it worked out. And, you know, stuff like drop shot is opinionated about how we do pagination where you can have APIs where you find 5 different ways of doing pagination because it's built by 5 different people. So why not?
Speaker 2:But some of the stuff that, like, Justin and David have done where we now get type checking across the the client server boundary is just beautiful. I just love
Speaker 3:it. Yeah. I mean, like, life changing as a as a client dev, to have that confidence that that you're you know, the when when the API changes, you know it because you get type errors.
Speaker 4:Yeah. I mean, the the having the spec that's true to the implementation because it's driven by the implementation has has been really a key to our success and and the whole reason, I think one of the large reasons that we can maintain such a small team working on console. So we open source, oxide TS, which is the repo today, which has our current generation stuff in it. Shout out to that.
Speaker 1:That that may be what I was stopped tweeting earlier, you know.
Speaker 4:Yeah. So from that open API spec we generate a lot of things. We of course generate like an SDK that we can use to work, with the the API itself but also, this sort of mock server framework that we have, this actually generates the the sort of wrapper, the like implementation wrapper for those those mock functions. It's like, okay, well, what is this function? What does it take?
Speaker 4:What does it expect to return? And we even have like validators to ensure that the things that we're passing in and the things that we're returning from this, like, mock server are in this the exact shape that we expect them to be in and, you know, they are the right format. So our mark server gives us a lot of stuff out of the box because we generate, like, 90% of what we need And the rest of it is just, okay, let's do a little bit of logic to say, hey, you know, here's this list of of VPCs. If we create a new VPC, stuff it in this list. Stuff like that where the logic that we have in the mock server is is really minimal, which makes that maintaining that sort of which is a duplicate implementation of, you know, what our control plane is doing to some degree, like a very lighter version of it, it makes that relatively trivial.
Speaker 4:And and we have correctness guarantees that we can sort of rely on in a lot of ways. It's like maybe the logic isn't correct, But for a lot of the testing and development we do in console, that's totally fine.
Speaker 2:I just wanna echo something you you said, Justin, which was when the API changes, we get, like, a compile error in the front end. And I feel like that is great, and not everyone has that same philosophy, which I just don't understand. Or, like, I I don't understand living in a world where you just press on in the face of incompatibility, but I I think that that is very common.
Speaker 3:I mean, I can imagine there just being so many incompatibilities that you could never hope to fix them all, then just knowing about one more is just like, you know, a fly buzzing around your head. And you just don't wanna know about it.
Speaker 1:That's right. Yeah.
Speaker 2:Maybe it's the benefit of a clean sheet of paper here where Yeah. You got to build the right thing from scratch.
Speaker 1:I think that that is a big part of because I just think of, like, where you know, mostly when the API API changes, it's like, oh, actually, what I actually love to have is an undefined property exception, like, deep in my stack. Like, that's how I'd love to actually do it. But I could I mean, I I just feel that the, the and also, Adam, having generating the open API from the implementation, and, Justin, you talking about, like, how what that I that's actually really important because it means that the the API spec actually is correct. And I feel that's I mean, I gotta believe that's not always the case.
Speaker 2:I I I gotta just to on that point, I have brought this up a lot of times in open API circles.
Speaker 1:And I am viewed Leventhall being right now? I have never No.
Speaker 2:No. No. No. No. I am viewed like a heretic.
Speaker 2:Like, this that like, that idea that you would let people writing code define the spec implicitly is a type of, like, specification heresy. Because there's there's this really, really strongly held belief, and you and it's not that surprising that people writing a spec or, like, people who whose output is this, you know, open API spec of the sort that you might find like a JSON scheme schema spec believe that the spec writers should be in charge, not the implementation authors, or or those responsible for implementation. But
Speaker 3:Which is wild because the spec is not human writable, really.
Speaker 2:Well, there's that
Speaker 3:too. It's very hard to read and write. Yes.
Speaker 2:So I I would just say this is I I think that this is the only say way sane way to live, but there are people who really, really very strongly disagree with this. And in fact, feel like it is critical to have this separation, this almost check balance of powers, if you will, where you have 1 person writing the spec and 1 person writing the implementation, and it's the spec that is true. And the thing that often gets lost is anything validating that the 2 have even a, you know, bearing passing resemblance of each other?
Speaker 1:Totally. Talk about, like, Conway's law and the the ramifications thereof. I mean, that yeah. That's kind of crazy to me because it's, like, ultimately, like, what you I mean, David, you and Justin want is, like, I need to know what the implementation is actually doing. Like, does and if the specification doesn't actually match the implementation, to a degree, it's like sorry.
Speaker 1:The implementation wins. And the implementation is actually the thing that you know, it's the implementation.
Speaker 2:Yeah. And you get these APIs out there where, you know, the, I bumped into this years ago with the Slack API a bunch where what the open API document was out of date and wrong. And you'd file issues, and they'd be like, oh, yeah. We are going to do a new drop of that. And and to your point about Conway's Law, it was a different team.
Speaker 2:It was the DevRel team responsible for maintaining that, which was different than the folks building the service. So it's not that surprising that it fell on the floor. Anyway, I'm done with my rant at least for the moment.
Speaker 3:Oh, I mean, that so that points at, something that we do in the mock server as well, which is like what Justin was describing, is we actually generate quite a bit of the implementation as well, because, you know, obviously, you can't generate the part where it, you know, inserts the thing into the mock database, but you can generate the validation. Right? The the same thing that the API does automatically when you, you know, tell it what type the request body is. It's gonna validate, using, and or JSON schema. Oh, yeah.
Speaker 3:Right. On the way in that the thing actually matches that type, we also do we'll do that because we have the shape, and even some extra validation stuff like, you know, number ranges. We have that. And so what we do is we generate validators with this library called XOD that lets you take an object and you essentially try to parse the object with with, a shape. And if it fails, it fails.
Speaker 3:So, you know, we can 400 in the mock server. For every endpoint, it has its parser upfront. That part is generated. So we get that for free, and it's really only that little bit in the middle where it's, like, you know, if I'm retrieving a list of projects, like, return the list of projects. You know, we have this little core of the implementation, but keeping that part as small as possible, I think, is is is in line with what you're saying about, you know, the implementation is is really the the the truth there.
Speaker 3:So we that's why we we wanna we wanna generate as much as we can and then define the boundary really, really carefully so that the the part that we have to define manually is very, easy to do, but, you know, you you can generate that part.
Speaker 1:Yeah. That is really cool. And I think and, again, just kinda you you admit made this point earlier, but we've done I mean, we've done a remarkable amount with a very small team. This is true, I feel like, across the board at oxide, but it's it is every bit is true in this domain as it is in every domain at oxide. We've had a very small number of people doing an enormous amount of work, in part because you've been able to rely on tooling and automation and generation of of logic and code.
Speaker 1:That is really pretty extraordinary. And did you also describe what you, demoed on most recently on on Friday with respect to these this kind of static? Yeah. That was
Speaker 3:crazy. Yeah. What's really neat about this mock server, it's implemented with this thing called mock service workers. So this is a little bit confusing because it's kind of backwards. So service workers are an API in the browser that lets you essentially run a separate application in the in page.
Speaker 3:But it runs, I I think, in a separate thread from, like, the main, the main thread of of the page, and you can have something that actually acts as a server and intercepts requests that your that your client sends. So when you use mock service workers, the mock there is because you're doing that in node because you're you're using you know, it was originally invented for writing, like, essentially unit tests on the server side where you don't need to spin up a browser. In in our case, we're pretty much always just using it in the browser. So because this, mock API is able to run-in a service worker, we can deploy the actual front end, the, you know, the JavaScript and HTML, as static assets along with the mock server implementation also as static assets, and it all just runs in your browser. So what I demoed on, on Friday was, we're able to get preview deploys of every commit in our in our repo, which with, you know, functioning app, but it's deployed as a static site because it's the front end is static, and the back end is also a static file that the JavaScript that runs in your browser.
Speaker 2:This is so wild. This is is so you can test every front end commit, every feature, re bug fix as though you were talking to this enormous, you know, 32 CPU, 7 foot tall, 15 k w rack, and get sort of a similar or or or close enough user experience, which is just
Speaker 3:awesome. And it I mean, it relies on being very judicious about, you know, the fidelity of the mock. Right? Because you can have too too, you know, too flimsy of a mock and you're not really testing the real thing, but too complicated of a mock and you are constantly bogged down fixing it when it gets when it starts to diverge. So we we we give a lot of attention to to getting that balance exactly right so that we're not feeling, you know, trapped by all this code that we have.
Speaker 3:And, like, you know, like I was saying, generating as much of it as possible so we don't even have to make that decision. It just that's just the way it works, and we know that it matches the, the real thing.
Speaker 1:And could you describe what you did in terms of, like, pulling some fraction of data from the actual API? And it was, like, half mock. Oh, I know I know I'm sounding like this. I'm I'm recounting a dream.
Speaker 3:Oh, that's a different one. So that's a different demo.
Speaker 1:Right. But the the
Speaker 3:yeah. Yeah. Yeah. Yeah. So so that's that's actually not using the mock API just because our, the way our front end is implemented is just like a pure web app that runs in the browser, it doesn't really care what the API is.
Speaker 3:So if we, proxy requests through to, you know, the real, API running on the rack, you can run the app in sort of, like, local dev mode, in your browser where, you know, you save a file and it changes live. But the API you're talking to is, like, the actual API of the rack. So, you know, there's a lot of situations where the data, that you're testing against, it's really hard to get realistic mock data. So for example, metrics is really hard to come up with stuff that really covers the the way that real metrics look, and and other things. You know, obviously, your mocks are never gonna really cover every, real world case.
Speaker 3:So when we run into bugs in the in the, rack, we can actually point our local server. We can do local dev, but just pointing at the at the real API, and, you know, it's just a different command to start it up. You know, it's it's a it's a one liner, difference when you, when you start up the dev server, whether you're pointing at the mock API or a locally running copy of Nexus, which we also do, or, you know, a remote API running on the rack.
Speaker 1:Yeah. I just thought it was amazing. And I still I love these kinda 2 together, because they're kind of 2 different points on the spectrum, where it's like, look, we can some stuff is fully mockable, and it's great. And we can, like and then for oh, by the way, for the stuff that's fully mockable, like, why don't you have this in your Vercel preview of the PR, which out of this you said, it's just, like, mind bending that you're actually, like I'm, like, interacting with a poll. Like, how am I what?
Speaker 1:It's like, you can actually pull up the static site, and you're interacting with the PR as part of, like, looking at it or what have you. And then for the as you say, for the stuff that that then there's certain stuff that's, like, just not as amenable to mocking or what have you. And then you can actually get this hybrid deployment where you're in this developer mode, but pulling actual data from the the real API. I mean, just say, I just love all the different points here in terms of all kind of pointing to how do we develop this thing quickly and robustly, Which is what you and and I gotta say, like, also, just the actual artifact is so crazy snappy. It is so great too.
Speaker 3:Yeah. We'll have to link a video or, you know, some kind of demo. Yeah. Well, these points are are really, you know, mutually reinforcing because the the the entire reason that we can draw that clean line between the front end and the back end is because of that open API spec. Like, it really all comes down to that clean, clearly, you know, formally computer, readably defined boundary, being being the line between the the client and the and the server.
Speaker 3:And, like, it that doesn't mean you know, it's funny because one way that happens is like a Conway's law thing where your your your front end devs are one group and your back end devs are another group, and you'll define the line really, really strongly just because those people don't talk to each other. But in our case, that's not really true. We do we work on both sides of the boundary, but so it's like we gave ourselves a really clean boundary to then still work on both sides of. And that's been really, really useful.
Speaker 4:Yeah. I think That's really important. To talk about the the API philosophy here. The the real thing is or the product philosophy. The real thing is the API is the product.
Speaker 4:Right?
Speaker 1:That Yeah.
Speaker 4:That's the closest thing to the rack. That is that is the realest sense of the word. And whether you're working console, whether you're working in a CLI, whether you're working in any of the SDKs, it should all feel internally congruent. It should feel like the same product, and and we've put a lot of work into making sure that that is true and the case. Right?
Speaker 4:So it's like, oh, well, I I hit the API, and I can kinda see how this is structured and and the language it uses and where it's, like, organized, and you'll find that mirrored everywhere. So, you know, something with console is it's not a rich application so much as it is a sort of reformatted view of the API. And and we do it to make it user friendly and and do what we can to to help. But, like, I mean, console does so little by design, you know, both for maintainability and for the fact that, like, we any various functionality that we handle, we want to push that down into the API. And, you know, we've had some tensions internally where we think about, like, oh, maybe we can do that just client side.
Speaker 4:And, you you know, this is a this is a thing that I feel really strongly about is, like, if we expose product functionality, by and large, where it makes sense, you know, we have to make trade offs sometimes. But as much as we can, we try to make that a rich API versus, you know, we'll just do it client side.
Speaker 1:Yeah. Aim it. 1, it's something the API is the product. I mean, it the which is absolutely true. Bullseye, not something you would expect to hear from a computer company, I think.
Speaker 1:But it's absolutely true.
Speaker 2:Not one that's not AWS, I guess. Right? Because You're
Speaker 1:right. Yeah. Exactly.
Speaker 2:In fact, I mean, I I I think whatever you said, AWS is obviously complicated. I feel like that I can stand by that bold claim. But So AWS we'll put
Speaker 1:AWS and World War 2 on equal footing there?
Speaker 2:Or is that the World War 2 was stressful. I guess AWS is stressful too.
Speaker 1:Stressful. Okay. Well, I think they're both stressful and complicated. Okay.
Speaker 2:So I wasn't There there we go. Let's split the baby. Right? But, you the philosophy of everything is an API, it's like, yeah. That's that's spot on.
Speaker 2:Right? You you nailed it.
Speaker 1:Well and then and then just all that stems from that. Like, why that is so important? Because, I mean, everything you can do in the in the console, you can also do in the COI. You can also do direct in the API. And then we can also I just love all the things that have been done though.
Speaker 1:Like, you know, oh, do you wanna do this thing? Do you wanna do this on the on the CLI? Here's the CLI indication for this. Do You wanna talk to the about also the overlap. Filmmings documentation also comes in here as well, and in terms of, like, how we are how we kinda document the I mean, say the API is the product, kinda how API that that we we end up with a with an with a a locus for documentation as well.
Speaker 4:Who's that pointing to?
Speaker 1:Yes. Silence. I don't know. The the ink, Yeah.
Speaker 2:Well, one thing is we, we do all of our documentation in line in the code, and this is another one of, like, drop shots opinionated takes. And and this is maybe a a bit of a cynical one. But what I've observed, and I I don't think this takes, you know, just too deep of an insight, is, like, that people writing code aren't good at remembering to update the documentation, especially if it's all the way in some other file that you have to remember to All the way. Right. It's not No.
Speaker 2:Right.
Speaker 1:I mean, here's this other window. Totally. Yeah. Absolutely.
Speaker 2:Right. Or or maybe it's not yeah. Exactly. It's like in markdown or ASCII doc, but I'm writing some Rust codes. So we just take the Rust docs, and we make that the documentation.
Speaker 2:And it's bitten us in some ways, and sometimes you can sort of forget that you're writing user facing documentation and start yammering about internal implementation details rather than explaining to the user what the API is. But it is sort of up there, you know, it it's right there in your face. And when you generate the docs, you you see it in the JSON description and so forth. So try to put the the, you know, the things that we, the developers of the API, have to say about the API as close to it as possible. So that whether you're the one right changing the code or often if you're the code reviewer who's taking a fresh look and saying, hey.
Speaker 2:The thing above says it goes left, but the code below says it goes right. Makes it a lot easier to keep those things in sync or a lot harder for them to fall out of sync. And then that gets propagated with in in work that jave David and Justin have done, you know, everywhere, including in our docs website.
Speaker 1:And, David dropped the link into the to docs at oxide.computing, but you can allow anyone to see the of that documentation, which is all effectively generated from the implementation ultimately.
Speaker 3:Yeah. And the CLI docs as well, I believe. Yeah.
Speaker 2:Yeah. That's right. We'd be remiss in
Speaker 4:our duties here if we also didn't give a shout out to Ben and Eugene, our designers,
Speaker 2:who Totally.
Speaker 4:Have touched every part of our product, be it docs or console, you know, industrial design, our internal RFD site, literally everything. Even Marketing site that everyone loves? Yeah. Which is Which
Speaker 1:is like like, the Oxman Trend speakers.
Speaker 4:Yeah. So they're amazing, and they do everything, which yeah. So props to them for sure.
Speaker 1:Well, and props to the and also just, like, their, disposition is very much a a cross disciplinary versatile disposition. I mean, part of what I love about just everyone. It's like everyone's everyone views the whole thing as part of their job. So it's like we don't because I think that these Conway law Conway's law problems are real problems, and they the the problem is they show scenes to the the the user. Like, you can see, like, where the these I feel like with so many Google products, like, oh, I get it.
Speaker 1:Rifle organizations. You do hate one of those guts. I gotcha. Yeah. Can you please I just hope just can we just make sure that we don't all kill one another at the same time?
Speaker 1:And, so we can at least have one of these products, but we so I think it's really important that you got that that and I think, yeah, just to your point, Ben and Eugene had done a great job of of stitching in across the the the console and the and the API and the docs and so on. It's been really terrific.
Speaker 4:Yeah. We don't have enough people to build silos.
Speaker 1:That's it.
Speaker 2:That's right.
Speaker 1:That's it. That is actually but, I mean, that is it. And, like, boy, if there's there's there's a real value to that about, not having because when you do have enough people to grow silos, like, their silos become a bit of a self fulfilling prophecy, and it can be really problematic. And then it becomes really difficult to actually develop something that feels coherent. And, boy, this is what you all have really pulled off.
Speaker 1:It's just been remarkable. I David, there's a a question in the chat about can folks see a a a look at, like, what this thing actually look like? This I didn't have Yeah.
Speaker 3:So let me post I'll post a screenshot, and then, when we open source the console, anybody will be able to just npm install and, you know, npm run dev and and run it locally with the mock API. And, you know, we'll be able to actually link you know, get a link to our our live demo that I was talking about as well. So you'll be able to see it, pretty easily.
Speaker 1:That is great and very excited to to, to get this out there, to get this open. So it's gonna be, people will be able to see exactly all the the the stuff that you built and the good the kind of the tooling and and how we're doing it. And I think that there's some real lessons there for other folks that that are, not building a computer company. But, in particular, the, the the the API primacy, I think, is really interesting. And, Adam, and I just in hindsight, that was important dimension to what we were I mean, an important thrust was that that kinda API centrism, which we, again, we knew.
Speaker 1:I did we didn't we doubt it, but, boy, seeing I I I think, it is surprising how many ramifications there are of it.
Speaker 2:Yeah. It's I'm I'm really pleased with how that worked out. And you're right. Not not wholly surprising, but I think it would have been easy at the time in those early days to say because we had a a, like, a handcrafted, you know, YAML file of the API. Like, this is how we got early feedback on the API.
Speaker 2:And it might have been easy to say, okay, well, that's the the open API spec. Now let's go build the implementation against that. And it would have been sort of fraught in all the ways that that, you know, building these APIs can be fraught. So it's it's worked out very nicely, and we're even generating the CLI by and large from that API spec. So it's, it's been pretty neat.
Speaker 1:That is really neat. And, yeah, it would have been easy. That's what I mean. It's like it would have been one of these things that it would have been easy. You can see how companies drift into this where Totally.
Speaker 1:Things are are out of sync. And then all of these kinda knock on effects of having them out of sync. It's like, well, now we actually can't actually use it to auto generate the client side validation. Sure.
Speaker 2:Because And and easy to see because when you start writing it, you're like, well, we don't kinda either we say we start from the spec and we try to conform to it, or more often you say, we don't really need a spec for the first, you know, 2 dozen lines of code we write. We don't we don't have a client. The client is curl. You know, we're not writing the TypeScript yet. So just can we all chill out a little bit?
Speaker 2:But then as soon as you do that, it's, like, really hard to go back and kinda stuff the genie back into the bottle on these things. Or or, you know, it becomes a heroic undertaking to document it and then maintain it and so forth. So, you know, much much easier as we've alluded to from a clean sheet of paper.
Speaker 1:It really is. And, Blaise, it's it's just it's amazing to see what you all built. And great job. They've been doing really terrific, terrific stuff.
Speaker 3:Thanks.
Speaker 2:Yes.
Speaker 1:Well, thank you very much. David, I I know you've got a, a negotiated truce with a 4 year old.
Speaker 3:Yeah. Correct.
Speaker 1:We all know that that 4 year olds don't honor their treaties.
Speaker 2:That's right. They really dictate the schedule of the show. We've we've we've learned over the years.
Speaker 1:So we'll let you get back to it with with a huge thanks to to, and our apologies for cutting into your family time. No problem. Did Adam, good luck resolving your, your labor dispute with the camp or or or
Speaker 2:or just just be fun. Just good
Speaker 1:luck with our time. I'm I'm so sorry. We can't I I know you want this podcast to go on forever, so you don't actually have to go. But
Speaker 2:I know I had a visitor halfway through who who who wanted to get on the show, but made him made him get a Discord account just like everybody else.
Speaker 1:There you go. He's like, what do you mean? I what do you mean? I I I can't be known as a numeral anymore. Well, thank you very much.
Speaker 1:Terrific discussion and really, really, really interesting stuff. And, again, great work. Really exciting to see.
Speaker 3:Thanks for having us.
Speaker 1:Alright. Thanks, everyone. See you next time.
Creators and Guests
