984: How to Make a DOM Library Render Anything w/ Paolo Ricciuti

Wes and Scott talk with Paolo Ricciuti about Svelte custom renderers and how Svelte actually talks to the DOM. They dig into compiler internals, CSS handling, native bridges, and the realities of maintaining ambitious open source tooling. Show Notes 00:00 Welcome to Syntax! March MadCSS 01:44 Paolo’s role at Mainmatter and his work on Svelte custom renderers 02:52 Why Paolo chose Svelte Why I choose Svelte Shift Dev 2019: “Rethinking Reactivity” 05:16 From Svelte ambassador to working on the project 07:45 How custom renderers change what Svelte can target 10:10 How Svelte uses the DOM and why that makes custom renderers tricky 20:32 What Lynx provides and how it differs from a web view 24:18 Brought to you by Sentry.io 35:56 Using Svelte with CSS outside the browser 39:09 The timeline and current state of the Lynx app 44:51 Sick Picks + Shameless Plugs Sick Picks Paolo: Opencode Shameless Plugs Paolo: Svelte Custom Renderers | TCMP Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Real quick before we get going, we are launching a new video series called March Mad CSS. It's a CSS battle tournament with 16 of the world's best developers. Josh Komu, Chris Koyor, Adam Wathan of Tailwind, Cassidy Williams, even Scott and I. Now, we have a ton of prizes to give away. And if you want to win, go to madcss.com and you're going to fill out the bracket. So madcss.com, log in with your GitHub and you're going to pick who you think is going to win each of these. And whoever gets the highest score is going to win this amazing prize pack. Like this sick CSS jacket. You can also order this from the website as well. We've got some pretty cool merch, some tees, stickers, and now Gene, first, second, third prize.

• 0:44Wes Bos?

  Go to madcss, make your picks. You can share them with your friends. You'll probably win. Peace.

• 0:49Scott Tolinski?

  Welcome to Syntax. Today, we have a really awesome guest on. Paolo Ricciuti is going to be talking about Svelte custom renderers and how this Svelte team is basically going to be taking a library that is entirely focused on the DOM and really putting it into a universe where, well, you can like render anything with it. So there's a lot that comes from that, both in strategy, but also in what that enables for developers who might be considering using this tool. And yeah, I'm really excited about this. So welcome to Syntax, Paolo.

• 1:26Speaker 02

  Hi, welcome. I mean, not welcome. Thank you for the welcome.

• 1:32Scott Tolinski?

  Of course. Yeah, yeah. Do we first meet in Barcelona? That's where we met somewhat recently, right?

• 1:38Speaker 02

  Yeah, the night in Barcelona, personally.

• 1:41Scott Tolinski?

  Yeah, the Svelte summit, it was a great hang there. You're at a company called Main Matter. What is it that you're doing and what's your relationship to this Svelte project overall?

• 1:51Speaker 02

  I lead the Svelte team at Main Matter. Main Matter is a consultancy. We do a lot of Svelte, we do Rust, we do Ember. So like it's, it's basically a sort of a top-tier consultancy. Like we were not just executors, like we...

• 2:10Speaker 02

  Actually help you architect your your solution. We help you hire even like it's more like on a high level. But we also do feature development and stuff like that. And basically, I am the Svelte expert there. And the reason why I am the Svelte expert there is because I'm very tied to this Svelte project. I'm one of the maintainers of this Svelte project. I also, I started as a Svelte ambassador as Scott, which is basically like people that won't shut up about Svelte. And so.

• 2:44Scott Tolinski?

  That's me, right? That defines me, I think.

• 2:47Wes Bos?

  Sometimes we have to shut them up about it, but it's all all good stuff here.

• 2:52Scott Tolinski?

  How did you find yourself in Svelte specifically? Did you do other frameworks before then? Like, and you actually just recently published a blog post about why you chose Svelte. I don't know if you want to get into some of that.

• 3:05Speaker 02

  Just today, we published a blog post about why I choose, I choose and I continue to choose Svelte. And you can check it out on mainmother.com if you want on the blog post. But yeah, in general, I I started with React, really. And like, nice thing, by the way, like, my first approach ever to React was watching CJ doing with React. And I still remember, like, I was taking my COVID vaccine for like in 2020. And generally, I am a huge nerd in in real life. So like, I tend to like watch syntax

• 3:48Speaker 02

  or watch conferences, even in my like off time. And so while I was waiting for to take a shot, a vaccine shot, I was rethinking Reactivity by Rich. I literally fell in love with Svelte because like the idea of using a compiler to like ease the burden on on the browser is something that like the moment like he mentioned it, I said like, why nobody else told about this? Because it felt so obvious to me and.

