Gregor Vand (3:08)

I just want to sidebar for just two seconds. You mentioned a very interesting thing, Rust that sort of looks like React. Can you just describe that and sort of.

Robert Bellicki (3:15)

Oh, yeah, absolutely. So Smithy. Well, basically Rust has this concept of procedural macros. So you wrap something in like, let's say vec and then whatever, and then the stuff that's inside of that isn't necessarily valid Rust code on its own. So I did the same thing with Smithy, where you would write like Smithy open paren and then you would write something that looked like JSX and under the hood that was transformed into essentially a function that from like, what phase are we in? To sort of the phase response. So in this case the phase might be like rendering. And then you would call this function and it would return some sort of data structure that was like, hey, you should have an H1, and inside of it you should have the title and so on and so forth. Or the input might be like, hey, we're responding to an event. And then that function would do that. So this, I think, was quite a clever way to work around a lot of the problems that you get with trying to implement React and Rust, which is that the borrow checker is going to be your enemy. Because if you have a DOM node that renders the click count and it has an on click handler that increments that well, now you have a mutable reference to the click count and also another reference in the display. And that's not going to fly with the compiler. So transforming it into a function that is a giant match statement was, I think, a pretty good way out of that situation. So that's what I did. It was a fun project.

Gregor Vand (4:34)

Yeah, fun was the word I was going to go for. Awesome. So I think that kind of even just sets up kind of how you think about problems and how to address them. So isograph is obviously, I imagine at this point, probably the largest project of its type for you on that basis. Could you just give us then what is A high level overview of isograph. What's it trying to solve?

Robert Bellicki (4:52)

Yeah, sure. So right now, isagraph is a framework for building React apps that are powered by GraphQL data. But the fact that you're building a react app and the fact that it's powered by GraphQL data is a little bit superfluous or superficially connected to isograph. In the long term, you'll be able to generate SQL, you'll be able to write Vue, you'll be able to write Swift, and so on and so forth. So let's put all that aside and just talk about sort of isograph as a concept. If you're building apps, you might divide your app into sub components, right? You might have an outer component for a blog, and then maybe the blog header, which is some sub component, and the blog body, which is another sub component. Now, if you modify one of these sub components, you also have to do a bunch of other stuff to keep your app performant and stable. So for example, if you start selecting another field in the blog body, maybe you start selecting the author or the comment count or whatever. Well, you need to go find some other file where you declare that, like, hey, when I'm making the network request for this blog, well, I also need the comment count. Okay, so that's fine. Like if you are only adding fields, it's pretty easy to go find the query and add it. But then what happens if you come back to this subcomponent and you stop using a field? Well, now you go back to the query and you prepare to remove it. Can you? It's a little bit iffy. The problem is that there might be another sub component that's using that comment count, or somebody else has landed a component at the same time that starts to use that comment count. So there's essentially this trade off between how efficient you can manually make your app by like looking at the query declaration or what have you and removing fields. And that comes at the cost of instability. Okay, so where does isograph fit into this framework? With isograph, every component in this tree. So the blog, the blog header and the blog body, they declare the fields that they end up using. So the blog body might declare like, hey, I'm using the component count. And then there's a compiler that runs a build time that looks at all your component tree and and says like, oh, I'm going to generate a query that selects just the fields that are used by this entire component tree. And as a result of that, on every save, you get exactly the fields that you need for a given screen and no more and no less. And it also means that you don't have to worry and you don't have to do any coordination. You don't have to do any communication with your co workers, or not just your co workers, but also you yesterday, you tomorrow. You don't have to like really remember every everything how the app works. You can just make local changes and have the confidence that the changes that you're making will result in an efficient and more importantly, stable app. Okay, so that's iSograph. Now if you're familiar with GraphQL, you might have heard my description and thought, well, that's just GraphQL fragments. And that's exactly right. The killer feature of GraphQL on the front end is, is that each component can declare the data that it needs locally and then there's some compile time process that stitches all those fragments together into a single query that fetches all the data for a given page. That's quite nice. And that gives us something that's really, really important, which is so called data masking, which is to say the blog body. Well, in a properly structured app you get data masking, so the blog body is the only one that will see the fields that are part of its fragment, which is to say you can make changes to the blog body, add or remove fields, and the behavior of no other component in this tree will change at all. So that's the killer feature of GraphQL. Now how does GraphQL actually do this? Well, on the one hand, we start with a query like for the blog page and we have fragments. So fragments are the unit of composition, but there's a little bit of inefficiency or sort of bad developer experience built into this.

