1008: Diffs, Trees, and VS Code 2.0

Scott and Wes sit down with Alex Sexton and Amadeus De Marzi from Pierre Computer to dig into the gnarly performance challenges behind building blazing-fast code review tools, covering virtualization, progressive rendering, and why GitHub’s UI feels so sluggish. They also chat about how major AI coding tools like Claude, Codex, and Cursor are adopting Pierre’s diffs library, plus the role of web components, benchmarking, and what it takes to build “VS Code 2.0.” Show Notes 00:00 Welcome to Syntax! 04:00 The Need for Better Infrastructure 05:53 Understanding Diffs and Trees diffs.com Trees by the Pierre Computer Co 08:16 Performance Challenges in Code Review 10:49 Virtualization Techniques for Smooth Scrolling 15:04 In-Page Find and Virtualization Limitations 17:00 Browser Limitations and Content Visibility 19:29 Progressive Rendering and Syntax Highlighting 23:05 Tools and Techniques for Performance Testing 33:35 Optimizing Performance with AI 36:31 Mastering Auto Research for Efficiency 42:00 Exploring Web Components and State Management 44:05 Innovations in Rendering and Virtualization 49:12 Business Insights and Future Directions 53:58 Sick Picks Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we've got Alex Sexton and Amadeus DiMarzi. Apologies if I goofed that up, but we are talking to them because they are building the primitives for something that Claude Code uses, Open Code, Conductor, Codex. They're building, essentially, they're building the building blocks for almost what would be like a new VS Code. And it's really cool. They're working on some pretty hard stuff, and we're going to dive into it. Let me just show you really quickly how impressive this is. So, one of the things, or two of the things that they build is diffs and tree, which is basically like if you want to show a diff of code, and if you want to show like

• 0:44Wes Bos?

  a tree in the sidebar of some files. And if you've been on GitHub lately, you may have noticed it's a little bit chuggy. So here I am scrolling on GitHub, and I'll just stop my thing. There it is. Let me scroll down a little bit. Have you ever tried to resize GitHub before? It's like, let's just wait here a second while GitHub resizes.

• 1:07Scott Tolinski?

  Brutal. Yeah.

• 1:09Wes Bos?

  Okay, there we go. So, oh, no, oh, no, oh, no. It's got, literally, I'm not touching anything.

• 1:15Scott Tolinski?

  For those of you who are just listening on audio, it is mega low FPS. It is mega lag, taking forever to restructure, repaint.

• 1:26Wes Bos?

  And look at that. Watch how fast I can scroll. I have like one of these like Logitech mice where I can scroll super fast.

• 1:32Scott Tolinski?

  Audio listeners.

• 1:33Wes Bos?

  Let's see how fast I can go.

• 1:34Scott Tolinski?

  He's not scrolling fast, and it has much better.

• 1:37Wes Bos?

  Thank you, Scott.

• 1:39Speaker 02

  I think even for video listeners, video watchers as well, it'll be lower FPS, because this is probably 30 FPS.

• 1:47Wes Bos?

  That's true. It is, it is very, very fast. So, welcome, guys. I just wanted to show the audience, before they tuned off, that this is extremely impressive, and I'm excited to talk to you about everything you're building, how you're building it, and a couple other things as well. So, welcome.

• 2:02Speaker 02

  Thanks. Thank you.

• 2:04Scott Tolinski?

  I've been seeing your stuff pop up a lot lately, and it seems like all different types of capacities. So, do you want to quick give us an introduction to who you both are and what you do?

• 2:16Speaker 02

  Sure. I'm Alex Sexton, mostly JavaScript front-end engineer at Pierre Computer Company. And we are structured around the idea of kind of making

• 2:29Speaker 02

  Code developer tools for the next generation of, I should practice this, next generation of AI agent-based coding. And so we have a core product called Code Storage, and it's kind of like Git for agents that can handle a massive volume. And then Amadeus and I work on the team that does primitives. And so if you were to want to layer user interfaces on top of changes that agents or you made to code, then you might use trees or diffs and some of the other things that we'll have in the future as well.

• 3:05Scott Tolinski?

  Sick. And Alex has been on Syntax before, back in 2024, February 16th, when we were talking about CSP, XSS, that type of stuff. And Amadeus, what's your story?

• 3:20Speaker 03

  Yeah, my name's Amadeus Demartie. I have been in tech for a little while, though I kind of fly a little bit under the radar, I'd say. My sort of biggest recent gig was I spent a few years, eight years actually, at Discord, which I think kind of like probably got me really into thinking about front-end scaling and stuff like that, which I think has a lot to do with the sort of diff stuff that we're doing now at Pierre. And then, yeah, to kind of echo a little bit about what Alex said, we, you know, the primitives team is very much focused on these sort of blocks, these building blocks for building, you know, viewing code and sort of how AIs will generate a lot of code and you need to review that stuff, so, yeah.

• 4:00Wes Bos?

  Yeah, it's kind of a weird world right now where there's all these like new ways to code. There's all these startups and GitHub is absolutely melting under everything to a fact that like, like you guys came up with like the code.store, which is, I know that you're not on that team, but like that's a product that a lot of these vibe coding startups can then use to push the code to instead of pushing it to GitHub.

• 4:25Speaker 02

  Yeah, that's right. The scale that code storage works out, and we do work on some of that product. But we are able to facilitate a much larger kind of scale when it comes to like AIs creating thousands and thousands of repos a second. And that's the type of activity that GitHub tends to have been shutting down and hitting API limits and things like that. And that's kind of what we're specifically built to be able to handle.

• 4:57Wes Bos?

  I saw that, like, I think like Jacob, you guys might know him as like as fat. He's the guy that created Bootstrap. He obviously, he founded the company. Is that right? He posted some like stats that blew my mind as to like how many things were recreated. You said thousands a second of these repos are being created?

• 5:20Speaker 02

  I can find his tweet, but yeah, I think at our peak, we were, do you remember Amadeus? I should have looked this up beforehand, but.

• 5:28Speaker 03

  I believe it was something around 15,000 repo creates per minute, if I remember correctly.

• 5:34Speaker 02

  Yeah, there you go. Yeah, that is correct. Yeah. Last week we had a sustained peak of 15,000 repos per minute for three hours. So.

• 5:42Wes Bos?

  That is insane, absolutely insane. So obviously there's a need for both better infrastructure as well as like better primitives for this type of thing. The, the diff in the tree thing, let's, let's talk about that, like, explain what they are and then let's dig into like how you made them so fast.

• 6:01Speaker 02

  Sure. They are essentially the ideas that we had from the original version of the Pierre kind of GitHub competitor that, that we worked on for a long time. And we learned a lot there. And, you know, when it comes down to like reviewing code and looking at code, those are the kind of two base elements. You might also like start to want to edit things or preview things. And you can imagine that, that, that might be things that we could work on in the future. But, but that's the fundamental view of, of reviewing code. And we thought that. In this new world, because of the way that code tends to be generated without a human in the loop a lot of the time, that we needed to break these things apart.