• 4:23Speaker 02

  Like from there on, I started using Svelte for some side project just for fun. I started learning Svelte just for fun and then I started using it. I also participated together with Antonio Sarchewicz. We teamed up and we built Svelte Lab, which is like a stackblitz-like specifically for Svelte kit. And we won the Akatons with that. And then this basically got me even more into the Svelte world. I became a Svelte ambassador and from there, like it's just, it's just free fold. Like I, for example, I am also the maintainer of the Blue Sky feed for Svelte.

• 5:03Speaker 02

  So I generally tend to joke that if it has the word Svelte in it, I'm probably somewhat involved in that.

• 5:10Scott Tolinski?

  Yeah, yeah, yeah. You've been like a really positive force in the Svelte ecosystem. I, I think it would be curious, it would be interesting for the audience to know like, how, how do you go from being somebody who's just like, like you said, an ambassador or somebody who's now actually working on the project?

• 5:29Speaker 02

  Yeah, so like the reason why I started contributing, I always want, like in general, I love open source. So I, I always did a lot of open source, be it like, I don't know, I want to create a new library because I have that need and I want other people to share the same, like I don't want other people to feel the same need, so I create a library for it. So I always been very open source. And so when they were working on the rewrite to Svelte 5, they shared the like initial draft of Svelte 5 with the ambassador team.

• 6:10Speaker 02

  Because the ambassadors are basically like, it's the first step of validation for some API. So like, the first thing that we generally do is that like we build some API and then we like let ambassador critique that API so that we get some initial feedback. And so when I was an ambassador, I got some like access to, to the initial draft of the Svelte 5 repo. And Like a few years ago, just for fun, I started building a reactivity system with signals. And so I knew a bit about signals and I said, this is a good moment to start contributing to Svelte.

• 6:50Speaker 02

  And so like be the like a more like circle, like a small circle of people watching the the contributions and stuff like that. I said, okay, I'll I'll start to contribute to that. I also was very interested in learning like how the whole like abstract syntax tree, the work, like the compiler work worked. And so I started going to to contribute to that. Then the repo went public and I continued to contribute. And the main motivation was I really want to like ease the experience for the for the maintainers to let them focus on the things that really mattered. And so I started to pick up some

• 7:31Speaker 02

  small issues and then I started to pick up some more difficult issues and then more and more and more. And then in the end, like they really didn't want me in the maintainers, but I was too much of a presence.

• 7:45Scott Tolinski?

  Wes, how do you feel about that? Like, how do you feel about like I I get so intimidated when I like, I I've used Svelte like daily since version three. I am a huge fan of the project. I follow along like the issues and all this stuff and I would still have major imposter syndrome, feeling like like trying to commit to it for some reason. I I got a huge blockage there. Do you feel like that too? Like, would you commit to React or or any of these big projects?

• 8:13Wes Bos?

  I I don't know that I would commit to React because so much of what they do is like planned out and it's being worked on somebody full time. But like like larger projects that simply just need the help? Absolutely. Yeah. I think in in most cases, if it's needed, why not, you know, kind of go for it, especially if they have like you can kind of get the vibe from a repo, whether or not they're they're actively searching for people to help them out. So yeah, go for it. That's that's how like everybody's story goes, right? Like Paulo's story is like that. Just go for it.

• 8:47Speaker 02

  Yeah, but also like it's way less like if you start, it's way less intimidating than that it might seem like. The moment you start getting familiar with the codebase. And you actually start getting familiar with the codebase even before committing code. Like if you live in the issue tracker, like you will see other mentors talking about, oh, we can do this and we can do this other thing and we can do this. And once you start seeing this, you start to get yourself familiar with the codebase. And then at that point, it's really just a matter of, and I would say nowadays with AI, it's even simpler.

• 9:27Speaker 02

  Because like you literally get like a very capable engineers that you can just even ask questions, like you can just say, hey, how does Svelte handles like the parsing in this file? And it will

• 9:41Wes Bos?

  Yeah.

• 9:41Speaker 02

  down stuff for you and you can just say, okay, that's now I want to try to do it and so.

• 9:47Wes Bos?

  Yeah, you can get up to speed real quick.

• 9:49Scott Tolinski?

  Yeah, really helpful for me when I was working on the zero Svelte bindings because the state there was like way more complex usage of the the Svelte reactivity APIs than I was used to in normal UI code. So like I really needed to dive quite a bit deeper into that stuff, uh, building the the zero bindings. So first of all, let's talk custom renderers for people who who don't use Svelte, who've never, they don't, they might not know how it differs from React. Could you give like an overview about like, how does Svelte use the DOM? Uh, as opposed to like the virtual DOM and then two, we can get into like what makes that challenging for custom renderers and and go from there?

