Diffs, Trees, and VS Code 2 0

Welcome to Syntax. Today we've got Alex Ston and Amadeas Demarzi. 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, Codeex. Uh they're building essentially they're building the building blocks for um almost what would be like a new VS Code. And it's 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 uh tree, which is basically like if you want to show a diff of code and if you want to show like 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. Oh, there it is. Let me load down. Scroll down a little bit. Ever have you ever tried to resize uh GitHub before? It's like Oh, yeah. Let's just wait here a second while GitHub resizes. Brutal. Yeah. Okay, there we go. So, oh no. Oh no. Oh no. It's I literally I'm not touching anything. For those of you who are just listening on audio, it is mega low FPS. It is mega lag. Taking forever to restructure, re re uh repaint. And look at this. Watch. Watch how fast I can scroll. I have like one of these like Logitech mice where I can scroll super fast. Boom. Boom. Let's see how fast I can go. Scrolling fast and it has much better. I think even for video listeners, uh, video watchers as well, uh, it'll be lower FPS because this is probably what, 30 FPS. 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, um, and a couple other things as well. So, welcome. Thanks. Thank you. I've been seeing your stuff pop up a lot lately and all and seems like all different types of capacity. So, do you want to quick give us an introduction to uh, who you both are and what you do? Sure. Uh, I'm Alex Ston. um mostly JavaScript front-end engineer at Pierre Computer Company and we uh are structured around the idea of uh kind of making code uh developer uh tools for the the next generation of uh I should practice this next generation of you know a AI agent-based uh coding and so we have a a core product called code storage and it's kind of like uh git uh for agents it can handle a mass massive volume. And then Amodus 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 uh or diffs um and some of the other things that we'll have in the future as well. Sick. And Alex uh has been on syntax before back in 2024, February 16th, uh when we were talking about um CSP, XSS, that type of stuff. And Amodus, what's what's your your story? Yeah. Uh, my name's Amadeas Damarti. Uh, 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. Um, 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 Pier. Um and then yeah to kind of echo a little bit about what Alex said uh we you know the primitives team is very much focused on these sort of blocks uh these building blocks for building you know uh viewing code and and sort of uh how AI's uh will generate a lot of code and you need to review that stuff. So yeah. Yeah, it's 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 under everything to a fact that like like you guys came up with like the code.sto which is I know 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. Yeah, that's right. uh the scale that uh code.s storage works at and we do work on uh some of some of that product uh but we uh are are able to facilitate a much larger uh kind of uh scale when it comes to like AI creating thousands and thousands of repos second. Um and that's the type of activity that GitHub tends to uh have been shutting down and hitting API limits and things like that. And that's kind of what we're specifically built to to be able to handle. I saw that like I think like like Jacob, you guys might know him as like as fat. He's the guy that created Bootstrap. Um he he obviously he founded the company. Is that right? Um 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. I can find his tweet. But yeah, I think uh at our peak we were Do you remember Amodus? I should have looked this up beforehand, but I believe it was something around 15,000 repo creates per minute if I remember correctly. There you go. Yeah, that is correct. Yeah, last week we hit a sustained peak of 15,000 repos per minute for 3 hours. Um so that quite a bit. 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 diffs and 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. Sure. Uh they are um 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. uh 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 uh preview things and you can imagine that that that might be things that we could work on in the future but um but that's the the fundamental view of of uh reviewing code and we thought that um in this new world because of the the way that code tends to be generated without a human in the loop a lot of the time that uh that we needed to break these things apart. Um and so diffs and trees are primitives that uh we make uh they're they're web component uh wrapped um vanilla JavaScript kind of things and so they can integrate with anyone using any kind of framework. Um and they are highly used already. Uh so I think diffs is in uh in codeex desktop and claw desktop and across uh I don't know uh every if you're seeing diffs uh in a web browser anywhere in the last few months it's it's kind of the cool thing to be using at the moment and then trees is much newer I think it's uh almost a month old at this point but actually codeex uh desktop uh had been betaing it so it's been in codeex desktop for a while um in the preview versions and it's already kind in a lot of other of these apps um as as people adopt it. Wow. And how did they find it? Were was it just from word of mouth or Yeah, I mean Yeah, like Jacob and I have a long history with a lot of JavaScript frontendy people. Uh and I think these are I don't want to take credit for it. Jacob has uh good connections there, but but also like I think we built it for their specific use cases. And I think that that's why a lot of that uh adoption occurred was that like they were like, "Hey, we we can't use Pierre your GitHub thing, but we'd love to it looks really great and we'd love to use it. 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 came naturally. And why like maybe I can explain to this like why is GitHub's UI so laggy or like 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? I can talk a little bit about the diff side of it um because that's where I have most of my experience. Uh it's a couple things. I think uh 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 lovehate relationship with React. I think it's amazing for certain things. Um but when you think about something like code it's very much uh 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 and you know, who knows how exactly. And then on top of that, you know, it's very easy for you to have maybe a couple thousand line file um which is not insanely big, but it's something that you can uh that obviously if you just sort of were to run that through React, for example, um it's going to have to create a virtual DOM of that entire thing. And so you're sort of putting a lot of uh 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. Um, 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. Um, 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. Um, and so that's kind of where sort of the initial version of kind of diffs came from. Um, you know, we have some pretty good primitive libraries like Shiki and so forth that like do a great job syntax highlighting, giving us back sort of an a blitting that to HTML. Um, and that also gives you power of or gives you the kind of power to say we can use this library in different contexts whether it's React, whether it's Vue, whether it's vanilla JavaScript. Uh, I think open code is uh solidjs I believe. Uh, so you know, and we don't have technically any SolidJS 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. Um, it sort of enables us to uh, you know, push towards what a browser is good at and instead of like trying to to create these like 12 levels of abstraction on top of you know rendering text basically. And like like how does it work? Um, I'm curious about that idea. Is a virtual DOM? Is a virtual like like I tried to scroll as fast as I possibly could with my like like riceed out mouse here and I couldn't I couldn't make it like like lag. Like how how are you doing that? That's like I remember that like every Uyu ID website where you could scroll and and see every UI. That was amazing to me. So that's actually I kind of glad you brought that up cuz in some ways I was a little bit inspired by that website. Okay. Um, I actually really liked what they did and I kind of studied a little bit of of sort of what they did and what they ultimately did I think is um, clever in that obviously it's virtualized. I mean if you go to if you like were to inspect the s or view s or not view source uh, bring up the dev tools um, in the 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. Um but there's a couple pieces there uh through my experience of of working through this problem which was uh essentially your scrolling interaction that you have uh I really wanted to maintain native scroll. So UU the UYU ID site for example uh they basically completely abstract away the concept of a scroll and 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 defub also works around but in a different way. Um, and so what they've bas basically done is I I have the feeling they've 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 if 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. Um, I wanted to obviously not do that with code. Um, and so there was when you have a scroll, this kind starts to get a little technical, but when you have, you know, browser scrolling, for example, uh, it's computed on a different layer than your kind of JavaScript DOM, they kind of put that in sort of a composited GPU accelerated layer. That's why it feels so smooth and 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. Um, and that's technically a problem we even have with the disc hub and the code view components that we sort of use to power this experience. Um, 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. Um, but at the same time, uh, I wanted it to make it impossible to blank. Um, and I kind of had this epiphany as I was going through it of like, you know, you can use sort of stick like people often use sticky compon uh 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. Um, 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 this 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 because your computer could be doing something or you know just rendering blitting out a whole new set of code lines or whatever. Yeah. Um this sticky positioning basically never allows it to blank. And so you can like if you I think in Mac OS 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 and if you did it with the diffub uh 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 uh 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. Um and so these kind of like clever tricks around, you know, how do you make it so that it never blanks on you? Um and then also be able to virtualize at the same time. It was kind of a a fun experience. And then on top of that, uh well, yeah. So I think that's probably a good sort of explanation. Yeah. Yeah, 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 uh in page find. Is that something you all had to to work around when using virtualized lists? Yeah, I mean we uh we don't support uh in page find. Um, 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. Uh the browser wouldn't wouldn't be able to do it either. And so at the scale of the pages that we are 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. Um but I think it's going to come down to some combination of at some scale you can move it off uh the main 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 based thing, but you know, you're you're like covering up the the the native one and everyone hates that and and maybe you know, you 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. It's the browser can't do it uh either, right? Um, and so the other thing for like trees is I need to there are uh like if you're rendering the 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 there's all sorts of rendering things that are happening at the same time uh when you're doing that filter. 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 it can work without going to the server or or doing something like that. 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? So I can somewhat answer that. Uh one of the things that like one of the things you can actually I we it's buried on the diffub website right now but if you open up one of the expansion things and you click uh it's like about 1 million line diffs. We one of the examples that we show is is a diff between Linux version 6 and Linux version 7. Um 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. Um that content is larger than the scroll view a scroll view would allow uh in a browser. I think different browsers have different uh max. Yeah. So it's like and it's like it's like I think in Chrome it's like 16 or 32 million pixels or something. 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, um, 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'sund 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 in certain sense a lot of the goal so maybe to take a step back with with the diffsub website is that it's really a marketing piece for us for this new component that we're launching with diffs called code view. Um and the idea of code view is that um you know especially with AI workflows and stuff today it's very easy for to an agent to come back with you know 10,000 lines of changes or something right and yes you're maybe not going to review all of that but if you have a service where you do need to render it um 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 render 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." Um, as long as it fits in the JavaScript memory, like we we'll be able to render it basically. Um, 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 as one piece. Um 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 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, yeah, you won't notice that. Um, so there's a lot of that kind of stuff that we have to think about. Oh, man. And I'd add I'd add uh 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 uh is going to explode memory. Uh like and that that's separate from the the rendering, right? And so will change only solves the 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 it's actually more active in like a single comment becomes very interactive but the the lines themselves uh don't really change uh or like collapse or whatever the full blocks do. But trees is interesting because if I were to I need I need a data structure that matches the trees uh like structure the structure of the actual you know this is a child of this is a child of this um just to compute that fully um 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 is uh 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. Um and you can kind of like jank free scroll through all 1.5 million files. Uh and uh 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. Um and if you were to switch to CSS uh 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 to do things quickly. And so I think in both cases threading virtualization down to like the smallest sections that we can um means that we're doing a lot less computations. Like don't do work if if the user can't see it. 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 I was recently watching some stream where some 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. Those are cool demos like whenever someone can see, you know, like the the pillar and then if you like move the camera from the 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. And how do you figure out what is supposed to be shown on the screen? do like like I know you can get the height and like you figure out how high text is. Um but also I'm thinking of all this uh Cheng Lao's pretext library as well where he did a lot of work in figuring out how big is text. Is is that a hard problem to figure out? Yeah. Uh I think Amaz uh wrapping here in a second uh because I think that's hard on the diff sides. But I I actually like the week before pretext came out came up 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 uh we we Jacob said I got overflow mogged by uh by chang uh and that's true. So, um, but the one hard, uh, uh, rule for both trees and diffs, uh, 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, uh, in an SSR, uh, situation. And all of our stuff is like rendered immediately and hydrated. So, even that first render is a virtualized uh, kind of like SSR render. Um, so on on immediate page load, if you go to trees.software software or um or disc.com. You can see that like it works without JavaScript. You know, it's obviously not interactive, but um but that that means that we can't do some of those text rendering stuff. For trees though, uh my lines are are uh non-wrapping and uh always the same height. And so I really only have to figure out whether I need like uh middle truncation or francation or any of those types of things. Um, and I have a lot to say on that, but I think Amadeus has a lot of uh stuff with line wrapping that was difficult. Yeah, I think with disc sort of an interesting problem, too, because some of it like the the pre-tex stuff is also pretty amazing and a pretty rad technology. Although it's a little bit like if it 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, 8 million lines of code. Um, if I wanted to iterate, if I just wanted to run a JavaScript loop over, you know, 8 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. Um, you kind of have I kind of have to work like start with like a really fast estimation. Um, and so the nice thing about diffs is you kind of have uh this idea of hunks, uh, which are basically like, you know, the the context blocks. Um, that was my nickname in high school. I know all about it. Yeah. Perfect. Um, and so like that's already kind of a little bit of a simplification and then you can just, you know, 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? Um, and so it builds up that sort of that numeric abstraction, you know, as fast as possible. I call it like basically the estimated height. And then when you actually render when I actually have to render it, then I can go back and let's say I'm rendering in your window, you know, 30 lines and and 10 of them are visible and the other 20 are not. Um, then after I render like 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, you know, check. But if they do, then I can just measure the the new height and then hold on like cache that calculation basically. So in the future um 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 it would push it down. Um we can obviously correct that before you you actually you know as a user you see it. So the whole thing is this sort of progressive calculation. You only calculate what you actually need. Um and and then obviously adjust and fix going as you continue. So, and you you never have any of those obnoxious little Well, I'm sure maybe you maybe you have is like obnoxious little, oh, it it it would it jumped the scroll like 20 pixels or one pixel up, you know? Was there any issues with that? So, I spent a lot of time like actually like one of the fun things you can do with the Dish Hub website right now is there's a little play button on it that says like go BERT or whatever and if you click that it'll like scroll it really fast. Um, and then I think while it's scrolling, if you open up the little tools, you can kind of switch between like uh 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. Um, so yeah, it should be pretty robust. If there are bugs, let me know. But I I feel pretty confident that it's in a good spot. So, 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. 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. Um and then just use that as kind of a relative measurement to make sure that we're still in the same spot. Man, even I just did a flick scroll or what do you call 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 a like what tools do you use to I was just ask you got something. Yeah. No, that was the exact question. I was what tools do you use? Are you are you guys just like great at reading flame graphs? Like what is the the stack here? Um I can say well I'm honestly I'm a I'm kind of I feel like I'm this weird guy of like I use Neoim and I'm a completely terminal build for everything that I do. So I don't use any desktop apps. Um I use Open Code Tuy for a lot of stuff. Um, 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. Um, one thing and I Alex is gonna 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 it like have it run some specific benchmarks and 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. Um that's been a great feed feedback loop to make sure that like what I'm doing is good. Um, and then I had this other thing. Uh, we have 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. Um, and so I had this parser that would like and I kind of created this like 20,000line 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 bunch of tests for like what the output of that should be. So basically I just like gave I think it was like codecs 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. 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 going to leave like I just put at the top. It's almost like it's an autogenerated 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. Um 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 the other diff 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. Yeah. I I think uh to half answer the question and then I'll answer it the whole way. I I think one of the reasons why this is great is that like uh 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 exper 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 months for me on tree four months for me on tree 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 but the like attention that even at when I was at Stripe for for 10 years no one ever spent 3 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 going down into like better, you know, high touch, high quality uh things. And there's a lot of uh 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 uh is is is the value there. Um but tools too. Uh or Go ahead. No, go ahead. I'm I'm saying yeah. Oh, yeah. Yeah. Uh um 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 uh and performance testing and things like that. It's kind of this like asmtoic uh uh 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 uh standing, you know, pure function of some sort. Um, and so a lot of my function shapes are are not necessarily normal or not how I would 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 and feed back into a loop. And I think that you'll see this more and more as the the AI era gets uh gets bigger is just like having these these really like crisp uh singleuse functions that you can throw into a loop. But then I would throw that into um a Chrome profiler um and I had an AI write some stuff to generate all the different stats that I wanted out of the Chrome profile top, you know, I I what I did is I profiled something myself and I was like, what do I actually pay attention to? I want the bottom up uh 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 ship it in the code is with phases um inside of the code. it does it it cost me like 1 millisecond on render or something like that. And so um 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 uh kind of like high signal bit of uh data outside of a render and then I have it um have scenarios the various things I want fast. It's re it's really easy to like make render performance your biggest thing, but like scroll performance is another one. Or in the case of trees, it's like when I collapse uh 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 uh on the trees and then have each of those as a scenario and then I throw that into PI auto research. Uh and so I say, hey, here is this scenario. Here is uh like out of the Chrome profiler, here's the memory usage. Here's this here are the like I'm happy to trade memory up until this point. Um I I you know get this as close to zero as possible and then you have tests. Um and so it goes through each of the actions. Usually you do one action at a time but I might have four running uh at the same time. uh and and uh that has shown an incredible ability to take something that I think at first we try to we tried to load Linux Linux into my first iteration of the file tree which is like I don't know it was uh 93,000 files and it was like pretty it was five took 500 milliseconds uh 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 in it's I don't know something like 350 milliseconds or something. Wow. So So like orders of magnitude faster. And I bet there's still a lot to be gained. And every click is you know a single frame. every like each one of those things I was able to put into py auto research and just the dopamine hit that you get from it is enough to like power you uh through uh 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 um and I try to you had luck with auto research was that a skill you had to develop was there um any learning period there because I have heard uh both uh people having a lot of success with it and people not having success with it. Yeah, I have two notes there. One is that it does take you the thing that you need to learn is really how to give it like the right amount of data um 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. Yeah. The faster you can let it run like 3,000 times, uh, it can get like a statistically significant output. I I also use a bunch of, uh, the mitata library. I don't know if you guys have ever used that. It's a benchmarking library. Uh, MITA. Um, it's it's used a lot in like, uh, like benchmarking of like this versus that. Um, and it it runs the things until you get a statistically significant uh difference. Uh, and that that really taught me to like um it also handles things like uh warm-up CPU warm-ups and all sorts of things that like cloud all your data. I wouldn't say that's like hyper necessary to get that deep. Uh I just really wanted uh to to to nail it. But so so that's the 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 PI auto research, as far as I can tell, PI auto research is much much better than like OMX auto research 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, PI auto research is is the jam. What models are you using with that? Uh I mean, I used it through uh I started that on Claude uh the first times I was running it. uh the five five point whatever the last two are and then 5.4 and 5.5 on uh codeex as well. Yeah. Man, that's fascinating. I love hearing about that. Just 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. 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? 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 it tested all that stuff and a lot of times you get some pretty good like follow on gains for each of those. 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. But luckily we have Amodus who's spent the last 10 years of his life writing infinite scroll windows. If you think about Discord Amodus is really just like been writing the same thing. Did you write the Discord window scroller as well? 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. The 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 backend 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 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 that you were within in the member list and then request that scroll. 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 anyways so like you shouldn't have to pay that cost. I love this podcast because we get to talk to people that just go so deep like we had uh Alex Reirden on. He's the guy that authored um 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. Sounds like my nightmare. Yeah. Well, that's why I'm I'm happy that like people that do know this stuff can can go deep on one aspect of it cuz like I probably will never have to write a diff library or a tree library now or a drag and drop. Um and we just get these awesome like blocks. Uh 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. Um thoughts on web components? Do you like web components and what are you doing for state reactivity things like that? We have two different answers here. Um I actually lied a little bit. We both use uh 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 styleshe like we're trying to make sure that this thing doesn't interact poorly with the rest of your web page. Kind of a third party JavaScript approach to it. But ultimately we're not using, you know, like bound attributes or anything that uh like like that. I did I did initially start trees in in like lib uh or what was it? Uh uh lit. Yeah, lit lit element and stuff like that, but but it just wasn't right for me. But I lied a little bit. Uh I I use Pact for one layer. Um because the hydration of the SSR is my code for hydration for SSR ended up being roughly as big as Preact. Uh 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 Pacted. I'm sure I could do that thing that uh like I think Tan Tanner uh from Tanstack tried his like uh what do they call it? Uh freeact or Yeah, 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 tan stack 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 uh for trees because we're using, you know, probably a quarter of it, but it's 3 kilobytes. It's it's not uh 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 3 kilobytes, you're like, "Okay, let's just use pact." So, but that's not the case uh for for diffs. If if wants to Okay, but like what about like reactivity as well? You delete a file. Um are you just manually deleting the node or do you have something that figures out ultimately uh a lot every action and everything is 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. Um, and that store 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 happen 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 Pact. So I do use Pact, 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 pact view know that it needs to rerender at that point. Okay. But yeah. Yeah. And for diffs, uh it's all pretty much kind of custom. I think uh inherently each there's kind of two pieces. there's like the the what 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 um and then kind of rendering basically rendering that to an a that we can then use for for ultimately the component uh 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 will then just render it to a container um and so I kind of had to build a little bit of my own sort of for react reactive stuff like for the React components essentially, right? That basically just you pass those props in via, you know, 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. Um, and then for the the code view, um, 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'd have to render it all. Um, and so for that I sort of built a structure that um kind of keeps some does some bookkeeping around what lines are rendered and then uh you know doesn't touch those if it needs to add more lines or clean up lines before after and stuff like that. Um and so there's I guess in some ways probably you know maybe if if I had started with pact or something maybe I could have simplified that a little bit but there is definitely a level of just like oh you just sort of we mostly just kind of hide it from you uh if you will. I'd add that we use declarative shadowdom which was initially pretty difficult to figure out with hydration. Um I don't know if you've ever used declarative shadowdom but it's you know it's how to mix SSR with the shadowdom. Um and web components typically in the beginning weren't good at SSR. Um but this allows you to kind of upgrade this injected blah blah blah uh uh component. And so we 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 um uh like the actual um uh web component slots. So I 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 uh 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. Then you have that pass through of the the shadowdom back into the slot. Um uh 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 uh slots and things like that. Man, I am glad there's people out there that are figure out web components. man. Like we we say on this thing a lot uh 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 Spalt. You know you can you can reuse them. 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 SSRD right um and including the comments and so you kind of get this best of both worlds where you can have hydratable SSRable children uh in these slots and because of the way uh shadowdom and and slots uh and web components work it all kind of this hydrates and is nice uh and and so there's 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 uh other than trying to figure it all out initially. Um and like we didn't even mention this but like these are both open- source projects or or how does that work? How do you guys make money? uh having a company uh switch from using GitHub or switch from using their AWS account uh and Git S3 or or or whatever is a is a big sale. Uh and code storage is a is a B2B product that we sell um and make money on and uh often uh much like Nex.js JS is open source for Versell. Um, and that brings in people into the ecosystem that is well supported on your platform. It's like if you need uh AI scale uh git storage, there's a good chance that you need to render a file tree and and a diff. Um, and we're happy to like support you in doing that. And if you want to serve them from a place that can handle uh many many orders of magnitude more than you currently can, then we're happy to to make money there. But but also like we just we like to to build cool things and and have people work on them and and uh share with the community. It's it's a it's a little bit of everything. Sweet. And I think early on too, Jacob had a good insight. I 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 there you go." Um, and they were just they were old school, like not not to to drag them or anything, but they were just libraries that would 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 like cheeky, you know, tokenization libraries. Um, how do we how do we rethink about this problem in a more modern context? Um because I think he also at the time he saw codeex 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. Um 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 um and kind of learn what their problems are and what their needs are. Um, 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, 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 Totally. 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 what other primitives are you working on? Yeah, it depends on if we can get tex area.com uh we did we did try to build uh 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 uh way too expensive. Uh they they wanted uh many millions of dollars for it. So trees software it was. But trees.com is not actually that impressive of a of a website. No, it's not. Yeah. Yeah. It's just a psychological I did check it out. Yeah. Your vendor perf is brutal. Yeah. It's no McMasters, you know. Uh yeah, I like we like McMaster on this this podcast. We do not accept that slander. No, that that was a compliment uh for McMaster. Oh, okay. Okay. Okay. I know that this podcast likes McMasters and that's why I brought it up. Okay, good. As a fan. Uh yeah, the the uh the requests for editing diffs specifically uh 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. Okay. Um, now we do support things like accept and deny, like kind of like cursor shows you like the little uh 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 update the CSS value from light blue to dark blue or whatever. You know, it's one of those. And so, uh, we do have stuff in the works for, uh, for editing on diffs, uh, but no promises on on when it will release. Yeah. So, now'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. Amadea, 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, uh, I'll let Amadeus go first. Do you have a sick pick for us? Yeah. Um, I would say my keyboard right now. I have like a 40% uh custom keyboard. Uh, it's by this there's this like random designer that I met online on a Discord and he's lazy designers and he just makes a lot of like 40% 30% style keyboards which is kind of my jam. Um, and yeah, that's probably my my current sick pick. the 40% keyboard. So that's what is that? What are you missing then? You don't have arrow keys or anything. Does it have a J? Well, the I guess the thing would be it has everything. Uh 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. Um, then space bar is just a little guy. So, yeah, little space bar in the middle there. Layers, whatever. Um, 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, And the the like the A and the the Q and the Z are all vertically lined up. That wasn't weird to to 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 I don't know maybe my autistic brain or something is like it 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 like there's like these like offsets that don't always match. And so 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 is 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 yeah, I I should add that whenever I go to the office and me and Amadeos 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. Yeah. Yeah. You travel with it. That's great. It is small. All right, Alex, I really hope you're going to sick pick something that you've been posting on Instagram, but go ahead. What have I been posting on Instagram? Oh, flip dots. Yeah, I I did I wasn't going to uh sick pick my flip dots, but I did spend a few months like building and designing a flip dots display. Um maybe I can get you a picture or something you can you can throw up here. But yeah, it's like uh you know like microcontrollers and then you know a black and white uh like magnetically controlled dot. it can go like 10 fps. Uh, and I needed like some art for the wall and I eventually but you had to like they send you like some raw materials and you had to like build all the aluminum and and program it all together and 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 like all the power cables are like loosely screwdrivered. Like I'm just like cutting I'm cutting IEC cables and just splitting them into places. But I'm sure it won't catch on fire. I was going to actually uh originally sickpick PI auto research, but I already talked a lot about that. And then whenever uh Amadeus was talking about keyboards, I thought maybe I'd sick pick uh my keyboard, which is the opposite keyboard uh of Amadeas. The the Senica weighs like 8 lbs, has every key. So, Senica keyboard. Okay. First, I Googled it. First thing that came up was the $3,600 keyboard. Is that true? Uh yes. Yeah, that's true. Cheaper than the flip dots. I bet. Holy, that's sick. The I honestly knew that Amadeus was into keyboards and Amodus 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. He's new. I'm going to get this keyboard and he's going to get it. We're going to be keyboard buds." And I got it. He's like, "Oh, I don't use keyboards like that. I I use these tiny ones." So, I was a little good about it. It heavy. Yeah. Uh He he like designed each of the switches and and and is like kind of a perfectionist on spoke. Yeah. The guy Norbower is pretty famous in the keyboard community is just being 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 stabil that space bar you'll hear a rattle. And so he basically spent probably hundreds of thousands of dollars in R&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 cuz he wanted to kind of thing. And that's sort of his ethos on everything. It's just mil from like a block of huge block of aluminum. That's beautiful. Piece of concrete. Yeah, for sure. 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. Um, when you launch textbox, come on back on and uh we'll uh or text area, we'll have you on. Appreciate it. Yeah. Thank you so much for having us. It's been great. Peace. Take care.