EPISODE 1847

[INTRODUCTION]

[0:00:01] GV: A challenge in modern frontend application design is efficiently fetching and managing GraphQL data while keeping UI components responsive and maintainable. Developers often face issues like over-fetching, under-fetching, and handling complex query dependencies which can lead to performance bottlenecks and increased development effort. 

Relay is a JavaScript framework developed by Meta for managing GraphQL data and React applications. It's designed to optimize data fetching by co-locating queries with components, ensuring that each part of the UI declares its own data dependencies. Robert Balicki was on the Relay Team at Meta and is now a staff software engineer at Pinterest. He is currently developing Isograph, which provides a declarative and type-safe approach to data fetching. Robert joins the show to talk about challenges and solutions for managing data in frontend applications. 

Gregor Vand is a CTO and founder, currently working at the intersection of communication, security, and AI, and is based in Singapore. His latest venture, Wyntk.ai, reimagines what email can be in the AI era. For more on Gregor, find him at vand.hk or on LinkedIn. 

[INTERVIEW]

[0:01:25] GV: Hi, Robert. Welcome to Software Engineering Daily. 

[0:01:28] RB: Hi. Thank you for having me. This is actually quite exciting for me. For many years, as I was getting started as an engineer, I listened to almost every single episode of this podcast. So this is quite meaningful for me. 

[0:01:40] GV: Awesome. It's really nice to hear that. I think we've also got quite a few listeners that's probably in the same position, but not many do then end up getting to come on the podcast. Great to have you here. We're going to be talking all about your project, Isograph, which we'll get into shortly. As usual, we'd like to sort of hear just a bit about who you are and what's led you on this journey to building Isograph. It's a lot around GraphQL. You're currently working at Pinterest. What's kind of been your path in software engineering? 

[0:02:09] RB: Yeah. I think the most relevant thing to the Isograph story is that, before this, I was at Meta where I worked on the Relay Team. And under the hood, Isograph and Relay are very similar frameworks. They're both frameworks for building data-driven apps that are powered by GraphQL data. And now, I'm at Pinterest helping them adopt Relay. I think that fits quite well. 

But just taking sort of a step back, I think you can kind of look back with hindsight and see a lot of connections to some of the stuff I was working on beforehand. Before, one of my side projects was a project called Smithy, which is a framework for building web apps where you write Rust and it sort of looks like React. And before that, one of my projects at work was building a configuration-driven framework for going through flows. And so one way or the other, I sort of want to help people build UIs where they can't shoot themselves in the foot. And I know that that's a very niche thing to want, but I guess that's where I ended up. Isograph fits really well into that. 

[0:03:09] GV: I just want to sidebar for just two seconds that you mentioned a very interesting thing, Rust that sort of looks like React. Can you just describe that and sort of - 

[0:03:16] RB: Oh yeah, absolutely. Well, basically, Rust has this concept of procedural macros. You wrap something in like, let's say, vec, exclamation point, and then whatever. And then the stuff that's inside of that isn't necessarily valid Rust code on its own. I did the same thing with Smithy, where you would write Smithy, exclamation point, open paren, and then you would write something that looked like JSX. And under the hood, that was transformed into essentially a function from like what phase are we in to sort of the phase response. 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. 

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. Transforming it into a function that is a giant match statement was, I think, a pretty good way out of that situation. That's what I did. It was a fun project. 

[0:04:34] GV: Yeah, fun was the word I was going to go for. Awesome. I think that kind of even just sets up kind of how you think about problems and how to address them. 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? 

[0:04:53] RB: Yeah, sure. Right now, Isograph 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. 

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 subcomponents, right? You might have an outer component for a blog, and then maybe the blog header, which is some subcomponent in the blog body, which is another subcomponent. Now, if you modify one of these subcomponents, you also have to do a bunch of other stuff to keep your app performant and stable. 

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. 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 subcomponent that's using that comment count, or somebody else has landed a component at the same time that starts to use that common count. There's essentially this tradeoff between how efficient you can manually make your app by 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. 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 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 coworkers. Or not just your coworkers, but also you yesterday, you tomorrow. You don't have to really remember 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 frontend 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. 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. That's the killer feature of GraphQL. 