Gregor Vand (8:41)

So you've mentioned quite a few points here and I'd like to just take a quick step back, especially around data fetching. That's sort of the big thing we're talking about here, which is there is this concept of overfetching and underfetching and could you maybe just speak a bit to what that even is? And how does isograph help address that?

Robert Bellicki (8:57)

Yeah, absolutely. So if you imagine this blog post page, right, we're getting a bunch of data. If we get more data than we end up using, well, that's over fetching, that's inefficient. Especially if you have many users, you really don't want to do that because it adds a lot of load to your backend. On the other hand, if you don't fetch enough data. Well, either your app is broken, because now your blog post body doesn't have the comment count field that it expected, or you could alternatively have your blog post body component fetch its own data. So in effect you're under fetching there, but you're making up for that by fetching in some sub component. So really what you want is to fetch exactly the right data for a given screen and just taking a step back to talk about, like, why that's difficult. When you're initially writing a screen, it's pretty easy to say, okay, this component uses this field, blah, blah, blah. But as these components, as their requirements change, as you start adding and removing fields, well, it's really hard to keep that query declaration in sync with all of the sub components, with the data that the subcomponents need. And sort of the reason that this is difficult is that there's not an automatic connection between adding a field in a subcomponent and it showing up in the query declaration that's manually maintained. And as a bunch of people are touching files hither and thither, it's really hard to maintain that. So that's sort of the gist. With overfetching and underfetching, basically there's a trade off between you can lean into overfetching and have an app that's less performant than it could otherwise be. But on the other hand, it's more stable. Or you could try to remove potentially unused fields and risk breaking your app. And if it's a Friday and you're thinking about whether to remove a field, well, the answer is you probably won't. And so over time, query declarations become bloated and filled with fields that are not necessarily unused but not provably used.

Gregor Vand (10:55)

An isograph, I mean, how does it then, what layer does it add to? I guess address that problem because devex is such a huge part of isograph.

Robert Bellicki (11:03)

Yeah, absolutely. So when you write an isograph app, what you're actually writing is essentially what are called client fields. So a client field is a function that takes some graph data and returns an arbitrary value. In this case, most of the values are going to be react components, essentially. Now, the important thing to note about client fields is that they can depend on each other. So your outer blog post client field will select the blog post body client field and the blog post header client field. So there's a connection known at compile time between the sub components and the parent component and eventually the root of the query. And as A result, the compiler can come in at build time and traverse that tree and say, okay, well, this component wants this thing, this component wants this thing, blah, blah, blah, bada bing. And you get a query for exactly the fields that are needed.

Gregor Vand (11:55)

Nice. And you touched on it briefly before, but data masking, I mean, that's Also something obviously GraphQL, how does it even handle this concept? And again, iSport, how is it working with this concept as well?

Robert Bellicki (12:08)

