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.
All right.
So today we are going to talk about Svelte custom renderers.
Is that what you call them?
Yes.
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.