Welcome to Syntax. Today, we've got Alex Sexton and Amadeus DeMarzi. Apologies if I goofed that up, but we are talking to them because they are building the primitives for something that Claude Node uses, OpenCode, Conductor, Node.

They're building essentially, they're building the building blocks for, almost what would be, like, a new Versus Node. And it's it's really cool. They're working on some pretty hard stuff, and we're gonna 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 wanna show a diff of code and if you wanna 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.

There there it is. Let me load down scroll down a little bit.

Ever have you ever tried to resize, 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 oh, no. Oh, no. Oh, no. It's got 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 repaint. And look at that. Watch watch how fast I can scroll. I have, like, one of these, like, Logitech mice where I can scroll super fast.

Boom. Boom. Boom. Let's see how fast I can go. Scrolling fast, and it has much better accuracy.

I think even for video listeners,

video watchers as well, it'll be lower FPS because this is probably, like, 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, and a couple other things as well. So welcome.

Thanks.

Thank you. I've been seeing your stuff pop up a lot lately in all and seems like all different types of capacity. So do you wanna quick give us an introduction to, who you both are and

what you do? 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 code, developer, tools for the the next generation of, I should practice this. Next generation of, you know, AI agent based, coding. And so we have a a core product called Node 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, or diffs, and some of the other things that we'll have in the future as well. Sick. And Alex, has been on Syntax before back in

2024, February 16, when we were talking about, CSP, XSS, that type of stuff.

And, Amadeus, what's what's your your story? Yeah. My name JS Amadeus DeMarci.

I have been in tech for a little while, though I kinda 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 up here.

And then, yeah, to kinda 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 and sort of, how AIs,

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 dot storage, 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?

Yeah. That's right.

The scale that, code dot storage works at and we do work on, some of some of that product, but we, are are able to facilitate a much larger, kind of, scale when it comes to, like, AI's 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 to be able to handle. I saw that, like

I think, like like, Jacob, I've you guys might know him as, like, as fat. He's the guy that created Bootstrap.

He he obviously he founded the company. Is that right? Yes.

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, at our peak, we were do you remember Amadeus? I should've looked this up beforehand. But I believe it was something around 15,000 repo creates per Sanity, if I remember correctly. 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

that JS 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.

They Yarn, essentially, the they Vercel, 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 kinda do 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 the fundamental view of of, reviewing Node, and we thought that, 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, that we needed to break these things apart.

And so distant trees are primitives that, we make. They're 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, in Node desktop and claw 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 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, Node, desktop, had been baiting it. So it's been in codecs desktop for a while, in the preview versions, and it's already kind of in a lot of other of these apps, as as people

adopt it. Wow. And how did they find it? Warp was it just from word-of-mouth? Or Yeah. I mean, I think

chips or Yeah. Like, Jacob and I have a long history with a lot of JavaScript front end y people, and I think these are I don't wanna take credit for it. Jacob has, 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, 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. And we actually need all the parts, but we can't, like, move everyone onto this product that you have. And so it kind of came came naturally. And why

like, maybe you 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 Yeah. Because that's where I have most of my experience.

It's a couple 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 little bit of a love hate relationship with React. I think it's amazing for certain things. Mhmm.

Mhmm. 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 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 ESLint 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 gonna have to create a virtual DOM of that entire thing. 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 gonna be updated very frequently.

And so a lot of for me, a lot of the, kinda architecture initially with diffs JS, 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 kinda 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 Sheikki and so forth that, like, do a great job syntax highlighting, 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 OpenCode is, Solid JS, I believe. So, you know, there Yeah. 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 ESLint 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, 12 levels of

abstraction on top of, you know, rendering text, basically. And, like like, how does it work? I'm curious about that idea. Is it is it virtual DOM? Is it virtual like like, I tried to scroll Yeah. As fast as I possibly could with my, like like, riced 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 I remember that, like, every UUID