So you're absolutely right that I really breezed over that. But it is a really key concept and basically the most important thing about using GraphQL on the front end. So if you have several components, a blog post body and a blog post header, well, it'd be really nice if you could just reason locally. So your blog post body no longer uses the comment count. Well, go ahead and stop selecting it. Stuff will continue to work. Now, if you were passing around the entire network response to each of these components, well, the fact that you stopped selecting the comment count in one of the components changes the behavior of every other component because they start receiving different data. So these other components might accidentally, or on purpose, whatever, depend on fields that they didn't specifically ask for. So that's inherently dangerous. And especially in a large app like that, slows you down. And we really want developer velocity so you can sort of discover the right thing for users and ship product quickly. Okay, so data masking is essentially the idea that each of these sub components, they don't receive that entire blog object that we received from the network. Instead, they receive just the fields that they specifically asked for. And the way that's implemented is that when the isograph compiler runs, it generates a bunch of files. Those files include the query text, as we discussed earlier. But it also includes basically JSON objects that describe exactly the fields that we need to read out and pass as a parameter to each of the client fields. So that means that the blog post body, if it selects or doesn't select the comment count, well, it's not going to affect the data that any of the other sub components receive at runtime. And that essentially eliminates this entire class of bugs. And it's what makes apps built with isograph or Relay or maybe some other frameworks more stable than apps where you pass the entire network request around. So that's the gist of data masking. And it's frankly like the most important thing. And I don't know how anybody in the year 2025 is satisfied with building an app that doesn't have data masking. It's just like it doesn't scale to any number of develop developers, more than one. And frankly, it doesn't scale to you coming back to the app a week later and sort of not remembering all the details of how the app works. That's the kind of security that data masking gives you.

Gregor Vand (14:28)

Nice. I completely agree. It's obviously a concept that sort of is still kind of new to, I think, a lot of people, but they haven't until you kind of experience it and done properly, which is precisely what isograph is helping people do. It isn't sort of fully realized and people are kind of just used to trudging through this problem of having these extra fields under fields, etc. You've introduced the concept of client fields, and that's sort of what you call like a unit of composition in isograph. And I believe this is sort of instead of fragments or does it sort of sit alongside.

Robert Bellicki (15:00)

Yeah, so with isograph you don't actually write any graphQL. So essentially what a client field is is something that looks like a fragment, but it looks like graphql and the function that receives that data, but it's not GraphQL. GraphQL is a great language for what it is, but it's not perfect for what I'm trying to do with it. So it's something that looks like GraphQL in that there are curly braces. And so you could kind of think of it as a fragment, but it's not exactly the same thing. So, yeah, client fields are exactly that. They're sort of this unit of composition. So you might, for example, have like a full name fragment that all it does is select the first name and last name of a user and concatenate them and return it back. And so let's say the user avatar component might select the full name client field and go ahead and render that in some sort of div. Right. So basically you can imagine an isograph app as like, there's a route where you make a network request and then when that network request comes back, well, we render the topmost component and that reads some other client fields. And in order to read those client fields, we read out the data that they need and pass it to them and get the result and pass that to that component and so on and so forth. So it's sort of client fields all the way down before we bottom out at GraphQL server fields. So actually, there are quite a few advantages to using client fields over, let's say, fragments in the GraphQL sense, and some of those we've already discussed, like the developer experience of using a client field is quite nice. So the blog post body, it just selects, which is to say you just write the name of a subfield, the blog post, the comment display component. Now, the parameter that you get passed in, which is the data that you read out, includes a React component that you can just go ahead and directly render. And what's nice about this? Well, on the one hand, there's no fragment spreads, there's no passing of fragment references, there's no this or that, there's no hoopla around it. But also, we didn't actually import ourselves the JavaScript for that comment list component. And that's quite nice because it means that it doesn't matter where your comment list lives. And more importantly, if we start asynchronously loading the comment list, let's say in this world, well, you have to make a. Your backend has to make a network request to another server. Okay, so comments are slow to load in GraphQL, usually without the defer directive. What you get is that your query is as slow as the slowest field. So it makes sense in our case to asynchronously load the comment list component. Okay, so yeah, let's go ahead and not load the data immediately. Let's load it slightly later. And now it's a best practice, if you're asynchronously loading the data for the comment list, to also asynchronously load the JavaScript. And I don't know about you, but I've never actually seen that happen in reality. Like, that's a very rare thing to do, to also asynchronously load the JavaScript. So in isograph, because the client field is both the function and the data that it needs sort of packaged together. Well, the ICE Graph compiler can be smart. It can say, oh, you're asynchronously loading the comment list. Why don't I not include the JavaScript for the comment list in the parent bundle? And instead when you make the network request, when you initiate the network request for the sub component for the comment list sub component, well, that's when we kick off the network request for the React component that renders it at the same time. So that's kind of nice. It means that it's really, really easy with isograph to have a very minimal bundle, both from a data and a JavaScript perspective.

