Supper Club × Visual Coding Languages With Steve Sewell

Welcome to Syntax. On today's Syntax Supper Club, we're gonna be talking with Steve Sewell About visual UI development, Steve is working on builder.i0, a little bit of a a project we talked about a couple of episodes ago with Mishko, and, we're gonna be talking all about visual programming, visual languages, how something like this Actually works behind the scenes and maybe some of the challenges of working with these types of tools, in terms of building them. My name is Scott Polinski. I'm a developer from Denver. With me as always, as you know, is Wes Boss. Say hello, Wes. Sup, everybody? There we go. And, Steve, welcome to the show. We're so happy to have you.

I can't wait to get into this thing. I'm I'm a huge visual programming type of fan. So, can you just give us a little bit of intro? Who you are, what you're doing, what you're working on, and what is builder? Absolutely. I love that you're visual programming nerd. This will be fun. So anyway, I'm Steve.

I'm cofounder and CEO of Builder Dot IO.

Previously, what I do. I actually began my career on the design side. Always wondered why you can't design an application that works. You have to design it, and somebody else gotta program it. And when I learned the programming side, I I was self taught.

I was like, wait. Wait. Wait. You have to type background red. Margin type top 10 pixels. Like, what the heck? This is insane.

And, learns, obviously, those challenges plus all the workflow challenges that ensue. It was it was wild to me.

I did a couple startups.

Most recently, did one that was acquired by a company called ShopStyle.

They are, like an ecommerce aggregator. So kind of like a Google Shopping. If Google Shopping sucks, like 20% less. The space is hard. Google Shopping is like a pay to rank system, so I think you probably don't use it. Use Google search, which is actually like quality ranking, you know, Ordering as opposed to, like, pay more to order higher, so, you know, poor results.

But, anyway, working there, I I realized quickly that I wanted to work on cool technology.

Ecommerce businesses are just selling anything online as much more marketing driven than tech driven. So it's you don't build cool features to to sell more products. You market The product's better. You show more personalized results. You, show more interesting you know, you run AB tests to see what type of stuff should be on the homepage to get you to buy stuff that Amazon does that everybody else wants to.

And so in doing that, that's where we ran into this problem of, Headless CMS is the way we are using, the way most people use them. It's a little hard to give marketing the ability to just do what they wanted, which is ideally To have it interface like, you know, Squarespace or Wix or Webflow, just drag and drop this product here and this hero there and a newsletter sign up, today, 50%, you know, AB test only to previous returning visitors who shopped men's products previously, you know, stuff like that. It frequently came down to the amount of stuff we had to build for them was, huge, like, engineering ticketing queue for, like, new landing pages for this campaign and all these new tests and all these personalized variations, just trying to sell more product. Right? And so ultimately, we kinda had this epiphany, like, if they could just have A draggy, droppy thing, but it was using our components. This was an Angular site. So if it's just our Angular components, they could just drag, drop them in any order, run this as a test, run this as a variation towards, You know, this cohort of users, whatever, all our problems will be solved.

And, I won't spoil the rest, but that's what led us to build or led me to quit, start building builder dot I o. And, course, we have a whole team today and solve that problem for all the frameworks, make it essentially a visual programming system on top of the framework

Stack you have today. Sorry if that was longer winded than you were looking for, but that's, I think, the full background. No. I think that was perfectly winded. I think that was Good. Exactly what we need. Yeah. So so okay. So, you know, you you very briefly or quickly mentioned that you can bring your own components, in in very, like just looking, you know, number one thing that you have on your features is that this works with any tech stack. So, like, depending on whatever Types of components you're writing, you know, Svelte, Vue, React, whatever, this works. How how is that possible that you're Able to combine all these things with a a visual programming language.

Yes. Yeah. It's really it's confusing at surface level, but it's it's simpler than you'd think. Somebody on Twitter We talked about this on JS Jabber once, and somebody comment on Twitter that that was the most confusing episode of that podcast ever. So I'm gonna try and do a much better job at describing it this time.

In short, it's pretty straightforward. So, normally, when you create, like, your home page in Next. Js, you hard code, you know, hero components at the top with this title and image Provide the props, below that, whatever else component. Maybe a cool little quote components and here's the props. Well, imagine for a second, instead of hard coding that, Instead, there is a component to dynamically render that from a simple JSON configuration.