• 6:46Speaker 02

  And so, Diffs and Trees are primitives that we make. They're web component wrapped vanilla JavaScript kind of things. And so, they can integrate with anyone using any kind of framework. And they are highly used already. So, I think Diffs is in Codex Desktop and Claude Desktop and across, I don't know, every... If you're seeing Diffs in a web browser anywhere in the last few months, it's kind of the cool thing to be using at the moment. And then Trees is much newer. I think it's almost a month old at this point. But actually, Codex Desktop had been beta-ing it.

• 7:28Speaker 02

  So, it's been in Codex Desktop for a while in the preview versions, and it's already kind of in a lot of other of these apps as people adopt it.

• 7:38Scott Tolinski?

  Wow. And how did they find it? Was it just from word of mouth?

• 7:42Speaker 02

  Yeah, I mean, I think... Yeah, like Jacob and I have a long history with a lot of JavaScript front-end people. And I think these are... I don't want to take credit for it. Jacob has good connections there. But also, like, I think we built it for their specific use cases. And I think that that's why a lot of that adoption occurred, was that like, they were like, "Hey, we can't use Pierre, your GitHub thing, but we'd love to... It looks really great, and we'd love to use it. And we actually need all the parts, but we can't like move everyone on to this product that you have." And so, it kind of came naturally.

• 8:16Wes Bos?

  And why... Like, maybe I can explain to this. Like, why is GitHub's UI so laggy? Or like, why do you need a highly performant nested tree of being able to open up folders? Or why do you need a highly performant way to display highlighted text? Like, why is that even slow on the web?

• 8:36Speaker 03

  I can talk a little bit about the diff side of it. Because that's where I have most of my experience. It's a couple of things. I think, you know... We live in a world now where I think a lot of people tend to use React. And I have sort of a, personally, I have a bit of a love-hate relationship with React. I think it's amazing for certain things. But when you think about something like code, it's very much, it's tons and tons of element. You know, when you think about syntax highlighted code, you have all these like little tokens and all these like little things. Lots of spans. Exactly. And then on top of that, you know, it's very easy for you to have maybe a couple thousand line file, which is not insanely big, but it's something that you can, that obviously if you just sort of were to run that through React, for example, it's going to have to create a virtual DOM of that entire thing.

• 9:20Speaker 03

  And so you're sort of putting a lot of additional pressure and a lot of additional work on something that inherently, in many ways, is usually static text, right? It's just, it's just there on the screen and it's probably not going to be updated very frequently. And so a lot of, for me, a lot of the kind of architecture initially with Diffs is like browsers are really good at parsing text and creating, you know, taking HTML, taking CSS and rendering something. And so a big goal of the library was like, well, let's, let's kind of lean into like what a browser is good at. And so that's kind of where sort of the initial version of kind of Diffs came from. You know, we have some pretty good primitive libraries like Shiki and so forth that like do a great job syntax highlighting,

• 10:02Speaker 03

  giving us back sort of an AST and then blending that to HTML. And that also gives you power of, or gives you the kind of power to say that we can use this library in different contexts, whether it's React, whether it's Vue, whether it's vanilla JavaScript. I think open code is solid JS, I believe. So, you know, there, and we don't have technically any solid JS components, but because we, the foundations are just vanilla JS and then the wrappers for like React are basically just these thin, light, use layout effect wrappers that kind of blit out to an element. It sort of enables us to, you know, push towards what a browser is good at. And instead of like trying to, to create these like

• 10:44Speaker 03

  12 levels of abstraction on top of rendering text, basically.

• 10:48Wes Bos?

  And like, how does it work? I'm curious about that idea. Is it a virtual DOM? Is it virtual? Like, I tried to scroll as fast as I possibly could with my like, like rice-out mouse here. And I couldn't, I couldn't make it like, like lag. Like, how are you doing that? That's like, I remember that, like, every UUID website where you could scroll and see every UUID. That was amazing to me.

• 11:12Speaker 03

  So that's actually, I'm kind of glad you brought that up because in some ways I was a little bit inspired by that website.

• 11:17Wes Bos?

  Okay.

• 11:18Speaker 03

  I actually really liked what they did and I kind of studied a little bit of sort of what they did. And what they ultimately did, I think, is clever in that, obviously, it's virtualized. I mean, if you go to, if you like were to inspect this or view, or not view source, bring up the dev tools in the Diffs hub, you would see essentially that we're basically doing per-line virtualization of everything. And so we only have like a little bit of a window above and below. But there's a couple of pieces there through my experience of working through this problem, which was essentially your scrolling interaction that you have. I really wanted to maintain native scroll. So the UUID site, for example, they've basically completely abstracted away the concept of a scroll.

• 12:01Speaker 03

  Part of that is because they were saying, oh, the height of this view would be so tall that it couldn't render in a browser, which is also something that our web, Diffs hub, also works around, but in a different way. And so what they've basically done is, I have the feeling they probably run some invisible scrollable region that they can detect your scroll physics from your browser and then just sort of use that to do kind of line-by-line, kind of basically virtualization. And so, yes, it won't blank, but if you kind of look closely at that website and, you know, drag the scroll, it's not like smooth scrolling. It's just, you know, it's almost like an Excel spreadsheet. It's just jumping line by line. I wanted to obviously not do that with code. And so there was, when you have a scroll, this kind of starts to get a little technical, but when you have, you know, browser scrolling, for example.

• 12:46Speaker 03

  It's computed on a different layer than your JavaScript DOM. They kind of put that in sort of a composited GPU accelerated layer. That's why it feels so smooth in like 120 FPS or whatever. The problem with that is if you scroll fast enough, your JavaScript inherently might not be able to keep up. And that's technically a problem we even have with the GitHub and the code view components that we sort of use to power this experience. However, I kind of had this epiphany when I was working through this problem of, you know, I didn't want to, I still wanted to use a kind of a normal browser scrollable region, so you can drag a scroll bar around and all that stuff. But at the same time, I wanted to make it impossible to blank.

• 13:27Speaker 03

  And I kind of had this epiphany as I was going through it of like, you know, you can use sort of state, like people often use sticky component, sticky positioning. It's a CSS thing where like, you know, as you scroll something out of view, it sticks it to the top, right? People usually use it in that sort of normal way, which is like, oh, I get to the top and then it keeps it in view. I realized if you, you can actually sort of invert that a little bit. If you use like negative sticky positions, you can also create the sort of inverted sticky container. So the code is like held in this like rectangle. And when you get to the bottom of it, then it becomes sticky. Or when you get to the top of it, it becomes sticky. And so basically this means that like, even if the JavaScript can't keep up, which it can't always keep up in certain situations