• 10:32Speaker 02

  So I I guess the the main point is that React really is just a diffing library. So like, uh, I think like this is pretty common knowledge at this point, but basically like React itself does not concern with anything related to the DOM. So like they have the virtual DOM and it's just saying like, hey, create this element and like switch this attribute on and off or change the value of the children of this of this thing. And then React DOM is the thing that actually says, okay, this is how you switch an attribute off on the DOM.

• 11:13Speaker 02

  And this is basically what allowed React to do stuff like Inc. or stuff like React Native. Because, uh, the diffing algorithm, which is what React is, is doing the diffing algorithm. And then it's communicating with the Virtual DOM, like the virtual DOM is communicating with Ink or with React DOM or with React Native. And each one of these renderers, at Ink React, they are called reconciliator. It's like, has the knowledge about how to actually apply an attribute, how to actually remove a children, how to actually append a children in their own world.

• 11:54Wes Bos?

  So let me say for the audience really quick, they might be wondering like, what is Ink? Ink is like React for terminal UIs. React Native is obviously React for native mobile UIs. You might not know this, but Raycast, the app that we use is built in React. And they're not running browser or anything like that. It's, they've built their own reconciler that, that runs. If you build a, if you build a Raycast app, you're just using React components. You're using Raycast tags. And then what happens is that like, you can, you can build a React app, but it actually renders out to native whatever, right?

• 12:35Wes Bos?

  And it's, it's, you can't just go ahead and use CSS or HTML or anything like that in there. You have to use like the blessed tags that they've given you. But there's just so many different instances where React is used as a renderer to something else.

• 12:50Speaker 02

  So like, the difference is that Svelte, like famously, like when like Rich presented Svelte, Svelte does not use a virtual DOM. Now, Svelte 4 and Svelte 3 was literally basically baking in the reactivity within like the compiled output. But even nowadays, the Svelte 5 is using like runtime reactivity with signals and stuff like that. If you take a look at the compiled output and you can do it either in the playground or there's even a command in VS Code. Like if you are in a Svelte component, you can use a command from the extension, which is show compiled code. And it will show you the compiled code, like what that Svelte component,

• 13:34Speaker 02

  which is at the end of the day, just a string, gets compiled to. Because obviously you are not shipping the component to the browser. So like, the way Svelte works is that it takes the string, which is your component. It will convert that into a JavaScript function, basically.

• 13:53Speaker 02

  And if you take a look at the JavaScript function, it's basically interacting with the DOM in real time. Like you will see stuff like get me like dollar sign dot first child, dollar sign dot set text, which is basically Svelte saying, okay, I want to set the text of this element to this kind of stuff. It was always imagined as a reactivity frame, like a framework for the web. And so like it was never actually imagined as a replacement of like, it it it didn't have the concept of a custom renderers because it was always, okay, we want to do web UI.

• 14:35Scott Tolinski?

  I will say, uh, for folks, if if if you haven't messed around, I'll have a link to the the Svelte Dev Playground. There is just a tab for JS Output and it's so readable. If you wanna really understand what's going on.

• 14:47Speaker 02

  This actually changed a lot with Svelte 5, like Svelte 4 was a lot less readable. And actually, one of the goal, the design goal of Svelte 5 was actually to make it much more readable. And another small, like, nice thing that you can actually get from the Playground, which is, uh, like a very nice way to learn, is that since we have source maps, if you hover over something in the Playground, while the JS Output tab is open, you can actually see which part of your Svelte component gets compiled to which part of your JavaScript file. So that's that's a nice touch. If you want to learn how Svelte moves stuff around, like, okay,

• 15:32Speaker 02

  this button that I have in my Svelte component, what did become inside my JavaScript file? As I was saying, like the Svelte custom renderers, we had the idea of, so Admin Matter, we love to give back to to the ecosystem that we thrive on. So since we use Svelte with our clients, uh, we also love to do open source. We even have like one, like one day at a week, we can work on some open source project because we love to give back to the community. Uh, and so like. We've built some libraries. We've built a ship dog, for example, which is like state management, like library that it's basically a way to handle, to juggle a sync task.

• 16:14Speaker 02

  Uh, once we finished that project, uh, which I mean, we are still maintaining it, but like the big part was, uh, was, was done. We said, okay, what can we do now for this Velt ecosystem? And it happened that during that period, when we were looking for stuff to do for this Velt ecosystem, a new framework came out, which proposed itself as the React Native alternative, which was framework agnostic. And I think you, you also did a, uh, uh, an episode on that, which is links. And one of the requirements for links for, for it to be very like links, it is framework agnostic in the sense that technically you can literally write, uh, an application even in a normal JavaScript file, like with, with the

• 16:59Speaker 02

  the element API, which is their API to create an element inside a links application. And like, it is technically agnostic, but to use it with Velt, we needed a custom renderers. So like, we needed a way to render a Velt component to something that was not the web, which was not a series of.

