Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of the WebDev podcast. Today on the show, we're going to dive into the idea of going multiplatform with a framework. So, that means, you know, if it's building to the web, maybe sometimes you want to target the terminal, or maybe you want to target a native app. In order to do that, you don't necessarily want to have to rewrite all of your components. So you build out another way to solve that problem. To talk to us about how you solve that problem and all the fun concepts, complications, and other considerations that go into making such a thing happen, we are going to talk to Paolo Ricciuti. Everybody, please welcome Paolo to the stage. How you doing?

PAOLO: Hi, yeah, doing great.

JASON: Good, good, good. I'm happy to have you here. I'm really I mean, this is a topic that I find very interesting because it's an area that I haven't spent a ton of time. My experience in this space has mostly been limited to, you know, I wrote a few Webpack plugins back in the day, a few Babel plugins. So I'm kind of familiar breaking down a component and kind of familiar with this idea of being able to switch up how you break a markdown into its component parts so you can re render it as JSX or HTML or whatever the thing is you want to do. But I've never really learned anything about how you would take something and literally target a different platform, like a native app or a terminal versus the web. Before we dive into that, let's maybe talk a little bit about you. For folks who haven't heard of you before, you want to give us a background on who you are, what you do?

PAOLO: Yes, absolutely. I'm Paolo Ricciuti. I come from Campobasso, Italy, which is very cold, despite me being in a T shirt. I've been always passionate about web development. Actually, I started at this point way more than half of my life ago. I started when I was 17. I'm now 37. I started with PHP4. So, very old. I've always been passionate. I also got a degree in computer science. I parted ways for a bit because I started working with photography, but then I came back crawling because I like development too much. Nowadays, I work at a consultancy. We specialize in Svelte, Rust, Amber, and personally, I lead the Svelte team. The reason why I lead the Svelte team is because I'm also very deep on open source. I'm one of the maintainers and the ambassador. So I'm very like I care very much about Svelte. If it has the word Svelte in it, I'm probably involved in some way. I maintain the Svelte feed for Bluesky.

JASON: Very cool, yeah. So, Svelte, I assume everybody is going to have passing familiarity with Svelte. To maybe set the high level, Svelte, until now, has been known as a web framework. It's similar to React, Vue, et cetera. I've had Rich Harris and a few other folks from the Svelte community on the show. We've done some animations. We've done some really interesting stuff with reactive data. It's a great framework. A lot to love about Svelte. It gets a lot of the ergonomics right, the defaults and primitives right, and it feels good to use, feels good to build with. But it doesn't historically have the same flexibility of something like React, which has React Native. Or there's React I can't remember what the thing React Tui or something like that. You can put it in the terminal. So I think that versatility has always been attractive to devs that you could write one React component and use it literally anywhere. It sounds like this is

PAOLO: Yeah, it's not exactly like that. It's not the same component you can use it anywhere. But React has this concept. I think in React, it's called a reconciliator, one of the big forces behind React. The fact you can be in your same environment, like if you know React, you can write for the web, but you can also learn React Native, which has some difference. But it's still like your familiar reactive framework around which is very it is a nice thing.

JASON: Yeah.

PAOLO: React generally like, it was basically perfect for that because React, at the end of the day, the package doesn't even know how to render to the DOM. Like React package is just a go between, basically. So the job of React is just having two visual DOMs and then emit some events for the reconciliator. So you install React, but you have to also install React DOM, which is the reconciliator, which allows you to write React to a web page.

JASON: Right. So this is a pretty big difference between React and most of the other frameworks because when you install Svelte or Vue, you're not also installing Svelte DOM or Vue DOM. The assumption is you've been using it in the web, and the DOM is kind of a presumption. So that, maybe, is the right first question here. As we talk about making Svelte multiplatform, when you start looking at that, how set up for success are you with a framework that was built with the presumption of the DOM in mind? I guess how do you even start to assess whether it's possible to address it this way?

PAOLO: Well, one of the advantages of Svelte is that Svelte itself is a compiler. So yes, historically, it's always targeted the DOM because that's what we wanted to target, really. The initial idea for Svelte was just to have a UI library for the DOM. But being a compiler means that we kind of have a certain degree of freedom to do even stuff that technically should not be possible. Recently, we are like, there is an experimental flag to use a sync and await directly in the template and directly in the script. The compiler is doing a lot of heavy lifting to make sure that when you have two subsequent await, you are not introducing a waterfall in your application.