• 14:07Speaker 03

  because your computer could be doing something or, you know, just rendering, blitting out a whole new set of code lines or whatever. Yeah. This sticky positioning basically never allows it to blank. And so you can, like if you, I think in macOS, if you like hold Option or Command or something and click somewhere on the scroll region, it'll like jump to that location, right? Instantly, instead of like, you know, smooth scrolling you there. And if you did it with the GitHub example site, you'd see that basically that effect would basically be taking over. So even if the scroll view, which is accelerated on the GPU layer and running faster than than your JavaScript can keep up with, you might just see like a frame that's like out of date for half a second. And then it'll like render the correct frame.

• 14:47Speaker 03

  And so these kind of like clever tricks around, you know, how do you make it so that it never blanks on you? And then also be able to virtualize. At the same time, it was kind of a fun experience. And then on top of that, uh, well, yeah, so I think that's probably a good sort of explanation.

• 15:03Wes Bos?

  Yeah.

• 15:04Scott Tolinski?

  Virtualization is one of those things that we talk about on the show that still feels a little mysterious to us sometimes. I think one of the big like user experience issues with virtualization that we all see is that it breaks in page find. Is that something you all had to work around when using virtualized lists?

• 15:20Speaker 02

  Yeah, I mean, we, uh, we don't support, uh, in page find. We support like a key command for you to implement it. But if you were to try to do any like, well, I guess maybe, uh, to step back is, is if you try to do in page find on the size of diff that, um, was breaking GitHub, the browser would crash. The browser wouldn't, wouldn't be able to do it either. And so at the scale of the pages that we were trying to render, there's no world in which, uh, the browser, but especially not you in the main thread, uh, can do, uh, fast finds. And so we haven't really tackled that, uh, in earnest. But I think it's going to come down to some combination of at some scale, you can move it off, uh, the main

• 16:05Speaker 02

  thread to a worker. Uh, and so I have some stuff in a, in a, in a work tree somewhere, uh, in, in trying to like get some indexes and do a worker kind of base thing. But you know, you're, you're like covering up the, the native one and everyone hates that. And maybe, you know, you'd let them hit it twice and then the real one should, I don't know. There's all sorts of opinions there. There's just really no good solutions as the browser can't do it, uh, either, right? And so the other thing for like trees is I need to, there are, uh, like, if you're rendering a tree and you start searching, you need to be able to jump between the matches with up and down arrows. And we actually like hide and collapse the various bits of the tree. So like, so all sorts of rendering things that are happening at the same time, uh, when you're doing that filter.

• 16:47Speaker 02

  And so, I don't know, I, I'm sad that it doesn't work, but I don't know if there's like, I don't know if there's a world in which it can work without going to the server or, or doing something like that.

• 16:59Wes Bos?

  Whenever we talk about this, like virtualization or any, anyone brings it up, like the question that always comes up is like, why can't the browser just do this for us? Or like, isn't that what content visibility was supposed to be for in CSS? Like, can't the browser figure this out as to what it should be painting?

• 17:16Speaker 03

  So I can somewhat answer that. One of the things that like, one of the things you can actually, it's buried on the Diffs Hub website right now, but if you open up one of the expansion things and you click, it's like about 1 million line diffs. We, one of the examples that we show is a diff between Linux version 6 and Linux version 7. That does take a while to fetch that diff content from GitHub. GitHub will basically, you'll basically have to wait like 12 or 15 seconds just to even start getting bytes back from that. But once it's rendered, it's basically then streams the rest of it in. That content is larger than the scroll, a scroll view would allow in a browser. I think, different browsers have different. So there's a max.

• 17:56Speaker 03

  Yeah. So like, and it's like, it's like, I think in Chrome, it's like 16 or 32 million pixels or something. And, you know, which is a lot, but like, if you think about, you know, you have 8 million lines of code and each line is 24 pixels tall, like, your math just doesn't add up. So, so there are like, you know, there are like certain limitations. I think if you try to, even if you, even if you had content visibility none and you were to try to inject that amount of content, I mean, that's 100, I think that patch file is like 150 megabyte patch file. So you can kind of see like, there are limits to what a browser can like to do. And so like, I think in certain sense, a lot of the goal,

• 18:38Speaker 03

  so maybe to take a step back with, with the Diffs Hub website, is that it's really a marketing piece for us for this new component that we're launching with Diffs called Code View. And the idea of Code View is that, you know, especially with AI workflows and stuff today, it's very easy for an agent to come back with, you know, 10,000 lines of changes or something, right? And yes, you know, maybe not going to review all of that, but if you have a service where you do need to render it, the last thing we want anyone to, like, at least the goal of this component is that you shouldn't have to think about that. You just be like, oh, here's all the content, figure out how to render it. I don't, you know, you literally give us an array of kind of these data structures that are the diffs or the file or whatever. And then we just say, okay, cool. Doesn't matter. As long as it fits in the JavaScript memory, like, we will be able to render it,

• 19:23Speaker 03

  basically. And so there's a lot of stuff that goes into like, how do you make sure that that renders efficiently and quickly? And obviously, we talked about. Virtualization is one piece. There's also a lot of stuff around like, you know, how we we actually syntax highlight off the main thread as well because because you know, you could have a file that's, you know, 10,000 lines of code and a syntax highlighter might, even if it's fast, might take 100 milliseconds and that's enough to like jank you for a frame or something, right? So we throw that off to a to a worker thread, let it do that work, come back. And so we kind of do this thing where progressively we render plain text right away. And then if if we get, most of the time, the worker is so fast that you almost don't even notice that it flickers or, you know, if you're aggressively scrolling and it's some part of it's out of view, by the time it gets into view, it'll already be syntax highlighted. So you won't notice that.

• 20:07Speaker 03

  So there's a lot of that kind of stuff that we have to think about.

• 20:10Speaker 02

  And I'd add, I'd add, well, A, the browser has to hold the entire DOM even like the will change thing is just for the render layers, but the DOM itself is going to explode memory like, and that that's separate from the rendering, right? And so will change only solves the tip of that iceberg and it would still crash it in every other respect. But if you think about like the complexity of like, like this is actually somewhat much more static than or less interactive, like even though it's actually more active in like a single comment becomes very interactive, but the the lines themselves don't really change or like collapse or whatever, the full blocks do.

• 20:51Speaker 02

  But trees is interesting because if I were to, I need, I need a data structure that matches the trees like structure, the structure of the actual, you know, this is a child of this is a child of this. Just to compute that fully is is something that would like jank your browser for like, I don't know, I think the demo we we put out in a in a video was was the Android open source AOSP Android open source project. So I think it's like just the files themselves, there are 1.5 million files. And you can kind of like jank free scroll through all 1.5 million files.

• 21:30Speaker 02

  And if you were to actually generate the DOM for that, it would it would take like 30 seconds or something like I'm. Through every thread of the entire project, virtualization is considered. So like, I'm not even computing data structures, or computing names of things, or anything if you can't see it. And if you were to switch to CSS, just will change it. You would have to have generated all of that and computed all of that. And it would instantly ruin your ability to do things quickly. And so I think in both cases, threading virtualization down to the like the smallest sections that we can means that we're doing a lot less computations. Like, don't do work if the user can't see it.