So the JSON says that. It just says, okay, the 1st component in the list is a hero with these props. The next 1 is your quote call out, your product recommender with these props, etcetera.

And so now imagine That Jason came over an API, just a list describing components and props, and then you installed on your website instead of, you know, Hand coding that configuration, that ordering of components and props, you instead installed a simple component like a react component that can ingest that JSON.

You tag your components by name. So you say this one's the hero component. This one's the product component. And it can just loop over that j s and say, cool. Put the hero here with these props, The columns here with these props. Now it gets more nuanced than that if you wanna build that yourself, which we learned the hard way. You know, you have to worry about recursion. You've got columns that have Buttons inside and the button can have a child of this type and not that type, but that's, like, the system that we built out the layer on top of it. But under the hood, it just ingests Jason that describes the UI and renders it using the combination of your components.

And the way we make these SDKs for all frameworks, it's it's own separate open source project. There's Layers of challenges that we had to solve to make this work, but that's the really quick gist. And so, like, that data like, the, the structure of the the site in that regard, Is that coming from a database specifically, or is it, like, being saved to, like, files or something? It's just coming from a yeah. Like, database. Yeah. Great question. Yeah. It's stored in a database because the idea the the goal here is that you have an end to end workflow where marketing team just goes in and makes a new variation of the home page or brand new landing page on some new URL. So they just click some buttons, drag and drop the components around, Hit publish. It's saved in the database and it's live on your site as immediately as your site can update content. If it's server rendered, it's immediate. If it's static generated, it's on the next builds, You know, triggered by Webhook or or whatever. Nice. You always wondered there's, like, a gap between, you know, building fully custom sites and building CMS based sites where it's like, what's saved in The database. Right? You know, in a WordPress site, there's so many things that are saved into a database that aren't, you know, saved into a database when you're working in a fully just custom custom site.

Okay. So builder dot io, we got we got the Hold on. Hold on. I have some questions here. Like, I just wanna I wanna make sure everybody understands it.

So Somebody signs up for Build. Io. You hook it up to your own components that you have, and then Your marketing folk can go in and and drag and drop and and basically compose a page out of the library of components, that you have.

But you, the developer, you're still you're writing a 100% of the code in React or whatever framework you actually end up quick you end up Trying to to use at the end of the day. That's right? That's correct. And to clarify one thing too, you're not making a net new website or anything. Like, we don't host anything.

You actually will generally let's say you have a Next JS site. You'll make a new route on your Next JS site called, like, you know, dot.page.js to say catch all page. And in that, you make the simplest Next. Js page ever that just says, get Stack props, call the builder API, and then we have the component that you pass that Results from the API call to to render your stuff. So you're working it into what you've got. You're not, like, producing some new thing hosted like a Squarespace or something like that. Oh, okay. Cool. And Yeah. And this this this solves the problem of you generally, you you have your app, But then you give the marketing folks their own website because you don't wanna have to deal with them or to fuss with them or anything like that. You just go do your own website over there. We're building the app here. Right? That solves that. Essentially, yeah. And in some cases so that's a common one. So that's just like builder stack. We have the heavy React app, and we have the marketing site. Marketing owns the whole marketing site Mostly made from scratch, and that's one missing nuance here is you don't have to have components for everything. Some people like I'm trying to think of which customer, like, Vistaprints chooses, like, everything must be composed out of their React components. There's a design system. They wanna stick to it. You know, tight guy rails. Don't want marketing going crazy. Mhmm. Other customers like, Everlane or, I'm trying to think of I'm trying to actually almost named a customer I'm not allowed to. Some of our busier customers are not allowed to use their names and logos. Anyway, a lot of customers will actually allow the marketing team to just Actually, create whatever they want. So you could look at it as compose my components, or you can look at it as full quote, unquote no code that you can mix in code.

So you can create anything you'd make on any other kind of site or page builder like a Squarespace, or Webflow, totally from Scratch and Builder. Literally, a kind of Figma like UI. Just design it from scratch in Figma, but just drop in your components inside of that too. So in builder's docs, it's basically made from scratch, But we needed a component to show nice code snippets and to show, some other kinda dynamic data. So you just drop that in where you need it. And so in the case of that, you can find, you know, some websites. Let's take Everlane.