• 17:21Scott Tolinski?

  And there's no DOM available here, which that to me feels like a crazy undertaking, just given how deeply rooted the DOM is in this Velt, right?

• 17:31Speaker 02

  Yes, like it's not, it's not an easy task and that's why it's taking a while, unfortunately, but uh, it's something that it's doable and I actually, uh, built a P O C, uh, for it. Because, uh, again, basically like we started working on this and my mother actually sponsored me to work on this thing for full time for three months or so. So like. My day-to-day job was to work on Svelte to to build the custom renderers API. And during this period of time, first thing first, we had to make a change because always talking about the JS output in the playground. If you go to the playground and write whatever component,

• 18:16Speaker 02

  you will see something in the compiled output, which basically like if you have in a very simple component like the input and a button that is the normal like if you go to the playground, there is a default input plus button. If you switch to the JS output tab, you will see in on line five var root dollar sign dot from HTML. And this from HTML basically is like all the HTML tags in your component minus all the event listeners and stuff like that and the dynamic part. So like all the static part of your Svelte component as a string. So if you think about it, it is kind of wild like

• 19:01Speaker 02

  how can we convert from a string to actual elements? Because at the end of the day, you have to convert that string into an element, right? To actually mount it to the DOM, to add event listener to that stream. And the way we are doing it, it's with a very neat trick, by the way. Like because I don't know if you are aware, but there is an HTML element, which is the template HTML element. And the template HTML element, if you write a template in HTML, it will not show up on the page. So it will create the element, but then those elements are not actually appended to the page.

• 19:42Speaker 02

  And then you can query the template and clone the template part. And so basically, it's a way that you can declaratively render some. Some HTML and then reference it in JavaScript and you can just populate that template however you want. Like, this is a trick that you can use if you want to use like normal JavaScript to build your components. So you can have a bunch of template in your HTML and then reference it and just fill it up with uh another variable. And that's basically what we are doing. So like we, we take the string, we give it, we create a template element on the fly.

• 20:22Speaker 02

  We set in a HTML and then we extract that string, like that component part on the fly. Interesting. I didn't know that.

• 20:32Wes Bos?

  I don't totally understand how it works. Like, like, how are you getting from Svelte code to like Svelte outputs like a paragraph tag? How does that then convert to whatever the native equivalent is on Android or iOS or whatever other target?

• 20:51Speaker 02

  Here I'm just talking about like Svelte for the browser right now.

• 20:56Wes Bos?

  Okay.

• 20:57Speaker 02

  We will get to that. I will get to that.

• 20:58Wes Bos?

  Okay, okay.

• 20:59Speaker 02

  What I was talking is that like in the, in the browser, we do that. Like we take your string and we pass it to the template element. The template element creates that element for us, which is very fast by the way, because it's like it's all done in the browser side, on the browser side. So like you don't have to do manually create element, create tag, create tags and stuff like that. And then we just read those value. We say like, give me the first child of this template. Give me the first child of the first child of this template and stuff like that. Now this, obviously like the reason why I started talking about this is because this is a huge problem. Because if you want to render to something that is not HTML.

• 21:43Speaker 02

  How do you get the template tag, right? So like, you would need to ask like the whoever builds the link renderer to create a template tag which takes a string and returns a series of elements, right? So that will be basically unbearable, like it's just impossible for for people to build custom renders this way. And so the first work that we had to do, and this is actually a PR that I worked on during my sponsorship for like the period that my mother paid for for me to work on on on Svelte on this. And it's the fact that now you can actually generate.

• 22:23Speaker 02

  So if we go back to the to the JS output tab in the playground. Now there is a new option for the compiler. So we can say svelte compile and then you can pass fragments three. And if you switch to fragments three, this is basically uncool. Instead of using templates dot inner HTML is literally creating like it's receiving an array which has the shape like the H1 with this children and this props. And then it's literally invoking document dot create element, document dot set attribute, document dot blah, blah, blah.

• 23:04Speaker 02

  And so this was basically a required step before we could even start to think about rendering to something that was not the web. Because without this step, you wouldn't need to create a template tag which was able to do all of this for you. So like this was the very first step, decoupling the logic from just get a string as input to get an actual array with all the elements and all the attributes and all the all the stuff, so. This was something that was also needed in Svelte because there are some CSP policies that prevent you from using inner HTML in any form or way. So there were people that actually were suffering from this because they had these

• 23:49Speaker 02

  CSP policies and as long as Svelte was using inner HTML under the hood, it was not working for them. And so this was a nice addition, like that we took, I don't know if it's something that people say even outside Italy, but we took two pigeons with a stone. That's

• 24:07Scott Tolinski?

  Oh, yes, yes. Yeah, we said two birds.

• 24:10Wes Bos?

  Two birds, one stone.

• 24:11Scott Tolinski?

  Two birds, one stone.