Gregor Vand (18:32)

Yeah, I kind of want to dig into the performance piece there. I mean, yeah, it's pretty fascinating. So I mean, as you've called out with isograph, a component, I'm just sort of thinking is I work with svelte. So I'm always trying to analogize in my head just sort of how this might look as well. But it's super fascinating because we're saying okay, as you say that first bundle size can come down and then the user is effectively loading each component as one thing.

Robert Bellicki (19:00)

Capital One's tech team isn't just talking about multigentic AI. They already deployed one. It's called Chat Concierge and a simplifier in car shopping using self reflection and layered reasoning with live API checks. It doesn't just help buyers find a car they love, it helps schedule a test drive, get pre approved for financing and estimate trade in value. Advanced, intuitive and deployed. That's how they stack. That's technology at Capital One.

Gregor Vand (19:24)

How does that actually play out in reality? And I'm curious of like we've used the blog example a lot, but are there any other examples that this makes a lot of sense to do it that way? I'm super curious.

Robert Bellicki (19:35)

Yeah, absolutely. So you could imagine if you have a large and dynamic app, that it's really important to try to have the smallest bundle, both from a Data and a JavaScript perspective. And we have a lot of not so good options. One of those is for example, splitting by route. So you might say like, okay, on this page the following components are needed and only load those as part of the bundle. So with a news feed, well that's a very dynamic app. So even if you split by route, the bundle is still going to be very, very large. Now if somebody navigates to a newsfeed, well, they might receive text based posts, image posts, video posts, you name it. There's maybe 50 different styles of newsfeed items, but a given user is not going to see all of them. And so what you really want, sort of the holy grail here is to load just the JavaScript for the types of components that the user actually encounters. So that's one thing that's really easy. With IsGraph, you can imagine a list of newsfeed items and the first time that we encounter a text based post, well that's when we fetch the JavaScript for the text based component renderer and the video post, well, we don't really want to include that with every bundle because it might be a really large thing, maybe brings in all of YouTube or something. So loading that only when we encounter a video post is really helpful because it keeps the bundle very small. So that's one example that's loading just the JavaScript for the types of fields that we received from the backend. Another thing we might want to do is to not load the JavaScript for a popover or for a modal and until we actually end up trying to render it. So in this case, well, not doing that. Well, that's not part of the initial render. So of course we don't want it initially. And instead what igraph lets you do is to initiate the network Request for the JavaScript for that modal when you sort of hover over the button for the modal, whatever you want and sort of lastly. Well, we talked about loading just the JavaScript for the type of component that you would actually encounter if you have like an interface. So like a newsfeed item is maybe an interface and there are concrete types, but you can also do the same thing for optional fields. So you might imagine that blogs may or may not have images and the image renderer is extremely expensive because, you know, you're not so good at writing small components. And so it would be really helpful in this situation to only fetch the JavaScript for the image component if you actually encountered that. And with IsGraph, because client fields, because the JavaScript and the data are linked at compile time, the default is if you asynchronously load the data for something, well, you can also asynchronously load the JavaScript for it. And so all of that sort of happens for. Not for free per se, but it's very, very easy. So that's the idea like you really want to have essentially to load just the JavaScript for the initial render and then as the user interacts, they fetch more data. Okay, so let's take a step back and say, okay, do we really need isograph for that? Okay, okay, you can just get some data and then trigger a follow up request for the image renderer plus the image data if we encounter an image. Okay, well if this image component, if it also uses a bunch of fields that are part of the parent network request, maybe it includes the author's name, the blog post author's name. I don't know why it would do that, but let's just say for the sake of argument that there are some fields that are part of that image network request that are also part of the parent network request. Well, if there's no connection known at compile time between the parent query and the subquery for the image, well, there's necessarily going to be duplication between these two Things. Now, a lot of this stuff is work in progress. Actually that's the first thing that's work in progress that I mentioned. Right now. Isograph will duplicate the fields in both network requests. But the goal here is to have the network request for the image be just the fields that are not part of the parent network request. Okay, so the image, that's a bit of a silly example, but what if you're, let's say, navigating from page one to page two and okay, page one is, I mean, you know, they're arbitrary pages. Okay, so those might have a lot of fields in common. They might select like who's the current logged in user and blah, blah, blah.