• 22:13Scott Tolinski?

  Yeah, and that makes so much sense. I mean, these are the lessons that, what, it feels like video game developers have known for a billion years at this point. It is so funny, I was recently watching some stream where somebody was writing a brand new Nintendo 64 game. And the graphics on it looked outrageous. And his whole thing was, here's how I'm doing virtualization of every single step of this thing. And this is like the limits that you can push, you know, that type of hardware. And it feels like on the web, those types of lessons are just ignored completely sometimes.

• 22:49Speaker 02

  Those are cool demos, like whenever someone can see, you know, like the pillar. And then if you like move the camera from the player's view, you can see that they're not drawing anything behind the pillar because the user can't see it at that exact moment. And it gets pretty Ray Tracy fast.

• 23:06Wes Bos?

  How do you figure out what is supposed to be shown on the screen? Do you like, like, I know you can get the height and like figure out how high text is. But also, I'm thinking of all this Cheng Lao's pretext library as well, where he did a lot of work in figuring out how big is text? Is that a hard problem to figure out?

• 23:24Speaker 02

  Yeah, I think, Amadeus, you should talk about wrapping here in a second, because I think that's hard on the diff sides. But I actually, like, the week before pretext came out, came out with this really cool, like, novel solution in CSS in order to like know when text is overflowing, in order to get like truncation to work. And then just got absolutely, we, Jacob said I got overflow-mogged by a...

• 23:51Speaker 02

  By Chenglu, and that's true. So, but the one hard rule for both trees and diffs is that we need to support SSR. And so pretext is super interesting, and I'm sure we'll probably end up using it at some point, but we currently don't because it's not really great in an SSR situation. And all of our stuff is like rendered immediately and hydrated. So even that first render is a virtualized kind of like SSR render. So on immediate page, though, if you go to trees.software or or diffs.com, you can see that like it works without JavaScript. You know, it's obviously not interactive, but but that that means that we can't do some of those text rendering stuff.

• 24:34Speaker 02

  For trees, though, my lines are are non wrapping and always the same height. And so I really only have to figure out whether I need like a middle truncation or fruncation or any of those types of things. And I have a lot to say on that, but I think Amadeus has a lot of stuff with line wrapping that was difficult.

• 24:55Speaker 03

  Yeah, I think with this, it's a sort of an interesting problem, too, because some of it, like the pretext stuff is also pretty amazing and a pretty rad technology, although it's a little bit like if it's in a perfect world, it's great. But if you think about the problem with diff, let's just take the Linux example. You have 150 megabyte diff file that has, you know, eight million lines of code. If I wanted to iterate, if I just wanted to run a JavaScript loop over, you know, eight million, that's going to take significant time. So I can't necessarily just be like, oh, I'm going to count each line and then whatever math it, you kind of have, I had to have to work like start with like a really fast estimation. And so the nice thing about diffs is you kind of have this idea of hunks, which are

• 25:39Speaker 03

  basically like, you know, the the context blocks.

• 25:42Wes Bos?

  That's my nickname in high school. I know all about it. Yeah.

• 25:45Speaker 03

  Perfect.

• 25:47Speaker 03

  And so that's already kind of a little bit of a simplification and then you can just math that. You can say like, oh, the hunk has 10 lines or whatever, 10 times 24 or whatever gives you the approximate height, the estimated height, regardless of whether you have wrapping enabled or not, right? And so it builds up that numeric abstraction as fast as possible. I call it like basically the estimated height. And then when I actually have to render it, then I can go back and let's say I'm rendering in your window 30 lines and 10 of them are visible and the other 20 are not. Then after I render that chunk of lines, then I can actually go through and say, hey, do these measured lines match up with the estimation? And so most of the time it does because they don't wrap. So it's just like, it's basically like a quick check.

• 26:32Speaker 03

  But if they do, then I can just measure the new height and then hold on, like cache that calculation basically. So in the future I have it. And then on top of that, we then have to potentially scroll fix. So we might jump to a location and we're supposed to show a certain line, but the line above it wrapped. And so to push it down, we can obviously correct that before you actually, as a user, you see it. So the whole thing is this sort of progressive calculation. You only calculate what you actually need and then obviously adjust and fix as you continue.

• 27:03Wes Bos?

  And you never have any of those obnoxious little, well, I'm sure maybe you have. It's like a noxious little, oh, it would, it jumped the scroll like 20 pixels or one pixel up, you know? Was there any issues with that?

• 27:16Speaker 03

  So I spent a lot of time, like actually like one of the fun things you can do with the DisHub website right now is there's a little play button on it that says like go Burt or whatever. And if you click that, it'll like scroll really fast. And then I think while it's scrolling, if you open up the little tools, you can kind of switch between like kind of side by side, the split view or the unified diff view and it should just keep scrolling. Or if you do kind of do that while it's like fling scrolling or whatever, like it should scroll fix automatically during that. So yeah, it should be pretty robust. If there are bugs, let me know, but I feel pretty confident that it's in a good spot. So yeah, like that was an example of like one area, right? When you switch between like, if you have a massive diff and you're scrolled halfway down and you switch from like split to unified, you're actually jumping a massive scroll range.

• 28:00Speaker 03

  So you kind of have to do this thing where you almost like, you kind of have to throw away all your cache calculations because we're saying, okay, now we don't know what it's going to be. We have to estimate where we're going to render. We have to render that chunk and then we have to like, obviously immediately correct if there's something wrong and like, keep an anchor point, which is essentially the first visible item that you can see, the first fully visible line becomes like your anchor point. And then just use that as kind of a relative measurement to make sure that we're still in the same spot.

• 28:24Wes Bos?

  Man, even, I just did a flick scroll, or what do you call it, fling scroll? And then I resized the page and zoomed in and out while it was zoom flick scrolling and it still worked. That's like, what tools do you use to? I was just gonna ask that. You got something? Yeah.

• 28:42Scott Tolinski?

  No, that was the exact question. What tools do you use? Are you, are you guys just like great at reading flame graphs? Like, what is the stack here?

• 28:49Speaker 03

  I guess, well, I'm honestly, I'm a, I'm kind of, I feel like I'm this weird guy of like, I use Neo Vim and I'm a completely terminal pilled for everything that I do. So I don't use any desktop apps. I use OpenCode2e for a lot of stuff. AI has obviously helped me with a lot of stuff, but I use it for a lot of like prototype, rapid prototyping and getting stuff like working.

• 29:09Speaker 03

  One thing, Alex is going to have a lot of amazing stuff to do with this. I've done like the baby version of it, which is like, I might have this hypothesis around like, oh, this could help performance with something. And then I'll have the AI sort of like rapidly prototype that and then it'll run its, like have it run some specific benchmarks and that, you know, actually it'll pull into like the Chrome Dev Tool graphs or whatever and figure out like if this is actually more performant or not. It's been a great feedback loop to make sure that like what I'm doing is good. And then I had this other thing, we had this one, like we have, one of our components in the Diffs library is called the merge, or it's unresolved file. It's basically like, if you have a merge conflict, you can render that file and then you can also like choose to accept both or one or the other kind of thing, like you would with a conflict.

