Preact, Performance, and the Future of Lightweight Frontends with Ryan Christian -JSJ 683

In this episode of JavaScript Jabber, we sit down with Ryan Christian, a core maintainer of Preact, to talk all things lightweight, performant, and practical in the JavaScript world. If you’ve ever wondered what makes Preact tick, why it continues to gain traction, and how it compares to the heavyweight champ React—this episode is for you.

We get into the nitty-gritty of what separates Preact from React, not just in size but in philosophy. Ryan sheds light on how Preact is engineered for performance, why it's not just a “React clone,” and how its compatibility layer makes it easy to drop into existing projects. Plus, we explore signals, class components, and what the upcoming Preact v11 has in store.

Episode Highlights

• [1:23] - Meet Ryan Christian: Preact core maintainer and open-source champion
• [4:10] - What is Preact, and how does it stack up against React?
• [10:15] - Preact’s tiny footprint and why size still matters
• [14:47] - Widgets, adoption, and why Preact powers ~6% of major sites
• [20:01] - Understanding Preact’s compatibility layer (PreactCompat)
• [25:40] - Hooks, signals, and modularity: build what you need, nothing more
• [31:10] - Why Preact won’t follow React into full-stack territory
• [37:22] - Server components, suspense, and what Ryan recommends instead
• [43:35] - Frameworks that pair well with Preact: Astro, Fresh, and Remix
• [47:55] - Sneak peek at Preact v11 and why it sticks with “classic” React experience

🔗 Links & Resources

• Preact Official Website
• Astro
• Fresh by Deno
• Remix
• Jason Miller’s VTalk on Signals (referenced)
• Google CrUX Report – for framework usage stats

Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.

Episode Transcript

Speaker 1 (00:05):
Hello, everybody, Welcome to another exciting episode of JavaScript Shabber.
I am Steve Edwards, the host with the face for
radio and the voice for being a mime, and if
you're watching on TV you can see that. And I'm
here with co panelist mister Dan Shapiro. How you doing, Dan,
I'm doing great.

Speaker 2 (00:21):
Hi from Tel Aviv. Is it still hot and dry,
isn't it always? Oh? Yes, yeah, it's good.

Speaker 1 (00:29):
We got really we got up in the nineties, fair
nine here recently, but it's a little cooler and cloudier today,
which is always a bummer. But anyway, our special guest
is mister Ryan Christian. How are you doing, Ryan?

Speaker 3 (00:42):
Doing great?

Speaker 2 (00:42):
Thank you?

Speaker 1 (00:43):
So before we dive into the topic of Preact, once
you tell people who you are, why you're famous, why
they should give you money, where they can give you money,
et cetera.

Speaker 3 (00:54):
Oh man, I wish.

Speaker 2 (00:57):
Well, I'm all the people working on open source super rich. Yeah, yeah,
I hear.

Speaker 3 (01:03):
The Larry Belle guy has a lambo soul waiting for
mine to come in, still waiting for one. So my
name is Ryan Christian. I'm a core maintainer of Preact
and have been for the past about four and a
half years now. Preact, for those unware, is a job
script UI library, and as the name can sort of suggest,

(01:28):
it is largely API compatible with React and shares a
lot of similarities with it in terms of how you
use it and some of the API constructs. I guess
where we diverge a little bit, just give a little
bit more information, is we're kind of more focused on size.
The core library is about four kb these days four
and a half kb, contrary to our marketing line, which

(01:50):
will be updated shortly. And we also kind of focus
on performance a little bit more heavily than React does.
And that terms React I think comes about across the
wire about sixty kV these days fifty eight. So there's
a quite big floor in difference in terms of the
size of libraries and how they can be used.

Speaker 2 (02:11):
So I have to ask a question about that. I
know that well. First of all, going back a little
bit in history, pre Act was created by originally by
Jesson Miller, and as I recall, he created it because
his attitude was that in order to properly understand something,
he needs to effectively rebuild it, and he rebuilt it

(02:34):
so well that it became very successful and on its own.
By the way, we were talking about this before we
started recording people, I don't think people necessarily realize how
popular pre act actually is in terms of by the
way you called it a library, why don't you call

(02:54):
it a framework?

Speaker 3 (02:57):
I guess my view is, I guess the older view
of a library is something you call in, something you use,
you manage to put in your existing app, or however
you want to do it. We generally don't prescribe solutions.
We don't require you to use it in certain ways.
It's a have toolkits that you can use however you

(03:17):
see fit, which from my understanding is for my use
I suppose is better fit towards the library side of
the spectrum than framework.

Speaker 2 (03:28):
But yeah, it is nuanced. I use the kind of
definitions that I used to use was that with and
I know that a lot of people still use them.
AJ for example, I know likes to use. This distinction
is that with the library, your application code calls into

(03:49):
the library, and with the framework, it's the framework that
calls into your application code. I've kind of modified the
way that I look at it. The way that I
look at it is that frameworks prescribe certain architectures, whereas
libraries do not. So that's kind of the distinction that

(04:09):
I make these days. So you would say that Preact
does not kind of describe a certain architecture.

Speaker 3 (04:16):
No, I mean, we generally leave that up to users.
They can decide how to do it. We're only concerned
with components and how you build out your you know,
veed on library and whatnot or vt on tree.

Speaker 1 (04:30):
Excuse me, so coming coming from the view view standpoint,
you know, I haven't really developed with reacting and myself,
so I'm just curious trying to understand how Preact works
and React. So if I have a pre Act project
in my package at Jason, do I only have Preact
and then that depends on the React library or how

(04:53):
is it that you have this this this much smaller
version of React. Does it have all the functionality of
React itself or just a limited set of functionality?

Speaker 3 (05:03):
Sure, so that's a great question. Preact core itself, Preact
is split into a bunch of sub packages. We have
the main Preact library that you install, and that comes
with a core of like I mentioned about four and
a half kb of content that has mostly focused on
class components. However, We have add ons which add different

(05:24):
API constructs, such as Preact slash hooks, so it's installed
with the Preact library and bundled into the Preact library,
but hooks you have an optional add on. Compat is
another thing that we look at. So our compatibility with
React comes from another subpackage, Preact compat, which is about

(05:46):
ninety five percent compatible with React. But we diverge in
some pretty big ways, namely around the event system. React
uses their own synthetic event system. They do not use
the vanilla events that you find in the dom. Well
they still do, yeah, and they'll probably have to do

(06:07):
so forever because that would be one hell of a
breaking change at this point. So that is a huge
ton of huge, massive code, and where a bunch of
that size comes from. I know a couple of years ago,
is something like twenty twenty five kb just for the
event system. They also do a bunch of event delegation