Their first use case is marketing just had to make more pages within their site without a developer backlog per new page. And so they hooked up builder to make new landing pages. But then they're like, well, the home page, Can we just drag and drop that tune? It's like, yes. You remove the hard coded content. You add that builder component in for the home page between the header and footer. Tada. You've got a home page that's visually editable, and they'll work that across pages. So there's many sites out there where, like, 80% of the website is controlled by builder. And In this format, developers just make components and move on with their day. Mhmm. The marketing team composes them into whatever configuration they desire.

You have hybrids where Some pages are pretty hard coded, and maybe a section or 2 is editable in builder, and some other full pages are builder editable. And you can even have the extreme or or kind of more code heavy situations like you mentioned, Wes, which is you have an entire application that's meant to be all code. Inside a builder, we have little callouts like when you onboard, you know, there's certain screens on the onboarding that's like, we don't wanna push new code to change the screen. This one's visually editable. This one we're just gonna drag, drop, change anytime, but a lot of the other stuff like the drag and drop editor, that's not made in builder. We could, but it's like why? This should be in code. But composition that's content marketing y, that should be outside of your code. So you don't have to push code for new marketing content. Mhmm. That's it. Okay. And one other thing I'm I'm curious about is,

I think back to the WordPress days. You see something on the website, and the client would say, How do I edit that? And you say, well, you you go to the edit page, and they'll say, which input is that? And it's like, well, it's one of these 15 inputs that I Preselected as options.

So, like, is are we ever are we in a space now where you can edit the content

In the component of what it looks like, I'm assuming yes because it's a visual builder. Right? Yes. So this is really cool. The workflow is really seamless, and you're right. This was one of the big Headless CMS challenges we had at ShopStyle that we built this thing to solve is exactly that. Whether it's WordPress or headless CMS, it is always like, What field do I edit? Which configuration? What model type is this? Because headless CMS is a model. Is this the what is this the blog article model or the blog page model? It's like, I don't know.

So with builder, one thing that's cool, because our little component controls the rendering, we add, a little attribute in there That we added a Chrome extension that can read, so you can trigger, a Chrome extension and it'll show you what you can edit and build around the page. You just hit edit and it pops it open, and it's like, oh, yeah. This is the hero components. Click the hero component, change the props, hit publish, and it's updated. So it's definitely like, I wanna edit this. You just click and edit it. It's about as visual as you'd imagine, and it's about as intuitive as you'd imagine. There's still rough edges that can happen in this situation, but it's Quite a nicer workflow than probably what most are used to. Yeah. And and if you're out there and you're wondering exactly what this looks like, considering it is so visual,

we have a link in the show notes for the demo builder dot I o forward slash demo. You can pop this thing open and just honestly, one of the best things that we did this morning was just click around and click threw it in and and try to see what you can make with it or see what you can do with it, adding blocks and whatever. It does feel very Figma Like, in terms of you have your components over on the side, you can pick and choose Dragon where to to to drop them and everything like that. I gotta ask about, like, the building of This tool, what is what is this tool built in specifically?

Yeah. Great question. So it's a React app, with let's see. We for state management, we use something called MobX state tree, which is built on MobX.

MobX just doesn't, I'm gonna stop and knock on a huge rant about this. MobX state management is freaking fantastic, and people do not realize, especially when you have, like, Full applications like heavy duty drag and drop or things that need back and forward state.

How nice the style of state management that frameworks like SolidJS use, Quick uses, Vue has used for a while. AngularJS arguably used to just implemented it in a very poor performing way.

It is quite nice. And so that's the 2 really, really big pieces. The rest is, more from scratch than you might think. A lot of people, I didn't realize kind of a sumo using a framework for the drag or drop. It's like, there's a soap bespoke. We we just had to build that from scratch, and just about everything is From scratch besides React MobX, and we use Material UI for buttons and stuff, which is great. Yeah. Right? Nobody likes doing the inputs. You can build all the complex drag and drop in the world, and then you get to input your account. Oh, yes. I told him about that. Yeah. Right? And and there's like a you guys have adapter to design Figma and convert it to HTML.

What's that about? That's a really good question, and that kinda touches on something I briefly touched on a minute ago, which is You kinda realize when building a system like this, there's some big missing pieces to get to the end result. So one big Challenge we found and this will seem like a tangent, but it will answer your question. I promise. I think it's helpful context.

