Svelte Radio

In this episode of Svelte Radio, we welcome Jeppe as a new permanent host and sit down with Paolo Ricciuti, Svelte maintainer and Senior Software Developer at Main Matter, to dive deep into Svelte custom renderers. Paolo walks us through how custom renderers work (using React's approach with React DOM, Ink, and React Native as context), explains the technical challenges of bringing this capability to Svelte 5—including the template element trick, CSP issues, and runtime modifications—and shares his proof-of-concept work enabling Svelte to render to non-DOM targets like terminals and native mobile apps via Lynx.js. The discussion touches on potential use cases like Threlte for 3D graphics, the importance of this feature for Svelte adoption, and wraps up with picks including Screen Studio, TMCP, and Advent of Svelte.

Guest
  • Paolo Ricciuti — Svelte maintainer and ambassador, Senior Software Developer at Main Matter

New Host
  • Jeppe joins as a permanent co-host!

Topics Discussed

Custom Renderers Overview
  • What custom renderers are and why they matter
  • How React separates React (the diffing library) from React DOM (the renderer)
  • Examples of React custom renderers: 
    • Ink — React for terminal/CLI applications
    • React Native — React for iOS/Android native apps
    • Remotion — React for programmatic video creation
    • React PDF renderer for generating documents

Svelte's Technical Approach
  • How Svelte 5 uses the <template> element and innerHTML for fast rendering
  • The CSP (Content Security Policy) challenges with innerHTML
  • Paolo's compiler option contribution to enable programmatic element creation
  • The custom renderer API: defining operations like createElement, setText, setAttribute, appendChild, etc.
  • Separating the Svelte runtime from DOM-specific code

Lynx.js Integration
  • Lynx.js — ByteDance's cross-platform framework (powers parts of TikTok)
  • Why Lynx was the catalyst for custom renderer work
  • CSS support in Lynx including Flexbox, Grid, and even Tailwind
  • The difference between Lynx's element approach vs React Native's component imports

Related Projects & Discussions
  • Threlte — Three.js for Svelte (created by Grisha)
  • React Three Fiber — Three.js React renderer
  • Svelte Native — Existing (but limited) Svelte native solution
  • LiveView Native (Elixir/Phoenix) as a comparison for multi-target templating
  • Discussion with Grisha about mixing renderers in the same component

Funding & Open Source
  • Main Matter's sponsorship of Paolo's custom renderer work
  • First external sponsor for this initiative
  • Discussion about using Svelte Open Collective funds for this feature
  • Why custom renderers matter for Svelte adoption in enterprise

Paolo's Recent Contributions to Svelte
  • onChange callback for $state (PR in progress)
  • from action utility
  • CSP-friendly compiler option (foundational for custom renderers)

Picks
  • Screen Studio — screen.studio — Mac screen recording app with automatic zoom animations (Kevin's pick, used for Advent of Svelte recordings)
  • TMCP — github.com/paoloricciuti/tmcp — Paolo's TypeScript MCP (Model Context Protocol) framework, praised for being much better than the official SDK (Jeppe's pick)
  • Advent of Svelte — svelte.dev/blog/advent-of-svelte — 24 days of Svelte features and improvements (Brittany's pick)

Links

Follow

Creators and Guests

Host
Brittney
DS Eng @Provihq 🧜https://t.co/U8JoqVO4Sm 😺https://t.co/5FKTbGIW8d 👩‍🏫 https://t.co/wGvIldEAIe
Host
Jeppe Reinhold 🇩🇰
Open Sourcerer at @chromatic.com working on @storybook.js.org 📚Write stories. Not too many. Mostly Svelte ones.🙋‍♂️☀️⚓🌱🙋‍♀️Achievements:🏆🥇🥇🥇🥇
Host
Kevin A. K.
Co-founder of Svelte Society 🌎 Organizer of Svelte Summit 🏔 Host of Svelte Radio 📻
Guest
{🧪} +paoloricciuti.svelte
S1 | Developer | https://sveltelab.dev | Fat guy | Svelte Ambassador 🔶 | Svelte maintainer 🧡 | JavaScript Bender

What is Svelte Radio?

Things about Svelte. Sometimes weekly, sometimes not.

welcome to svelte radio hey

welcome everybody we're back it's svelte radio are you excited

Yes,

of course.

Yeah, everyone's excited. Who isn't? I'm here with my beautiful co-host Brittany. And today

I have an

announcement. Jeppe, from a couple of episodes ago, I think,

is joining

us as a host on Svelte Radio. Welcome, Jeppe.

Amazing. I love being here, so I'm super happy to now be here on a permanent basis.

From

guest to host in No Flux.

We're happy

to have more people rotating.

Yes,

yes.

And we also have a guest.

There's so many new people here today.

It's crazy.

Paolo, welcome.

Yeah,

hi.

And Paolo, you're a Svelte maintainer.

People can find you everywhere in the Svelte world, I think.

Yeah, I used to joke that if it has the word Svelte on it,

I'm probably involved in some way.

Yeah.

Yeah.

All right.

So today we are going to talk about Svelte custom renderers.

Is that what you call them?

Yes.

Yeah.

Yeah.

So basically, Paolo, you've made like a proof of concept of a custom renderer and stuff.

So there's all sorts of fun things to talk about here.

But maybe before we start, why don't you tell us a bit about yourself?

And how you got into Svelte?

I think we've

done this once before for Svelte Lab way, way back.

But let's hear a refresher.

To refresh.

So I am Paolo Ricciotti.

I come from Campo Basso, Italy, which is a very small city,

very small and cold city in Italy.

I am, yeah, as you said, I'm a Svelte maintainer.

So I was previously a Svelte ambassador.

I'm still a Svelte ambassador in the heart.

So I will continue to say that I'm a Svelte ambassador.

But I've also joined the core team, I think,

like it's been six, seven months now.

And I work for Main Matter, which is a consultancy.

We specialize in Svelte and also Rust

and like all this difficult stuff.

How is being a core maintainer?

What have you worked on?

Yeah, I mean, I did a bunch of small bug fixes overall.

I also worked, like, I have a PR open to the onChange,

like, you can add an onChange prop to state.

It's been stale for a while,

so, like, I don't know if we will ever get to merge, but...

So what

does that actually mean?

Like, onChange states?

Basically a way to, like, when you declare your state,

you can add an unchanged property as the second.

Okay, so just like an event, basically.

Yeah, it's basically a callback.

But basically it's a bit different from an effect

from the fact that, well, first thing first is sync.

So like it's not delayed after a microtask.

And also in general, like it's a bit less,

it doesn't rerun whenever some dependency inside reruns.

So like it's a bit more constrained,

but it could be very well used to do stuff like

synchronize with local storage or stuff like that

without

using one

effect.

Okay, nice.

That

probably is my biggest PR.

I also did some other nice feature.

I think I've implemented the from action utility.

And I've also added,

like one of my achievement on lock was

I've added a compiler option, which we will talk about for a second.

All right.

But we're not here to talk about all your other PRs, right?

We're here to talk about

maybe

an upcoming one.

So let's dive into custom renderers.

Well, why should we care?

Yeah, okay.

So a custom renderer is basically, it's a way to render Svelte to something that is not the DOM.

I think initially, I'm pretty sure that React was the first one.

I mean, the concept of React is based on custom renderers, basically,

because I hope that you don't have to know, but unfortunately, I know that when you start a React project,

you install bot React and React DOM.

And the reason for

that is because you are basically,

like React doesn't concern itself with DOM at all.

So like the only thing that React does,

React is basically a diffing library.

So like it's just saying, okay,

I have this huge tree of objects,

which is the virtual DOM.

And then I just say, okay, I need to change this thing.

So I invoke the custom renderer to say,

please update the text,

or please insert this element as a children of this element.

And so React is the defig library,

and then when you install React DOM,

is what is actually writing to the DOM.

And the power that this gave to React

was the fact that if you want,

you can technically write your own custom renderer

to use the syntax of React

and the reactivity model of React

to basically render to the terminal.

For example, there is Inc, which is a popular library

that allows you to write terminal application with React.

Or, for example, there is React Native,

which I

think is probably the biggest rendering

React

to a native application, so either Swift

or Android.

It's quite interesting in general, like custom renders.

You mentioned a terminal.

You wouldn't really think about, oh, should I use React for a terminal?

And then there's also other stuff.

I used to look with Envy on this thing called Remotion,

which is

basically React rendering to video, which is very cool.

So you could programmatically create

videos.

There's also a dog X renderer for Word docs and for PDFs, I think.

So that's pretty cool.

Yeah,

exactly.

Basically, the point is you are using the library,

the framework, the UI framework,

as a bit of a templating language

because, for example, a PDF is not reactive at all.

You are literally just using the templating language,

but it is the templating language

that you are familiar with, as well.

Or in case you can actually introduce

a bit of reactivity like in the terminal,

you might listen for input, for example.

So like when the user types something

and you want to re-render a part of the application

and the terminal is actually quite flexible

if you think about it

because like you can do some very crazy things.

Like we've seen now with like the advent of agents

and like, for example,

I think cloud code initially was,

I don't know if it's already,

but some of these are actually built with React Inc.

because obviously you can build this nice UI

with input that is actually a box

and not

just something

in your terminal.

Because, again, with ANSI code,

which is the things that you are using,

you can basically log some strings

that renders an UI inside your terminal.

So that's pretty nice.

Yeah, some examples of that are like HTOP on Linux,

so you can see

a bunch of stuff.

and so yeah basically

that is the concept of a custom

renderer and

Svelte at this

moment unfortunately does not have one

like does not have the capability

at all

because like there are

multiple reasons why there's

no like there's

there is no this capability

one of these

reasons is that especially with Svelte 5

this is like I think it's a

like interject like a very nice like side quest but and this by the way is the PR that we already

merged into Svelte so up until a certain version which I'm gonna search but basically Svelte 5

uses a very clever trick in my opinion to render your component so I don't know if you ever like

sneaked into the output of a Svelte component,

like the actual JavaScript that is compiled

when you run a JavaScript.

But if you have done it,

you would notice that there is like a JavaScript file

and then there is a call at the top level of the module,

which is something like $.template.

Now it's $.fromString.

But the point is inside this template,

there is a string which is basically

all the static part of your component.

So like if you have button with some variable,

then an h1 and stuff like that,

all these things are all part of this string, basically,

that is passed to this template function.

And obviously, like the reason why we need something like that

is because when you mount your component to the DOM,

you need to create all of this element, right?

So if

you would do something like that in vanilla JavaScript, for example, you would do something like documents.createElement, h1, and then documents.createElement, p, and then p

.textContent

is equal to hello world, and then h1.append p, and stuff like that.

So like it's a very, but an easier way to do it

and also faster way to do it is using the template element.

The

template element is part of the web component API.

And so in the template element,

what you can do is that you can write some HTML

directly into your HTML if you want.

And it will not render to the DOM.

It will just basically be a container that you can fetch

and then you can clone the input

and everything inside it's already created for you

by the HTML parser of the browser.

So it's very fast.

And so what

Svelte is doing under the hood

is that when you have, like, it builds this string,

it then basically creates a template tag in memory,

it's set inner HTML,

and then it returns the content of the template.

And so basically this is an easy way

for you to convert from a

string

to an actual bunch of elements

that actually you can put into the DOM.

So the template element never shows up in the DOM?

The template element doesn't show up in the

DOM,

regardless, but in this case,

it is never even close to the DOM.

It's literally a template

element in memory

that then

you set the

inner HTML,

and then we just use that element

to extract all the elements inside.

Now,

this is very, like, it's nice.

It's a nice trick.

It's fast and it's better.

He had a couple of problems.

The problem, number one, is that there are some CSP policies

that don't allow you to use inner HTML at all.

So, like, we had some issue actually open

because, like, there were people that will not be able to use Svelte 5

because Svelte 5 is using inner HTML.

So even if nobody in their code was using inner HTML,

Svelte was doing it and the CSP policy was saying,

you can do that.

I wonder what the reason is for that.

Well, because inner HTML is very prone to XSS attack, right?

That's why you

get the dangerously used HTML.

Yeah, fair enough.

This is not a problem for Svelte, obviously,

because the string that is passed to inner HTML

is something that we built.

So it

does

not have any user input at all.

So it is fine to do,

but obviously some CSP policy are very strict about it.

And so this was a problem for some people,

but most importantly for just Svelte custom renderer stuff,

it was a problem because in the terminal,

there's no template element.

So there's no way to create an element that when created

and when you set the inner HTML,

it would be very complex.

For example, Svelte native,

which is another way to build a native application

with Svelte, it is monkey patching document.createelement, basically.

Right.

But that doesn't work anymore in Svelte 5.

So the first step that we did, so first thing first,

I should say why the first thing that we did was because at MindMatter,

we love to give back to open source in general.

And we especially do that for technologies that we use.

So with Svelte, we use Svelte, we want to give back to the Svelte ecosystem.

And so when we stopped to think and we said, okay, what can we do for this Velt ecosystem?

We started to think about the things that we were talking with our clients, for example.

And some of our clients was actually saying, okay, but I want to use Velt, but what if I need an app, for example?

And so there was this issue laying around.

And so a few months ago at this point,

there was a new framework that showed up,

which is called Lynx.js.

And Lynx.js is basically the,

I think it's from ByteDance,

which is the company behind TikTok.

And they market it as like the alternative

to React Native, but framework agnostic.

So obviously everybody got really excited about this

just to realize that for Svelte,

we couldn't actually use it

because it kind of requires a custom renderer API of some sort.

And so when we were talking,

what can we do for the Svelte ecosystem?

We actually stumbled across this opportunity

and we say, okay, let's do it.

And so for a couple of months, I think three months actually,

I actually worked full-time on Svelte,

on Svelte custom renderer.

Oh, nice.

I was able to work with it

and I was actually able to get a pretty good POC of that.

So we spent a lot of the time also talking with the other maintainers

to figuring out the actual

API for it.

So in terms of, maybe I'm jumping ahead here,

but the problem is we have to separate the renderer

from

Svelte's diffing

functionality,

right?

So then does that mean that instead of using...

So I don't remember who I was talking to about this,

but there's...

Oh, it was Elliot.

So we did a stream, I think last week,

about the Hydrate

functionality.

And he mentioned, I think, if I remember correctly,

that Svelte used to be just

a string thing, but...

He was talking about the server side, though,

which is a bit different.

Right, right.

Oh,

I see, I see.

On the server,

Svelte basically do that.

Like,

it's all your

component.

Before the async stuff,

it was just

literally concatenating a big string

and returning this.

But I was going to say,

now there's an AST involved, right?

I think, no, probably,

like, there's always an AST involved with the Svelte compiler,

because, like, it's

an AST and then converted into

JavaScript.

But the server side, I don't think it's using the AST.

I think the only thing that Elliot had to do to make Async SSR work

is that it needs to be a bit more involved than just concatenating strings,

because there's

something

that you are waiting for and something that you are going through.

And then obviously you don't want to await for every single thing.

You only await, like if you have two components that are parallel,

you want to start the patch at the same time.

So that's why it's a bit more involved than just a string concatenation on the server.

But yeah, like it's obviously like right now on the server side,

it's a bit more complex.

On the client side, right now, like by default,

Svelte will still use the template tricks that I was talking,

because that's just faster and much more convenient.

But one of the first things that we did once we, okay,

we settled on some sort of API.

So we talked a bit with Reach and with the other

to say, okay, what kind of API do we want

for the custom renderer API?

Once we settled on a sort of API,

we said, okay, there is one problem now

that all our templates are literally just string,

like the static part of the template,

it's a string that we pass to template.

We can't do that because we need to basically,

I don't want to say to invoke document.h,

create element,

but we need a point where we can create an element

and then set the text and then stuff like that.

And so what we did is that the first thing

that also fixed the bug about the CSP

was the compiler option that I contributed to the Svelte compiler.

And because basically right now,

what you can do is that you can pass a compiler option.

And instead of creating this long string

that then is passed into the template,

it's actually creating an object,

which is kind of similar to the React object,

but we don't have a virtual DOM anyway, don't worry.

But basically, it's creating this structure

that then under the hood actually creates a bunch of,

like does a bunch of document.createElement,

document.setText,

document.

And stuff like that.

So it's doing all of this programmatically.

And this means that for the CSP problem,

you are not accessing your HTML anymore.

For the custom renderer problem,

we now have a place where we can put our call

into your code,

because

that's kind

of an issue, right?

Like the custom renderer is something that you, the user, would have to define and you would have to provide like your way to render as well.

Yeah.

And to do so, it means that we need a place where the framework can call your custom renderer so that it creates your element, basically.

Yeah.

You mentioned, I don't know, maybe you didn't mention it while we were recording, but you made a proof of concept, right?

So

after we basically merged this PR, I started actually working on the implementation itself.

And so what we ended up with is something that basically you as a user can pass a compiler option.

Obviously, like the API can still change until...

Of course.

If we actually get to...

Just put it in experimental.

Yeah, yeah.

That's fine.

The API can actually change, obviously.

But the idea is that you will define a module, and from that module, you will export your renderer.

And so once you export your renderer, you define your renderer by defining an object that contains a bunch of operations.

So you will need to define how to create a fragment, a document fragment in your system, how to create an element in your system,

how to

set the text, how to set an attribute, how to add a child, how to get the parent, how to get the next sibling and stuff like that.

And

once we have that under the hood,

we just basically invoke your function

instead of doing document.createElement.

So basically

when you define a custom renderer

and the definition will probably be something

like you just define the module where we can import it.

And so when you do that,

so that can be a module in your application.

So like technical, you could even like define your own custom renderer in line.

But more often than not, very likely what you would do is just, I don't know, install a custom renderer from a package and then you literally have the package as the custom renderer.

And so when you do that, by default, Svelte will basically change the runtime because there's also another issue with Svelte runtime, which is the Svelte runtime.

obviously it's hyper-optimized for the DOM.

So there are a lot of places

where we actually use some trick

because the DOM is hella weird.

So it is silly, but for example,

if you want to completely remove every element

from an element, right?

You can do document.remove, document.remove,

document

.remove,

document.remove.

Sounds like a lot of work.

document.textcontent is equal to empty string

and that's it.

So

if

you do something like this,

it would be much faster,

like even computationally.

And so the normal runtime of Velt,

I think it's only fair that it stays

as performant as

it is.

But this means that there are some,

like some other stuff that basically

cannot happen outside of the DOM.

Right.

And so something that we settled pretty early on

was that we will basically rebuild

a small version of the runtime

because there's also another interesting bit

is that if you are using a custom renderer,

you probably don't need hydration

because

with

a custom renderer,

there's no concept of server-side rendering

for the terminal or for a native stuff.

And so since you don't need hydration,

we can basically like wipe off all the hydration code

from the custom runtime.

And so make stuff

a little lighter

and easier to maintain on the other side.

And so the work that I started doing it is basically,

okay, let me start to rewrite the runtime

so that it's entangled,

like it's completely detached from the DOM.

And we can actually start using it.

And so I wrote a couple of,

like basically I rewrote,

I think the each block,

the if block,

the key block,

all these blocks.

I've rewrote it already.

I also rewrote part of the element runtime,

basically.

So the things that actually creates the element.

And once I've done that,

I was actually able to,

like I started the POC

and I actually got a links application working.

It was a bit more involved on the links side.

Because in links, you basically have this,

they are called the element PPI,

that you can basically call to create a links element.

And it's kind of similar to the DOM.

You can literally do underscore, underscore, create element,

and you pass.

You have

a list of elements that you can create in links.

So you can create text.

You can create, I think, view.

Text and view are the ones

that

are very useful.

And then it will create an element in links.

And so I've built a small to-do app in links,

and it actually worked.

After that, so unfortunately,

after three months of working on it,

we kind of ran out of funds for doing it.

We had a set budget to do it.

So actually, right now,

we are looking for funding for that.

So if you are interested, by the way,

like if you or any of your companies

are interested in building a native app

or even just like, I don't know, for example,

we have been talking with people

that maybe they have a custom WebGL runtime

and they would love to use Svelte as a templating language.

And so like they are

interested in,

we actually got a bit of,

we got our first sponsor recently.

So, but if you are interested,

you can go to sveltecustomrenderers.com to learn more.

And you can contact us and we can

bring this to the finish line together.

How far are you?

Do you need three more months or a year?

We

kind of estimated it around four or five months.

So it's not super far because I think already the POC was enough to be.

But obviously there is a lot more to do

because first thing first,

I need to bring the branch up to date with today's belt.

That will be a challenge a bit

because obviously there is the async stuff.

There's also a new system to manage branches.

There's also a new system to manage each blocks

and stuff like that.

So a lot of changes since I last worked on this.

So I need to bring it up to date.

There is also a bit more, which is right now,

like the client runtime,

which is what we are really interested in.

So like the reason why you might want to use like Svelte

to build a terminal application

is because you want the Svelte signal runtime

to power the changes inside,

behind your terminal.

Now the client runtime is kind of baked in like physically,

like the files that contains the client's runtime

are all inside the client folder, basically,

which means that there is a bunch of circular imports

and some of these circular inputs go back to some module

that access the document

.mediaquery,

for example,

at the top level.

So when I tried to build the links custom renderer,

I basically had to like surgically remove every import that was leading

back to

that.

But obviously that will not be maintainable.

So like some other work that I will need to do once we were able to work a bit more on this is that I need to take the runtime and move it in its own shared module so that it's detached from any document API.

That would

work too.

I was going to say you need some kind of alias system or something that would

change the

imports.

Yeah, but I mean, it's much better to like,

even for future, like for free to prove the code base,

like we want the runtime to be completely

like in its own module

so that we can actually access it from both runtime.

So I'm wondering,

what does the authoring experience look like?

Let's say you build this custom vendor with links

and you have like iOS and Android.

I mean, in React DOM and in Svelte,

you use div and P and whatever HTML elements.

in React Native, you use view and text.

What would you use in Svelte links?

This, I think, is one of the nicest parts

of the custom renderer API,

is that you kind of get to choose what you want to do.

So, like, the custom renderer that I've built for links,

I actually use the same API that I have

for the links react, react links.

And

so, in React links and in my custom renderer,

you would need to do view, text, and stuff like that.

So it's kind of similar to React Native,

except that those are actually elements.

In React Native, you need to import the component

and use the component and stuff like that,

while with links, with SvelteLinks,

my SvelteLinks thing,

I actually did it so that you can just use,

just like you would do div, you would do view.

and stuff like that.

How does the IDE and or the types handle that at all?

I mean, in terms of like the IDE sees it as just

like...

Just a named div, right?

Yeah, it's just

like...

I see.

It's technically

a custom element

because...

Oh

yeah, of course.

Everything, like if you're in the DOM,

if you do slash view, it's a custom element.

It's

not a web

component, but it is a custom element.

So that's how you see it.

Obviously, we could also think about some more deep integration.

I think probably, I actually haven't tried this yet,

but I think that you can actually do,

we can probably do interface merging with a.d.ts.

So you

can just reference a.d.ts

that then augment the types that Svelte already provides

for the

DOM.

and so you should be able to also get some auto-completion

if you want.

Obviously, that will be related

to the custom renderer creator.

That's the, like,

but the nice part is that you can actually come up

with your own way to name stuff.

That's the nice thing.

Like, technically, and for example,

in the view integrate, like,

when links came out,

a lot of frameworks tried to build an integration with it

and there are some PR that I actually use as a reference

for solid and view, for example.

And for example, in view,

what they did is that they related some element

in the HTML world into some links element.

So like what you could do is that if you see div,

you assume that div is a view.

If you see text, like if you see span,

you assume that span is a text.

And again, the nice thing is that

since you are the one responsible to create the element,

you can do pretty much whatever you want.

So

you can come

up with your own symbols.

In the meantime, I can already tell you that

obviously this will probably depend on the recipient

of the custom renderer.

So for example, links can actually render your thing

to Android, iOS.

Yeah, yeah, yeah.

So basically writing to one,

writing one template is very nice, right?

Because you get to write once

instead of three times, right?

Or two times for links and HTML, right?

Is there some thoughts about like

letting the user write multiple things

at the same time?

So let's say you have a project

and you want to create both a DOM target,

if you will,

and then also a links target.

so a build

but you kind of want

yeah yeah yeah

and you want to share

maybe

the reactivity of it

but

the templating

you might

so

I think

that

I

I would need to

think a bit

about this

but

I think

depending on how

you structure it

it can

probably

work

in both ways

so

I guess

the problem is really

that it depends on

the kind of custom

renderer that you

build like at that point is more on your side than on the side see there

being a compiler

with compiler options that you can feed your options to and then it compiling it just like

we do with spell like we have compiler options

we

can build the package you could do this with that

too it could build a package for the dom and build a package for native

yeah yeah so what i'm asking

is so like I know there's a project called LiveView Native in like the Elixir world and

they went the route of so Elixir is a framework built on

sorry

Phoenix LiveView is a framework

built on Elixir and LiveView Native is built on top of Phoenix and or rather LiveView and they

let you write templates depending on what you want to target and then it kind of reuses the

same logic it's it's not really i i suppose it could be a custom renderer in a sense

but i i'm kind of asking like i i want to bring multiple templates into the same space kind of

and reuse the script tag for example like obviously like you can put you can extract

your logic into like state classes and stuff and put them in a separate module and then import them

but I don't know.

Yeah okay so we actually so I was talking with Grisha which is the creator of

Threlt which obviously like for example

would be nice with a custom renderer there.

Yeah react

react 3-fiber which is what like is the 3.js version of react is actually using a react

renderer under the hood.

And so I was talking with Grisha

because obviously I asked him for feedback

on this feature because it could be interesting for him.

And he actually says something like that.

So like right now, basically,

you have to kind of compile one custom renderer,

like one component, at least one component.

It needs to know that he wants,

that you want to compile with custom renderers.

You cannot do it at runtime, as I was saying,

because

the condition

is literally different

from

one

to the other,

because it needs to import the different runtime,

it needs to import your custom renderer,

it needs to store your custom renderer somewhere,

because it needs to reuse that

when you trigger an effect, for example.

So

before

triggering an effect,

we need to reset the custom renderer

and then adding it again.

So because of this, it means that you can't really have

in the same component two different custom renderers, right?

So the solution would be to move that code

into a separate component and

run that component

with a different custom renderer that could work.

Obviously it depends on the kind of renderer

that we are talking about.

Like if the

final

target is still the DOM,

like with Trelt, for example,

you would still render to a canvas

or to, like, it's still in the DOM environment.

So probably

one can work with

the other.

If your custom renderer is accessing the links PPI,

obviously cannot in any way or form mix with DOM.

So like that will, like,

it's mostly on the custom renderer side again.

But the fact that you will, like, this is what actually one of the input from Grisha is that he wanted a way to seamless move from one custom renderer to the other without having to create a separate component, without having to

do that.

We actually thought a bit about that.

We didn't actually settle that part.

So, like, that's something that we were working on.

We are thinking if there is a way to do it.

That's the point.

Because I think if you have a clear mark inside your component, it could work.

But we'll need to see.

That brought up another question that I had.

Are you looking for financial support just for you and MainMatter to work on this project?

Or is this for, like, spelled maintainers?

Or is it open to, like, everyone to be able to help and contribute to it?

Obviously, like, everybody can help to, like, and contribute.

we are looking specifically for funding because I honestly I tried to work on this on my free time

but it is a it is a big project like and

it's

very difficult to do I don't have much free time

and and it's also like it's a very big change and so like I like the reason why we are looking for

funding is because I need to be able to work on it full time like even when I was working on it

full-time. We were

doing progress and we actually did a lot of

progress because obviously we were able to

merge the first PR and

then to building the POC

and stuff like that, but it was still

like, it would

probably also take a lot of time to

complete. That makes sense.

Yeah, I'm

out of questions.

Jeppe, Brittany?

No, it's super awesome. I want to see

this tomorrow, so

whenever

you

release this.

Yeah. I mean, again, like if like something that could help, like, obviously I know that like not everybody works for a company that is building a native app, for example,

and not everybody

is building terminal application.

But if you know of any companies that might be interested in this, we tried to reach out to some company and we are actually talking with some company and we actually got our first sponsor.

So like we luckily got the first sponsor.

So actually a bit of work is actually happening right now.

What I was trying to, what I was trying,

like what will happen in the immediate future

is that probably I will try to bring the branch up to date

with the funding that we got.

And once I got that, I should, no promise, but I should be able to at least keep it up to date.

Because at MainMatter, we also have like basically 20% of our time, we can do it, we can do open source.

And so if I can do open source in my 20% time, I might be able, once I build this, like I bring the branch up to date.

And then after I do that, I can try to keep it on par

so that when we get new funding,

we can actually immediately jump into it and start

working on it.

Make progress quickly.

And so what

I was saying is that if you have any company

that might be interested,

please send them to SvelteCustomRenderers.com.

I'll put it in the show notes.

So in summary, basically,

the first work that needs to happen is,

well, bring the branch up to date,

but then it's not so much about writing customer renderers yet, right?

It's more about making it ready

for anyone

to write a custom renderer.

Yeah, exactly.

So the

main goal of this initiative

is basically bring the custom renderer API to Svelte

itself.

The moment we have something insveled,

then we can, like, literally everybody

can write a custom renderer.

And I have

to say, by the way,

like, maybe it is because I am,

like, I wrote the actual code underlying that,

but I have to say that

they are decently easy to build.

Like,

at

the end of the day,

it didn't took me much time to build

the terminal renderer and the links.

Yeah,

yeah.

I mean, you would just have to handle,

so in the example of links,

you're kind of offloading the complexity

of creating native apps

to

links, right?

So you don't have to think about like,

oh, how do you do this in iOS, right?

Because links will handle that for you.

But like theoretically,

you could write an iOS renderer or something.

Yeah, please.

That would output...

You could technically write an iOS renderer

that just renders into Swift elements, for example.

Yeah, yeah, exactly.

But then you would need to do work around that

to actually make it into an application.

Something

very nice about Lynx

is that they have a very good CSS support.

So when you build a custom renderer for Lynx,

I was able to use Flex, Agreed, even...

Oh, wow.

You can run Tailwind inside.

Oh, nice.

I'm sold.

I didn't write anything of that.

Like, links did all the job.

So

the only thing that I did is

write the code

so that when you, I don't know, write a style tag,

you actually get the CSS for that.

And links handle all of that.

That's awesome.

I want

to also shout out our first fan,

because it's like

a sub

code that actually came in

and gave us a bit of funding for working on this.

And so like with this funding,

we can actually start working a bit on like bringing

in the branch update and so.

- So this brings me to another question.

Why does

a supplement company need a custom renderer?

- I get, they are using Svelte and probably they,

I mean, I don't know if they are using Svelte,

but they want to

use Svelte.

to use Svelte.

Okay.

Yeah.

Maybe you can

create a renderer

that creates

supplements.

Yeah,

you can probably.

So you can

declaratively

define

I

want to call

a 3D printer

with Svelte.

A couple of

companies that I

worked for

would have

like

chosen Svelte

long term

if they had

had that

as an

option.

That has

been

a deterrent

of keeping

Svelte around.

That's also

why we started

working on this

because like

we have seen

clients asking, yeah, how, like,

but does Velt have a solution for,

granted,

sorry, I just want to say this

because I'm very keen on this.

Like, if I have to build an app for myself

or for developers, I will 100% go with PWA.

I was going to say the same thing.

I'm just going to say that I would just build a web app,

like, over native period.

I

think we talked about this with, was it with Ilya?

a couple of weeks ago

when we talked about

I mentioned Stanislav

he showed

like a proof of concept thing

with like

animations and stuff like a stack

thing

with like a progressive web app

basically like a Twitter clone

and it

like

he showed it on his phone and it

feels like native

it feels like yeah

it's really really cool

I guess you know what PWA can do today,

but it's true.

Nowadays, the web is very powerful

and you can do a lot of stuff.

The only issue, in my opinion,

for PWA is to really have adoption

is the fact that you cannot install them

from the App Store.

Yeah, it's a distribution part.

You need to get in there.

Yeah,

it's just discovering

and also the fact that they feel more fishy

to the main user.

For developers,

it's absolutely fine.

I will never build.

If I'm building a product for developers,

I will never build an app.

But if I'm building a product for my mother,

my mother will never install a PWA.

What do you mean?

You don't want to open the share menu,

scroll to

bookmark to home screen

or whatever the option is?

No.

But I also, I

mean,

I think there's an important piece of the puzzle here

is that I don't think people want to build

their own custom renderer.

They probably don't

care even.

What they want is to be able to write native apps in

Svelte.

And

whatever gets them there is what we'll be happy about

and everyone in the ecosystem, right?

As

I was saying, most likely people will actually

just install a custom renderer and use that custom renderer.

But it is very nice that you can actually build your own pretty simple

because maybe you have some custom solution that you need.

I was talking before with this theme

that they have already a WebGL renderer

that they are using,

and basically they've built their own DSL

to interact with it, and they hate it.

And they would love to be able to write

a Svelte component that then render

to their WebGL renderer,

and that will unlock them to do it.

Yeah, very exciting.

I feel like this should probably be a higher priority.

From an outside perspective,

in looking at the Svelte,

whatever people are doing inside of the Svelte project,

this is one of the key issues for adoption for Svelte.

Even if, because it's like Brittany said,

oh,

long term, maybe

we want an application.

How are we going to, oh, no, we can't.

oh, we'll pick React, right?

That's how it goes.

So I think, I wish it was high priority.

Like, personally, I would just spend

some of the open collective money on this, but...

Yeah, I mean, there's also talking about that,

obviously.

Yeah, yeah.

Because we do have an open collective

and there are a bit of money on it.

So we will probably

also use

part of that.

It's better to use the money than not use it, right?

Because now it's just sitting there and earning interest for open collective.

But I mean, it's also true that like, like the pros and cons needs to be good for, because

you can own

for, to the people that actually donate, but I

agree.

Yeah.

It's, it's like a, it's an opportunity cost as well.

Like if you spend money on, on the custom render stuff, you can't spend money on something

else.

So anyway, let's, let's talk unpopular opinions.

do you guys have one Anthony is not here he usually has one but uh we will have to do without

um so

I I mean I don't know I finally bit the bullet and switched from Android to Apple and I

have an iPhone now and I guess I don't know there are things I cannot stand about Apple and iPhones

and it drives me absolutely crazy that the ipad keyboard that i have has this ability to

hold a key and then you swipe up or down like you're scrolling on it and you

get like

your

special characters you get your numbers like whatever you're on you get whatever's on the

upper part of it that doesn't exist on iphone and the keyboard

is

like the worst keyboard ever

ever and like

i installed gboard which is like what i was using on google android and it doesn't

have any of my savings type it doesn't know that i'm vulgar so i typed in shit and it autocorrected

shoot like all the stupid things and it's driving me crazy i need a keyboard that functions for apple

Yeah. So what made you switch to Apple?

So I

switched because

family permissions.

So we're actually giving our kids phones for Christmas.

Verizon, one of the companies here

in the U.S., had free phones.

So we got our new service that has all of us on it.

We're getting them phones.

And family permissions, it's always been a hassle because my husband will have to approve it

or I'll have to get my iPad to approve it.

it's just it's it's been annoying

i think in the u.s is very like iphone is basically almost a

necessity right it

it is like 90 something percent i

think of the ecosystem

but i have been a die-hard

samsung user since like the note 3 like i love i had a samsung 24 or ultra and

so your so your

unpopular opinion is iphone sucks basically no it's

that iphone keyboards

iphone keyboards suck

i actually like i like a lot of things about the apple phone much better like all these extra

buttons it has now it has one to open the camera and i can double click for wallet and then i have

one that turns my flashlight on without me doing anything

like i

just push a button

that's nice

but

there are is that a thing mine

has it i have the new phone though i have the 17 max pro

but there's an action button that you can set for the flashlight there's a new button that opens the

camera

yeah yeah

i like a lot of things it's the keyboard is

freaking

terrible

it's interesting you

say this because i i was actually thinking about completely getting rid of all my apple stuff

just going

Android and

Linux.

But I realize as I've been thinking about it,

it's just like, no,

it's going to be too much work.

I would have never bet to ever hear this sentence from you.

It was

much easier for me to switch

than I thought it was going to be.

I thought the transition out of the ecosystem

was going to be the worst.

But Google transfers.

So

Gmail,

like Calendar, all of that's on my iPhone.

I didn't have to do that.

So the

thing I

had to do was

cancel Google One.

That's it.

Talking of switches,

I tried to switch from VS Code to Zed.

And I was not like, I think it's nice.

Like, it is very nice and it's fast and it's,

but there are some, a few things that I like really enjoy about VS Code

and that are really part of my workflow.

I can never get rid of them.

and so

nice

wish back

all right

unpopular opinions

anyone

I think I have one

that might be unpopular

maybe it's popular

I think it sounds unpopular

but I actually like writing

my thoughts down in Notion

I know you're not allowed to say that out loud

you

have to write in Markdown

files

or Obsidian or whatever

but I like Notion

and

when you get it under your skin

it stops getting in the way of you

and it just helps you continue

Notion is also one of the few apps

well not one of the few but

it doesn't yet also complete

with some AI suggestions so it doesn't

take me out of the flow it

just

looks me right

and that whole

formatting

thing like it just works for me

but I also get like if you don't understand

the keyboard shortcuts if you don't understand

and the whole code blocks versus headings,

then it's super annoying.

Do you do it on the web, or have you used the app?

No, it's the app.

I just don't know if there's a difference.

I was going to agree with you that the web version is fine,

but then as soon as I used the app, it would jump around on me.

I would try to select

something,

and maybe it was because it was the Android version of the app.

Maybe I

need to try the Android version.

The Android app is meh.

Okay, so maybe that was

the reason.

Maybe I should try the app version.

No, but I did like it on the web.

Yeah,

I see.

Okay, I don't know if this is an unpopular opinion,

but I really don't like autosave.

Oh, interesting.

Well, it depends

on what you mean by

autosave.

Autosave or save on format unsave?

Format

unsave, I love it.

But autosave,

no.

I will

never autosave.

I don't do autosave either.

When would you

autosave?

What does autosave mean for you?

Save on blur.

When

you

blur the...

Autosave, so as soon as you stop writing, it saves you.

Oh, I see.

Oh, wow.

Yeah, that does mean it.

Yeah.

And I actually got this because I had to write a tiny bit of Rust.

I don't know Rust, right?

but I was surprised by the fact that in Rust,

you don't get errors in the editor

until you save the file.

Which to me,

it's wild.

Like I was there and I was seeing like squiggly lines

on part of the code that was not there

because I just changed it.

And I talked with a colleague that obviously,

we also specialize in Rust.

So like he's a Rust developer.

I said, like, do you really not, like, get, like, errors and warnings and stuff until you save?

And he said, yeah, but, I mean, I have auto save on, so, like, I always get it.

That's the solution.

Maybe we need it if

they have that, then.

Yeah.

That's weird.

Oh, wow.

Save on idle?

I've never heard of that.

Like, that sounds super annoying, but I would definitely always buy save on blur.

So save on blur is when you switch away from the tab?

When you switch

to the browser, then it saves.

Or when you switch tab, then it saves, right?

Yeah.

Okay.

We

had a setup

where we had, like, lint on save.

And then the linter was, oh, there's an unused variable here.

I'm going to delete

that.

And so if you wrote the variable but didn't use it yet

because you

had to read documentation, that was really good.

Another issue is

that, like, I think, at this point,

I suspect it's my fault, to be fair.

Because I contribute a lot on open source, right?

So like, obviously I work a lot on Svelte,

but I also contribute a lot on open source.

And every single time I work on an open source project,

like the moment I save,

like it's almost like their Precure config is not like a thing.

Like either they misconfigured it

or I have something in my editor set up wrongly.

And I always change so much of the editor.

So like the moment I do

that

too,

the moment I have to contribute to some other open source project,

I always do like,

I do my changes and then I format save without format

and without formatting.

I do that when I have to touch other people's files because we even have a

prettier config set up, but the other,

I don't think the other developer that works on the project

runs format

or

went or anything ever.

And so I

go in there and it will have like the entire page is changed.

and you're like oh

yeah yeah that's a that's not fun

we

need a ci that like just auto formats

and lints everything but it would have to be ran once through everything i mean

there is right

there's uh there's like a bunch of the stuff that you can do like a husky oh yeah is

yeah husky

It's not CI,

though.

I mean, you could...

Husky is pre-gommetook.

Husky did.

Yeah, exactly.

I don't think you should have pre-gommetook.

I don't know if it's unpopular.

Yeah.

I don't know.

All right.

Unpopular opinions.

Now it's picks.

I have a pick.

So I am going to pick Screen Studio.

Found it today.

I needed to record Advent of Svelte day four.

And I was in a hurry.

And I found Screen Studio.

And it's a really nice application.

Basically, it lets you record your screen and your cameras and everything.

And then it lets you edit afterwards.

And it has these really nice Zoom animations.

I

think Paolo

loves them.

I think they are very nice.

I just think that I'm popular opinion.

No, because I think a lot of people on the web uses this.

and like some people really go bonkers

with Zoom animations.

So like they move them around

and like the whole application shifts

left and right.

And it's

very annoying.

I've been using Screen Studio for years.

I love it.

But also the first action I do

whenever I open a new recording

is to disable those Zoom things.

Yeah.

So you don't like the advent of Svelte day four either then?

I

mostly looked at your face.

To not get disoriented.

No.

So a few weeks ago, I had to record a video of myself,

like without, not the screen at all.

And I chose to record that with Screen Studio

just because I wanted the editing features.

Ah, right.

Yeah,

that's good.

All right, that's my pick.

Anyone?

No picks?

I'm trying

to think

of something.

Not a lot of good in the world this week.

You said my microphone is terrible, so I was maybe going to pick these headphones, but these are the Beats Studio Pro headphones for, like, noise cancelling and sound quality.

They're amazing.

But apparently the microphone is so-so.

I mean, it's good enough.

It's good enough.

It's not a studio microphone, but I would be

surprised if it was.

Advent of Svelte.

That's a good pick.

That is a very good pick.

Nice.

Yeah.

Advent of Svelte.

yeah

do you have one?

I mean if we're doing

insider picks

I would choose

TMCP

because

I'm working a lot

on a storybook

MCP at the moment

I've been for a month

and it's based on TMCP

which is this framework

that Paolo is building

and that is just

a billion times better

than the original

official MCP SDK

so

it's a joy to work with

it also helps of course

that I can just

ping Paolo

and it'll fix stuff

but it's like

the API is better

the docs are better

if you're doing MCP stuff

use TMCP

even if you don't use Svelte

I'll slide like the 20 euro

nice

all right

I think that's everything for today

thank you Paolo for joining us

and

again welcome Jeppe as a new

host

Brittany, hello.

I am by.

Sorry, what?

I am by, like

we're saying goodbye.

Yeah. Definitely go find Paolo and

fund this custom render stuff because I also want custom renders.

With

that said, goodbye everyone.

Thank you.

See you.

Bye.