website where you could scroll and and see every UUID. That was amazing to me. So that's actually I I kinda glad you brought that up because in some ways, I was a little bit inspired by that website. Okay.

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 clever in that it it obviously, it's virtualized. I mean, if you go to if you, like, were to inspect the or view or not view source, bring up the dev tools, 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.

But there's a couple pieces there, through my experience of of working through this problem, which was, essentially, your scrolling interaction that you have, I really wanted to maintain native scroll. So you you the UUID site, for example, they've basically completely abstract away the concept of a scroll. 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 GitHub also works around, but in a different way.

And so what they've base basically done is I I have the feeling they'd 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 kinda 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.

I wanted to obviously not do that with code. And so there was when you have a a scroll this kind of starts to get a little technical. But when you have, you know, browser scrolling, for example, 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 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 disk hub and the Node view components that we sort of use to power this experience.

However, I kinda had this epiphany when I was working through this problem of, you know, I didn't wanna 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 it to make it impossible to blank.

And I kinda had this epiphany as I was going through it of, like, you know, you can use sort of like, people often use sticky compo 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 then 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.

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 and if you did it with the DiffSub, 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 Node up with, you might just see, like, a frame that's, like, out of date for half a second, and then it'll, like, run to the correct frame.

And so these kind of, like, clever tricks around, you know, how do you make it so that it Vercel blanks on you, 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,

well yeah. So I think that's probably a good sort of explanation. Yeah. Virtualization JS 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 to work around when using virtualized lists? Yeah. I mean, we,

we don't support, 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, to step back is is if you try to do in page find on the size of diff that, 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 are trying to render, there's no world in which, the browser, but especially not you in the main thread, can do, fast finds. And so we haven't really tackled that, in earnest, but I think it's going to come down to some combination of at some scale, you can move it off, the main thread to a worker, and so I have some stuff in a in a in a work tree somewhere, 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 the native one and everyone hates that and 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. It's the browser can't do it, either. Right? Yeah. And so the other thing for, like, trees is I need to there are, 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, 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.

One of the things that like, one of the things you can actually I mean, it's buried on the Diffsub website right Node, but if you open up one of the expansion things and you click, it's like about 1,000,000 line diffs. We one of the examples that we show is is a diff between Linux version six and Linux version seven.

That does take a while to fetch that diff content from GitHub. GitHub will basically you'll basically have to wait, like, twelve or fifteen 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 view a scroll view would allow, in a browser. I think different browsers have different So there's a max.

Yeah. So, like and it's like it's like sick I think in Chrome, it's like 16,000,000 pixels or something and you Node? Which is a lot, but, like, if you think about, you know, you have 8,000,000 lines of code and each line is 24 pixels tall. Like Yeah.

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 Node and you were to try to inject that amount of content, I mean, that's a 100 and I think that patch file JS, like, a 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 Diffs Hub website is that it's really a marketing piece for us for this new component that we're launching with Diffs called CodeView.

And the idea of CodeView is that, 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 Node not gonna 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. Render figure out how to render it. I don't you Node, 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 we'll be able to render it, 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 as Node 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 Node, and a syntax highlighter might even if it's fast, it might take a hundred 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 kinda 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 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. 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, well, a, the 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 gonna explode memory, 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 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, don't really change, or, like, collapse or whatever. The the full blocks do. But trees is interesting because if I were to, I need I need a data structure that matches the tree's, like, structure, the structure of the actual, you know, this is a child of this is a child of this.

Yeah.

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 JS, was the Android open source, Bos Android open source project. So I think it's, like, just the files themselves, there are 1,500,000 files, and you can kind of, like, jank free scroll through all 1,500,000 files.

And, if you were to actually generate the DOM for that, it it would take, like, thirty 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 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 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.

Yeah.

It is so funny. I I was, like, 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 Deno. 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. Like, it's pretty raytracy

fast. And 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 JS.

But, also, I'm 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 is that a hard problem to figure out? Yeah.