• 29:53Speaker 03

  And so I had this parser that would like, and I kind of created this like 20,000 line file that had like, you know, thousands of conflicts in it, like just a garbage file or whatever. And then I ran it through my parser because it has to create a data structure so I can render from it. And my initial thing on that 20,000 line file was, it was fast. It was like 20 milliseconds, but to me that was still like not great. And so I just kind of like, But I had a bunch of tests for like what the output of that should be. So basically, I just like gave, I think it was like Codex, whatever. I was like, hey, currently, when you run this function over this file, it takes 20 milliseconds or whatever. Can you just like go to town, make sure it passes the tests that I have written for it and just see if you can get it faster? And I let it run for like an hour and it got it down to like 0.5 milliseconds or something like that. And so it was just like, perfect.

• 30:38Speaker 03

  And I, I've sort of just accepted that like, I don't understand how this file works. If I have tests for it, I'm just gonna leave, like, I just put at the top, it's almost like it's an auto-generated file. Like, if you need to fix a bug, create a test that fails and then just like, give it to the AI and just have it figure it out. And, you know, that's, there's, there's a certain level of certain stuff like that, you just kind of give up. But a lot of the other diffs code is not like that. I have used AI quite a bit to like reinforce things or check things or help me with stuff. But, uh, yeah.

• 31:05Speaker 02

  Yeah, I, I think, uh, to half-answer the question and then I'll answer it the whole way. I think one of the reasons why this is great is that, like, Pierre, as a company, has dedicated like a full-time human designer and a full-time human, like, senior engineer to work on a single, like, trees or just diffs for, uh, for like, I don't know, how long have you been working on it? Like, five, five months or something like that? I think three, three months for me on tree, four months for me on tree. And, and that's it. That's, I mean, like, obviously, supporting the rest of the company and doing a lot of stuff for a small startup, um, when it comes to headcount.

• 31:45Speaker 02

  But the, like, attention that, even at, when I was at Stripe for, for 10 years, no one ever spent three months on a, on a sidebar, right? Like, that, that's the, like, that's part of this much bigger project you have much less time to do. And so I think that, like, a lot of it comes from just like, man, there still is value and there's still a lot to be gained by, like, really focusing on, like, narrowing down into, like, better, you know, high-touch, high-quality things. And then there's a lot of, uh, user experience to be gained there. And I think that's why it's great versus the tooling. Um, it's kind of the, the, the... The spirit that that is is is the value there.

• 32:28Speaker 02

  But tools too, or go ahead.

• 32:32Wes Bos?

  No, go ahead. I'm saying, yeah.

• 32:34Speaker 02

  Oh, yeah.

• 32:39Speaker 02

  But the the tools that I use, I got really deep into this. The closer the deadline for the trees launch got, the better I got at AI. And performance testing and things like that is kind of this like asymptotic fever dream. And I really, I really found this rhythm with using my, you know, personal experience in order to figure out where the hot paths are. But even using AI to be like, hey, tell me where the hot path is. And then really making sure I could pull that hot path out into like a very like self

• 33:19Speaker 02

  standing, you know, pure function of some sort. And so a lot of my function shapes are are not necessarily normal or not how I write them if I was just trying to eyeball it. But it's something that I can test over and over and over again and feed back into a loop. And I think that you'll see this more and more as the AI era gets gets bigger is just like having these, these really like crisp, single use functions that you can throw into a loop. But then I would throw that into a Chrome profiler. And I had an AI write some stuff to generate all the different stats that I wanted out of the Chrome file. The top, you know, I, I, what I did is I profiled something myself. And I was like, what do I actually pay attention to?

• 34:04Speaker 02

  I want the bottom up stuff up top. I want, I want to look at like highest called functions, time in the function, like function iterations and things like that. And I actually, I chip it in the code is with phases inside of the code. It does, it, it cost me like one millisecond on render or something like that. And so I also get like the phase breakdown of like, this is like the ingestion phase. And then this is the building, the data structure phase, and then I can pipe that. And so I get this really kind of like high signal bit of data outside of a render. And then I have it. Have scenarios, the various things I want fast. It's really easy to like make render performance your biggest thing, but like scroll performance is another one.

• 34:48Speaker 02

  Or in the case of trees, it's like when I collapse something or when I delete a file, I don't want to have to rebuild the entire tree. And so I need to do all these various different actions on the trees and then have each of those as a scenario. And then I throw that into PyAutoResearch. And so I say, hey, here is this scenario. Here is like out of the Chrome profiler, here's the memory usage, here's this, here the like, I'm happy to trade memory up until this point. I, you know, get this as close to zero as possible. And then you have tests. And so it goes to each of the actions. Usually you do one action at a time, but I might have four running at the same time.

• 35:27Speaker 02

  And, and that has shown an incredible ability to take something that, I think at first we tried to, we tried to load Linux Linux into my first iteration of the file tree, which is like, I don't know, it was 93,000 files and it was like pretty, it was five, it took 500 milliseconds. And I was like, man, there's no way this could get faster. We're just like at the edge of where computers can even do it, you know? And then I think a month later I could do the 1.5 million Android stuff and it's, I don't know, something like 350 milliseconds or something. Wow. So like orders of magnitude faster. And I bet there's still a lot to be gained.

• 36:11Speaker 02

  And every click is, you know, a single frame, every like each one of those things I was able to put into PyAutoResearch and just the dopamine hit that you get from it is enough to like power you through. And I just like, it's just me sending screenshots of my AI. It's like, oh, it's five times faster now. It's 10 times faster now. And I try to bust the other.

• 36:32Scott Tolinski?

  You had luck with AutoResearch. Was that a skill you had to develop? Was there any learning period there? Cause I have heard both people having a lot of success with it and people not having success with it.

• 36:46Speaker 02

  Yeah, I have two notes there. One is that it does take. The thing that you need to learn is really how to give it like the right amount of data in order to like be able to evaluate its work well. You can't just say make this faster because then it'll be usually confounded with a bunch of other things. Second is like to make it be able to iterate very fast. So if you give it something that takes a 10 minute, you know, a 10 second test, or it takes 10 seconds to even boot up the browser and connect to the thing.

• 37:16Wes Bos?

  Yeah.

• 37:16Speaker 02

  The faster you can let it run like 3,000 times, it can get like a statistically significant output. I also use a bunch of the MITATA library. I don't know if you guys have ever used that. It's a benchmarking library. M I T A T A. It's it's used a lot in like benchmarking of like this versus that. And it runs the things until you get a statistically significant difference. And that that really taught me to like, it also handles things like warm up, CPU warmups, and all sorts of things that like cloud all your data. I wouldn't say that's like hyper necessary to get that deep. I just really wanted to nail