One big missing piece we found is like, okay. We need to make these, What we call SDKs to be able to install to a React, Vue, Svelte, Quick, Solid, whatever website and, register components, dynamically render components. We also have built in components. We have an image component, columns component, button, all this stuff. You could choose to use the built ins. They're kinda like primitives Or your own custom components only. That's up to you. But it's most powerful when you use everything out of the box. To build that for all of these frameworks, so to Rinse and repeat all of these different, components for every single framework out there is way too much than, I mean, just last year, we were Only a team of, like, 20. We're more than double that now, but at that time, that was just impossible to support all these frameworks without a huge effort, especially keeping all up to date.

So one of the first things we did is we realized, well, builder under the hood maybe does more than you might think. The reason we to it as a visual programming language as it is actually capable of doing anything you can actually do in React. So you can Have components that dynamically fetch data from an external data source and render out things dynamically.

You can create your own components that, have child components that are made in builders. So you can make a reusable component with inputs that dynamically binds. You can create effectively anything you can make in React, but fully visually, Including imperative logic, you can say click this button, the state changes, which triggers, UI to update an animation to fly. It gets very, very bespoke if you still want it to be. And in doing that, we realized we had to make a data format that is a lot like, an intermediate representation in compiler architectures.

So, like, the LLVM compiler can transform, you know, Rust and c and Swift and all these languages to a format that then can turn into all of the different sort of, like, assembly, like, lower level code that will become optimized for all the different machine architectures.

In builder, we needed an agnostic system for defining components. Again, simple compositions of your components are super intricate, super dynamic, super interactive things made from scratch Visually, that renders perfectly and consistently to React views, felt quick, etcetera. I mean, everything.

And so in doing that, we were kinda like, Another challenge we have is to make these SDKs, which we similarly need a simple way to define how to make components, and we can output code to all these different frameworks, and that is this intermediate representation. This JSON that just describes, a div should go here with a hero there, and they should have a binding that connects this to that and an event handler that triggers this binding to change or whatever.

And so we made a project called Mitosis It allows you to write a component in one way. Originally, JSON because that's the data format builder uses, but we later added the JSX syntax so it's easy to write as a human. And then that can output code to views, felt, quick, react, etcetera.

So you can solve this problem of, like, I wanna make a material library, but I want it to support Svelte and solid and quick. Well, you could just write it in this project Mitosis.

It parses JSX to JSON and then outputs to all these languages.

When you have that, you realize, well, Builder has this GUI that outputs that, and this GUI can import from things like Figma because That's an obvious thing. You make a design, you pull it into builder, you publish it on your site. That's a great workflow. Well, what if we just connect, you know, 1 cable to the next thing and say, okay. Import from Figma. Output to your framework, we've now created all these pieces.

Apologies if that was that's the one thing I think people will comment on as confusing of what I've said so far, but that's the gist of It's amazing because it is like low code

tools, no code tools, but also for the developers. Like, no code tools for developers, and and That's gotta feel like a really powerful thing. You know, one thing I I I think is, like, really fascinating is trying to dive into, like, the interface of building Tools like this. So when you select something, it has blue boxes and margin dimensions and padding dimensions and dotted lines in here and there. Is at the end of the day, is that just divs all the way down, essentially? The these these interactive

elements that you're building in a UI for this type of project, are those Just divs in in are you using anything fun there or yeah. Yes. No. You're right. It's divs all the way down. I wish there were, like, common abstractions for these type of things. And maybe one day there will be or, like, we make a lot of open source. Our core platform and editor are not open source, but, you know, you talked about Quik and Partytown and other things, I'm sure on other episodes of your podcast.

But, yeah, there really are no common abstractions. It is divs all the way down, but use something like React and MobX or we'll We'll probably move to quick because we are feeling some of the performance challenges of the React app taking a minute to load. Mhmm. We know we can solve that now, but migrating is a whole thing. So we'll figure that out when the time is right. But, yeah, React and MobX plus divs all the way down works surprisingly effectively.

Yeah. It it was funny because when I I was building my own, like, isolation design tool.