(06:27):
by default, which again is just more code, as well
as a lot of their newer concurrent features, so you
can have like two different trees rendered or in memory
at one point. We don't do that. We are generally
more focused on web standards and keeping the kind of
core library small, so the core is kind of focused,

(06:51):
but we do have compatibility with React, and that just
adds that links into existing reacts libraries that you might
have your package Jason or whatever, and kind of converts
the React vedam shape and the React constructions some of
the React ideas into what Preact understands. So if you
have a Preact project, you're only using Preact, we alias

(07:15):
out React for Preact compat if that makes sense.

Speaker 1 (07:20):
So then Preact itself is small, but you still got
some other dependencies.

Speaker 3 (07:26):
Sorry, sort of it. Those dependencies are in prec. I
mean those dependencies are part of Preact. Our compatibility layer
is part of Preact.

Speaker 2 (07:36):
Yeah, you can clear because you kind of in you
alluded to it. And it's important to make this point.
Preact is not dependent on React in any way, shape
or form. When you use the project with Preact, it's
just Preact. It's compatible with React, it's not built on React.

Speaker 3 (07:55):
Yeah, completely separ things.

Speaker 1 (07:57):
So you're basically just taking the most important stuff and
put it in a separate that has the similar you know, functionality.
It's almost like you're mimicking it.

Speaker 3 (08:08):
Yeah, yes, form, Yeah exactly. We take the APIs and
we mimic them and try to recreate them in a
smaller form that works for our needs. Okay, yeah, that
React knowledge and still the effective and functional.

Speaker 2 (08:22):
So I've not used pre Act in a while to
my detriment. So we were talking before about the usage
were The fact is that Preact is the number one
framework slash view library out there. It's it's used as
much as all the other frameworks combined. Just so we

(08:44):
have a total size, View is about somewhere between forty
percent and a half. I'm basically the numbers I'm using
are from the Google Crux, which basically looks at the
numbers of origins. You can have other measurements like the
number of NPM downloads and stuff like that. I guess

(09:06):
they're kind of aligned, but probably a bit different. View
is like about somewhere between half and forty percent of
React and pre Act is about thirty percent of React,
which doesn't leave a whole lot for all the other frameworks. Yeah,

(09:26):
when you think about it, but it does mean that
Preact is a third of React, which is the leading
front and framework, which is a lot. You're used by
thousands of sites and web application hundreds, well, actually hundreds
of thousands, I will.

Speaker 3 (09:42):
Yeah, And there's something a little bit more interesting there
is because preact has this focus on small size, it
is especially well suited for widgets.

Speaker 2 (09:52):
I know.

Speaker 3 (09:52):
I think a number of major websites use Preact on
it to the point where Jason quotes a figure Jason Miller,
who created quotes figure that Preactive be found on about
six percent of sites these days, or major sites used.
So this isn't necessarily as the main view library or
the main driver of all interactivity, but that it can

(10:14):
be found on a huge portion of the web just
because it could be used for those kind of small,
self contained widgets.

Speaker 2 (10:23):
So that kind of brings out a point that I
was thinking about, because these days, when you consider this
typical size of a web site or web certainly of
a web application, they're pretty huge. And they're huge mostly
because of either user code or because of the whole

(10:44):
bunch of NPM stuff that people just bundle into their
web applications, to the extent that the twenty to thirty
K difference between Preact and React is not necessarily a
whole lot at the end of the day, or do
you disagree.

Speaker 3 (11:00):
Well, it's closer to fifty k these days, and sure
when you start building massive websites, that is indeed going
to be swallowed up by you know, node modules or
user code. I was looking at the open ai site
the other day and I think it downloads something like
three megs of JavaScript. Fifty kb is not going to

(11:21):
make a difference there.

Speaker 2 (11:23):
Gesip three megs or yeah.

Speaker 3 (11:27):
Yeah, it has no code splitting whatsoever, so it loads
absolutely everything. Did you guys not see that? There was
the article between Sam Altman and Jonie I've that came
out a couple of weeks ago. It's a static page,
just has a single you know, BIV text, single video,
and it loads three megs of jobscript because it's a
next yess app with no codes playing whatsoever. So it

(11:50):
loads all of the you know, chat g ept and
stuff into it. It's bad. Wow, yeah, but.

Speaker 2 (11:57):
So fifty K. It's not about perform months.

Speaker 3 (12:01):
Yeah. So yeah, in that case, it's not gonna make
a difference. And we don't proclaim that it would. It's
we don't proclaim that preact, you know, adding swapping out
react and switch preacts can change anything on its own. However,
it does vastly reduce the floor I know, Alex Russell

(12:23):
of previous Chrome pain and now he works on Blink,
comes out.

Speaker 2 (12:27):
With a guest on this podcast several times.

Speaker 3 (12:30):
Yeah, he comes out every couple of years with a
job script budget to kind of talk about what should
be our height of job script for the current low
end devices and you know users and fifty KB in
terms of those budgets, which I think are about said
about three hundred K these days, three hundred KB. Fifty
k is quite a bit, as you know, one six

(12:51):
year total budget that could be reduced if you did
switch to Preact, and that could be you know, fifty
k on every page. Combined with some other opportunities. It
adds some extra room to add UX features or d
X stuff.

Speaker 2 (13:08):
Oh for sure. And like you also said, it's in
very interesting use cases the widget scenario where you want
to add something to a page that already potentially has
some framework on it and you don't want to overload
that page even more exactly.

Speaker 3 (13:25):
Yeah, that's quite usedful.

Speaker 2 (13:29):
Now you did mention that in terms of the way
that the core Preact works, you're still focused on class
components rather than hooks. Are most people using Preact with
as far as you know, with classes or with hooks,
because with React itself it's hooks all the way these days.

Speaker 3 (13:54):
Yeah, so I think hooks are definitely more popular, and
I should mention signals. It's another kind of state primitive
re add on top a couple of years ago. You
can use those with function components or class components. They're
kind of their own separate thing. But while hooks are popular,
they are just an optional add on and Preact so
you can use hooks if you want them, if you

(14:16):
don't want them, they're going to cost nothing to your bundle.
They are in a subpath, so you can say, hey,
I just want the lightest toolkit that can use, so
you just use the core Preact library and just use
class components go which you need done. And that's kind
of the interesting way that Preact to structured. We have
a plugable renderer with a public API, so people can

(14:39):
come and add existing like add ons and state primitives
tying into the render cycle if they want, and they
can use the exact same tools that we use to
build out our add ons, like compat, hooks, signals. More recently,
all that stuff, it's all public API.