JASON: Oh, right, right.

PAOLO: So all this kind of stuff is stuff that the compiler is very good at. Now, in terms of when we started experimenting with this idea of building the custom renders for Svelte, first things first, I think let's start by why do we even want custom render. We already told everybody a bit about it because obviously React, by the fact it has this ability, it also has the ability to build a custom renderer for the native apps, React Native, or for the terminal, which is what Claude code is using, for example. So it is a good power for a web framework to have. Specifically, the reason why we started looking into this is because when we started looking into this, a new framework came out, which is called Lynx. When they came out, it's from ByteDance which is the company behind TikTok. So we can rest assured about the visibility of a framework. But we started looking into how can we use Svelte in Lynx. One requirement is you have to have a custom renderer. The point is Lynx knows how to, like, create, for example, an Android button or an iOS button just like React Native knows how to create an Android button. But to convert between a button inside your Svelte component into a Lynx button, you need some way to communicate to Lynx. Hey, this is not a web button. It's just a button. Give me your button, basically.

JASON: Gotcha. And so, just as I guess we made an assumption, which is that people know how this stuff works, right. And so I think it might be worth talking really quickly, when you write a component, like if I open up Svelte or Vue or React or Angular, whatever, I'm writing custom syntax in a file. So I do my curly braces, and I write my Svelte tag and get to throw in attributes and get to throw in custom things. You know, I can use runes in Svelte. Each of those things is kind of being put into my component. I've got my dot Svelte file with all these things in it. Now, in order to use that on the internet, like a browser cannot render a dot Svelte file. So can you talk just at a super high level, when I write a component, what is happening, like the steps between me saving that component and then starting my dev server, how does it become something that the browser can read? I think that'll be good context for as we start talking about Lynx or Native or any of those other, making sure we're being clear on what's happening.

PAOLO: So, it really depends on the framework you're using because in Svelte, it's a compiler. So what you are writing in your Svelte file, it's actually just a string. So there are multiple steps that go into converting your up dot Svelte into something the browser can understand. The first step is parsing. So we just take the string, and we go over character by character and parse your component into an abstract syntax tree. So the abstract syntax tree is just representation of your component as an object. It's a huge object that has nested property that just basically represents your component. So you have your script tag, and inside your script tag, there is, I don't know, some JavaScript. The JavaScript has a variable declaration. The variable declaration has an identifier, which is called a name. The name has an init property, which is a function call, and stuff like that. Then we take this abstract syntax tree. Piece by piece, we convert your syntax tree into JavaScript. And you can actually check this out if you go to Svelte.dev/playground. You can write code, and then there is a tab on the right, which is the result. But there's also another tab, which is the JS output. The JS output basically shows you how you can like, how your string gets converted into a JavaScript function, basically.

JASON: Right. Yeah, and the AST, I think, is one of those things. It starts to I feel like there were a few moments as I was learning programming where the magic sort of dissipated, and I started to see like, it really started to make sense how this stuff works. Figuring out how an abstract syntax tree gets put together was one of those moments. It starts to make it feel approachable. This is you know, an AST is kind of dense. It's a big JavaScript object. But it's still JSON. You can still look at it and see, okay, so this is like, we're saying this is a type of element. It's got attributes of X, Y, Z. Okay. I get it. Text content is. And suddenly, you're thinking, oh, all right. I can do this. I could design one of these. Then you think of it as your framework, your Sveltes and Vues and Angulars and Reacts are giving you an abstraction that allows you to take whatever custom syntax you want. You break it into an AST. Then you use your compiler or other approach to turn that AST into valid HTML so you can then and along the way, we get to do all sorts of things. We can call custom functions. We can look for specialized tokens that let us do runes for example, in Svelte. It's a specialized token. You see that and, oh, that means we do something special in our compiler that results in some other outcome in the HTML. It was really, really fun to start getting my head around how that works. Where I did it was I was at Gatsby. We were working on MDX. So I got my hands dirty in a lot of AST work during the MDX days. It was just fun. Suddenly, I felt like a wizard. I could let somebody write nonsense in their markdown, and I could detect that and turn it into something fun. I was like, wow, this is so cool!