I think, Amadeus, you should talk about, rapping here in a second, because I think that's hard in on the diff sides. But I 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 we Jacob said I got overflow mogged by, by, Cheng Liu, and that's true. So, but the one Yarn, 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 ESLint. 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 on immediate page load, if you go to trees.software or, or disc.com, you can see that, like, it works without JavaScript. You Node? It's obviously not interactive, but, but that that means that we can't do some of those text rendering stuff. 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, middle truncation or truncation 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.

Yeah. I think with this, it's a sort of an interesting problem too because some of it, like, the the pretext 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 a 150 megabyte diff file that has, you know, 8,000,000 lines of code.

If I wanted to iterate if I just wanted to run a a JavaScript loop over, you know, 8,000,000, that's gonna take significant time. So I can't necessarily just be like, oh, I'm gonna count each line and then whatever math it. You kinda have I kinda have to work like, start with, like, a really fast estimation.

And so the nice thing about diffs is you kinda have, this idea of hunks, which are basically, like, you know, the the context blocks.

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

And so, like, that's already kind of a little bit of a simplification, and then you can just, you know, Node that. You can Sanity, 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 sort of that numeric abstraction, you know, as fast as possible. I call it, like, basically, the estimated height. And then when you actually rend 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.

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, cash 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 ESLint, but the line above it wrapped, and so it would push it down.

We can obviously correct that before you the 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, 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 maybe you have. It's like a 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 Dis GitHub 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 really fast.

And then I think while it's scrolling, if you open up the little tools, you can kinda 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 kinda do that while it's, like, ESLint 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 I feel pretty confident that it's in a good spot. So so, yeah, like, that was an example of, like, one pnpm. 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 gonna be. We have to estimate where we're gonna 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 ESLint, and then just use that as kind of a relative measurement to make sure that we're still on the same spot. 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 zoomed flick scrolling, and it still worked.

That's a like, what tools do you use to I was just gonna ask Scott guys. Yeah. 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?

I guess, well, Wes, honestly, I'm a I'm kinda I feel like I'm this weird guy of, like, I use Neovim, and I'm a completely terminal build for everything that I do, so I don't use any desktop apps. I use OpenCode 2e 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.

One thing and 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 its, like, have it run some specific benchmarks. And then, you know, actually, it'll pull into, like, the Chrome dev tool graphs or whatever and and figure out, like, if this is actually more performing or not. That's been a great feed 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 a conflict.

And so I had this parser that would, like and I kinda created this, like, 20,000 line file that had, like, you know, thousands of conflicts ESLint, 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, twenty 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, Node, whatever. I was like, hey. Currently, when you run this function over this file, it takes twenty 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? I let it run for, like, an hour, and it got it down to, like, point five milliseconds or something like that. And so it was just like, perfect. And I I 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 so there's there's a certain level of certain stuff like that you just kinda give up. But a lot of the 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,

yeah. Yeah. I I think, 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 JS 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, 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, when it comes to headcount, but the, like, attention that even at when I was at Stripe for for ten 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 and there's a lot of, user experience to be gained there. And I I think that's why it's great versus the tooling.

It's kind of the the the the spirit that that JS is is the value there. But tools too.

Or go ahead.

No. Go ahead. I'm I'm saying yeah. Oh, yeah. Hell yeah. Hell yeah.

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. It's kinda 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 Yarn. 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, standing, you know, pure function of some sort.

And so a lot of my function shapes are are not necessarily normal or Scott how I'd 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 feedback into a loop. And I think that you'll see this more and more as the the AI era get gets, gets bigger JS 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 at the top. You know? I've I've what I did is I profiled something myself, and I was like, what do I actually pay attention to? I want the bottom up, stuff up top. I want I wanna look at, like, highest called functions, timing the function, like, function iterations, and things like that. And I actually the I chip it in the code is with phases, inside of the code. It it it Scott 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 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 Wes I collapse, something or when I delete a file, I don't wanna 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 PyAuto Research.

And so I say, hey. Here is the scenario.

Here is, 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.

I I, you know, get this as close to zero as possible, and then you have tests.