Speaker 2 (14:58):
Now. Looking at the directions in which React is moving,
and I'm kind of interested in contrasting some of them
with Preact, especially since, for our conversation before you're about
to release a new version of PREACTI pretty soon. One
of the core things about React for several years now,
and I think you mentioned it, is the whole fiber

(15:20):
thing and the concurrent stuff and the suspense and stuff
like that. Do you have anything like suspense built into Preact.

Speaker 3 (15:31):
Yeah, Suspense has been part Preact for years now. It
is essentially in the same state. That is and React
more or less. You can use it for all sorts
of things like lazy loading, data hatching, asynchronous actions, whatnot.
That's all there. We, however, are less interested in following

(15:51):
React into things like concurrent mode and current features. Their
implementation is server components.

Speaker 2 (16:01):
Yeah, we'll get to that. Let's let's put that to
the side, because I will want to go there. But
just to clarify to our to our listeners who may
or may not know, suspense is basically about making the
rendering of certain certain things, certain components a synchronous to
the rest of the page, and they can have a

(16:22):
loading state while they're getting retrieving the data and they
are not They don't block the rest of the page,
and when they get the data, they can then update
themselves with the data. I like to say that the
way that you can identify modern web applications is that
instead of one big spinner, we now have lots of

(16:43):
little spinners.

Speaker 3 (16:44):
Yeah.

Speaker 1 (16:46):
Yeah, that was actually what I've talked about this before
on Views on View and might have been here. But
View three added that feature, so it's native. It's just
super easy now to say, okay, while it's loading, shows this,
and then once it's loaded, then show the data. Where
before it was like said a loading variable. Okay, so
it's loading, so show this gift. And now it's loaded,

(17:08):
so you can unset that variable and show the data.
And so it was a very very nice convenience feature
added of View three.

Speaker 3 (17:14):
Yeah, and reacts and preact. There are certainly more performance
considerations with it, especially just the way it works as
promises are essentially thrown up through the component tree. We
don't necessarily love it as a primitive. It certainly has
some bad performance footguns, but it is something that's been

(17:37):
the framework for years and you can make use of
it intelligently.

Speaker 2 (17:42):
So what do you kind of recommend it potentially instead.

Speaker 3 (17:46):
Generally extracting all sorts of day of hatching out of
the render tree entirely. This is something that Jason has
talked about a bit on I think like the his
VT talk of last year, so twenty twenty four. It's
something that the remix guys have been talking about for
a while in that if you put your data fetching

(18:07):
at the component level, you're only going to trigger those
requests as or once the page loads, and that creates
waterfalls and all sorts of delays that could otherwise be
avoided by hoisting. So you take all those data fetches,
you create either you know, like a page level loader
or just manual hoisting with things like you know fetch

(18:30):
or graph qul is great for this, and you track
that completely outside the render tree and have it live
outside entirely. So you load the main bundle, you fire
off all those patches, and once you get that data,
then you start rendering.

Speaker 2 (18:47):
And then how do you propagate the data into the components?
So put it in an alternative way, what state management solutions
do people usually use on the client side with preact
in order to propagate this data into the components.

Speaker 3 (19:03):
The contact API is great contact API has been there
forever and you can you know, initialize your app just
pass data into the root you know. App component signals
in more recent years have been great for that too.
So signals are a reactivity primitive that we added in
September of twenty twenty two, So you can very very

(19:26):
easily have state that exists outside of your tree. It's reactive,
you can change it however you want. And there's also
tie into the component life cycle, so when that data changes,
you know, components will update themselves or update text content, whatever,
so they can tie into that global store idea.

Speaker 2 (19:47):
So we had Joe Savona and Sati on the show
a while back and one of the things that came
up in the conversation worse signals, and Joe was pretty
frank on the point that React is not going to
support signals. It's not part of their vision. Or actually
put it more accurately said, if signals becomes a core

(20:09):
feature of JavaScript itself, then they will support the JavaScript signals,
but otherwise they don't plan to integrate signals into React.
I know that, like you mentioned, Preact has had signals
for a while. Now do basically do signal our signals
in Preact used to trigger the re render of a component.

Speaker 3 (20:31):
So yes and no. So signals have a very deep
integration with React. We do actually with Preact, excuse me,
we do also have a React integration. So if users wanted,
we do have a signals integration that they can use.
But for Preact there's kindy modes where you can use

(20:52):
a signal within your JSX as a direct text binding
or a atropute binding, and that if that signal updates,
it will change only say like a text value within
the JSX. It will not re render the entire component.
It does it at the granular, very specific level.

Speaker 2 (21:10):
So what is known as fine grain reactivity.

Speaker 3 (21:13):
Yes, exactly, you can if you want to reference the signal,
unwrap it within the actual component function and that will
subscribe the component essentially to the signal and will rerender it.
You don't need to do that, You don't necessarily need
to use the fine grain reactivity. Our signals implementation isn't

(21:36):
necessarily focused on fine grain reactivity, as other tools like
solid kind of folks on I think speltz runes are similar.
Our signals are meant to complement VDOM and provide a
more performance solution to those cases where you do want
fine grained reactivity when that could be valuable, But you're
not throwing out the baby with the bathwater. You still

(21:58):
do have the component model, you still have free renders.
That's still a kind of primitive and solid building boket
build on.

Speaker 2 (22:07):
So basically you're saying that in terms of context, when
I need to propagate updates throughout the componentry, I would
either use something like context or signals as the means
of getting the data from whatever state management solution I
choose to use to the components themselves. Yeah.

Speaker 3 (22:30):
Yeah, those are the kind of favorite ways these days.
And signals along those signs are interesting because you could
just directly import the signal. You don't need, you know,
like a use contextfook or anything. You can just have
a bear signal in a module important in that signal
and use it in your component and it's reactivity.

Speaker 2 (22:51):
Very good. By the way, do you have anything similar
to ten stack query what used to be React Query?

Speaker 3 (23:00):
No, we don't have anything built in. I think it
works fine with our compatibility layer. So, as we kind
of mentioned earlier, users can add tansac query to their app.
They set up the Preact aliases, so that just swaps
out references of React with Preact compat in their bill
tool of choice and it should just work.

Speaker 2 (23:23):
Now. In recent years, a React has been really focused,
it seems, on transitioning from being a view library into
becoming a full stack framework. Some might say that nextjs
is kind of the future of of React in a

(23:45):
lot of ways, and a lot of and some of
the React core team members have indeed moved to Versailles,
and the vision includes stuff like React server components like
servers in a lot of ways, Next jays is back
and first everything first runs on the back end. Then

(24:06):
you actually need to explicitly specify that from beyond this
point things will start executing on the client side. I
gather that that's not the direction that you're going down
with pre Act now.