PAOLO: Yeah, that's absolutely the same feeling. The moment you start working with compiler in particular, because it seems like this thing that is very complex, but at the end of the day, it's just a way to transform a string into a different string. So when you start working with an AST and you realize that at the end of the day, it's even much, much easier to work this way than with regex, for example. It's a very simple way to convert a string into another string. When you see that like, oh, I can add this thing and a console log shows up here, it's very nice.

JASON: Yeah. So, a question then is, there was a very, very clear separation of concerns in React and React DOM. They said that, you know, React is the diffing engine. React DOM is the way we compile React components to HTML for the browser. In Svelte, I know that you're a compiler. It's part of the same package, so when you made the decision to start looking at a custom compiler or a custom renders API, was that something you had to sort of dig into the Svelte source code to pull those pieces apart, or was it always kind of built with that abstraction just in the same package?

PAOLO: So, I mean, I didn't actually have to look into the Svelte compiler because I already worked on the Svelte compiler.

JASON: Fair, fair. (Laughter)

PAOLO: But this, for example, is actually the first thing that I had to do. The moment we decided so, just as a small, brief history, the point is we love to give back to the ecosystem that we work on. So we have one day to work on open source. We release libraries for the ecosystem that we are on. At one moment, we said, okay, what we can do for the Svelte ecosystem. We decided to look into this Svelte custom rendering. The moment I started to look into this, I knew we had to change something because I knew that there was something that was particularly challenging already. And the thing that we had to change, and we actually merged this already into Svelte, is the fact that if you take a look at the same JS output tab in the playground, you can see that basically if you write a Svelte component, in the output there is one line which is like route is equal dollar sign from HTML. Then there's a string which is basically all the static part of your component as a string into the final output basically. If you think about it, to attach an element, to attach a listener to a button, for example, you have to have a reference to that button. So that string needs to somehow be converted into an actual JavaScript element. So under the hood, what we're doing with Svelte is that we are taking your string, and then we are using this very nice HTML element. I don't know if you know about it. It's the template element.

JASON: I love the template.

PAOLO: So the template element, if you write in your index dot HTML file, technically it's just there to be able to be referenced in JavaScript. So you can have this template element. You write whatever HTML you want inside the template element. Then in your JavaScript, you can do, okay, get element by ID, that template, and you can clone all the HTML that you've wrote declaratively inside your HTML. Then you can fill in all the variables basically. We are basically doing the same thing on the fly in Svelte. So we have this string. We create a template element on the fly. We set the inner HTML of the template to the string and get the first element, the first child of the template, and we get back all the attributes, all the HTML elements we created for free, basically.

JASON: Cool.

PAOLO: That's really nice because we basically instead of calling documents dot create element, document dot append, and stuff like that, we delegate all that work to the browser. So like it's much faster. And it's also easier to do because if you have a huge tree of HTML, obviously you will have to do that loop over and over again.

JASON: Right.

PAOLO: That was absolutely a problem the moment you want to do stuff with something that is not the HTML.

JASON: That was going to be my follow up question.

PAOLO: The problem was, like, either you ask whoever is creating the custom renderer to create something like this that can take a string and return all the elements, but that would be, like, incredible work for everybody. Nobody will create a custom renderer if you have to do something like that. So the first thing that we did, and this is mostly what I worked on during the period. The point is we decided that we wanted to build the custom renderer. I was actually sponsored to work on Svelte.

JASON: Oh, very cool.

PAOLO: So during these months, we started developing the API. The first PR we opened was to basically add a new compile option. So right now, basically, what you can do is you can pass this fragment property to the compiler, and you can either choose HTML, which is the default, or three. If you switch to three, what we do is basically we switch from, okay, we create the template and pass the inner HTML two, instead of creating a template as a string, we create the template as a series of arrays that contains the name of the tag, the attributes of the tag, and the children of the tags. So with that array, then we can loop and do document dot create element, document dot set tags, and stuff like that. So we manually loop over the structure, and we create the elements one by one.

JASON: Got it. And because you're doing it that way, then, you can use the native APIs.