• 24:12Speaker 02

  Yeah, just two birds, one stone.

• 24:13Scott Tolinski?

  I like pigeons better, though. That's fun. More visual. And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io/syntax. You don't want a production application out there that, well, you have no visibility into in case something is blowing up and you might not even know it. So head on over to sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 24:41Speaker 02

  And so, yeah, basically, this was the very first step to get something going on. And then from there, we basically went, like, we had two different directions that we, like, two different ideas. The first one was kind of a crazy one, and I actually started implementing it. But we said, well, what if we, like, the custom renderer? So first thing first, let's talk about how will creating a custom renderer will work in Svelte. So basically, the way we need, we need it to work is that you need to define some sort of module. So this can literally be a module in your project, or it can be an NPM package, for example.

• 25:25Speaker 02

  And you will like expose a module from this where the renders leave. So like the renderer lives in this module. We import your module and then we can use the methods that you define. So like you export default create renderer. And then you have to basically tell Svelte how to create an element in your world. How to update an attribute in your world. How to delete a children in your world. Et cetera, et cetera. So because obviously if we want to to make this very, how can I say, very like flexible in the sense that it's not tied to anything. We basically need to go one layer above and say, okay, we don't even know what your word is.

• 26:11Speaker 02

  So your word could be the terminal, could be a links application, could be a Thrall application, why not? And so you can, in this way, you that creates the custom renderer can manage whatever, like you know how to render something in your world, basically.

• 26:30Scott Tolinski?

  That would effectively turn Svelte into something that could build terminal UIs and native apps. And like you said, what Thrall, for people don't know, is the three JS renderer for Svelte.

• 26:43Speaker 02

  The first instinct was what if when you create a custom renderer, like when you define those functions, we create a mocked version of the DOM so that then we can just pass it to Svelte and Svelte will continue to invoke documents dot create element. But instead of document, it will invoke the renderer if the renderer is is defined. And so like the first idea was we can make so that when you like create an element, you just return some extra information and then we wrap your information with a DOM compatible API. So like we create a class which is an HTML element like class.

• 27:28Speaker 02

  And so that when Svelte on that element call first child, we then invoke from within that class, we invoke your your custom renderers to get the first child. And this was, I actually started implementing something like this. But then I quickly realized that the DOM is just a mess and you can't do that. Because like, there are so many quirks in the DOM. Which like are not really immediate, like it's something that it's the silliest thing, for example, is that. If you have an HTML element and you call text content is equal to empty string.

• 28:08Speaker 02

  That will actually remove all the elements inside that element from the DOM, right? It's simple, but it means that we have to manually check, like when you, we would have to shim text content. And then inside text content do something like if content is empty.

• 28:28Scott Tolinski?

  Yeah, yeah. And that's probably just like one of a thousand of these things, right?

• 28:32Speaker 02

  Yeah, exactly. Like it was just too messy. And so the other thing that we did, and that's basically what I've built my P O C on top of. Is what we want to do is that we want to create another runtime. Because again, if we circle back to the J S output of the playground. You will see that like the third line is import star as dollar sign from Svelte internal client. And that is basically our API. So like that's Svelte internal client. Is all the JavaScript API that we use to interact with the DOM, to create a stateful variable and stuff like that. And so our idea was let's switch that import.

• 29:17Speaker 02

  And so instead of importing from Svelte internal client, we import from Svelte internal custom. And then we can build basically the same runtime, but a very simplified version of the same runtime. Because the client runtime actually has to do a lot of stuff. Uh, for example, for hydration and hydration is just not a thing in the custom renderer world because.

• 29:42Scott Tolinski?

  Yeah, yeah.

• 29:43Speaker 02

  Obviously like hydration makes sense if you are server side rendering an HTML page. It doesn't make sense if you are building a native app, for example. Or if you are building to the canvas, for example, like there's no such thing as hydration. So we could remove all that part. But also the internal runtime is using a lot of these HTML DOM quirks to make Svelte as fast as possible.

• 30:09Speaker 02

  So as I was saying, like, setting text content is equal to empty string to to an element. It's the fastest way to remove all the elements from that element. So if we had to remove all these quirks, we would basically like put whoever uses Velt normally at a at a small disadvantage, just because we want to do, we want to use the same runtime. And and also, uh, it was from a maintainability perspective, because our thought was like, if we have two separate runtime, whenever we are working on the first runtime, we know that we are in the client runtime, and so we can use this DOM trick.

• 30:54Speaker 02

  And whenever we are in the custom runtime, we know that we are in the custom runtime, and we can not use those DOM tricks. And I actually got decently far with this, so like I built a a very small subset of the runtime. And then, because I wanted to try, like, blame me, but like, I built a very minimal runtime, like, where you could just use like props and state and like some basic element. And then I built a very basic version of a custom renderer for links. So right now, there is a links app, which is a to do app that I've built with Velt.