Speaker 3 (24:23):
A lot of the React a lot of the ideas
that the React team as present over the years are interesting.
Server components as an idea are interesting, but we're definitely
not looking to follow them down that path in any way.
I guess a big thing for us is a lot
of our users don't use Preact in a way where

(24:45):
they want a framework. They want to be able to
just grab it added into their existing stack, their existing solutions.
So that sort of framework and prescribed, you know, a
way to build apps just wouldn't fly even if we
did offer it, and no one's asking for it, so
we're not going to follow that kind of path.

Speaker 2 (25:07):
Yeah. So about my own experience, about a year ago,
I switched jobs, and because of the type of roles
that I did, I do it was not only me
being interviewed by various companies, but also me kind of
interviewing those various companies, and one of the things that

(25:28):
I was looking at was their technological stack, and the
majority of them were using React, but essentially none of
them the companies that I talked to were using server
components or stuff like that. So it creates it's it's
interesting to me that there seems to be a kind

(25:48):
of a growing gap between how the market is using
React and how and the direction in which the React
core team and versell are actually taking React. And it
seems to me that preact remains much closer to the

(26:09):
way in which most companies are using React than React itself.

Speaker 3 (26:16):
Yeah, and along those lines, that's actually kind of one
of the things we're looking at for our upcoming version eleven.
So we're kind of thinking about our tagline. And I
know when the suggestions was bring your React seventeen eighteen
knowledge and have a good time, because.

Speaker 2 (26:34):
Where's the rip shots? Too late? Too late?

Speaker 1 (26:41):
Sorry, sorry my DJ responsibilities there.

Speaker 3 (26:46):
Yeah, so yeah, we are kind of focusing more on
that experience that classic React has just because that's that's
where we find most the users are. And as you said,
most people that we talk to anyways aren't using React
in that context anyway, So Preact on having it isn't

(27:08):
a problem for them. If anything, they kind of like
that our engineering talent isn't spent on, you know, features
that they can't use or don't want to use. That's
spent on other stuff.

Speaker 2 (27:20):
So before we move over to the new version of
pre Act, one more question that I wanted to ask, though,
there are people who do want or like using view
library in the context of a full stack framework, and
if those people look at pre Act, what do you

(27:43):
guys kind of recommend as the full stack framework of
choice in this scenario.

Speaker 3 (27:50):
Sure, so, Astro has been great and very much aligns
with our vision of trying to minimize jobscript on the
web and really utilizing them primitives. Astro is great and
definitely something can recommend. Dino's Fresh is also something along
the same lines similar to Astro, and that's focused on

(28:10):
islands of interactivity and kind of the minimal.

Speaker 2 (28:13):
Job of them are I think, yeah, yeah.

Speaker 3 (28:16):
They both are.

Speaker 2 (28:18):
Dino is er.

Speaker 3 (28:19):
Dina's Fresh as recently coming or is coming up with
a version two in the near future, and that is
also aimed at providing more extensible kind of back end
features alongside the existing front end stuff, So that would
be a great option.

Speaker 2 (28:34):
Too, And soon we may have remixed version three yep,
something which if people have not heard, they've stated that
they're building it on a fork of pre Act. I
don't know why they feel the need to fork it.

Speaker 3 (28:50):
As they mentioned, they said something along the lines of
they want to own the entire experience, they want to
build component libraries, Preact all the stuff, they want to
own it completely. So along those lines, I guess fork
makes sense. We'll have to see what they actually remove
or change, or we don't know yet. I'm not sure

(29:11):
they know yet.

Speaker 2 (29:13):
Yeah. Probably. It seems to me that, like you indicated,
that it's more about ownership and control than necessarily making
any specific change, at least at this point in time.

Speaker 3 (29:25):
Yeah, that's what I've mentioned publicly. At least we'll have
to sway and see.

Speaker 2 (29:30):
Okay. Then then talking about the upcoming version of Preact,
when is it coming out and what are we going
to get with it?

Speaker 3 (29:39):
Sure, so I guess we'll backstory first. We are currently
on Preact version ten, and version ten released actually back
in October of twenty nineteen. It is a very very
long lasting major for view libraries in the space.

Speaker 2 (29:57):
And to be fair, React, I think the previous version
came out in twenty eighteen, and the recent version came
out recently.

Speaker 3 (30:07):
React nineteen came out December eighteen, a couple of years
before that. It's definitely not that far back or near
that far back. I think React sixteen came out in
twenty seventeen.

Speaker 2 (30:22):
No, what I'm saying is that around twenty eighteen React
kind of got stuck as well. That's what I'm saying
that They also had a I think, as I recall,
a lengthy period of time between releases.

Speaker 3 (30:34):
Yeah, I know, between some of their major releases, they
didn't have many breaking changes. So how you count majors
is a little bit up the air. But yeah, so
Preact ten came out in twenty nineteen and we've been
pretty happy with it since. We had some initial talks
about V eleven I think started in twenty twenty one

(30:57):
for some breaking changes that we wanted, so we end
up ending up like being able to land most of
our changes into Preact to absolute wizard degree by people
other than myself, Yov Marvin Andre Yoakim bet So we've
been able to kind of keep Preact stable for so

(31:19):
long without any sorts of breaking changes, which we've been very,
very happy with. However, over the years, a number of
breaking changes do kind of come up that you you know,
put off and you have in your head forever, and
that is going to culminate in V eleven, hopefully with
the next couple of months. We plan to have an
alpha out I think about the end of the month,

(31:42):
so we'll see where it ends up. But this is
going to be not huge set breaking changes. We're going
to keep it pretty minimal so that everything can be
migrated over pretty easily. The biggest thing, at least for me,
is we're finally dropping I E eleven compatibility. So yep,

(32:02):
back in twenty nineteen, that was unfortunately still a.

Speaker 2 (32:09):
Back Actually, I kind of shocked that we were even
mentioning Internet Explore.

Speaker 3 (32:14):
Yeah, yeah, same here in twenty nineteen. Unfortunately, that was
a bit more of a sticking point. Some people still
needed it for e commerce and stuff, as much as
I hate that, And every now and then we'd get
people coming into the library to say, hey, this doesn't
work with I eleven, or hey you need to use
this older method, and every single time we're like, uh,

(32:35):
do I really want to look.

Speaker 1 (32:36):
At that pr?

Speaker 3 (32:36):
Do I really want to look at that issue? Yeah,
it's been something that unfortunately has been there forever, and
yeah it is open source stewards. We don't want to
break people's library, so we have to keep that compatibility
even if we're not necessarily in love with it. So
we're finally killing that off, bumping up to more modern