Now, how does GraphQL actually do this? Well, on the one hand, we start with a query, for the blog page, and we have fragments. Fragments are the unit of composition. But there's a little bit of inefficiency or sort of bad developer experience built into this. 

[0:08:41] GV: 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 over-fetching and under-fetching. And could you maybe just speak a bit to what that even is. And how does Isograph help address that? 

[0:08:58] RB: Yeah, absolutely. 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. 

In effect, you're under-fetching there, but you're making up for that by fetching in some subcomponent. 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 subcomponents, 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 and a subcomponent and it showing up in the query declaration. That's manually maintained and has a bunch of people are touching files hither and thither. It's really hard to maintain that. That's sort of the gist with over-fetching and under-fetching. 

Basically, there's a tradeoff between you can lean into over-fetching 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. 

[0:10:56] GV: And isograph, I mean, how does it then - what layer does it add to, I guess, address that problem? Because DevX is such a huge part of Isograph. 

[0:11:04] RB: Yeah, absolutely. When you write an Isograph app, what you're actually writing is essentially what are called client fields. 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. There's a connection known at compile time between the subcomponents 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. 

[0:11:56] GV: 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, Isograph, how is it working with this concept as well? 

[0:12:09] RB: 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 frontend. 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. 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. These other components might accidentally or on purpose, whatever, depend on fields that they didn't specifically ask for. That's inherently dangerous. And especially in a large app, 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 subcomponents, they don't receive that entire blog object that we receive 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. 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. 

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 just like it doesn't scale to any number of 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. 

[0:14:29] GV: Nice. I completely agree. It's also 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, underfields, etc. You've introduced the concept of client fields, and that's sort of what you'd call like a unit of composition in Isograph. And I believe this is sort of instead of fragments, or does it sort of sit along side? 

[0:15:01] RB: Yeah. With Isograph, you don't actually write any GraphQL. Essentially, what a client field is it's 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. 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. 

Yeah, client fields are exactly that. They're sort of this unit of composition. 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? 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 top-most component and that reads some other client fields. And in order to read those client fields, we read out the data they need and pass it to them, and get the result, and pass that to that component, and so on and so forth. It's sort of client fields all the way down before we bottom out at GraphQL server fields. 

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. The developer experience of using a client field is quite nice. 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 - you're backing us 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. It makes sense in our case to asynchronously load the comment list component. Okay. 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. That's a very rare thing to do to also asynchronously load the JavaScript. 

In isograph, because the client field is both the function and the data that it needs sort of packaged together, well, the Isograph 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 subcomponent, for the comment list subcomponent, well, that's when we kick off the network request for the React component that renders it at the same time. 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. 

[0:18:32] GV: Yeah, I kind of want to dig into the performance piece there. I mean, yeah, it's pretty fascinating. 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 them 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." 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. 

[0:19:11] RB: Yeah, absolutely. 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. 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 newsfeed, well, that's a very dynamic app. Even if you split by route, the bundle is still gonna 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. That's one thing that's really easy with Isograph. 

You can imagine a list of newsfeed items. And the first time that we encounter a text-based post, well, that's when we fetched 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 it brings in all of YouTube or something. Loading that only when we encounter a video post is really helpful because it keeps the bundle very small. That's one example. That's loading just the JavaScript for the types of fields that we receive from the backend. 

Another thing we might want to do is to not load the JavaScript for a popover or for a modal until we actually end up trying to render it. In this case, well, not doing that, well, not that's not part of the initial render. Of course, we don't want it initially. And instead, what is Isograph 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 a JavaScript for the type of component that you actually encounter if you have like an interface. A news feed item is maybe an interface, and there are concrete types. But you can also do the same thing for optional fields. You might imagine that blogs may or may not have images. And the image renderer is extremely expensive because 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 Isograph, 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 not for free per se, but it's very, very easy. That's the idea. 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. 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 sub-query 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 that request. But the goal here is to have the network quest 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, they're arbitrary pages. Okay, those might have a lot of fields in common. They might select who's the current logged-in user and blah, blah, blah. 

[0:23:28] GV: 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 if you want to be able to select, say, the different variants of a product and you've got to load old app or a product, that kind of thing. That feels like a pretty strong use case here. 