Oh, cool. 1st 1st SvelteKit. And it was kind of like, it was kind of like Figma meets, storybook in a way where it was Yeah. It was trying to yeah. I I since put a pause on it because history, which is, like, kind of what I was basing it off of, has come out for SvelteKit. So it's almost like I don't need anymore. But When I was diving into a lot of these tools that have frames and they have canvases and whatever, I was shocked to see it's just dibs All the way you click out a thing and you make some dibs and you change the it's like, oh, it really opened up the possibility. So when I the first thing Thing I did when I clicked on this was went right to the devs and saw, like, how you're doing the the because it was some of the things that are so great in this for this or you might not know that you have When you have design tools and you put a box, you don't just have a box with you could have a box with padding and margin and whatever, and those are illustrated when you select that box or hold option. And in the web, you don't really get a lot of those tools just by clicking around. So in builder, you click on something, you hover over something, You're getting that spacing. You're getting those those margins, that padding. And I think those are the types of web tools that we're truly missing in building interfaces right now with code. And and something that I'm so impressed by with with this tool in general, what about, like, the resizing of panes and stuff like that? I've done a fair amount of that myself where you click and drag to resize a container. What's the process for making something like that? That's a great question. And that Well, I will explain 1 nuance I wanted to point out about divs all the way down is

there's really 2 layers here. So there is an iframe that displays the end results, And that is hooked up to your live website. So if you're everlane.com, you've got everlane.com and an iframe.

And then you have what we call the overlays. You essentially have, a div overlaid on top of the iframe that has all of these cool little things that show you the margins padding spacing, And they give you those little interactive bits, like little bubbles, little drag handles to to drag to resize.

What's interesting is it is a big facade in a sense. In fact, we are always guessing at all because we can't see inside the eye frame, so we have to guess at where the position of something is. And, occasionally, we guess wrong. It's extremely rare. I found we had 1 very edge case just the other day where we guessed wrong. But we are Guessing at where everything is, we just guess so accurately that it looks perfectly illustrated on top of the box and this and that. But what happens when you grab let's say you wanna edit the the margin distance and you grab the little bubble and drag to edit.

What's happening is You start, you know, moving your mouse up. And we track the mouse movements. We're like, okay. You've moved it 10 pixels up over the course of a a couple, you know, a second or so. What we do is we then message down to the iframe that dragging your mouse 10 pixels up means adding an additional 10 pixels of margin to this, div or whatever it is. And we just have a really lightweight kinda message bus going to the Iframe to say, make little patches. So, hey, Iframe.

Add margin top was 10, now make it 20. But we do this in real time, so it's really like margin top is 12, 14, 16, 18, whatever. And then we update the overlay optimistically. We're like, okay. The div should be here.

Yeah. And then div moves there, and it generally is is Perfectly in sync. And we do an additional check after you make the movements to say, did the div actually lands there? We can do get bound in client rep. Oh. And under some rare circumstances, it Couldn't land there because let's say you're dragging the height, but it actually had a max height. It's actually gonna not be able to go past a certain point, So that's when we actually go, woah, wait. It stopped.

And we usually catch that before the user notices any sort of glitch in behavior at all.

Wow. That's cool. That's amazing. Yeah. That's really cool. I can't imagine building something like I'm just, like, in awe building something like this because, like, I I one day woke up, and I said, I'm gonna implement drag and drop in vanilla JavaScript. And that was a hard day. That was a hard day, and that was a very ugly drag and drop solution.

And imagine something like this is a 1000 times more complicated and and intricate and whatnot. And and, literally, it's not even being rendered in the same Origin as the the UI that's overlying on top of it. You know? Like, I can't even get my dibs to line up, let alone something on the entire website.

And you can't do anything synchronously. That's the other ugly part. The message passing must be asynchronous, so you cannot you can't know, synchronously, what's the location or position or even the state of many things.

I'll keep you a secret though. I bought the builder dot io domain in 2013. I've made about 5 versions of this before the current one. We see production now. So I got a lot of mistakes out on versions, like, 1 through 4. Like, many things I knew, like, okay, there's a wrong way and a right way. The last hard one, though, it was on this one that I I realized that you needed to have the rendering and the overlays in in different frames. So that was the remaining big Ugly thing that I had to figure out on the final production version. But beyond that, most of the original drag and drop mistakes were made prior, and how I knew which tools would would work well for this. Is is there any, like Like browser gremlins that you've hit doing this type of stuff, I'm sure. Do you have any stories you could share with us? That's a good question. You know what's funny is we've hit a lot more browser gremlins when building things like quick in Partytown, as weird as that sounds. Partytown in particular.

Yeah. Partytown is browser gremlin city. Builder, the interface mostly lives as an abstraction layer on top, but I will say there are a few things. Like, you forget that actually, here's The ugliest thing that's somewhat browser related, but more just how people use browsers.