• 31:37Speaker 02

  And I was so excited when I actually got it work. And it was like the my my favorite to do app ever. And the nice thing, like, to circle back to your question before, uh, Wes, which is, like, how do you even relate like an input or a P tag to a native Android surface? For example, the answer to the question is really that. When we will build this custom renderer API, Svelte will not care at all about that. Like you write a p tag, we just call the custom renderer and we say, hey, we want to render a p tag. And then it's up to whoever writes the custom renderer to say, okay,

• 32:21Speaker 02

  a p tag is something that needs to display text. So what I want to create is a text element inside links. So you could do that.

• 32:32Scott Tolinski?

  You could, you could say like a custom render is like a translation layer then.

• 32:35Speaker 02

  Yeah, basically.

• 32:36Scott Tolinski?

  Yeah.

• 32:36Speaker 02

  Like it's, it's basically.

• 32:38Wes Bos?

  Does links, does links supply that? Like, like do they, does links have tags that are like, like a text tag? Or, okay, so you.

• 32:47Speaker 02

  More or less in the sense that if you, if you read the, the links documentation, basically what they supply is the, the PPI. Like they called it the PPI, which I assume that that's how it's spelled. But basically is an API that is close enough, like it's similar to the DOM API in the sense that you can have like underscore, underscore, create element. And then you can create an element, underscore, underscore, set attribute. And then you can set an attribute, underscore, underscore, like flush three, and it will re-render a specific portion of the page. There are specific attributes. And I, I guess like if you ever use React Native,

• 33:32Speaker 02

  it will feel familiar with you because the links element are called view and are called text. So like.

• 33:39Scott Tolinski?

  Yep.

• 33:39Speaker 02

  They are not called p, they are not called div or span. Like they are literally called text and div. But the nice thing about writing a custom renderer is that you kind of get to decide which elements you want. So like, because at the end of the day, Svelte will just invoke your function and say, hey, please create me a p tag. And then if you want to make the translation between a p tag and a text tag inside, inside links, it's kind of up to you. And it's very nice because like you can literally create whatever element you want. So like, uh, another thing that I did for a talk and also for fun, I created a terminal renderer.

• 34:23Speaker 02

  A very crud version of a terminal renderer, I would say, because one of the reasons why ink is popular, but also because it's kind of slow, and we've seen this like going around because Cloud Code is built with ink. One of the reasons why it's kind of slow is because it's using Yoga under the hood, which is like a library built by Facebook, I think, that basically tries to mimic Flexbox. Like you can just give it a bunch of like data, a bunch of objects, and it will calculate where those objects will in inside a thing. So like this is a process that is kind of slow.

• 35:04Speaker 02

  And so ink, it's much more featureful because they are doing this so you can actually move stuff around and do like Flexbox and stuff like that. My terminal renderer was much, much more stupid. I was just using some basic ANSI code to like color stuff and do stuff. But it was very fun because like I had a Svelte component that was literally named like counter dot Svelte, and I had like text, which is counter with the color attribute, which was one of my color. And pressing play, it was basically using an effect to increase the count and then using a derived to derive the color. And it was actually working.

• 35:48Speaker 02

  You you could see like what you wrote inside the terminal changing color reactively. So like it was very fun.

• 35:56Wes Bos?

  Okay. And what about CSS? So React Native and Links support a subset of CSS, right? Like that's what Yoga is. It's it's translating regular CSS into whatever the like iOS or Android equivalent is. But they, one of the biggest pain points there is they don't support grid, which Links does support.

• 36:18Speaker 02

  Yeah.

• 36:19Wes Bos?

  So what does that look like with with Svelte CSS?

• 36:22Speaker 02

  Yeah. So in terms of like Svelte obviously has scoped CSS. And the nice thing about that, about Links specifically, is that, as you said, Links really like while React Native is kind of a borked down version of CSS, like they are

• 36:40Speaker 02

  They are doing like they support a bit of flex, they support some CSS stuff, but they don't support everything, to the point that if you want to use Tailwind, for example, with React Native, you can't use Tailwind. You need to use a native wind, I think it's called, which is basically our new version of Tailwind, written specifically for React Native, as people usually do with React.

• 37:09Speaker 02

  Right, except like for for the the thing, like Links instead, like they have a very good support for CSS, so you can just use CSS and it will work, basically. And so in my P O C for Links, like that part is actually untouched. So like you write your CSS and what's the compiler produce is just the same CSS. And then it's up to you to actually, like it's the it's more of a bundler work. So like the work that I did for the for the Links P O C was that I've used the Links bundler to say, okay, this is my CSS, the CSS type is component, please make it work.