• 37:58Speaker 02

  it. But so that's the first thing is like, make sure you're only measuring one thing and you have a really good measurement of it and that measurement runs really fast. And the second is that PyAutoReaderSearch, as far as I can tell, PyAutoResearch is much, much better than like OMX AutoResearch or any of the auto research that I've tried, like an order of magnitude more success from that. And I'm sure someone disagrees with me, but for me, PyAutoResearch is the jam.

• 38:22Wes Bos?

  What models are you using with that?

• 38:24Speaker 02

  I mean, I used it through, I started that on Claude, the first times I was running it, the 5, 5 point, whatever the last two are, and then 5.4 and 5.5 on Codex as well.

• 38:38Wes Bos?

  Yeah. Man, that's fascinating. I love hearing about that. Just.

• 38:43Wes Bos?

  Just figuring out how it, how you can gain speed by just sheer brute forcing, looking at running many, many, like more than a human could possibly ever do.

• 38:52Speaker 02

  Oh, for sure.

• 38:53Wes Bos?

  And like, did you ever dip into like, things like, uh, like a set is faster than an array? Or like, if we use background color on the line versus background color on the span, does that affect performance at all?

• 39:06Speaker 02

  Yeah, so a lot of the, at, you know, 1.5 million items that we're looping over, building a data structure, everything, every counter that you have, um, you get into like, I haven't done a lot of this, but it like reusing elements or reusing, uh, like, like stores is really good, or like sets versus objects and it, uh, it tested all that stuff. And a lot of times you get some pretty good like follow-on gains for each of those. Uh, a lot of, both of ours is not really like render constrained because we're doing such, we, we take such a focus on not rendering too much, that rendering is really quite fast. Um, and so that's less of a concern, uh, though like scroll performance is still can be very difficult.

• 39:50Speaker 02

  But luckily we have Amadeus, who's spent the last 10 years of his life writing infinite scroll videos. If you think about Discord, Amadeus is really just like, been writing the same thing.

• 39:59Wes Bos?

  Did you write the Discord window scroller as well?

• 40:02Speaker 03

  Yeah, uh, well, I rewrote it. I rewrote it probably in 2018 or something like that. I redid messages. The big one was the user. Messages weren't too hard because we'd only show like 50 at a time and stuff like that. But the, the whole thing of like a member list on the sidebar was definitely something that we had to do. It was a, it was actually a cool kind of collaborative front-end, back-end thing. Because yes, you have to render, I mean, the good news is it's like, oh, each member is X pixels tall. So the math is, is very fast to generate. But, um, you know, in the early days, we definitely were, you know, if you were in a chat room with, you know, a million people, we were sending a million user records down, which just wasn't, wasn't effective. And so we built this whole system that could kind of like detect the scroll region

• 40:45Speaker 03

  that you were within in the member list and then request that scroll. But so like even the server would generate like, oh, these elements are in this scroll position. And so then we could basically say, as you'd scroll down the list, we could like fetch. It, it was a blankable list, of course, because of the nature of like, you know, fetching the, needing to fetch the records and stuff like that. And there's probably tuning that could have been done with like being more aggressive about what you fetch. But the idea was very much around like, you know, most people, most people don't scroll that list and most people never see more than. The first 50 people in the list anyway. So like,

• 41:15Wes Bos?

  Yeah.

• 41:16Speaker 03

  You shouldn't have to pay that cost.

• 41:17Wes Bos?

  I love this podcast because we get to talk to people that just go so deep. Like, we had Alex Reardon on. He's the guy that authored React Drag and Drop and Pragmatic Drag and Drop. And like, he's, he's probably spent the last 10 of his 10 years of his life just doing drag and drop. You know, just obsessed with it.

• 41:39Speaker 02

  Sounds like my nightmare.

• 41:42Wes Bos?

  Yeah. Well, that's why I'm happy that like people that do know this stuff can, can go deep on one aspect of it. Cause like, I probably will never have to write a diff library or a tree library now, or a drag and drop. And we just get these awesome like blocks. Let's talk about web components. So obviously it didn't write it in React or anything like that. Part probably partially because of perf, probably partially also because it needs to work with everything. Thoughts on web components? Do you like web components? And what are you doing for state reactivity, things like that?

• 42:17Speaker 02

  We have two different answers here. I actually lied a little bit. We both use web components as a shadow boundary, shadow root boundary. And neither of us are really using primitives past that, you know, we're using adopted styles. She like, we're trying to make sure that this thing doesn't interact poorly with the rest of your webpage. Kind of a third party JavaScript approach to it. But ultimately we're not using, you know, like bound attributes or anything that like, like that. I did, I did initially start trees in, in like lib, or what was it?

• 42:50Wes Bos?

  Lit?

• 42:51Speaker 02

  Yeah, lit, lit element and stuff like that. But it, but it just wasn't right for me. But I lied a little bit. I, I used preact for one layer. Because the hydration of the SSR is my code for hydration for SSR ended up being roughly as big as preact. And I was like, this is silly that I've written like a worse version of this. Like at some certain, at some certain scale, like, but I'm really not using much of preacted. I'm sure I could do that thing that, like, I think. Tanner from Tanstack tried his like, what do they call it? Free, free act or?

• 43:31Wes Bos?

  Yeah.

• 43:31Speaker 02

  Redacted, redacted. Yeah, it was redacted. I think is what they went with. Where they took out everything from React that they didn't need for the, the Tanstack stuff. And that's an interesting idea. I don't think it's necessarily a good one, but it's still pretty interesting. And I'm sure I could also do that for trees because we're using, you know, probably a quarter of it, but it's three kilobytes. It's, it's not, it's not the strain on it. And as soon as you're writing all these checks for your own hydration and you're not even sure if it works as well. And it gets pretty close to three kilobytes. You're like, okay, let's just use preact. So, but that's not the case for, for diffs if Amadeus wants to.

• 44:05Wes Bos?

  Okay. But like, what about like reactivity as well? You delete a file. Are you just manually deleting the node or do you have something that figures out?

• 44:15Speaker 02

  Ultimately, a lot, every action and everything is this like virtualized store. So like I said, like everything in the trees library down to the base data structure understands the visible slice of the tree that you can see. And that store, it obviously doesn't have like an on click handler on it, but all the actions that you might do like collapse, expand or whatever, all happened there. And so like all of the code for the library is like in that kind of idea. And then the actions themselves are kind of just wired through preact. So I do use preact, you know, on click or, or whatever, but then it immediately goes and calls this other stuff. And then that, that thing does need to like, let the, the preact view know that it needs to re-render at that point.

• 45:00Wes Bos?

  Okay.

• 45:00Speaker 02

  But.

