¶ Intro / Opening
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.
Hi from Tel Aviv. Is it still hot and dry, isn't it always? Oh? Yes, yeah, it's good.
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?
Doing great?
Thank you?
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.
Oh man, I wish.
Well, I'm all the people working on open source super rich. Yeah, yeah, I hear.
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,
¶ Meet Ryan Christian: Preact core maintainer and open-source champion
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 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.
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 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 it a framework?
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 see fit, which from my understanding is for my use I suppose is better fit towards the library side of the spectrum than framework.
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 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 I make these days. So you would say that Preact
¶ What is Preact, and how does it stack up against React?
does not kind of describe a certain architecture.
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.
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 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?
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 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 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 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 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, 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 out React for Preact compat if that makes sense.
So then Preact itself is small, but you still got some other dependencies.
Sorry, sort of it. Those dependencies are in prec. I mean those dependencies are part of Preact. Our compatibility layer is part of Preact.
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.
Yeah, completely separ things.
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.
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.
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 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 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, 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.
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.
I know.
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 be found on a huge portion of the web just
¶ Preact's tiny footprint and why size still matters
because it could be used for those kind of small, self contained widgets.
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 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.
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 make a difference there.
Gesip three megs or yeah.
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 loads all of the you know, chat g ept and stuff into it. It's bad. Wow, yeah, but.
So fifty K. It's not about perform months.
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 of previous Chrome pain and now he works on Blink, comes out.
With a guest on this podcast several times.
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 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.
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.
Yeah, that's quite usedful.
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.
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 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 come and add existing like add ons and state primitives tying into the render cycle if they want, and they
¶ Widgets, adoption, and why Preact powers ~6% of major sites
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.
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 thing and the concurrent stuff and the suspense and stuff like that. Do you have anything like suspense built into Preact.
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 React into things like concurrent mode and current features. Their implementation is server components.
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 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 little spinners.
Yeah.
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, so you can unset that variable and show the data.
And so it was a very very nice convenience feature added of View three.
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 the framework for years and you can make use of it intelligently.
So what do you kind of recommend it potentially instead.
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 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 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.
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.
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 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.
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
¶ Understanding Preact's compatibility layer (PreactCompat)
support signals. It's not part of their vision. Or actually put it more accurately said, if signals becomes a core 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.
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 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.
So what is known as fine grain reactivity.
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 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 do have the component model, you still have free renders. That's still a kind of primitive and solid building boket build on.
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.
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.
Very good. By the way, do you have anything similar to ten stack query what used to be React Query?
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.
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 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 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.
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 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.
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 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
¶ Hooks, signals, and modularity: build what you need, nothing more
components or stuff like that. So it creates it's it's interesting to me that there seems to be a kind 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 way in which most companies are using React than React itself.
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.
Where's the rip shots? Too late? Too late?
Sorry, sorry my DJ responsibilities there.
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 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.
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 guys kind of recommend as the full stack framework of choice in this scenario.
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 islands of interactivity and kind of the minimal.
Job of them are I think, yeah, yeah.
They both are.
Dino is er.
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.
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.
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 they know yet.
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.
Yeah, that's what I've mentioned publicly. At least we'll have to sway and see.
Okay. Then then talking about the upcoming version of Preact, when is it coming out and what are we going to get with it?
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.
And to be fair, React, I think the previous version came out in twenty eighteen, and the recent version came out recently.
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.
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.
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 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
¶ Why Preact won't follow React into full-stack territory
been able to kind of keep Preact stable for so 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, 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, back in twenty nineteen, that was unfortunately still a.
Back Actually, I kind of shocked that we were even mentioning Internet Explore.
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, do I really want to look.
At that pr?
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
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 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 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.
Versions, so no big philosophical changes like we get in recent React.
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.
And how about and it's still going to be class components as the core implementation and hooks as an add on.
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.
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.
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 that the world is moving in that direction, like it or not.
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 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, 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 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.
Stuff like that, and in more racent in circular updates and.
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.
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
¶ Server components, suspense, and what Ryan recommends instead
that it's it's interesting that basically we have like two camps of front end development in view libraries these days. 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. And that's kind of and and I think that view is also kind of signal oriented, correct, Steve.
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 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.
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.
And now Angular is dropping our xgs in favor of signals as well.
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.
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.
Yeah, defaulting in our xgs is I think where they're moving away from to my understanding anyways.
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 the past six years and doing it like in one fell swoop, so in order to minimize the pain of migration.
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 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.
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.
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, 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.
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 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 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 the experience much more seamless.
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. It's something we love to look at. It's definitely an area that's lacking.
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.
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.
Basically while the video starts over.
Yeah, exactly, because unfortunately, there's just no way to move
¶ Frameworks that pair well with Preact: Astro, Fresh, and Remix
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 being able to actually move elements is amazing. It's so exciting.
So are you bugs? Are you familiar with the teleport functionality in view three?
I am not.
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.
That might be similar to like portals or something and react Land not sure.
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 and at the end of the day, you just want platform support for it.
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.
By the way, in order to achieve that amazingly small size, do you minimize by hand or are you using tooling?
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 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.
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 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.
Exactly.
Yes, we have.
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.
Pea request animation frame here's a short one.
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 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 of time.
That's kind of I have to say, it's it's technically amazing, but it seems almost vanity.
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
¶ Sneak peek at Preact v11 and why it sticks with "classic" React experience
bytes by five percent, you know, five bytest.
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.
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.
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?
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 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 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 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, seeing what users want.
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 SSR service side rendering?
Yep, yep. That's how they all work.
They do, And you have the ability to do hydration on preact code, so hydration capabilities are built into the preact library.
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.
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 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?
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 implementation that you'd like.
Cool Steve, anything else you would like to add.
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.
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.
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.
Can you elaborate not too much, but.
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.
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.
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.
Is there anything that you would like to add about pre arc.
Ryan, I think we've covered most of the main stuff.
Okay, I'm also done from my perspective.
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.
See.
So, Dan, you want to go first?
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 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 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, 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 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 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
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 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 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 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 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 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 there if you have the opportunity to do so, and those would be my picks for today.
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 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 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.
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 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 in the market.
All right, what is next tool that they're using? I've forgotten.
I know they're using a turbo pack.
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.
Yeah, everybody else's using it.
It's fast. I love it anyway, So that tools out if you want to take a look at that and play with that.
By the way, and everybody else includes most react projects.
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 answer it.
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.
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 the week, Ryan, what do you got for us?
Sure?
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 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.
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.
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.
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
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 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 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?
Well wouldn't it. I mean, it isn't the standard to keep that like an environment variable or something.
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.
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.
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.
Alrighty, So with that we will end this episode of Joba script Jabber.
When a minute, Oh oh, don't forget you need to ask Ryan about how people can contact him.
Oh yes, and give him money? That's right, So please how can people do those things?
Yeah?
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 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 that they have on their tooling whatnot. So if you have any interests, yeah, join us.
There and preact is preactjs dot com.
Yep, yep.
So okay, did I get everything Dan?
Thank you finally did Okay, thanks.
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.
Thanks for having me