PAOLO: Right now, technically, you can't. But the point is the moment we add the custom renderer API, the plan is if you specify a custom renderer, you don't get to choose fragments HTML. You need to use a second structure. This way, we can call your renderer, and your renderer is responsible to tell me how to create an element, how to set the tag, how to append the child and stuff like that.

JASON: Cool. So, once this goes into place, though, the work of building the custom renderer is on the person building and maintaining that renderer. For me as the dev, the intended outcome, I assume, is that I will just say I want to build a Svelte app, and this target is native. Its target is terminal. Its target is web. And once I've installed the right custom renderer, it will I won't need to know the difference between like the default fragment HTML versus the array based HTML.

PAOLO: For you, the dev that is using Svelte, the only thing you have to care about it that you need to specify your custom renderer. So once you say, okay, I want this to render with Lynx, for example, automatically, you will write your code as a normal Svelte, and under the hood, Svelte will be invoking the custom renderer from Lynx. That's just a package that you install and import their model and stuff like that.

JASON: Nice. Yeah, so a very familiar, you know, process. Like Astro is like that. When you install Astro, you have to choose what your deployment target is. Then you just install the package that is for Netlify or for

PAOLO: It's very inspired by the adapter pattern, basically.

JASON: Oh, nice. Yeah.

PAOLO: And at that point, we basically had to choose how to actually implement this kind of stuff. The very first idea which was kind of a wild idea, but I actually started implementing it a bit, is we said Ginn that Svelte actually knows how to interact with an HTML element, like a node in the DOM, what if when you create your custom renderer, you give us a series of functions but then we wrap your functions in an interface that is DOM like. So you pass me the function to create an element. What I do is I create a document where I can call a document dot create element, and document dot create element returns an element, a fake element, that then invokes your function to populate its attributes and stuff like that.

JASON: Interesting.

PAOLO: Given that Svelte already interacts with an HTML element like interface, we can prevent any change to Svelte basically, and we just wrap your class with a class that looks like an HTML element. But it's not an HTML element. I actually started implementing something like this because we wanted to explore that direction. But then we figure out the DOM is just too crazy because there are so many quirks in the DOM. You don't think about it when you start. Oh, yeah, it's just an HTML element. Then you start to look at it. For example, if you set the class element, you need to sync that with the class list element. Then maybe if you set the text content is equal to an empty string, you will need to invoke the remove function on every element that is inside that element, like recursively. So you start to look at all this various behavior that we take kind of for granted because we're in a DOM environment. In reality, we would have to basically rebuild all this quirk behavior of the DOM inside.

JASON: It gives you a new appreciation for how hard it is to maintain a browser, right.

PAOLO: Absolutely. And so like we said, okay, let's not do that. So we started looking at something different. And the other idea we had, and I actually implemented a POC for that and also implemented a POC for a Lynx renderer with this. The other idea was so we want to reuse basically all the reactivity part, like the reactivity core of Svelte is that it's not interacting with the DOM. So we want to leave that part basically by itself. What we wanted to do was to basically re create another runtime. Right now, if you build your component, and if we go back to the JS output page before, you can see that basically there is an import as dollar sign from Svelte internal client. That Svelte internal client is basically a model that contains all the API that we use to interact with the reactivity system and with the DOM. So if you take a look, there are APIs like dollar sign dot first child, dollar sign dot child, dollar sign dot sibling, and stuff like that. So the idea was what we can do is we can replace that import with a Svelte internal custom, which is a runtime that is much, much simpler than the client runtime because obviously for a custom renderer runtime, you don't need to think about hydration, for example. Hydration only makes sense if you're building HTML on the server and attaching elements on the client. So we could remove the big part of hydration and have a much simpler runtime so when you're using a custom renderer, you import this much simpler runtime. The other reason why we wanted to split initially was that from the maintainability perspective, you don't want to risk because inside the Svelte runtime, we do use a lot of these quirks of the HTML. So for example, if you are building a block, for example, and we need to get rid of all the elements, the fastest way in terms of actual performance is to do text content is equal to empty string. If you do that, it's the browser that is removing all the elements. So we don't loop over all the elements and remove one by one.

JASON: Right.