(32:57):
browsers and browser features, so that's great. We're also just
kind of slimming out a lot of the core library,
so the core libraries can drop down size at least
a few on bytes, so I think it drops down
to about four point four kb these days. Our react
combat ability is going to get better. There's a couple

(33:17):
of breaking changes that were in that that we couldn't
quite land in version X unfortunately, so will be improven
compat bit and generally just kind of cleaning up internally
dropping out some weight. So for normal users there shouldn't
be too much differences in the way that she used library.
There shouldn't be too many breaking changes. A couple like

(33:39):
type switched here and there, and we're dropping a couple
kind of very very fringe features, but in general there
should be no problems For most users. There's could be
no migration times upgrade the.

Speaker 2 (33:52):
Versions, so no big philosophical changes like we get in
recent React.

Speaker 3 (33:58):
Versions now, and most we might change up the kind
of version or the messaging that we have around our
tagline and kind of how we relate to React, but
in general it's going to work the exact same way,
the exact same patterns.

Speaker 2 (34:18):
And how about and it's still going to be class
components as the core implementation and hooks as an add on.

Speaker 3 (34:29):
Yep, well that's not something ever in general that's a
zero cost abstraction. It doesn't cause us much to have
hooks on and separate on, so for us, it doesn't
really make sense to inline hooks into the main library,
especially if some people don't use them, so.

Speaker 2 (34:46):
We can keep doing that. Yeah, to be fair, I
do wonder if because hooks first of all, hooks were
you know, for better or worse, Hooks were one of
the more popular changes that came or about with the React.
They really popularized that kind of style of front and programming.

(35:08):
Other frameworks adopted similar patterns as well, and consequently, all
the documentation, all the people who learned React in recent
years went through some boot camp all you know, that's
the method of operation that they learned, or the AI
generated code will likely use it. So I am thinking

(35:33):
that the world is moving in that direction, like it
or not.

Speaker 3 (35:37):
Yeah, I mean that is something we offer. All it
is is a separate import, so you port use states
or use reducer from preact slash hooks. It works the
same way. It's still bundled with the same package. It's
just a subpath export. However, with the Adventus signals that
hooks aren't something you necessarily need to use. We do

(35:58):
offer kind of alternatives in that space that we would
probably start suggesting more heavily in the next coming or
upcoming years, as they generally lead to better experiences. Than
our findings. Hooks look great, but as we've kind of
everyone in the React ecoss experienced the last few years,

(36:22):
they have a lot of problems around d X and
certainly user experience. You know, you have to use a
linter with it. That's the only way the React team
really allows it to be used, as we saw with
kind of the some of the Beat recommendation stuff earlier
this year, in which they wouldn't suggest Beat unless Beat

(36:43):
had slint added to all their templates, because you know,
you have to use linters to help you with React.
You have to use and.

Speaker 2 (36:53):
Stuff like that, and in more racent in circular updates and.

Speaker 3 (36:58):
Yeah, and in or recent times the compiler which also
tries to paper over a lot of the hook's issues,
adding memmoralization and all those extra things on top.

Speaker 2 (37:10):
Which so if I would I would be that blunt.
I can appreciate your your point of view on this,
I'm I'm a bit more lenient towards them. I think
that it's it's interesting that basically we have like two
camps of front end development in view libraries these days.

(37:31):
We have like React with the component based updates and
the vdomin which in the way that they use it
and on one side and basically everybody else with signals
and find grain reactivity more or less on the other side.

(37:51):
And that's kind of and and I think that view
is also kind of signal oriented, correct, Steve.

Speaker 1 (37:59):
Yeah, When I was a buddy of mine, Eric Hanshid
had done some videos on signals, and I remember, as
I'm watching them explaining, I'm like, that sounds a lot
like how ux already works. Really, it was like, I
don't know if they borrowed from View for signals or
I don't know, you know, how everything originated, but but

(38:21):
just in listening to descriptions of signals and how they work,
I'm like, well, that's how I coded the view x
a lot anyway.

Speaker 3 (38:27):
You know, for our signals implementation, v reps were absolutely
a major source of inspiration. We absolutely took some of
the ideas that they used. So it works very similarly.

Speaker 2 (38:38):
And now Angular is dropping our xgs in favor of
signals as well.

Speaker 3 (38:43):
I won't say dropping it signals. Our XCHS does different
focuses than signals. They are they work differently in kind
of target different areas. I think anyone familiar will say.

Speaker 2 (38:59):
That, Yeah, but from what I understood from Angular core
team members that I've been speaking with the direction of
the project in general, they're not, well, you can still
use our xjs, but the direction that they're moving in
is away from our xgs and towards it. Yeah.

Speaker 3 (39:17):
Yeah, defaulting in our xgs is I think where they're
moving away from to my understanding anyways.

Speaker 2 (39:26):
So basically this version is less about, let's say, what
we've been used to with React of here's the big
message from on high, and more about cleaning house and
putting in all the API breaking changes that accumulated over

(39:48):
the past six years and doing it like in one
fell swoop, so in order to minimize the pain of migration.

Speaker 3 (39:56):
Pretty much. Yeah, that's exactly it. It's an opportunity for
us get a lot of those changes that users have
been asking for, but unfortunately we've been unable to provide
for that time. And then the kind of example you said,
we're still in that middle of the continuum from React
with the full component model to signals. We are still

(40:18):
quite happy sitting in the middle, being able to provide
both if we want, and allowing users to use both
at the same time if they want. That's still our
kind of comfort area and what we like to pride
users the opportunity and option to use wherever they feel
fits or needs best at that moment.

Speaker 2 (40:37):
And in recent years, the web platform itself has gotten
some significant enhancements, especially on the CSS side. If we're
looking at things like view transitions and stuff like that,
is that something that you integrate with.

Speaker 3 (40:57):
It's something we've looked at a little bit, unfortunately, not
too much yet. I'd love to look into it, but
I just don't have too much time. So I know
React has recently produced a view transition like component built
into the library that helps facultate that. We don't yet
have anything along those lines. Depending on what you're doing,

(41:18):
I think we can work with vanilla view transitions, but
there are a couple of situations where we would like
to improve support and to provide some better support for
those situations, but don't currently add unfortunately.

Speaker 2 (41:33):
Just to give our audience context, and we actually had
episodes in the past about few transitions. I don't remember
off the top of my head which number. I think
we even had. Normalsenthal who created the spec or actually
took over the spec from Jake Archibald on the show
to talk about it. It's basically a way of transitioning

(41:53):
between pages with using animations that are very similar to
what you might experience with native appations. Like if you
think about I don't know, let's say a Netflix type
experience where you click on some movie and it expands
to cover the entire screen, So instead of just switching
from one view to the next, it kind of animates