And so it goes through each of the actions. Usually, you do one action at a time, but I might have four running, at the same time.

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 JS, like, I don't Node. It was, 93,000 files. And it was, like, pretty it was five it took five hundred 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,500,000 Android stuff in it's, I don't know, something like three hundred and fifty 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 prior research, and just the dopamine hit that you get from it is enough to, like, empower 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. Oh, it's 10 times faster now.

And I try to bust out the other reason. Luck with auto research. Wes that a skill you had to develop? Was there, any learning period there? Because I have heard, both,

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, 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 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 ten minute you know, a ten second test or it takes ten seconds to even boot up the browser and connect to the thing Yeah. The the faster you can let it run, like, 3,000 times, it can get, like, a statistically significant output. I 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, like, benchmarking of, like, this versus that. Mhmm. And it it runs the things until you get a statistically significant, difference.

And that that really taught me to, like, it it also handles things like, 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. I just really wanted Yeah. 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 PyAutoResearch, as far as I can tell, PyAutoResearch is much, much better than, like, OMXAutoResearch 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

re research is is the jam. What models are you using with that?

I mean, I used it through, I started that on Claude, the first times I was running it. The five five point whatever the last two Yarn, and then five point four and five point five on, codecs as well. Yeah. 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 did you ever dip into, like, things like, 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,500,000 items that we're looping over building a data structure, Everything, every counter that you have, you get ESLint, like I haven't done a lot of this, but it like, reusing elements or reusing, like like, stores is really good or, like, sets versus objects. And it, 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.

And so that's less of a concern.

Though, like, scroll performance is still can be very difficult. But luckily, we have Amadeus who's spent the last ten years of his life writing infinite scroll windows. If you think about Discord, Amadeus has really just, like, been writing the same thing for the Discord window scroller as well? Yeah.

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 Mhmm.

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 Scott. 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 Yeah. 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,

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 ten of his ten years of his life just doing drag and drop, you know, just obsessed with it.

Sounds like my nightmare.

Yep. Yeah. Me too. Wes, that's why I'm I'm happy that, like, people Yeah. That do know this stuff can can go deep on one aspect of it. Because, 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? 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 style sheet. Like, we're 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, like like that. I did I did initially start trees in in, like, Lib, or what was it? Lit? Yeah. Lit Lit Element pnpm 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 Preact at all. I'm sure I could do that thing that, like, I think Tan Tanner, from TanStack tried his, like, what what what do they call it? Free free act or re 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 pan 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, 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 if Amadeus wants to. 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? Ultimately,

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.

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 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 rerender at that point. Okay. But yeah. Yeah. And for diffs,

it's all pretty much kinda custom. I think, inherently, each there's kinda 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 dot render, which will then just render it to a container.

And so I kinda 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, your props and your component, and then it kind of figures out, you know, whether it should call render or shouldn't, that kind of thing.

And then for the the code view, we wrote some kind of more intensive virtualization stuff because we kind of wanted line like, per line virtualization. So we only render the lines. We didn't wanna think about it as files because you could have a 10,000 line file, and we'd want to render it all.

And so for that, I sort of built a structure that kinda 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 Node, maybe if if I had started with Preact 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

Wes mostly just kind of hide it from you. If if I'm if you will. So 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. And web components typically, in the beginning, weren't good at SSR.

But this allows you to kind of upgrade this injected blah blah blah, component. And so we do 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, Wes component Scott. So I I lied that we don't use any of the APIs. So if you wanna 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 wanna, 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 Oh, yeah. 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 kinda solves for both of those situations, and you have that pass through of the the Shadow DOM back into the slot.

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. 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, this podcast a lot. It's 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. 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'd, right, and including the comments. And so you kinda get this best of both worlds where you can have hydrateable, SSR able children, in these slots. And because of the way, shadow DOM and and slots, and web components work, it it all kind of just hydrates and is nice. 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, other than trying to figure it all out initially.

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?

Having a company switch from using GitHub or switch from using their AWS account, and Wes three or or 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, much like Next. Js 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 and a diff.