PAOLO: So our idea, our thing was we don't want to, when we are developing Svelte, to keep in mind that, oh, I am inside this world where I don't know if this will be run in the DOM or some other environment where text content is not a thing. So we decided to initially split the runtime. Again, I actually built a POC of this, which worked, and it was so cool. The fact I could build a custom renderer for Lynx and see it up on my phone, that was so magic. Huge shout out to Lynx. It's so cool. The CSS support that they've built in Lynx is amazing. And you can literally use whatever CSS you want, and it works magically. So it's very cool. And so we started doing this. Then unfortunately, the three months were over. So for a bit of time, we actually had to stop development of this thing. So that's why it passed a bit. We are looking for funding, by the way. So if one of the like if you work for some company that is using Svelte and wants to build a native app with it, we are talking even with companies that maybe don't want to build a custom app with Svelte but they literally have built like they have their own platform they want to support and want to you Svelte as a template language. So we are talking with some of those. But if you are interested, by the way, if you go to Svelte custom renderers.com, you can support this initiative. We're looking for funding to finish up this work, basically. At the end we got a bit of funding. I was able to finish up and bring everything up to date. Obviously, a lot of time was passed between these two times. So now the new direction we want to take is we were talking a bit more about will this actually be maintainable, the fact that we have the split runtimes. The answer is probably not, at the end. The problem is when you have those two runtimes, the code is very similar. There is one runtime that has much less code. But the code is very similar except some small quirks.

JASON: Okay.

PAOLO: So while we were working on this, we realized maybe we should try to unify the runtime. So the next step, basically, will be I will try to actually build with a single runtime, which should be doable. Basically, what we will do is if we have a custom renderer, we will have a bit more branching in the brain client runtime, but this will allow to keep the performance when we are in the DOM world, when you are using Svelte normally. Then we have only the small sections of branching, not a huge branching between two different runtimes that looks the same and you have a lot of code, basically.

JASON: Gotcha. Yeah, and that does seem like the sort of thing that would get really, really if you've got that code duplication, then as soon as you duplicate code, you're contending drift. This was a problem we ran into with like Gatsby, for example. When we were trying to implement themes and trying to implement the ability to sort of extend themes, we were trying to figure out how to take that WordPress theme magic where you had your WordPress site and theme, but then you could override specific files in your WordPress theme. Of course, the issue with that is over time you've got the original file, and then the extended file. You don't know where everything is stored, and things just start to drift out of date, and it gets really, really hard to keep track of what's going on.

PAOLO: Basically, it was a file that visually basically looked the same. Then there was maybe one line that was different because it was using the us can top renderer. So it could have become very difficult. You also have to remember, whenever I fix a bug in this file, I have to check if on the other side there's also the same bug. It would have become like a mess probably. So now we are trying to go this different direction.

JASON: Yeah, and I think if anybody watching has been part of a large team, right, an enterprise scale team, like when I was at IBM, this was a pretty constant problem for us. We had done things like went from a giant monolithic codebase that was hard to ship to, to a microservices architecture in an attempt to give the teams more autonomy. But the scale wasn't there. The time wasn't there to correctly implement microservices. So we just duplicated the monolith 35 times. And everybody had their own copy of the monolith that just slowly drifted. And that meant every time we actually had a team whose full time job was circulating between all of the different microservices teams and implementing the latest security fixes. And it was a never ending circuit because by the time they got around to the last team, there was an all new set of things to fix. And they implemented the same fix on all 35 monoliths.

PAOLO: Do you know that like on the biggest sky scraper in the world, it takes three months to clean every window. Then they clean them every three months. So they're basically always cleaning some window.

JASON: Perpetual window cleaning job. It's a dream if you're into that sort of thing. Like if you're somebody who loves that type of maintenance, it'll keep you busy forever. But generally speaking, that means that the entire codebase is always slightly drifted because you're waiting for it to get implemented everywhere, and it just never will be because that's not how you know, that's not how duplicate fixes work.

PAOLO: But there's also another point, which is that right now, the Svelte codebase is moving like crazy.

JASON: I bet.