(42:14):
from one to the next. And with view transitions, I
think you can now get it for both single page
applications and multipage applications, so it'll be it's getting support
from the framework itself does or the view library itself
does mean a lot in this context. It certainly makes

(42:35):
the experience much more seamless.

Speaker 3 (42:38):
Yeah, and prex casey on that that means switching, having
the user signify that a component switch of conditional rendering
or just swapping on router has to be like synchronous
by design to start start a transition the end transition
that unfortunately just isn't something we support at the moment.

(42:58):
It's something we love to look at. It's definitely an
area that's lacking.

Speaker 2 (43:03):
Another thing, by the way that I think the platform
is supporting or about support is the ability to move
live components from one place in the dormitree to another,
which would be also to view libraries.

Speaker 3 (43:16):
Yeah, that is super exciting. We have a number of
issues open on the preact tracker and have been open
for seven eight years where I frames or videos that
when they're shifted they lose all state.

Speaker 2 (43:31):
Basically while the video starts over.

Speaker 3 (43:33):
Yeah, exactly, because unfortunately, there's just no way to move
stateful elements at this time reliably, especially for a view
library that relies on diffing to figure out where componentcy
and move. There's no algorithm you could possibly use to
be correct one hundred percent of the time. We've tried
all sorts of different solutions that it's unfortunately impossible. So

(43:57):
being able to actually move elements is amazing. It's so exciting.

Speaker 1 (44:02):
So are you bugs? Are you familiar with the teleport
functionality in view three?

Speaker 3 (44:07):
I am not.

Speaker 1 (44:08):
No, you should look it up. That's the whole point
is to be able to, you know, dynamically move content
from one part of the dom to the other.

Speaker 3 (44:18):
That might be similar to like portals or something and
react Land not sure.

Speaker 2 (44:24):
The bottom line though, is that at the end of
the day, we're getting it from the web platform itself,
and ideally solutions should be built on top of that
rather than hack around it. I know that we also
spoke with Carson Gross from HDMX. He was using trying
to use some library that kind of hacked this functionality

(44:46):
and at the end of the day, you just want
platform support for it.

Speaker 3 (44:50):
Yeah, and that example for us, all it is is
I think all we need is a trycatch that we're
going to do the I think it's moved before is
the tomb method, and if that fails, we go back
to you know, inserting before. That is pretty much all
the change that we need and preact which will absolutely
land something like that when we can actually.

Speaker 2 (45:12):
By the way, in order to achieve that amazingly small size,
do you minimize by hand or are you using tooling?

Speaker 3 (45:20):
Yeah, so we do use a lot of tooling to
help do that, you know, tools like Turcerta and one
on a great. We mangle properties to keep a consistent API,
so that means things like render becomes underscore underscore are
diff underscore underscore B. We do a lot of that

(45:41):
kind of work by hand, and we track sizes every
single PR and we have tons of prs on the
preact library that are just reducing the size by four
bytes here, six bytes there.

Speaker 2 (45:53):
Yeah, people don't realize. People don't realize the userland that
even when you minify a lot, a lot of the
text that exists in your JavaScript source code or typescript
source code actually has to state the way that it
is because it's property names, and since properties are looked

(46:17):
up by name, they can't be changed. So you're what
you're saying is that you're kind of creating aliases to
properties in order to reduce the size of common commonly
used properties throughout the code.

Speaker 3 (46:31):
Exactly.

Speaker 2 (46:31):
Yes, we have.

Speaker 3 (46:32):
In the practic code, there's at the basic the repo
there's a mangle dot chase on file which has a
mapping for all those properties. So you map properties like
render or component def that go down to short names.
On top of that, very very.

Speaker 2 (46:49):
Pea request animation frame here's a short one.

Speaker 3 (46:52):
Yeah, not quite that. But in addition to that, very
smart people have looked through and seen, okay, of these
mangled properties, which ones will never exist alongside each other.
So you have four or five different properties essentially all
using the same alias, but they're used in different contexts.
There's never over any colliding that further reduces the bundle

(47:15):
size because you have you know, underscore underscore b that
could be used in three different contexts, which is you know,
fewer bytes with modern jesup and compression. Yeah, there's been
a lot of work that's done into that, and we
have tons of prs of you know, reducing by a
handful of bytes or exploring handful of bytes. Yeah, tons

(47:37):
of time.

Speaker 2 (47:38):
That's kind of I have to say, it's it's technically amazing,
but it seems almost vanity.

Speaker 3 (47:45):
To an extent. Yeah, it is an exercise sometimes, you
know devs do that where you optimize something by two
percent and that feels like a great day. You reduce
bytes by five percent, you know, five bytest.

Speaker 2 (48:01):
It reminds me of that competition of writing games that
fit in one k and see programs that fit in
one line and all sorts of weird things that people
used to do.

Speaker 3 (48:13):
It does add up over time, though, you know all
those efforts you know, ten bytes here, ten bites there,
over a couple of years. You know, that does you know,
increase what we can offer and features that we would
feel uncomfortable with otherwise we can fit in because of
all that work done in other parts of library to
reduce the size, so there's definitely a reward for it.

Speaker 2 (48:38):
Cool. What are you looking at for the future? I mean,
if you're thinking about where you would like this library
to go, what are you thinking about?

Speaker 3 (48:47):
Yeah, so a couple other people have been interested in
frameworks and offering something more along the lines of a
full track framework. We don't really have anything planned there
just yet. It is in the investigation phase, and some
people are quite interested in offering something along those lines.
We are trying to figure out, I guess, in a

(49:09):
large way, the future of the React compatibility. You know,
for the past six seven years we have been defined
by our React compatibility. That's been the major selling point,
that we could just be dropped into existing React apps.
But as React aims more for concurrent features and full
stack framework survey components whatnot, we are starting to kind

(49:33):
of look at, Okay, how do we differentiate ourselves. What
can we offer instead that fulfills the same use cases
or same problems that people are having, but in that
we feel as a subjectively better experience or better fits
our use cases. Anyhow, So we're starting to look at
various options along those lines too. We'll always look at

(49:54):
being smaller and faster, you know, as it comes. But
we're kind of open just seeing where it goes. Right now,
our growth has ballooned like crazy over the past couple
of years, so we're assuming that most users are pretty
happy with the current direction. So we're kind of just
keeping at it, seeing, uh, keeping our own options open,

(50:15):
seeing what users want.

Speaker 2 (50:18):
So I I kind of scaled when we were talking
about integration with frameworks, I kind of neglected this question.
When I use it with either astro or or or
Fresh was the other one. I think. Do I get