• 45:01Speaker 03

  Yeah. And for diffs, it's all pretty much kind of custom. I think inherently each, there's kind of two pieces. There's like the, the, we call the rendering layer, which is essentially like taking like our, our data structures, whether it's a file or whether it's a diff. And then kind of rendering, basically rendering that to an AST that we can then use for, for ultimately the component. And then the component itself is basically just a class. And so it shares a lot of like types of, you know, has like kind of public methods on it like .render, which. We'll then just render it to a container. And so I kind of had to build a little bit of my own sort of for reactive stuff like for the React components essentially, right? That basically just you pass those props in via, you know,

• 45:44Speaker 03

  your props in your component and then it kind of figures out, you know, whether it should call React render or it shouldn't, that kind of thing. And then for the the code view, we wrote some kind of more intense virtualization stuff because we kind of wanted line like per line virtualization. So we only render the lines. We didn't want to think about it as files because you could have a 10,000 line file and we don't want to render it all. And so for that, I sort of built a structure that kind of keeps some does some bookkeeping around what lines are rendered and then, you know, doesn't touch those if it needs to add more lines or clean up lines before or after and stuff like that. And so there's, I guess, in some ways, probably, you know, maybe if I had started with preact or something, maybe I could have simplified that a little bit,

• 46:28Speaker 03

  but there is definitely a level of just like, oh, you just sort of, we mostly just kind of hide it from you.

• 46:35Speaker 02

  I'd add that we use declarative shadow DOM, which was initially pretty difficult to figure out with hydration. I don't know if you've ever used declarative shadow DOM, but it's, you know, it's how to mix SSR with the shadow DOM. Web components typically in the beginning weren't good at SSR, but this allows you to kind of upgrade this injected blah, blah, blah

• 46:58Speaker 02

  component. And so we do use that and that has hydration, like the DOM that eventually exists is different than the HTML you send down, which you always have like hydration warnings and things like that you have to work around. But I'd also add that both of us use slots, like the actual

• 47:18Speaker 02

  web component slots. So I lied that we don't use any of the APIs. So if you want to add in a comment between two lines, or if you want to, like, for instance, the context menu in trees, like if you right click or you hit the context menu button, we didn't want to like, we're not shipping a context menu library, which is its own whole thing. And we don't want your context menu library to be different than the one that that works in your trees. It should be, you know, good. Across your whole app. And so we allow you to inject your context menu into a slot. And then we place that slot into the to the right location. And so that kind of solves for both of those situations. And you have that pass through of the the shadow DOM back into the slot.

• 47:59Speaker 02

  But it's a difficult thing like that took a lot like it took me a month to like really feel like we were solid on like SSR plus DSD plus slots and things like that.

• 48:10Wes Bos?

  Man, I am glad there's people out there that are figure out web components, man. Like we say on this thing a lot, this podcast a lot is like, you don't have to like write your own stuff in web components, but be thankful that people are building primitives in web components. So that we're not building everything in React or everything in Svelte, you know, you can you can reuse them.

• 48:30Speaker 02

  Yeah, it's fun because you can hydrate like if you want, if you're using React and you use diffs, for instance, we you can, you know, pass in a child or it's a render function that has React in it. And that is hydrated, even though the entire thing is SSR, right? And including the comments. And so you kind of get this best of both worlds where you can have hydratable SSR-able children in these slots. And because of the way shadow DOM and slots and web components work, it all kind of just hydrates and is nice. And so there is a lot of benefit and, you know, we have no CSS trouble and all that kind of stuff. It's been it's been really nice, other than trying to figure it all out initially.

• 49:12Wes Bos?

  And like, we didn't even mention this, but like, these are both open source projects. Or how does that work? How do you guys make money?

• 49:21Speaker 02

  Having a company switch from using GitHub or switch from using their AWS account and Git S3 or whatever is a is a big sell. And code storage is a is a B to B product that we sell and make money on. And often

• 49:43Speaker 02

  Much like NextJS is open source for Vercel, and that brings in people into the ecosystem that is well supported on your platform. It's like if you need AI scale Git storage, there's a good chance that you need to render a file tree and a diff. And we're happy to like support you in doing that. And if you want to serve them from a place that can handle many, many orders of magnitude more than you currently can, then we're happy to make money there. But, but also like we just, we'd like to, to build cool things and, and have people work on them and, and share with the community. It's, it's a little bit of everything.

• 50:26Wes Bos?

  Sweet.

• 50:26Speaker 03

  And I think early on too, Jacob had a good insight. We were working on the old Pierre product, which was basically a GitHub competitor at the time. And we weren't really getting a lot of traction. And I remember him coming to me and saying, hey, you know, like I'm looking around the ecosystem right now and I'm seeing, you know, HTML to diff or something, or I forget what it was called. Or, but it was like all these libraries, diff to HTML, there you go. And they were just, they were old school, like not, not to drag them or anything, but they were just libraries that would have been written in 2012 and solved 2012 problems around, you know, diff rendering and like, you know, we have crazy CSS subgrid stuff now. We have crazy color mixing abilities. We have these new fancy client side or server side,

• 51:09Speaker 03

  like Shiki, you know, tokenization libraries. How do we, how do we rethink about this problem in a more modern context? Because I think he also, at the time, he saw Codex before it was like a desktop app. They had like a web app and, you know, their diffs were just kind of not that great. They didn't feel very good. It didn't feel very like smooth or professional or whatever. And he's like, you know, we've sort of solved this with Pierre. Why don't we figure out a way to take what we've solved and like sort of, you know, give it out to other people. And I think it also like gives us the opportunity to work with other companies and kind of learn what their problems are and what their needs are. And then build for that, which is obviously building something for somebody is kind of the best place to be building things, in my opinion, so.

• 51:52Speaker 02

  And if people see us as, as people who care a lot about this problem, then, then maybe they'll trust us with the rest of their business.

• 52:00Wes Bos?

  So you've got trees, you've got diffs. I think the the next clear winner is the text area. Like, are you guys, what's what's next? What other primitives are you working on?

• 52:11Speaker 02

  It depends on if we can get text area.com.

• 52:16Speaker 02

  We did try to build, buy trees.com and it took a long time and we had to like go through this like person who tracks down the people so they'll actually answer and it was way too expensive. They they wanted many millions of dollars for it. So trees.com software it was. But trees.com is not actually that impressive of a website.

• 52:38Wes Bos?

  No, it's not.

• 52:41Scott Tolinski?

  I did check it out. Yeah.

• 52:43Wes Bos?

  Perf is brutal.

• 52:46Speaker 02

  Yeah, it's no McMasters.

• 52:51Speaker 02

  Yeah, I think.

• 52:52Wes Bos?

  We like McMaster on this this podcast. We do not accept that slander.

• 52:56Speaker 02

  No, that was a compliment.

• 52:59Wes Bos?

  Okay, okay, okay.