• 37:54Speaker 02

  And it worked, the moment you started doing that. It just automatically worked. So probably if you want to do this translation layer where a p tag is a text, you will also need to do a bit of work to change the CSS into the other forms, like you would need to do a bit of work. But the at least for the moment, this is probably something that we can explore a bit. I don't know if there are any work that we need to do to support custom renderers like in the style tag, basically. There will be some particles belt that can't be ported to custom render, like that that will be disabled for custom renderers.

• 38:38Speaker 02

  Because obviously, like, for example, bind value really only works if we, Svelte, can register an input, an input event listener on the input. So like, there's a very specific amount of bind that you can do. So binding will probably be disabled, like in in custom render works. Obviously, you can still use a listener, so like. There is like one of the function that you need to provide when you create your your custom renderer.

• 39:09Scott Tolinski?

  You do it the React way. All right. Wait. So what what does this realistically look like in terms of like actually existing for for people to use timeline? What what's the? Yeah. Where where are we at?

• 39:25Speaker 02

  So again, basically, right now, we had like we had a lot of discussions with the rest of the team. One of the last discussion that we had, actually, we realized that our idea of splitting the two runtimes was more maintainable in the sense that when you write something in one runtime, you have a very clear idea of where you are. But it was a very not maintainable in the other sense, because like you have a lot of code duplication that changes slightly, like just in like two or three characters is different. So like it would be a nightmare to maintain. So what I'm doing right now

• 40:07Speaker 02

  is actually rebuilding my P O C so that we can use one single runtime. And then we use whenever we we have this trick like that we use the DOM API in a certain way. We actually branch out. So like we say, if there is a custom renderer, we can invoke the custom renderer. Otherwise, we can use the the shortcut. So like

• 40:28Scott Tolinski?

  Yeah, yeah.

• 40:29Speaker 02

  We make the code slightly more complex in like having one single runtime. But it should help in the maintainability long run long term, because we will have like if we fix one bug in another related part, we don't have to fix that bug also in the custom runtime. Otherwise, we would have a lot of P R s that are basically just copy and paste of a fix in two separate files. So like that that would be annoying. So what I'm doing right now is basically trying to rebuild this this kind of part. In terms of like when will it be available? I don't know, because basically like after like we, my mother founded me for uh three months,

• 41:10Speaker 02

  we are now actually looking for sponsorship for for this, like if there's some companies up there that wants to like build a native app with Svelte or even something else, like for example, we had discussion for people that wanted to build, I don't know, with WebGL, uh they wanted a renderer for WebGL, and so we are talking to sponsor that. And if you are interested in sponsoring, by the way, you can go to svelte-custom-renderers.com and uh you get in contact with us. What I hope is that if we find a bit more funding, when I was working on this before,

• 41:49Speaker 02

  I like AI was really not there at all. So I really hope that with the aid of some agent, I might be able to go a bit faster on this thing. And unfortunately, this is a big enough problem. Like, I kind of feel, sometimes I kind of feel um like annoyed with myself, because uh like I know that like technically I could work on this in my free time, like I do.

• 42:21Scott Tolinski?

  You can just spend all of your time, yeah, yeah.

• 42:24Speaker 02

  Like, like the rest of the resources. But the problem is that like this is a big enough thing that I really can't work. Like if I, if I was to work on this on my free time, I would have zero free time and I would would would not be able to contribute anything else to Svelte for a very long time. And also working at increments of like one hour, because I have a four-year-old kid. So I, it's not like, I don't have like all the time of of the world.

• 42:51Scott Tolinski?

  Yeah, I don't think you got to justify uh DD sponsorship to work on this. Honestly, this is a huge project. Um so we'll make sure we link that up. Syntax is going to be sponsoring some of this effort here because uh we use, we use Svelte uh full-time uh in syntax.fm. We have a new Svelte Kit app. I obviously use it for for everything, but man, it would be really cool to have to customer under support. And to be clear here, folks, because we've been talking a lot about native apps and links and stuff like that. We often get like people saying like, well, why not just use, what is it, or even like Cordova, whatever they call those things now, which is basically just a web view rendering web content in the DOM. That's not really what this is. This is React Native. This is a real native app that is being

• 43:36Scott Tolinski?

  translated from Svelte code into whether that is Swift or what is Kotlin? Does Android use Kotlin nowadays?

• 43:45Speaker 02

  I agree, yes.

• 43:46Scott Tolinski?

  Yeah, but this would be done through the Links project, which is what TikTok is built on. And it's a really, really cool thing. So if your company's out there, you might find interest in sponsoring this as well. We'll make sure we have those links available. Really, really exciting work. And I'm really, really stoked to see what comes of it.