(50:38):
SSR service side rendering?

Speaker 3 (50:40):
Yep, yep. That's how they all work.

Speaker 2 (50:44):
They do, And you have the ability to do hydration
on preact code, so hydration capabilities are built into the
preact library.

Speaker 3 (50:55):
Yep, yep, just as it would with reactor view or
anything else. You can have those islands of interactivity where
you have static content with little bits of preact here
in there. You can do full page hydration service side
rendering streaming. That's all built in and available.

Speaker 2 (51:12):
Cool and one of the I'll mention it in my picks,
but I'm actually going to be giving a talk soon
at a conference I gave one and I'm going to
be giving this a variation on the same talk and
another conference about how more and more frameworks are adopting

(51:34):
RPC type approaches for communication in the full stack scenario,
for communication between the front end and the back end.
In the case of preact, do you have anything built
in or would I be using something like TRPC? What
would be the rec or you don't recommend this type
of approach at all?

Speaker 3 (51:55):
Maybe now, we don't have any opinions on that at
the moment. How you do it is kind of outside
the what we consider to be concerns. I think Astro
has something along those lines. I'm not one nine percent sure,
but in general we don't have any opinion on that.
And you can use tools like RPC or any other

(52:18):
implementation that you'd like.

Speaker 2 (52:20):
Cool Steve, anything else you would like to add.

Speaker 1 (52:26):
Or ask, No, I think I'm good for now. Like
I said, not big React users, so not real big
into the world, just where it it interacts with view
or intersects with you.

Speaker 2 (52:38):
Yeah, I would say that if you ever want to
try out something other than View, then I think that
preact might be more aligned with your point of view.
Then react and we do.

Speaker 3 (52:56):
I think I can tease something. We do have something
coming along lines which might be a little bit more
interesting to the folks who are interested in view and
spelt and whatnot.

Speaker 2 (53:05):
Can you elaborate not too much, but.

Speaker 3 (53:09):
We are It's been teased a couple of times by
Jason last month or so. But we have something coming
along lines which might tickle that fancy a little bit better.

Speaker 2 (53:20):
And then we'll need to bring you on again or
somebody else on your team to talk about it if
and when it actually materializes.

Speaker 3 (53:29):
Yeah, it's been something that Jason has been working on
for years and there's a number of public implementations of
it for tweaks. But it'll be interesting.

Speaker 2 (53:39):
Is there anything that you would like to add about
pre arc.

Speaker 3 (53:42):
Ryan, I think we've covered most of the main stuff.

Speaker 2 (53:48):
Okay, I'm also done from my perspective.

Speaker 1 (53:51):
Alrighty, So with that, we'll move on to picks, picture
part of the show where we can talk about anything
we want at least that won't get us censored by
the FC.

Speaker 2 (54:00):
See.

Speaker 1 (54:01):
So, Dan, you want to go first?

Speaker 2 (54:05):
Okay? So I have a couple of picks first and
foremost I'll be speaking at two upcoming conferences. I don't
know if they'll happen before or after this episode actually airs,
but for people listening to the live stream, they will

(54:26):
certainly happen after because they're in the future. The first
one is they are both in Tel Aviv. They're actually
back to back day after day, so and I'll be
speaking at both of them. The first one is called
React Next. It started as a REACT conference but has
kind of evolved or matured into a general front end

(54:49):
development conference, and it's now Israel's largest front end development conference.
They're about over one thousand attendees and this year I'll
be keynoting it. So yeah, so I'm really excited Tory
about that, and that will happen on June twenty fifth.
I think they're actually sold out of tickets, so unfortunately,

(55:13):
even if people listening are interested in going, they can
join the waiting list, but I don't think they can
actually buy tickets at this point in time. And the
day after, in the exact same venue in Tel Aviv
is the no TLV conference, which is as its name implies,
a conference about everything having to do with the node

(55:36):
and the back end usage of JavaScript. And I'll be
speaking at that conference as well, not keynoting it this time.
Our friend Josh Goldberg will be keynoting it, talking about
modern tooling and stuff like that, which will should be

(55:57):
really interesting. And I'll be speaking about out in that conference.
I'll be speaking about using heap dumps in order to
analyze performance issues and memory leaks and stuff like that,
which should be fun as well. So it will be
interesting to talk back, you know, back to back in
two conferences. That one might actually still have tickets. Let

(56:21):
me check. Yeah, you can buy the last minute tickets
a bit more expensive, but you know, wait for the
last minute, then that's what you get. But if somebody
wants to join, apparently they still can, So that would
be my first pick. My other pick was the fact

(56:42):
that I actually recently spoke at a conference. I spoke
at the JS Heroes conference in Clues, Romania. It's an
It was a great conference. If you get an opportunity
in the future to attend or speak at that conference,
I highly recommend it. It's a community driven conference and
they do blind selections, so there's no benefit in being

(57:05):
well known or less known as a speaker. You just
need to come up with an interesting topic. The lineup
was amazing, the talks were great, well amazing and also
me ah and the talks were great, and the organization
was a top notch and I can only say great
things about it. They took us to dinners, they hosted

(57:29):
us the speakers in this picnic in the woods, which
was great. It was just a lot of fun. And
the last, my last pick is it As I mentioned
that conference took place in Cluse, Romania, so my last
pick would be Rominia itself because we took the opportunity,
my wife and I to tour Romania a bit both

(57:51):
before and after the conference. So we drove through places
like obviously Bucharest, which is the capital of Romini, but
also Brashov and Sigishwara and Cibiu and Cluge which I mentioned.
And Romania is a lovely country, has a great outdoors

(58:13):
in terms of the Carpathian Mountains, and there are a
lot of castles there, including Dracula's castle known as brand Castle,
and there are other lovely castles there, and you know,
a lot of historical towns and cities and places to visit,
and it's just a lovely place and I recommend visiting

(58:33):
there if you have the opportunity to do so, and
those would be my picks for today.

Speaker 1 (58:39):
All righty, I will go next, and before I get
to the highlight of every episode, at least the ones
that I'm on, there's interesting announcement from Avenue of View
and beat Fame if you don't know. Recently he started
a company called VOYD zero with the goal to sort

(59:02):
of build a unified tool set for build processes and
so on. And one of the things they're doing is
in the original VAT they use roll up. They just
incorporated roll up to do the build process, and they
said that they were going to start building their own
version of that called roll down obviously sort of a

(59:24):
play on that, And as of about a week ago
May twenty ninth, as of this recording, they have a
product called roll Down VAT, which is VAT with the
initial build of their Rust powered rolldown tool. So if
you want to test it out.