• 53:01Speaker 02

  I know that this podcast likes McMasters and that's why I brought it up. As a fan. Yeah, the the requests for editing diffs specifically have been by far the highest request because people will throw diffs into their app and then someone will want to make changes and then they have to like switch to a totally different view and that kind of ruins like the context for the user. Now, we do support things like accept and deny, like kind of like cursor shows you like the little buttons for accept it like like. So there are ways to get it, but it's kind of silly like it's easier right now in diffs to add a comment box that prompts an AI to

• 53:44Speaker 02

  update the CSS value from light blue to dark blue or whatever, you know, it's one of those. And so we do have stuff in the works for for editing on diffs, but no promises on when it will release.

• 53:58Scott Tolinski?

  Yeah. So now it's the part of the show where we get into sick picks and shameless plugs. Alex, you've been here before, so you know a bit about bringing a sick pick. Amadeus, sick pick is just something that you're enjoying in life right now. Could be anything physical or digital or whatever, just something you like in life. So Alex, I'll let Amadeus go first. Do you have a sick pick for us?

• 54:20Speaker 03

  Yeah, I would say my keyboard right now. I have like a 40%.

• 54:26Speaker 03

  Custom keyboard. It's by this, there's this like random designer that I met online on a discord is lazy designers and he just makes a lot of like 40%, 30% stock keyboards, which is kind of my jam. And yeah, that was probably my, my current sick pick.

• 54:44Wes Bos?

  The 40% keyboard. So that's, what is that? What are you missing then? You don't have arrow keys or anything?

• 54:50Speaker 02

  Uh, well, the, the, I guess the other thing would be it has everything.

• 54:58Speaker 03

  And what I mean by that is like, everything is like within, every key is like on the home row or within one key of the home row. Basically you just have these layer buttons that like, when I hold this down, for example, now it's like a completely different keyboard.

• 55:11Wes Bos?

  The space bar is just a little guy.

• 55:14Speaker 03

  So yeah, a little space bar in the middle there, layers, whatever. But yeah, you can kind of see it like there's like legends and stuff like I actually have everything like zero through or one through zero numbers are all in the home row. So I can just, you don't have to do some weird contortion to reach for it, that whole thing. So, yeah.

• 55:30Wes Bos?

  And the, the like the A and the, the Q and the Z are all vertically lined up. That wasn't weird to.

• 55:37Speaker 03

  Oh, yeah. Yeah. So it's ortholinear. Uh, yeah, it took me like a week or two to relearn it, but there's also kind of a nice thing because it means that like, and I don't know, maybe my autistic brain or something is like, like if you like, actually look at a shifted keyboard, you'll notice that like certain spacing on certain keys is different. Like if you have to go from like J to Y or something like that is different than like F to T or something like there's like, these like offsets that don't always match. And so you're, so you're kind of, your fingers have to kind of learn something weird. So I just, there's something like the perfection of a perfect grid. Uh, to me it's just, I love it. Uh, it does make typing on a normal keyboard. I kind of can't, I have to look at it and type on it, but.

• 56:14Speaker 02

  Yeah. I, I should add that whenever I go to the office and me and Amadeus are there and we like pair on the couch next to each other. He disables his laptop keyboard and places the ortho 40% on top, just, just to keep it the same. And I just love the dedication.

• 56:31Wes Bos?

  Yeah. You travel with it. That's great.

• 56:35Speaker 02

  It is small.

• 56:36Wes Bos?

  All right, Alex, I really hope you're gonna sick pick something that you've been posting on Instagram, but go ahead.

• 56:41Speaker 02

  What have I been posting on Instagram? Oh.

• 56:42Wes Bos?

  Your flip dots.

• 56:44Speaker 02

  Yeah, I did. I wasn't gonna sick pick my flip dots, but I did spend a few months like building and designing a flip dots display. Maybe I can get you a picture or something you can you can throw up here. But yeah, it's like, you know, like microcontrollers and then, you know, black and white, like magnetically controlled dot can go like 10 FPS. And I needed like some art for the wall and I eventually, but you have to like, they send you like some raw materials and you have to like build all the aluminum and and program it all together and do all the things. So it was it was a big project. It's it now works, but it's not hanging on my wall yet. And then like all the power cables are like loosely screwdrivered like I'm just like cutting.

• 57:25Speaker 02

  I'm cutting IEC cables and just splitting them into places, but I'm sure it won't catch on fire. I was gonna actually originally sick pick Pi Auto Research, but I already talked a lot about that. And then whenever Amadeus was talking about keyboards, I thought maybe I'd sick pick my keyboard, which is the opposite keyboard of Amadeus. It's the Seneca, weighs like eight pounds, has every key, so.

• 57:50Wes Bos?

  Seneca keyboard. Okay, first I Googled it. First thing that came up was the $3,600 keyboard. Is that true?

• 57:58Speaker 02

  Yeah, that's true.

• 57:59Wes Bos?

  Cheaper than the flip dots, I bet. Holy, that's sick.

• 58:03Speaker 02

  The I honestly knew that Amadeus was into keyboards and Amadeus in the channel at work was like, hey, here's this cool keyboard if anyone wants the best keyboard of all time. And so I was like, well, I want to be Amadeus. He's new. I'm gonna get this keyboard and he's gonna get it. We're gonna be keyboard buds. And I got it. And he's like, oh, I don't use keyboards like that. I use these tiny ones.

• 58:26Speaker 02

  So I was so

• 58:26Wes Bos?

  What's so good about it?

• 58:28Speaker 02

  It's heavy. Yeah.

• 58:29Wes Bos?

  Yeah.

• 58:30Speaker 02

  He like designed each of the switches and and it's like kind of a perfectionist on.

• 58:36Wes Bos?

  Bespoke.

• 58:38Speaker 03

  Yeah, the guy Norbauer is pretty famous in the keyboard community is just being like like attention to detail at any cost. He did like a whole, there's a whole post you can find somewhere where he basically like one of the big problems with mechanical keyboards is stabilizers. They kind of rattle. You won't see it on an Apple keyboard, obviously, really, but like if you take a normal mechanical keyboard and you smash that stable, that spacebar, you'll hear a rattle. And so he basically spent probably hundreds of thousands of dollars in R and D to like develop these, basically these custom stabilizers that didn't need to be lubricated, that would basically not not rattle. And it's like, for what reason? Just because he wanted to kind of thing. And that's sort of his ethos on everything.

• 59:15Wes Bos?

  It's just milled from like a block of a huge block of aluminum.

• 59:18Speaker 02

  Again.

• 59:19Wes Bos?

  Oh, that's beautiful.

• 59:20Speaker 02

  Piece of concrete. Yeah, for sure.

• 59:22Speaker 03

  Yeah.

• 59:24Wes Bos?

  Cool. Well, thank you so much for coming on. This was super interesting. Always like catching up and seeing all the crazy ways you're going down. When you launch Text Box, come on back on and we'll or Text Area. We'll have you on. Appreciate it.

• 59:42Speaker 03

  Yeah, thank you so much for having us. It's been great.

• 59:44Speaker 02

  Peace.