• 44:08Speaker 02

  And by the way, there is like a guy, I just saw it yesterday in the Svelte Discord, that actually took my POC for Links and somehow, because it's a huge undertaking, because it's using a very old version of Svelte, custom made for that and stuff like that. And he actually made it work with Hermes, which is the engine behind React Native. So like, it's so wild.

• 44:37Scott Tolinski?

  That is crazy. All right. I gotta check that out. All right. Well, thank you so much for sharing all this. Man, I'm excited for all the work and really thankful for all the work that you and all the Svelte maintainers do. As a huge fan of this project. Now it's going to be the part of the show where we get into sick picks and shameless plugs. A sick pick could be anything that you're just enjoying right now. And a plug is anything you want to plug. It could even be the Svelte customer renders thing that our website that we will link up to.

• 45:06Speaker 02

  Yep. I mean, I so, I mean, I would say like a sick pick is definitely like for me, something that I've been using a lot lately. And I really enjoyed using is open code. It is my main driver for when I use AI and it's lovely. And I really like it. It's very flexible.

• 45:26Scott Tolinski?

  Yeah, I do too. I use it as my main. And it's just like, I don't want to be using the product that's tied to one model. And I wanted to be fully configurable. When I got brought out to talk to the VS Code folks about the like Copilot CLI and all my requests were like, I need to be able to customize these paths. I need to be able to customize this. Like, it's all the stuff that I have set up in, in open code. I love to tweak my tools, so I get that. And shameless plugs, what would you like to plug?

• 45:57Speaker 02

  Well, obviously, like, I will plug, once again, svelte-custom-renderers.com. If you want to join the initiative, you also get a shout out from our socials, and you will help bring this to, to the, to the, to the finish line. If I'm allowed, I will also like to shield another project of mine.

• 46:17Scott Tolinski?

  Do it.

• 46:18Speaker 02

  TMCP, which is, it's something that I've been trying to shield as much as possible, because I've built, basically, a competitor SDK to build an MCP server with TypeScript. It is, like, in my opinion, a bit more lightweight. It has less bloat of dependencies. To be fair, like, the official SDK is getting way, way better. But, uh, yeah, it's, I've built this, like, alternative SDK, which uses web request and web response instead of node request and node response. It's using standard libraries, so you're not tied to ZOD. Like, you can use whatever validation library you want.

• 47:00Scott Tolinski?

  Oh, yeah.

• 47:01Speaker 02

  It's much more modular, so like, I have, like, the transport part separated, so that if you want to build your HTTP transport, you don't have to get all the dependencies of the SDI U transport. And, much importantly, like, vice versa, like, if you are building an SDI U MCP, you will not get expressed as a dependency and stuff like that. Again,

• 47:23Scott Tolinski?

  Yeah.

• 47:24Speaker 02

  this is, like, the official SDK is getting way, way better. And, uh, but, yeah, the Svelte MCP is built with TMCP. The Storybook MCP is built with TMCP.

• 47:34Scott Tolinski?

  What about the Syntax MCP?

• 47:36Speaker 02

  The Syntax MCP is built with TMCP, because I actually opened up VR to build the Syntax MCP.

• 47:42Scott Tolinski?

  I love, I, I'm sorry for not getting that merger. We're working on a big rewrite, so there, there's, like, some precedence there.

• 47:48Speaker 02

  Yeah.

• 47:48Scott Tolinski?

  Wait, you, you, you said, uh, you can use any type of, um, like, uh, um, you said ZOD, or what, what's your preferred schema library for that?

• 47:57Speaker 02

  100%.

• 47:58Scott Tolinski?

  Which one?

• 47:59Speaker 02

  Valibot.

• 48:00Scott Tolinski?

  You like Valibot the best. Why do you like Valibot the best?

• 48:03Speaker 02

  In terms of additional libraries, if I have a additional library, I don't want to feel bad if I ship that to the client.

• 48:09Scott Tolinski?

  Yeah.

• 48:10Speaker 02

  Maybe I don't need it, but if I need to ship it to the client, it's nice to know that my users will get like one kilobyte instead of 10.

• 48:18Scott Tolinski?

  Cool. I love that. Hell yeah.

• 48:20Wes Bos?

  Beautiful.

• 48:21Scott Tolinski?

  Cool. Uh, you got anything, Wes?

• 48:23Wes Bos?

  I don't know. I think this is good. I've got a list of things to check out. I've, we talked to Zach when he came on. He works at ByteDance about links. And this was before it was released and now it's, it's out and it's really cool to see. People are writing custom renderers and fussing with that. So certainly excited to check that out now.

• 48:46Scott Tolinski?

  Yeah, yeah, absolutely. Cool. Well, thank you so much for coming on the show. Uh, it's been a long time coming and I'm sure we'll chat soon.

• 48:54Speaker 02

  Yeah. Thank you for having me.

• 48:56Wes Bos?

  Peace.

• 48:57Speaker 02

  Bye.