Gregor Vand (23:53)

I guess on the page example, E Commerce is a great example of that, right? Where you've got page to page, different products, different images, lots of variables around. Especially nowadays where people want to be able to select say the different variants of a product and you've got a load old app or a product, that kind of thing. That feels like a pretty strong use case here.

Robert Bellicki (24:12)

Yeah, that's exactly right. That is a really good use case. So you imagine, let's say you're going from a list of products to a detail view. Now one thing that's really nice is that you can imagine that because these navigations are linked sort of at compile time, that the network requests you make for the detail view will exclude the data that's already been fetched by the list view. So for example, the name of the product and maybe the small image. And so when you navigate to the next page, all you're actually fetching is the large image and the detail of the product. That's actually a really good example. Thank you for bringing that one up.

Gregor Vand (24:50)

Well, I used to work in that area of technology for a long time, so it's the easiest one that suddenly comes to mind when I'm thinking, I mean, I did a lot of work, not working for Shopify, but a lot of work with that platform and they were a great proponent of GraphQL when it was in its early days as well. So yeah, it sort of came to mind. I mean, just looking at again, developer experience, I mean, it's a lot of what we're talking about here. There's all the building, which is, I think, most of what we've been talking about. There's then the debugging, which is half of a developer's life as well. I spend half my life in the network tab these days. How is isograph helping on that front?

Robert Bellicki (25:26)

Yeah, absolutely. So right now, a big project that we're working on is rewriting the compiler to be incremental. And once we're done with that, we're going to build out a language server. And the reason you want the compiler to be incremental is, Is because, well, if you're hovering over something, you're going to get some information and you're going to. Then you hover over some other field in your isograph literal, you're going to get some more information, but you're going to reuse most of the work from the first time around. You're going to reuse the parsed isograph literal, you're going to reuse all the validation and work and so on and so forth. So that's why we're rewriting the compiler to be incremental. And as a result of that, we're going to. Well, the next thing after that is to build out a language server. So the idea that I have here is that you're essentially able to do everything you want from within VS code, select a new field if it doesn't exist. Like there's going to be some sort of auto fix that's like, hey, create a new client field. And another thing that I really want essentially for isograph, and this is actually, we have a proof of concept of this, but it hasn't landed in the main branch yet, is that, ask yourself this, how many redundant user avatar components are there in your code base at a very large company? There are a lot and they're really doing the same thing. It's an image that's in a circle and then maybe it has some like random other, you know, specifics. But like, you can imagine that when you are on the user object, if you start typing ava, it will autocomplete avatar and then you're going to have a lot fewer duplicated components as a result of just being able to discover all the components that are in your code base. And what's really nice about this is that, well, it's really easy to write a reusable component if you don't care about the data and leave that to the user. But now what you can do is select a user avatar component that, heck, if it needed the day that the user signed up, if it needed the user's initials, if it needed, you know, whatever else it needs, it will just automatically get that and the compiler will do all of the stitching to make that all work. So that's sort of the big thing in terms of developer experience right now. There's a lot more that we can do in this world there. We're building out the language server. We need a Chrome extension that lets you do better debugging and so on and so forth. But even right now we have one company that is using isograph and their response is that it's a great user experience already. So.

Gregor Vand (27:51)