And we're happy to Yeah. 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 to make money there. Yeah. But but also, like, we just we'd like to to build cool things and and Yeah. Have people work on them and and, 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 Node, like, I'm looking around the ecosystem right now, and I'm seeing, you know, HTML to diff or something. I I forget what it was called. Or but it Wes, like, all these libraries.

Diff HTML. There you go.

And they were just they were old school. Like, not not to to drag them or anything, but they were just libraries that would've 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 Node, 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 Node before it was like a desktop app. They had, like, a web app, and, you know, the 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 kinda learn what their problems are and what their needs are,

and then build for that, which JS, 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 Wes rest. 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 Wes other primitives are you working on? Yeah. It depends on if we can get textarea.com.

We're actually working on it. We did 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.software, it was.

But trees.com JS not actually that impressive of a of a website. Node. It's not. Yeah. Yeah.

It's just a slice of cookies. I did check it out. Yeah. Your vendor perf is brutal.

Yeah. It's it's it's Node McMasters.

You know? Yeah. Yeah.

Yeah. I think that McMaster on this this podcast. We do not accept that slander.

No. That that was a compliment,

for Zig McMaster. Okay. Okay. Okay.

I know that this podcast likes Zigmasters, and that's why I brought it up Okay. Good.

As a fan.

Yeah. The 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 kinda ruins, like, the context for the user.

Now we do support things like accept and Deno. Like, kinda like cursor shows you, like, the little, buttons for accept it. Like like so there are ways to get it, but it's kinda 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, we do have stuff in the works for, for editing on diffs, but no Exactly. 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, 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?

Yeah.

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

Oh. It's by this there's this, like, random designer that I met online on a Discord. He's lazy designers, and he just makes a lot of, like, 40%, 30% style keyboards, which is kinda my jam.

And, yeah, that Wes probably my my current sick pick. The 40% keyboard. So that's

what JS that what are you missing then? You don't have arrow keys or anything?

You don't have a j. Well,

the I got like to change that. Thing would be it has everything.

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.

That Space bar is just a little guy. So, yeah, little space bar in the middle there, layers, whatever.

But, yeah, you can kinda 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. And the the, like, the a and the the q and the z are all

vertically lined up. Yeah. That wasn't weird to to Oh, yeah. Yeah. So it's ortholinear.

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. Just 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 JS different than, like, f to t or like, there's, like, these, like, offsets that don't always match. And so you so you're kind of your fingers have to kinda learn something weird. So I just there's something like the perfection of a perfect grid.

To me, it's just I love it. It does make typing on a normal keyboard. I kinda 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 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.

Yeah. Yeah.

You travel with it. That's great.

It is small. Alright. Alex, I really hope you're gonna sick pick something that you've been posting on Instagram, but go ahead. What have I been posting on Instagram? Oh, I dots.

Yeah. I 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. It can go, like, 10 FPS.

And I needed, like, some art for the wall, and I've I've ventured 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 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 screwdriver. 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 gonna actually, originally sick pick PI auto research, but I already talked a lot about that. And then whenever, Amadeus Wes talking about keyboards, I thought maybe I'd sick pick, my keyboard, which is the opposite keyboard, of Amadeus. It's the the Seneca. Weighs, like, eight pounds, has every key.

So

Seneca keyboard.

Okay. First, I googled it. First thing that came up was the $3,600 keyboard. Is that true? Yes. Yeah. 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 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 wanna 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 was like, oh, I don't use keyboards like that. I I use these tiny ones.

So I was still looking for good about it. It looks cool. Heavy. Yeah.

He he, like, designed each of the switches and, and and is, like, kind of a perfectionist on Bos spoke.

Yeah. The guy, Norbauer, is pretty famous in the keyboard Sanity. It's 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 kinda 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 or that space Bos, it'll 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 kinda thing, and that's sort of his ethos on everything.

It's just milled from, like, a block of a a huge block of aluminum. Again. Oh, that's beautiful. Piece of concrete. Yeah. For sure. Yeah.

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 TextBox, come on back on, and, we'll, or Textarea.

We'll have you on. Appreciate it.

Yeah. Thank you so much for having us. It's been great. Peace. Take care.