Speaker 2 (59:45):
It seems that all modern JavaScript tooling is heading the
way of either Go or Rust. Yes, so yeah, interesting
I have to say about this. As an aside that
I mentioned before that the front end framework world is
kind of divided between React using component level updates and

(01:00:09):
everybody else going with signals. It seems that the in
terms of bundling, you've got next Gs going with their
thing and everybody else going with wheat. So it's it's
surely interesting again this kind of split that we're seeing

(01:00:29):
in the market.

Speaker 1 (01:00:30):
All right, what is next tool that they're using? I've forgotten.

Speaker 2 (01:00:33):
I know they're using a turbo pack.

Speaker 1 (01:00:34):
I think turno pack, right, okay, right, so yeah, yeah,
Beat has certainly taken the world by storm, since it's
at least the frun end development world.

Speaker 2 (01:00:43):
Yeah, everybody else's using it.

Speaker 1 (01:00:45):
It's fast. I love it anyway, So that tools out
if you want to take a look at that and
play with that.

Speaker 2 (01:00:52):
By the way, and everybody else includes most react projects.

Speaker 1 (01:00:59):
Uh okay, so dad jokes of the week. So recently
a friend of mine texted me. He said, what do
you doing now? And I said, probably failing my driving test, right,
I was texting back. I went to my doctor the
other day. I told him the doctor I ever ringing
in my ear and he says, whatever you do, don't

(01:01:19):
answer it.

Speaker 2 (01:01:22):
That reminds me of this guy that goes to the
doctor and says, doctor, when I put my finger on
my shoulder, it hurts, and on my legg it hurts,
and on my stomach it it says, of course, your
finger is broken.

Speaker 1 (01:01:34):
Right exactly. The alternative answer to that is, well, don't
touch him there. And then finally, so some I'm not
a coffee drinker, but my daughter is, so I've observed this,
and they say some people stir their coffee with the
right hand, others use their left hand, but most are
normally just use a teaspoon. So's the dad jokes of

(01:01:57):
the week, Ryan, what do you got for us?

Speaker 2 (01:02:00):
Sure?

Speaker 3 (01:02:02):
So, unfortually, I've been in the nightmare realm that is
source maps for the past couple of weeks. So yeah,
so yeah, So I guess one of my picks is.
Evan Wallace, the creator of yes Belt, has this source
map visualization tool on the web where you can upload
a bundle and a source map and it kind of

(01:02:22):
maps out really nicely color coded, so you can you know,
figure out, you know which function goes switch source map
bit whatnot. That has been an absolute life saver over
the past couple of weeks as I debug some plug
ins that haven't quite set up their source maps correctly,
so everything gets mangled and broken and awful. So Evan
Wallace's tool is.

Speaker 2 (01:02:42):
Brilliant that it's my understanding that we are kind of
slowly moving in the direct Well, i'll backtrack. People don't
necessarily realize that there's no standard for source maps, and
they kind of happened and put my understanding. We're kind
of moving in the direction of finally get think some
sort of standard for official standard for source maps. Yeah.

Speaker 3 (01:03:04):
I mean there has been a spec for years. I'm
not sure how official it was. I know it's becoming,
I guess more official recently. I know there's been I
think some TC thirty nine work on it recently, but
I don't know about this stork kind of background there.

Speaker 2 (01:03:21):
I have to mention this. First of all, we probably
should have an entire show just on source maps at
one point or another. And I recently found something really amusing.
So as I mentioned, both a talk that I gave
and the one that I'm about to give as a
keynote are about RPC and modern frameworks, and I've been

(01:03:44):
speaking with Rich Harris. I've been effectively speaking about RPC
with all the framework creators more or less, and I've
been speaking with Rich Harris about it, and he raised
some security concerns that he has around RPC, and one
of them is that with co located code, when you've
got both front end code and back end code located

(01:04:06):
in the same file, and you're counting on the bundler
to make that separation, so only the client side code
actually gets downloaded down. And he said that that potentially
creates a full sense of security because you might keep
some secrets in the back end code, assuming that it's
fine because it just stays on the back end. But

(01:04:28):
then you get something like source maps with all the
code in its source form download it to the clients.
So if you've done the bad thing of embedding let's
say your AWSK or whatever in your back end code
because it's just on the back end, well guess what
it's now in your source map?

Speaker 1 (01:04:47):
Well wouldn't it. I mean, it isn't the standard to
keep that like an environment variable or something.

Speaker 2 (01:04:51):
Well, you're supposed to keep it somewhere. Yeah, you're not
supposed to keep it in the source code in any event,
But there's still the potential assumption that you know, maybe
it's a propriety algorithm that you don't want to expose
or something like that. And you're keeping it on the
back end. Well, with co located code, it can easily
find its way to the front end. And source maps
are one reason why that might happen.

Speaker 3 (01:05:14):
Yeah, I know that came up a lot when next
Years started doing the server components thing, but I haven't
even thought about that or heard anything about it since.

Speaker 2 (01:05:22):
Ideally, what you would want to do in a scenario
like that is when generating the source maps file. I
think he would want to do something like the type
stripping that you now have its alright, with spaces that
entire backend code something like that. But you know, I
don't think anybody's doing that at this point in time.

Speaker 1 (01:05:45):
Alrighty, So with that we will end this episode of
Joba script Jabber.

Speaker 2 (01:05:50):
When a minute, Oh oh, don't forget you need to
ask Ryan about how people can contact him.

Speaker 1 (01:05:56):
Oh yes, and give him money? That's right, So please
how can people do those things?

Speaker 2 (01:06:03):
Yeah?

Speaker 3 (01:06:04):
So on Twitter x I am at underscore r S
Christian and then at blue Sky I think I'm rs
Christian dot dev and on GitHub i am r S Christian.
So pre consistent chat me scored for pre act we

(01:06:24):
have a slack. I think that's it's linked on our
website and I think most of our read mes. I
think it's just like chat dot slack dot app or
preacts slack app. It's something we have it advertised everywhere.
It should be easy to find if anyone's interested. Yeah,
we have a community there, talked about all sorts of
things help people with various preact and non preact issues

(01:06:46):
that they have on their tooling whatnot. So if you
have any interests, yeah, join us.

Speaker 1 (01:06:52):
There and preact is preactjs dot com.

Speaker 3 (01:06:56):
Yep, yep.

Speaker 1 (01:06:58):
So okay, did I get everything Dan?

Speaker 2 (01:07:01):
Thank you finally did Okay, thanks.

Speaker 1 (01:07:03):
For the help. Alrighty, so that we'll end this episode.
Thank you for listening, and thank you Ran for coming on,
and we will talk to you next time.

Speaker 3 (01:07:12):
Thanks for having me