PAOLO: We are implementing the new async features. It's one of the like, in my opinion, it's one of the best features, period, out there in the world of web framework. I mean, obviously Rich, Simon, and Elliot, they're working full time on Svelte. They're the main actors implementing this thing, and they're doing a great job. It really feels like it's just like, okay, that's how I would write code if I could write it everywhere. It's very nice. But this means that the codebase is changing a lot because we are restructuring the code to make like, it's a very hard problem. So it requires a bit of abstraction around the codebase to make it work without going insane. So the codebase is changing a lot. This means if I let's say tomorrow I complete the custom renderer work, it will take a bit before it's merged because obviously it's a huge work. I would basically go catch up with the rest of the bugs, even before merging. That would already be a mess to maintain. I'm pretty confident about this new direction. We'll probably be able to complete this new direction. I'm also a bit more confident because when I started with this project, AI really wasn't there. Like, you couldn't use AI for such things, like for something this complex. But I think nowadays, we are slowly getting there. So I think AI could help build something like this.

JASON: Man, I've been trying my hardest to be an AI skeptic. You know, every time I watch somebody build with AI, I'm waiting for it to fall over. Then I take my smug satisfaction that I, the dev, am clearly superior to these AI tools. And I don't know, man. It's getting harder to be a skeptic. Now when I see it work, when I see people using these latest models, they're good, man. They're real good. And I

PAOLO: I was an AI skeptic myself. I think there was a moment where AI models actually started getting like, you could get real usage out of models.

JASON: And it was recent too.

PAOLO: I put a post on Bluesky. Like, Claude, please, do this. And he does something. I say, oh, you did this very silly thing. Please refactor it. Then he refactors it. I look at it and say, oh, gosh, he was right. Like, it was a silly thing, but it was the right thing to do because now it doesn't work. I feel a bit

JASON: Yeah, it's definitely strange. And it's been very recent. Like, it's been within the last two, three months that these models turned a corner where the code they're writing is honestly it's good now. And I still think I have a million questions about how these things are going to work. Like, we haven't really figured out how long term maintenance works. We haven't figured out how security audits and things like that work. At the same time, these are problems we've had forever. Like, how do you do security audits on an open source project? You trust the open source maintainers to do it. How do you do it on a Claude code or a Codex generated thing? Hopefully, you've got somebody who's going to do that work. I think in the past, we've just always hoped that somebody did it before. So I don't know that a whole lot changes, unfortunately.

PAOLO: Personally, when I code with AI, I review the code. I don't ship.

JASON: Yes, absolutely.

PAOLO: Unless it's something super silly I don't care about. But the point I was trying to make is that even just exploring the whole Svelte codebase to find like old instances where we are using the DOM API, for example, it can be much, much simpler. Like, I can just send Claude to explore the codebase, leave me a to do comment, so I can go there and watch instead of literally opening every single file to look for this kind of stuff. So I think that's one of the things that gets me hopeful that we can complete this sooner rather than later.

JASON: Yeah, and you know, like I said, I've tried to be a skeptic. I've tried to believe that it would never happen. You know, it's getting harder and harder to hold that stance because I think we're in a new world, and I think we've got a lot to learn about the tools. But the tools seem to be here, and they seem to be performing at a level that it's pretty tough to deny that they are, in fact, capable of doing the things that we want them to do now. So it's a little more about learning how to use them. And to your point, when we start getting into, okay, how do we build a custom render API for Svelte if you don't have a full time sponsor, if you're not full time on the project. It's going to require having the ability to sort of multi leverage your time. From an open source standpoint, I think that's a good thing. You know, I hope that we figure out ways to responsibly use these tools to like make sure we're not just making excuses to lay off everybody in the industry. Because that's going to be a real bummer. But I do like that somebody who has a vision and doesn't necessarily want to give up their nights and weekends or family time, you can do a lot.

PAOLO: Yep, I agree. And by the way, I also think that in the open source world, we are kind of deviating, but I think it's an interesting argument. For like if you know what you're doing in general, like if you have a taste for the code, the bar to start doing open source has never been lower. You can literally open the codebase, ask Claude where to do the change, and it's much easier to get accommodated to a codebase. You can ask him to do the change, and then you can verify and check like, yeah, this feels like the right fix. You can ask him to explain the change and get a feeling about the stuff. You can just do stuff in open source now. So please, feel free to contribute.