[0:23:48] RB: Yeah, that's exactly right. That is a really good use case. You imagine, let's say you're going from a list of products to a detail view, right? 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. 

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 brining that one up. 

[0:24:25] GV: Well, I used to work in that are or technology for a long time. So it's the easiest one that something 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. 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 is 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 spent half my life in the network tab these days. How is Isograph helping on that front? 

[0:25:01] RB: Yeah, absolutely. 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 because, well, if you're hovering over something, you're going to get some information. And then you hover over some other field in your Isograph, literally, 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 literally. You're going to reuse all the validation and work, and so on and so forth. 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. 

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, 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 random other specifics. 

But 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 of the day that the user signed up, if it needed the user's initials, if it needed whatever else it needs, it will just automatically get that. And the compiler will do all of the stitching to make that all work. 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. 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. 

[0:27:26] GV: 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? 

[0:27:40] RB: Yeah. I'm biased, of course. But I think Isograph is a great project to contribute to because we have a very detailed road map. Basically, all the features that are in relay, they need to eventually get to Isograph. Local updates. We recently added garbage collection and loading just the data that you need. There's a lot of detail around that, the language server, everything. All this stuff needs to be built out. 

We have a very detailed roadmap, but the project is still at the point that you can dive in and start making fundamental contributions. If folks are interested in pushing the state of app development forward, well then, by all means, join the Discord, reach out. Or even just if you want to try something that I think is exciting and new, 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. 

That being said, we have a whole bunch of developers. I think there's basically four others that are just the most active right now working on it. And it's just great. There's a lot of people making a lot of great contributions. A lot of stuff going on. It's a very fast-moving project. 

[0:28:49] GV: Awesome. Looked at the repo, obviously, before we got going. And yeah, six hours ago, various things going on. That's always a nice, healthy cadence. I mean, I think you just touched on it there. I think probably 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? 

[0:29:21] RB: Relay is really, really a great framework. And one of the things that Relay doesn't do is it doesn't compromise on performance. 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. I can tell you that, yeah, at scale, there's a lot of issues 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 Isograph. There is an actual company using it. They're really kicking the tires, and they're called Content Foundry. 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. By the time you get around to using it, it's going to be even better. That being said, I think it's a good time to start using Isograph. 

I think the best users of Isograph are as follows. Folks who are really, really into good developer experience, and also large companies. At a large company, the real advantage of something like Isograph 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 of all this coordination and communication that's required, well, that means that you can't ship features. Isograph really makes it easy to have really high developer velocity. 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. Also, you should have that. 

[0:31:05] GV: I just want to touch on that future stack integration compatibility. 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?

[0:31:18] RB: Let's talk about GraphQL. Right now, we are generating a GraphQL query that we then send to the backend. But the user doesn't write GraphQL. If we were generating an SQL query, or GRPC, or whatever, it would just work. 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 generic over the type of query that we're generating. It isn't perfect, but there's some attempts at that. 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. I think 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 Vue, versus Svelte, 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. Give it some time. Isograph will be a framework that you can write and use in a cross-platform fashion. 

[0:32:58] GV: 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? 

[0:33:10] RB: Yeah, absolutely. 

[0:33:12] GV: 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 liked 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? 

[0:33:42] RB: I have never been asked that as far as I know. 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. I want to provide a better experience. I want to have a better experience for myself. And I think that a lot of times, 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. 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 a couple of years now is just kind of amazing. I think changes on the day-to-day. But in the end, I guess there's 100 ways to justify it. But in the end, I'm an interminable nerd. 

[0:34:57] GV: That's awesome. I like that in 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. I'm looking forward to the more users and the more joy from those users. 

Again, Robert, thank you so much for coming on today. It's great to have a long-time listener come on Software Engineering Daily. Great to have you here. And obviously, we'll be following along with Isograph. And I also encourage our listeners to do the same. 

[0:35:27] RB: Thank you so much, Gregor. Thank you for taking the time to chat. I'm really happy that I've been able to get on a podcast that I've listened to for so many years. 

[END]



SED 1847		Transcript

	(c) 2025 Software Engineering Daily	1