And I mean, yeah, just I guess diving into the open source aspect and the contributions, I believe it's yourself. And I think I've seen there's definitely some others working on isograph as well. And what's your kind of approach to having people come in and contribute to isograph?

Robert Bellicki (28:05)

Yeah, so I'm biased of course, but I think isograph is a great project to contribute to because we have a very detailed roadmap. Basically all the features that are in Relay, they need to eventually get to isograph. So local updates. We recently added garbage collection and loading, just the data that you need. Like there's a lot of detail around that, the language server, everything like all this stuff needs to be built out. So we have a very detailed roadmap. But the project is still at the point that you can dive in and start making fundamental contributions. So if folks are interested in pushing the state of app development forward, well then by all means join the discord. You know, reach out or even just if you want to try something that I think is exciting and new, you know, try it out, kick the tires, see what works and what doesn't work for you. I'm extremely available and happy to answer whatever questions. So that being said, we have a whole bunch of developers. I think there's, you know, there's basically four others that are just the most active right now working on it and like it's just great. There's a lot of people making a lot of great contributions, a lot of stuff going on. So it's a very fast moving project.

Gregor Vand (29:15)

Awesome.

Podcast Sponsor/Intro Voice (29:17)

Building an app often feels like a balancing act. You want to ship features fast, chat, activity feeds, moderation, video, but building them from scratch is slow and complex. That's where Stream comes in. Stream provides developer friendly APIs that let you add real time communication without reinventing the wheel. Why Stream? First developer experience. Stream has clean open source SDKs and great docs and you can get a proof of concept running in hours. Second speed to build, experiment, prototype or launch features quickly. No credit card required to start. Stream also scales. Over 2000 global apps including Strava, Patreon, Nextdoor, Robinhood and Peloton rely on Stream to power in app communication for More than a billion users. Whether you're a startup or an enterprise, Stream handles the hard parts so you can focus on what makes your app unique. Get started today at Getstream IO podcast.

Robert Bellicki (30:25)

APIs are the foundation of reliable AI and reliable APIs start with Postman. Trusted by 98% of the Fortune 500, Postman is the platform that helps over 40 million developers build and scale the APIs behind their most critical business workflows. With Postman, teams get centralized access to the latest LLMs and APIs, MCP support and no code workflows all in one platform. Quickly integrate critical tools and build multi step agents without writing a single line of code. Start building smarter, more reliable agents today. Visit postman.comsed to learn more.

Gregor Vand (31:00)

Looked at the repo obviously before we got going and yeah, six hours ago, various things going on. So that's always a nice healthy cadence. I mean I think you just touched on it there. I think probably a lot of the audience, Relay is probably the framework that they're most thinking about in terms of, well, I already use Relay or I was thinking of using Relay and now I know there's isograph, especially for, I guess, greenfield projects. What would you say to a developer who's got those two on their table right now and they're having to make that choice?

Robert Bellicki (31:30)

So Relay is really, really a great framework and one of the things that Relay doesn't do is it doesn't compromise on performance. So as a result I think there's a reputation in some cases deserved, in other cases not so deserved, that Relay is hard to adopt. And I'm at Pinterest, I'm helping them adopt Relay and I've been on the Relay team so I can tell you that yeah, at scale there's a lot of issues with, with adopting Relay. I think it's still ultimately the absolute best popular framework out there. That being said, I think that now is a really great time to adopt iGraph. There is an actual company using it. They're really kicking the tires and they're called Content Founder. You should check them out. I think they're doing really, really cool stuff and we're solving all of their problems sort of in real time. So by the time you get around to using it, like it's going to be even better. That being said, I think it's like it's a good time to start using Isography. I think the best users of igraph are as folks who are really, really into good developer experience and also large companies. So at a large company like the real advantage of something like isgraph or Relay is that you can make changes to a component locally, ship and not worry. And if Developer Velocity has to slow tremendously because all this coordination and communication that's required, well, that means that you can't ship features. So isograph really makes it easy to have really high developer Velocity. So if you value developer experience or Developer Velocity, then I think that it's the right framework for you. That being said, right now you need a GraphQL backend, so also you should have that.