When you're building an interface that must live within anybody's website, and their website may not, you know, do what many people do is, you know, asterisk, you know, all elements, box sizing border box. Like, basic stuff like that. Yeah.

Yeah. And so that's where you're like you make this nice drag and drop system, and people start using on another website and go, this is really unintuitive. And it's Oh, yeah. Because if you're not using border box, the behavior of padding and box positioning is really funky.

And so you start adding some little CSS resets. They have to scope it to your stuff and not affect their stuff. So the compatibility between the expectations that our has or more, like, intuition of people using a drag and drop editor combined with anybody's website that's using who knows what. That was where all the crazy stuff happened, but These days, it's not a challenge. We found that there was a common set of ugly things that are easy to to work around.

I wouldn't say that 2 years ago. 2 years ago, I'd say it's hair on fire, huge monstrous issue, but today, we're like, okay. We're on the other side. That's good. What do you need drag and drop pro tips for, like, People who who, like, maybe they're new to drag and drop. They might not be prepared for what's in store.

Anything that you could have to save people a lot of time? Yes.

I I forget what the proper definition of this is, but, like, my big one is, like, use a Full featured reactivity system. So, like, if you ever watch Ryan Carniato talk about how reactivity works in SolidJS, you do not wanna use Redux for drag and drop system. Just don't.

Don't use immutability.

Don't do that whole, like, I love functional programming. Don't use it for drag and drop systems.

What works, yeah, what works really well in my experience is MobX State Tree, which is a bit like if you're familiar with Immer, which is more Popular, but more simple, where you need immutability in one aspect because every drag and drop system needs an undo redo because you're gonna mess something up And you gotta go back and forth quickly.

So you need immutability for that.

Yet, when it comes to, in particular, performance, like, you know how I mentioned When you drag the margin top, it updates the div to to change margin top. We used to do this in a reduct style flow where you have the entire tree of Jason representing the full composition, and we would update that tree and send it down to the iframe and rerender the whole tree. If you're doing that for every pixel movement, that is horrifically slow. You have to do a a mutation. You gotta do a little patch to say, no. No. No. Don't re reflow everything. Just move this div 10 pixels. Anything else is gonna give you performance problems.

But when you're making the UI, like this dragging this thing, the the data in, a system like this, where you have a hierarchy of elements and everything.

Everything you'll want to use references as much as possible. Like, I'm dragging this element, update this element. Don't wanna be looking and scanning through a tree to find the right element or changing the the top level reference in a reduct style way. What you wanna do is is what MobX State tree is so good at providing, which is you mutate data, you can listen to granular changes to data and and react in the UI or or sending a message The iframe in a granular little tiny piece by tiny piece way, but you can observe the entire tree and make copies of the tree or patches to the tree As it changes, so that becomes your history. You could fast forward and rewind, but in real time, you're not having to recompute big chunks of the tree just To render an update because a pixel changed, you need to do that piece granularly. I've never seen a solution as good as MobX State Tree, which is not popular. I don't even think it's super well maintained these days, But it's quite capable, and Michelle Westright is incredible

at what he's saying. Like, to to kinda parlay off of that, Is does, like, FPS become, like, a major

concern when you're working in this stuff given performance and, you know, you're dragging and dropping things? And so that's something that you guys are constantly evaluating? Yeah. Exactly. And we do it mostly I I wish I could say we did it in a more structured way, like using proper FPS tooling, but, Really, we just have a a gut feel on is it janky, is it not janky? And anytime it's janky, you gotta remove the jank.

And that's where the reactivity really comes in. I realized I probably didn't properly answer why the reactivity matters.

It's largely just because When you're dragging, like let me give a really quick example, and this relates to, frames per second as well.

A really easy way to make a dragging overlay is just to track the cursor position and have a reactive binding of this box is always the cursor top and left. So as cursor moves, you you change a piece of state. Cursor top and left is here and here. And now everything on the screen is relational to that top and left value. And just Anything that must update, updates automatically. It's not listening to events. It's just listening to the change in state little piece by little piece.

And the little piece is the important part for FPS, which is you don't want the whole tree to reflowed. You don't wanna manually rig up, These type of reduct situations where you're like, okay. If this selector changes, update this component. You want it to be as core as fine grained as, like, Ryan Cardinato would say as possible So that, if you're getting low FPS, that means your 2 course grains seem to get finer and finer. What's updating, what must render, And nothing else should change, move, or or execute ideally.

Nice.