JASON: Well, and bear in mind, this is a huge leap forward in your ability to learn. We can treat it like like, there is, I think, an opportunity here to just shut your brain off and never use it again. You've gotten a instant answer machine. You can decide to trust that without verification and move on, and that's you know, I hope you don't. But the same thing is true of, for example, calculators. You could make the choice to never learn math and just punch everything into a calculator and hope for the best. But if you used it instead as like a way to think through how the math works and verify your answer or use it to, you know, get through a complicated part you didn't quite understand so you can move on and continue building your understanding, I think that's a way forward with all of this stuff. If you have access to all the world's information, if you have access to something that can interpret your poorly worded questions because you lack the jargon, lack the deep context that allows you to ask the really good questions, suddenly you've unlocked the ability to step into something that previously would have required someone else taking the time to onboard you into it. In a world where open source does not have enough time as is and most of the maintainers are trying to fit in these fixes and PR reviews and dealing with all the downsides of AI, like junk PR requests and a lot of mess that gets created that way, they don't have time to really mentor everybody who wants to get into OSS. So it's kind of cool you do have the ability now to use an AI that can quickly parse a codebase and sort of give you some instructions on how to onboard yourself into it. That's cool. And it gives you a lot of leverage as a dev if you want to get involved in these things.

PAOLO: Yeah, absolutely agree.

JASON: So let me pull us back on the topic here. Let's talk about you were talking about the next steps. You're looking for funding. How you know, so we've got the Svelte custom renderers. The link is up above. Let me put it on screen. If somebody wants to get involved, is there a work in progress branch that somebody can pull and try this out? Is there a way for somebody to get in there and make their own version of a custom renderer to get their hands dirty? I guess what are the steps right now? Where are things?

PAOLO: Right now, we are basically like, we did a bunch of go forward and go backward and go forward and go backward. I'm slowly trying to put together a branch that I can actually put on the Svelte repo so that people can actually start playing around with it. In the meantime, I did publish any POC. So that was using basically a package version of my branch locally. And you can find it on let me find the link.

JASON: It's on the Mainmatter

PAOLO: Yeah, it's...

JASON: Links integration.

PAOLO: Yeah, exactly. So this is the repo. You can see the Svelte, which is basically what you get when you download from npm, but this also has the custom renderer API. You can explore a bit of the code. There's this render.js, which is the Lynx renderer I've built as a POC. There's also these to do, which is the Svelte component that's rendering the Lynx application.

JASON: You want to know a little today I learned thing that I didn't realize was possible? You've included Svelte as a tarball in this repo. I just looked in the package JSON, and you can set a dependency with the file prefix. So you've got your Svelte dependency set as file: And then the name of this tarball file. That's really cool. I didn't know you could do that. That's a fun little upgrade.

PAOLO: This is like a maintainer trick. If you want to try a new version would having to publish an npm, without having to link it, and you maybe want to let someone install your repo, you can just do you go into your project and do pnpm pack or npm pack, and it will produce this. This is literally what you download from npm. Then you can move it in your project and install by pnpmi and link to the file. Actually, I think it works also with npm.

JASON: That's very cool. That's a super handy little trick for all you up and coming OSS maintainers out it. So I think that's about all the time we have today. So, I want to thank you, first and foremost, for coming on and talking about this. I love that you're exploring these areas. I love that we're going to see more capabilities come to more frameworks. And I also just love hearing how the sausage is made when we talk about, you know, the complexities of how do we get a component to render on multiple platforms. So, thank you for taking the time. Anything that you wanted to say as parting words before we wrap up today?

PAOLO: No. Just if you are interested in funding this thing, because maybe you have something, you could go to Svelte custom renderer.com. That's it. Thank you for watching this, and I hope you learned something.

JASON: Yes. Thank you, all, for watching as usual. If you're enjoying this, remember the WebDev podcast is on your favorite pod catcher. You can find us on Apple Music and all the places. You can find Paolo on Bluesky, on the Mainmatter repo that we linked in the show notes here. Make sure you like, subscribe, leave a comment, do all the things that tell the algorithm to show it to your friends. So, thank you all again for being here. Thank you, Paolo, for being on the show today. We'll see you all next time.

PAOLO: Bye.