Gregor Vand (33:14)

I wanted just to touch on that future stack integration compatibility. You know, at the moment it's GraphQL, it's React, which obviously means JavaScript. What are the thoughts and plans for where this might go and what this might work with in the future?

Robert Bellicki (33:27)

Let's talk about GraphQL. So right now we are generating a GraphQL query that we then send to the backend, but the user doesn't write GraphQL. So if we were generating an SQL query or GRPC or whatever, it would just work. So there's just some amount of work involved in doing that and sort of writing the adapter and what have you. And I've tried to be, I guess have the foresight and sort of design the compiler in a way that's like generic over the type of query that we're generating. It isn't perfect, but like there's some, some attempts at that so we can generate different queries that we end up sending to the backend. Secondly, the generated files, they're basically JSON objects that import the function that ends up getting called. That's certainly doable in any other language. So I think it will be pretty, it'll be work, but it'll be fairly easy to essentially have a version of this that works with Swift or works with Kotlin. From that perspective, we just have to rewrite the very small core, which is sort of an incremental computation engine. If you take an extremely, extremely wide aperture. And lastly React versus View versus Felt. The connection between isograph and React is actually extremely, extremely small. There's basically just one transform that makes the component stable so that it doesn't lose state on every render. And yeah, I mean it'll take a slight refactor to make that not be part of isograph the core, but it's on the roadmap, so give it some time. Isograph will be a framework that you can write and use in a cross platform fashion.

Gregor Vand (35:07)

Nice. Well, I think that's a great thing for people to follow along even if people don't have the time effectively to contribute. I'm sure checking out on GitHub, giving it a star following along. I think that's always helpful to these kinds of projects, right?

Robert Bellicki (35:19)

Yeah, absolutely.

Gregor Vand (35:20)

Fantastic. Well, Robert, thank you so much for coming on today. I'm going to wrap up with one question. I've been asking slightly different questions at the end of episodes, but this one I heard today on a different podcast. I've already been out for a walk this morning and you're a builder, and this was a very builder question and I really like this. It was where do you get your energy to build this? I think that's probably what a lot of builders listening today. Probably the biggest barrier to building is finding that momentum and finding that energy. And where do you find yours?

Robert Bellicki (35:51)

I have never been asked that as far as I know. So let me think about this for a second. I think a lot of this comes from two things. One is that, well, programming, I feel like I'm solving puzzles and so I find it inherently fun and enjoyable. And then I also feel like I'm oftentimes frustrated by the state of not just web development really, but the state of development. And I feel like that frustration really drives me. Like I want to provide a better experience. I want to have a better experience for myself. And I think that a lot of times, like when something isn't working quite right, it just fills me with sort of a righteous anger, I guess that keeps me going. But the motivation changes over time. Like I think it really starts with that now, recently now that Content Foundry is really using isograph and we meet pretty frequently to sort of discuss the details. Well, seeing somebody else get joy out of using what I've worked on for, you know, a couple years now is just kind of amazing. So I think changes on the day to day, but in the end, I guess there's a hundred ways to justify it. But in the end, I am an interminable nerd.

Gregor Vand (37:05)

That's awesome. I think I like that in the sort of the two phases almost one is frustration, like, why can't this be better? Why has no one done this? And then as soon as people do start using it, that's where things flip over. Often I'm somewhere right in the middle of that exact journey right now. So I'm looking forward to the more users and the more joy from those users. So again, Robert, thank you so much for coming on today. It's great to have a longtime listener come on Software Engineering Daily. Great to have you here, and obviously we'll be following along with isograph and obviously encourage our listeners to do the same.

Robert Bellicki (37:36)

Thank you so much, Gregor. Thank you for taking the time to chat. I'm really happy with that. I've been able to get on a podcast that I've listened to for so many years, so.