Speaker 1: Hello, everybody, Welcome to another exciting episode of JavaScript Shabber.
Speaker 1: I am Steve Edwards, the host with the face for
Speaker 1: radio and the voice for being a mime, and if
Speaker 1: you're watching on TV you can see that. And I'm
Speaker 1: here with co panelist mister Dan Shapiro. How you doing, Dan,
Speaker 1: I'm doing great.
Speaker 2: Hi from Tel Aviv. Is it still hot and dry,
Speaker 2: isn't it always? Oh? Yes, yeah, it's good.
Speaker 1: We got really we got up in the nineties, fair
Speaker 1: nine here recently, but it's a little cooler and cloudier today,
Speaker 1: which is always a bummer. But anyway, our special guest
Speaker 1: is mister Ryan Christian. How are you doing, Ryan?
Speaker 3: Doing great?
Speaker 2: Thank you?
Speaker 1: So before we dive into the topic of Preact, once
Speaker 1: you tell people who you are, why you're famous, why
Speaker 1: they should give you money, where they can give you money,
Speaker 1: et cetera.
Speaker 3: Oh man, I wish.
Speaker 2: Well, I'm all the people working on open source super rich. Yeah, yeah,
Speaker 2: I hear.
Speaker 3: The Larry Belle guy has a lambo soul waiting for
Speaker 3: mine to come in, still waiting for one. So my
Speaker 3: name is Ryan Christian. I'm a core maintainer of Preact
Speaker 3: and have been for the past about four and a
Speaker 3: half years now. Preact, for those unware, is a job
Speaker 3: script UI library, and as the name can sort of suggest,
Speaker 3: it is largely API compatible with React and shares a
Speaker 3: lot of similarities with it in terms of how you
Speaker 3: use it and some of the API constructs. I guess
Speaker 3: where we diverge a little bit, just give a little
Speaker 3: bit more information, is we're kind of more focused on size.
Speaker 3: The core library is about four kb these days four
Speaker 3: and a half kb, contrary to our marketing line, which
Speaker 3: will be updated shortly. And we also kind of focus
Speaker 3: on performance a little bit more heavily than React does.
Speaker 3: And that terms React I think comes about across the
Speaker 3: wire about sixty kV these days fifty eight. So there's
Speaker 3: a quite big floor in difference in terms of the
Speaker 3: size of libraries and how they can be used.
Speaker 2: So I have to ask a question about that. I
Speaker 2: know that well. First of all, going back a little
Speaker 2: bit in history, pre Act was created by originally by
Speaker 2: Jesson Miller, and as I recall, he created it because
Speaker 2: his attitude was that in order to properly understand something,
Speaker 2: he needs to effectively rebuild it, and he rebuilt it
Speaker 2: so well that it became very successful and on its own.
Speaker 2: By the way, we were talking about this before we
Speaker 2: started recording people, I don't think people necessarily realize how
Speaker 2: popular pre act actually is in terms of by the
Speaker 2: way you called it a library, why don't you call
Speaker 2: it a framework?
Speaker 3: I guess my view is, I guess the older view
Speaker 3: of a library is something you call in, something you use,
Speaker 3: you manage to put in your existing app, or however
Speaker 3: you want to do it. We generally don't prescribe solutions.
Speaker 3: We don't require you to use it in certain ways.
Speaker 3: It's a have toolkits that you can use however you
Speaker 3: see fit, which from my understanding is for my use
Speaker 3: I suppose is better fit towards the library side of
Speaker 3: the spectrum than framework.
Speaker 2: But yeah, it is nuanced. I use the kind of
Speaker 2: definitions that I used to use was that with and
Speaker 2: I know that a lot of people still use them.
Speaker 2: AJ for example, I know likes to use. This distinction
Speaker 2: is that with the library, your application code calls into
Speaker 2: the library, and with the framework, it's the framework that
Speaker 2: calls into your application code. I've kind of modified the
Speaker 2: way that I look at it. The way that I
Speaker 2: look at it is that frameworks prescribe certain architectures, whereas
Speaker 2: libraries do not. So that's kind of the distinction that
Speaker 2: I make these days. So you would say that Preact
Speaker 2: does not kind of describe a certain architecture.
Speaker 3: No, I mean, we generally leave that up to users.
Speaker 3: They can decide how to do it. We're only concerned
Speaker 3: with components and how you build out your you know,
Speaker 3: veed on library and whatnot or vt on tree.
Speaker 1: Excuse me, so coming coming from the view view standpoint,
Speaker 1: you know, I haven't really developed with reacting and myself,
Speaker 1: so I'm just curious trying to understand how Preact works
Speaker 1: and React. So if I have a pre Act project
Speaker 1: in my package at Jason, do I only have Preact
Speaker 1: and then that depends on the React library or how
Speaker 1: is it that you have this this this much smaller
Speaker 1: version of React. Does it have all the functionality of
Speaker 1: React itself or just a limited set of functionality?
Speaker 3: Sure, so that's a great question. Preact core itself, Preact
Speaker 3: is split into a bunch of sub packages. We have
Speaker 3: the main Preact library that you install, and that comes
Speaker 3: with a core of like I mentioned about four and
Speaker 3: a half kb of content that has mostly focused on
Speaker 3: class components. However, We have add ons which add different
Speaker 3: API constructs, such as Preact slash hooks, so it's installed
Speaker 3: with the Preact library and bundled into the Preact library,
Speaker 3: but hooks you have an optional add on. Compat is
Speaker 3: another thing that we look at. So our compatibility with
Speaker 3: React comes from another subpackage, Preact compat, which is about
Speaker 3: ninety five percent compatible with React. But we diverge in
Speaker 3: some pretty big ways, namely around the event system. React
Speaker 3: uses their own synthetic event system. They do not use
Speaker 3: the vanilla events that you find in the dom. Well
Speaker 3: they still do, yeah, and they'll probably have to do
Speaker 3: so forever because that would be one hell of a
Speaker 3: breaking change at this point. So that is a huge
Speaker 3: ton of huge, massive code, and where a bunch of
Speaker 3: that size comes from. I know a couple of years ago,
Speaker 3: is something like twenty twenty five kb just for the
Speaker 3: event system. They also do a bunch of event delegation
Speaker 3: by default, which again is just more code, as well
Speaker 3: as a lot of their newer concurrent features, so you
Speaker 3: can have like two different trees rendered or in memory
Speaker 3: at one point. We don't do that. We are generally
Speaker 3: more focused on web standards and keeping the kind of
Speaker 3: core library small, so the core is kind of focused,
Speaker 3: but we do have compatibility with React, and that just
Speaker 3: adds that links into existing reacts libraries that you might
Speaker 3: have your package Jason or whatever, and kind of converts
Speaker 3: the React vedam shape and the React constructions some of
Speaker 3: the React ideas into what Preact understands. So if you
Speaker 3: have a Preact project, you're only using Preact, we alias
Speaker 3: out React for Preact compat if that makes sense.
Speaker 1: So then Preact itself is small, but you still got
Speaker 1: some other dependencies.
Speaker 3: Sorry, sort of it. Those dependencies are in prec. I
Speaker 3: mean those dependencies are part of Preact. Our compatibility layer
Speaker 3: is part of Preact.
Speaker 2: Yeah, you can clear because you kind of in you
Speaker 2: alluded to it. And it's important to make this point.
Speaker 2: Preact is not dependent on React in any way, shape
Speaker 2: or form. When you use the project with Preact, it's
Speaker 2: just Preact. It's compatible with React, it's not built on React.
Speaker 3: Yeah, completely separ things.
Speaker 1: So you're basically just taking the most important stuff and
Speaker 1: put it in a separate that has the similar you know, functionality.
Speaker 1: It's almost like you're mimicking it.
Speaker 3: Yeah, yes, form, Yeah exactly. We take the APIs and
Speaker 3: we mimic them and try to recreate them in a
Speaker 3: smaller form that works for our needs. Okay, yeah, that
Speaker 3: React knowledge and still the effective and functional.
Speaker 2: So I've not used pre Act in a while to
Speaker 2: my detriment. So we were talking before about the usage
Speaker 2: were The fact is that Preact is the number one
Speaker 2: framework slash view library out there. It's it's used as
Speaker 2: much as all the other frameworks combined. Just so we
Speaker 2: have a total size, View is about somewhere between forty
Speaker 2: percent and a half. I'm basically the numbers I'm using
Speaker 2: are from the Google Crux, which basically looks at the
Speaker 2: numbers of origins. You can have other measurements like the
Speaker 2: number of NPM downloads and stuff like that. I guess
Speaker 2: they're kind of aligned, but probably a bit different. View
Speaker 2: is like about somewhere between half and forty percent of
Speaker 2: React and pre Act is about thirty percent of React,
Speaker 2: which doesn't leave a whole lot for all the other frameworks. Yeah,
Speaker 2: when you think about it, but it does mean that
Speaker 2: Preact is a third of React, which is the leading
Speaker 2: front and framework, which is a lot. You're used by
Speaker 2: thousands of sites and web application hundreds, well, actually hundreds
Speaker 2: of thousands, I will.
Speaker 3: Yeah, And there's something a little bit more interesting there
Speaker 3: is because preact has this focus on small size, it
Speaker 3: is especially well suited for widgets.
Speaker 2: I know.
Speaker 3: I think a number of major websites use Preact on
Speaker 3: it to the point where Jason quotes a figure Jason Miller,
Speaker 3: who created quotes figure that Preactive be found on about
Speaker 3: six percent of sites these days, or major sites used.
Speaker 3: So this isn't necessarily as the main view library or
Speaker 3: the main driver of all interactivity, but that it can
Speaker 3: be found on a huge portion of the web just
Speaker 3: because it could be used for those kind of small,
Speaker 3: self contained widgets.
Speaker 2: So that kind of brings out a point that I
Speaker 2: was thinking about, because these days, when you consider this
Speaker 2: typical size of a web site or web certainly of
Speaker 2: a web application, they're pretty huge. And they're huge mostly
Speaker 2: because of either user code or because of the whole
Speaker 2: bunch of NPM stuff that people just bundle into their
Speaker 2: web applications, to the extent that the twenty to thirty
Speaker 2: K difference between Preact and React is not necessarily a
Speaker 2: whole lot at the end of the day, or do
Speaker 2: you disagree.
Speaker 3: Well, it's closer to fifty k these days, and sure
Speaker 3: when you start building massive websites, that is indeed going
Speaker 3: to be swallowed up by you know, node modules or
Speaker 3: user code. I was looking at the open ai site
Speaker 3: the other day and I think it downloads something like
Speaker 3: three megs of JavaScript. Fifty kb is not going to
Speaker 3: make a difference there.
Speaker 2: Gesip three megs or yeah.
Speaker 3: Yeah, it has no code splitting whatsoever, so it loads
Speaker 3: absolutely everything. Did you guys not see that? There was
Speaker 3: the article between Sam Altman and Jonie I've that came
Speaker 3: out a couple of weeks ago. It's a static page,
Speaker 3: just has a single you know, BIV text, single video,
Speaker 3: and it loads three megs of jobscript because it's a
Speaker 3: next yess app with no codes playing whatsoever. So it
Speaker 3: loads all of the you know, chat g ept and
Speaker 3: stuff into it. It's bad. Wow, yeah, but.
Speaker 2: So fifty K. It's not about perform months.
Speaker 3: Yeah. So yeah, in that case, it's not gonna make
Speaker 3: a difference. And we don't proclaim that it would. It's
Speaker 3: we don't proclaim that preact, you know, adding swapping out
Speaker 3: react and switch preacts can change anything on its own. However,
Speaker 3: it does vastly reduce the floor I know, Alex Russell
Speaker 3: of previous Chrome pain and now he works on Blink,
Speaker 3: comes out.
Speaker 2: With a guest on this podcast several times.
Speaker 3: Yeah, he comes out every couple of years with a
Speaker 3: job script budget to kind of talk about what should
Speaker 3: be our height of job script for the current low
Speaker 3: end devices and you know users and fifty KB in
Speaker 3: terms of those budgets, which I think are about said
Speaker 3: about three hundred K these days, three hundred KB. Fifty
Speaker 3: k is quite a bit, as you know, one six
Speaker 3: year total budget that could be reduced if you did
Speaker 3: switch to Preact, and that could be you know, fifty
Speaker 3: k on every page. Combined with some other opportunities. It
Speaker 3: adds some extra room to add UX features or d
Speaker 3: X stuff.
Speaker 2: Oh for sure. And like you also said, it's in
Speaker 2: very interesting use cases the widget scenario where you want
Speaker 2: to add something to a page that already potentially has
Speaker 2: some framework on it and you don't want to overload
Speaker 2: that page even more exactly.
Speaker 3: Yeah, that's quite usedful.
Speaker 2: Now you did mention that in terms of the way
Speaker 2: that the core Preact works, you're still focused on class
Speaker 2: components rather than hooks. Are most people using Preact with
Speaker 2: as far as you know, with classes or with hooks,
Speaker 2: because with React itself it's hooks all the way these days.
Speaker 3: Yeah, so I think hooks are definitely more popular, and
Speaker 3: I should mention signals. It's another kind of state primitive
Speaker 3: re add on top a couple of years ago. You
Speaker 3: can use those with function components or class components. They're
Speaker 3: kind of their own separate thing. But while hooks are popular,
Speaker 3: they are just an optional add on and Preact so
Speaker 3: you can use hooks if you want them, if you
Speaker 3: don't want them, they're going to cost nothing to your bundle.
Speaker 3: They are in a subpath, so you can say, hey,
Speaker 3: I just want the lightest toolkit that can use, so
Speaker 3: you just use the core Preact library and just use
Speaker 3: class components go which you need done. And that's kind
Speaker 3: of the interesting way that Preact to structured. We have
Speaker 3: a plugable renderer with a public API, so people can
Speaker 3: come and add existing like add ons and state primitives
Speaker 3: tying into the render cycle if they want, and they
Speaker 3: can use the exact same tools that we use to
Speaker 3: build out our add ons, like compat, hooks, signals. More recently,
Speaker 3: all that stuff, it's all public API.
Speaker 2: Now. Looking at the directions in which React is moving,
Speaker 2: and I'm kind of interested in contrasting some of them
Speaker 2: with Preact, especially since, for our conversation before you're about
Speaker 2: to release a new version of PREACTI pretty soon. One
Speaker 2: of the core things about React for several years now,
Speaker 2: and I think you mentioned it, is the whole fiber
Speaker 2: thing and the concurrent stuff and the suspense and stuff
Speaker 2: like that. Do you have anything like suspense built into Preact.
Speaker 3: Yeah, Suspense has been part Preact for years now. It
Speaker 3: is essentially in the same state. That is and React
Speaker 3: more or less. You can use it for all sorts
Speaker 3: of things like lazy loading, data hatching, asynchronous actions, whatnot.
Speaker 3: That's all there. We, however, are less interested in following
Speaker 3: React into things like concurrent mode and current features. Their
Speaker 3: implementation is server components.
Speaker 2: Yeah, we'll get to that. Let's let's put that to
Speaker 2: the side, because I will want to go there. But
Speaker 2: just to clarify to our to our listeners who may
Speaker 2: or may not know, suspense is basically about making the
Speaker 2: rendering of certain certain things, certain components a synchronous to
Speaker 2: the rest of the page, and they can have a
Speaker 2: loading state while they're getting retrieving the data and they
Speaker 2: are not They don't block the rest of the page,
Speaker 2: and when they get the data, they can then update
Speaker 2: themselves with the data. I like to say that the
Speaker 2: way that you can identify modern web applications is that
Speaker 2: instead of one big spinner, we now have lots of
Speaker 2: little spinners.
Speaker 3: Yeah.
Speaker 1: Yeah, that was actually what I've talked about this before
Speaker 1: on Views on View and might have been here. But
Speaker 1: View three added that feature, so it's native. It's just
Speaker 1: super easy now to say, okay, while it's loading, shows this,
Speaker 1: and then once it's loaded, then show the data. Where
Speaker 1: before it was like said a loading variable. Okay, so
Speaker 1: it's loading, so show this gift. And now it's loaded,
Speaker 1: so you can unset that variable and show the data.
Speaker 1: And so it was a very very nice convenience feature
Speaker 1: added of View three.
Speaker 3: Yeah, and reacts and preact. There are certainly more performance
Speaker 3: considerations with it, especially just the way it works as
Speaker 3: promises are essentially thrown up through the component tree. We
Speaker 3: don't necessarily love it as a primitive. It certainly has
Speaker 3: some bad performance footguns, but it is something that's been
Speaker 3: the framework for years and you can make use of
Speaker 3: it intelligently.
Speaker 2: So what do you kind of recommend it potentially instead.
Speaker 3: Generally extracting all sorts of day of hatching out of
Speaker 3: the render tree entirely. This is something that Jason has
Speaker 3: talked about a bit on I think like the his
Speaker 3: VT talk of last year, so twenty twenty four. It's
Speaker 3: something that the remix guys have been talking about for
Speaker 3: a while in that if you put your data fetching
Speaker 3: at the component level, you're only going to trigger those
Speaker 3: requests as or once the page loads, and that creates
Speaker 3: waterfalls and all sorts of delays that could otherwise be
Speaker 3: avoided by hoisting. So you take all those data fetches,
Speaker 3: you create either you know, like a page level loader
Speaker 3: or just manual hoisting with things like you know fetch
Speaker 3: or graph qul is great for this, and you track
Speaker 3: that completely outside the render tree and have it live
Speaker 3: outside entirely. So you load the main bundle, you fire
Speaker 3: off all those patches, and once you get that data,
Speaker 3: then you start rendering.
Speaker 2: And then how do you propagate the data into the components?
Speaker 2: So put it in an alternative way, what state management solutions
Speaker 2: do people usually use on the client side with preact
Speaker 2: in order to propagate this data into the components.
Speaker 3: The contact API is great contact API has been there
Speaker 3: forever and you can you know, initialize your app just
Speaker 3: pass data into the root you know. App component signals
Speaker 3: in more recent years have been great for that too.
Speaker 3: So signals are a reactivity primitive that we added in
Speaker 3: September of twenty twenty two, So you can very very
Speaker 3: easily have state that exists outside of your tree. It's reactive,
Speaker 3: you can change it however you want. And there's also
Speaker 3: tie into the component life cycle, so when that data changes,
Speaker 3: you know, components will update themselves or update text content, whatever,
Speaker 3: so they can tie into that global store idea.
Speaker 2: So we had Joe Savona and Sati on the show
Speaker 2: a while back and one of the things that came
Speaker 2: up in the conversation worse signals, and Joe was pretty
Speaker 2: frank on the point that React is not going to
Speaker 2: support signals. It's not part of their vision. Or actually
Speaker 2: put it more accurately said, if signals becomes a core
Speaker 2: feature of JavaScript itself, then they will support the JavaScript signals,
Speaker 2: but otherwise they don't plan to integrate signals into React.
Speaker 2: I know that, like you mentioned, Preact has had signals
Speaker 2: for a while. Now do basically do signal our signals
Speaker 2: in Preact used to trigger the re render of a component.
Speaker 3: So yes and no. So signals have a very deep
Speaker 3: integration with React. We do actually with Preact, excuse me,
Speaker 3: we do also have a React integration. So if users wanted,
Speaker 3: we do have a signals integration that they can use.
Speaker 3: But for Preact there's kindy modes where you can use
Speaker 3: a signal within your JSX as a direct text binding
Speaker 3: or a atropute binding, and that if that signal updates,
Speaker 3: it will change only say like a text value within
Speaker 3: the JSX. It will not re render the entire component.
Speaker 3: It does it at the granular, very specific level.
Speaker 2: So what is known as fine grain reactivity.
Speaker 3: Yes, exactly, you can if you want to reference the signal,
Speaker 3: unwrap it within the actual component function and that will
Speaker 3: subscribe the component essentially to the signal and will rerender it.
Speaker 3: You don't need to do that, You don't necessarily need
Speaker 3: to use the fine grain reactivity. Our signals implementation isn't
Speaker 3: necessarily focused on fine grain reactivity, as other tools like
Speaker 3: solid kind of folks on I think speltz runes are similar.
Speaker 3: Our signals are meant to complement VDOM and provide a
Speaker 3: more performance solution to those cases where you do want
Speaker 3: fine grained reactivity when that could be valuable, But you're
Speaker 3: not throwing out the baby with the bathwater. You still
Speaker 3: do have the component model, you still have free renders.
Speaker 3: That's still a kind of primitive and solid building boket
Speaker 3: build on.
Speaker 2: So basically you're saying that in terms of context, when
Speaker 2: I need to propagate updates throughout the componentry, I would
Speaker 2: either use something like context or signals as the means
Speaker 2: of getting the data from whatever state management solution I
Speaker 2: choose to use to the components themselves. Yeah.
Speaker 3: Yeah, those are the kind of favorite ways these days.
Speaker 3: And signals along those signs are interesting because you could
Speaker 3: just directly import the signal. You don't need, you know,
Speaker 3: like a use contextfook or anything. You can just have
Speaker 3: a bear signal in a module important in that signal
Speaker 3: and use it in your component and it's reactivity.
Speaker 2: Very good. By the way, do you have anything similar
Speaker 2: to ten stack query what used to be React Query?
Speaker 3: No, we don't have anything built in. I think it
Speaker 3: works fine with our compatibility layer. So, as we kind
Speaker 3: of mentioned earlier, users can add tansac query to their app.
Speaker 3: They set up the Preact aliases, so that just swaps
Speaker 3: out references of React with Preact compat in their bill
Speaker 3: tool of choice and it should just work.
Speaker 2: Now. In recent years, a React has been really focused,
Speaker 2: it seems, on transitioning from being a view library into
Speaker 2: becoming a full stack framework. Some might say that nextjs
Speaker 2: is kind of the future of of React in a
Speaker 2: lot of ways, and a lot of and some of
Speaker 2: the React core team members have indeed moved to Versailles,
Speaker 2: and the vision includes stuff like React server components like
Speaker 2: servers in a lot of ways, Next jays is back
Speaker 2: and first everything first runs on the back end. Then
Speaker 2: you actually need to explicitly specify that from beyond this
Speaker 2: point things will start executing on the client side. I
Speaker 2: gather that that's not the direction that you're going down
Speaker 2: with pre Act now.
Speaker 3: A lot of the React a lot of the ideas
Speaker 3: that the React team as present over the years are interesting.
Speaker 3: Server components as an idea are interesting, but we're definitely
Speaker 3: not looking to follow them down that path in any way.
Speaker 3: I guess a big thing for us is a lot
Speaker 3: of our users don't use Preact in a way where
Speaker 3: they want a framework. They want to be able to
Speaker 3: just grab it added into their existing stack, their existing solutions.
Speaker 3: So that sort of framework and prescribed, you know, a
Speaker 3: way to build apps just wouldn't fly even if we
Speaker 3: did offer it, and no one's asking for it, so
Speaker 3: we're not going to follow that kind of path.
Speaker 2: Yeah. So about my own experience, about a year ago,
Speaker 2: I switched jobs, and because of the type of roles
Speaker 2: that I did, I do it was not only me
Speaker 2: being interviewed by various companies, but also me kind of
Speaker 2: interviewing those various companies, and one of the things that
Speaker 2: I was looking at was their technological stack, and the
Speaker 2: majority of them were using React, but essentially none of
Speaker 2: them the companies that I talked to were using server
Speaker 2: components or stuff like that. So it creates it's it's
Speaker 2: interesting to me that there seems to be a kind
Speaker 2: of a growing gap between how the market is using
Speaker 2: React and how and the direction in which the React
Speaker 2: core team and versell are actually taking React. And it
Speaker 2: seems to me that preact remains much closer to the
Speaker 2: way in which most companies are using React than React itself.
Speaker 3: Yeah, and along those lines, that's actually kind of one
Speaker 3: of the things we're looking at for our upcoming version eleven.
Speaker 3: So we're kind of thinking about our tagline. And I
Speaker 3: know when the suggestions was bring your React seventeen eighteen
Speaker 3: knowledge and have a good time, because.
Speaker 2: Where's the rip shots? Too late? Too late?
Speaker 1: Sorry, sorry my DJ responsibilities there.
Speaker 3: Yeah, so yeah, we are kind of focusing more on
Speaker 3: that experience that classic React has just because that's that's
Speaker 3: where we find most the users are. And as you said,
Speaker 3: most people that we talk to anyways aren't using React
Speaker 3: in that context anyway, So Preact on having it isn't
Speaker 3: a problem for them. If anything, they kind of like
Speaker 3: that our engineering talent isn't spent on, you know, features
Speaker 3: that they can't use or don't want to use. That's
Speaker 3: spent on other stuff.
Speaker 2: So before we move over to the new version of
Speaker 2: pre Act, one more question that I wanted to ask, though,
Speaker 2: there are people who do want or like using view
Speaker 2: library in the context of a full stack framework, and
Speaker 2: if those people look at pre Act, what do you
Speaker 2: guys kind of recommend as the full stack framework of
Speaker 2: choice in this scenario.
Speaker 3: Sure, so, Astro has been great and very much aligns
Speaker 3: with our vision of trying to minimize jobscript on the
Speaker 3: web and really utilizing them primitives. Astro is great and
Speaker 3: definitely something can recommend. Dino's Fresh is also something along
Speaker 3: the same lines similar to Astro, and that's focused on
Speaker 3: islands of interactivity and kind of the minimal.
Speaker 2: Job of them are I think, yeah, yeah.
Speaker 3: They both are.
Speaker 2: Dino is er.
Speaker 3: Dina's Fresh as recently coming or is coming up with
Speaker 3: a version two in the near future, and that is
Speaker 3: also aimed at providing more extensible kind of back end
Speaker 3: features alongside the existing front end stuff, So that would
Speaker 3: be a great option.
Speaker 2: Too, And soon we may have remixed version three yep,
Speaker 2: something which if people have not heard, they've stated that
Speaker 2: they're building it on a fork of pre Act. I
Speaker 2: don't know why they feel the need to fork it.
Speaker 3: As they mentioned, they said something along the lines of
Speaker 3: they want to own the entire experience, they want to
Speaker 3: build component libraries, Preact all the stuff, they want to
Speaker 3: own it completely. So along those lines, I guess fork
Speaker 3: makes sense. We'll have to see what they actually remove
Speaker 3: or change, or we don't know yet. I'm not sure
Speaker 3: they know yet.
Speaker 2: Yeah. Probably. It seems to me that, like you indicated,
Speaker 2: that it's more about ownership and control than necessarily making
Speaker 2: any specific change, at least at this point in time.
Speaker 3: Yeah, that's what I've mentioned publicly. At least we'll have
Speaker 3: to sway and see.
Speaker 2: Okay. Then then talking about the upcoming version of Preact,
Speaker 2: when is it coming out and what are we going
Speaker 2: to get with it?
Speaker 3: Sure, so I guess we'll backstory first. We are currently
Speaker 3: on Preact version ten, and version ten released actually back
Speaker 3: in October of twenty nineteen. It is a very very
Speaker 3: long lasting major for view libraries in the space.
Speaker 2: And to be fair, React, I think the previous version
Speaker 2: came out in twenty eighteen, and the recent version came
Speaker 2: out recently.
Speaker 3: React nineteen came out December eighteen, a couple of years
Speaker 3: before that. It's definitely not that far back or near
Speaker 3: that far back. I think React sixteen came out in
Speaker 3: twenty seventeen.
Speaker 2: No, what I'm saying is that around twenty eighteen React
Speaker 2: kind of got stuck as well. That's what I'm saying
Speaker 2: that They also had a I think, as I recall,
Speaker 2: a lengthy period of time between releases.
Speaker 3: Yeah, I know, between some of their major releases, they
Speaker 3: didn't have many breaking changes. So how you count majors
Speaker 3: is a little bit up the air. But yeah, so
Speaker 3: Preact ten came out in twenty nineteen and we've been
Speaker 3: pretty happy with it since. We had some initial talks
Speaker 3: about V eleven I think started in twenty twenty one
Speaker 3: for some breaking changes that we wanted, so we end
Speaker 3: up ending up like being able to land most of
Speaker 3: our changes into Preact to absolute wizard degree by people
Speaker 3: other than myself, Yov Marvin Andre Yoakim bet So we've
Speaker 3: been able to kind of keep Preact stable for so
Speaker 3: long without any sorts of breaking changes, which we've been very,
Speaker 3: very happy with. However, over the years, a number of
Speaker 3: breaking changes do kind of come up that you you know,
Speaker 3: put off and you have in your head forever, and
Speaker 3: that is going to culminate in V eleven, hopefully with
Speaker 3: the next couple of months. We plan to have an
Speaker 3: alpha out I think about the end of the month,
Speaker 3: so we'll see where it ends up. But this is
Speaker 3: going to be not huge set breaking changes. We're going
Speaker 3: to keep it pretty minimal so that everything can be
Speaker 3: migrated over pretty easily. The biggest thing, at least for me,
Speaker 3: is we're finally dropping I E eleven compatibility. So yep,
Speaker 3: back in twenty nineteen, that was unfortunately still a.
Speaker 2: Back Actually, I kind of shocked that we were even
Speaker 2: mentioning Internet Explore.
Speaker 3: Yeah, yeah, same here in twenty nineteen. Unfortunately, that was
Speaker 3: a bit more of a sticking point. Some people still
Speaker 3: needed it for e commerce and stuff, as much as
Speaker 3: I hate that, And every now and then we'd get
Speaker 3: people coming into the library to say, hey, this doesn't
Speaker 3: work with I eleven, or hey you need to use
Speaker 3: this older method, and every single time we're like, uh,
Speaker 3: do I really want to look.
Speaker 1: At that pr?
Speaker 3: Do I really want to look at that issue? Yeah,
Speaker 3: it's been something that unfortunately has been there forever, and
Speaker 3: yeah it is open source stewards. We don't want to
Speaker 3: break people's library, so we have to keep that compatibility
Speaker 3: even if we're not necessarily in love with it. So
Speaker 3: we're finally killing that off, bumping up to more modern
Speaker 3: browsers and browser features, so that's great. We're also just
Speaker 3: kind of slimming out a lot of the core library,
Speaker 3: so the core libraries can drop down size at least
Speaker 3: a few on bytes, so I think it drops down
Speaker 3: to about four point four kb these days. Our react
Speaker 3: combat ability is going to get better. There's a couple
Speaker 3: of breaking changes that were in that that we couldn't
Speaker 3: quite land in version X unfortunately, so will be improven
Speaker 3: compat bit and generally just kind of cleaning up internally
Speaker 3: dropping out some weight. So for normal users there shouldn't
Speaker 3: be too much differences in the way that she used library.
Speaker 3: There shouldn't be too many breaking changes. A couple like
Speaker 3: type switched here and there, and we're dropping a couple
Speaker 3: kind of very very fringe features, but in general there
Speaker 3: should be no problems For most users. There's could be
Speaker 3: no migration times upgrade the.
Speaker 2: Versions, so no big philosophical changes like we get in
Speaker 2: recent React.
Speaker 3: Versions now, and most we might change up the kind
Speaker 3: of version or the messaging that we have around our
Speaker 3: tagline and kind of how we relate to React, but
Speaker 3: in general it's going to work the exact same way,
Speaker 3: the exact same patterns.
Speaker 2: And how about and it's still going to be class
Speaker 2: components as the core implementation and hooks as an add on.
Speaker 3: Yep, well that's not something ever in general that's a
Speaker 3: zero cost abstraction. It doesn't cause us much to have
Speaker 3: hooks on and separate on, so for us, it doesn't
Speaker 3: really make sense to inline hooks into the main library,
Speaker 3: especially if some people don't use them, so.
Speaker 2: We can keep doing that. Yeah, to be fair, I
Speaker 2: do wonder if because hooks first of all, hooks were
Speaker 2: you know, for better or worse, Hooks were one of
Speaker 2: the more popular changes that came or about with the React.
Speaker 2: They really popularized that kind of style of front and programming.
Speaker 2: Other frameworks adopted similar patterns as well, and consequently, all
Speaker 2: the documentation, all the people who learned React in recent
Speaker 2: years went through some boot camp all you know, that's
Speaker 2: the method of operation that they learned, or the AI
Speaker 2: generated code will likely use it. So I am thinking
Speaker 2: that the world is moving in that direction, like it
Speaker 2: or not.
Speaker 3: Yeah, I mean that is something we offer. All it
Speaker 3: is is a separate import, so you port use states
Speaker 3: or use reducer from preact slash hooks. It works the
Speaker 3: same way. It's still bundled with the same package. It's
Speaker 3: just a subpath export. However, with the Adventus signals that
Speaker 3: hooks aren't something you necessarily need to use. We do
Speaker 3: offer kind of alternatives in that space that we would
Speaker 3: probably start suggesting more heavily in the next coming or
Speaker 3: upcoming years, as they generally lead to better experiences. Than
Speaker 3: our findings. Hooks look great, but as we've kind of
Speaker 3: everyone in the React ecoss experienced the last few years,
Speaker 3: they have a lot of problems around d X and
Speaker 3: certainly user experience. You know, you have to use a
Speaker 3: linter with it. That's the only way the React team
Speaker 3: really allows it to be used, as we saw with
Speaker 3: kind of the some of the Beat recommendation stuff earlier
Speaker 3: this year, in which they wouldn't suggest Beat unless Beat
Speaker 3: had slint added to all their templates, because you know,
Speaker 3: you have to use linters to help you with React.
Speaker 3: You have to use and.
Speaker 2: Stuff like that, and in more racent in circular updates and.
Speaker 3: Yeah, and in or recent times the compiler which also
Speaker 3: tries to paper over a lot of the hook's issues,
Speaker 3: adding memmoralization and all those extra things on top.
Speaker 2: Which so if I would I would be that blunt.
Speaker 2: I can appreciate your your point of view on this,
Speaker 2: I'm I'm a bit more lenient towards them. I think
Speaker 2: that it's it's interesting that basically we have like two
Speaker 2: camps of front end development in view libraries these days.
Speaker 2: We have like React with the component based updates and
Speaker 2: the vdomin which in the way that they use it
Speaker 2: and on one side and basically everybody else with signals
Speaker 2: and find grain reactivity more or less on the other side.
Speaker 2: And that's kind of and and I think that view
Speaker 2: is also kind of signal oriented, correct, Steve.
Speaker 1: Yeah, When I was a buddy of mine, Eric Hanshid
Speaker 1: had done some videos on signals, and I remember, as
Speaker 1: I'm watching them explaining, I'm like, that sounds a lot
Speaker 1: like how ux already works. Really, it was like, I
Speaker 1: don't know if they borrowed from View for signals or
Speaker 1: I don't know, you know, how everything originated, but but
Speaker 1: just in listening to descriptions of signals and how they work,
Speaker 1: I'm like, well, that's how I coded the view x
Speaker 1: a lot anyway.
Speaker 3: You know, for our signals implementation, v reps were absolutely
Speaker 3: a major source of inspiration. We absolutely took some of
Speaker 3: the ideas that they used. So it works very similarly.
Speaker 2: And now Angular is dropping our xgs in favor of
Speaker 2: signals as well.
Speaker 3: I won't say dropping it signals. Our XCHS does different
Speaker 3: focuses than signals. They are they work differently in kind
Speaker 3: of target different areas. I think anyone familiar will say.
Speaker 2: That, Yeah, but from what I understood from Angular core
Speaker 2: team members that I've been speaking with the direction of
Speaker 2: the project in general, they're not, well, you can still
Speaker 2: use our xjs, but the direction that they're moving in
Speaker 2: is away from our xgs and towards it. Yeah.
Speaker 3: Yeah, defaulting in our xgs is I think where they're
Speaker 3: moving away from to my understanding anyways.
Speaker 2: So basically this version is less about, let's say, what
Speaker 2: we've been used to with React of here's the big
Speaker 2: message from on high, and more about cleaning house and
Speaker 2: putting in all the API breaking changes that accumulated over
Speaker 2: the past six years and doing it like in one
Speaker 2: fell swoop, so in order to minimize the pain of migration.
Speaker 3: Pretty much. Yeah, that's exactly it. It's an opportunity for
Speaker 3: us get a lot of those changes that users have
Speaker 3: been asking for, but unfortunately we've been unable to provide
Speaker 3: for that time. And then the kind of example you said,
Speaker 3: we're still in that middle of the continuum from React
Speaker 3: with the full component model to signals. We are still
Speaker 3: quite happy sitting in the middle, being able to provide
Speaker 3: both if we want, and allowing users to use both
Speaker 3: at the same time if they want. That's still our
Speaker 3: kind of comfort area and what we like to pride
Speaker 3: users the opportunity and option to use wherever they feel
Speaker 3: fits or needs best at that moment.
Speaker 2: And in recent years, the web platform itself has gotten
Speaker 2: some significant enhancements, especially on the CSS side. If we're
Speaker 2: looking at things like view transitions and stuff like that,
Speaker 2: is that something that you integrate with.
Speaker 3: It's something we've looked at a little bit, unfortunately, not
Speaker 3: too much yet. I'd love to look into it, but
Speaker 3: I just don't have too much time. So I know
Speaker 3: React has recently produced a view transition like component built
Speaker 3: into the library that helps facultate that. We don't yet
Speaker 3: have anything along those lines. Depending on what you're doing,
Speaker 3: I think we can work with vanilla view transitions, but
Speaker 3: there are a couple of situations where we would like
Speaker 3: to improve support and to provide some better support for
Speaker 3: those situations, but don't currently add unfortunately.
Speaker 2: Just to give our audience context, and we actually had
Speaker 2: episodes in the past about few transitions. I don't remember
Speaker 2: off the top of my head which number. I think
Speaker 2: we even had. Normalsenthal who created the spec or actually
Speaker 2: took over the spec from Jake Archibald on the show
Speaker 2: to talk about it. It's basically a way of transitioning
Speaker 2: between pages with using animations that are very similar to
Speaker 2: what you might experience with native appations. Like if you
Speaker 2: think about I don't know, let's say a Netflix type
Speaker 2: experience where you click on some movie and it expands
Speaker 2: to cover the entire screen, So instead of just switching
Speaker 2: from one view to the next, it kind of animates
Speaker 2: from one to the next. And with view transitions, I
Speaker 2: think you can now get it for both single page
Speaker 2: applications and multipage applications, so it'll be it's getting support
Speaker 2: from the framework itself does or the view library itself
Speaker 2: does mean a lot in this context. It certainly makes
Speaker 2: the experience much more seamless.
Speaker 3: Yeah, and prex casey on that that means switching, having
Speaker 3: the user signify that a component switch of conditional rendering
Speaker 3: or just swapping on router has to be like synchronous
Speaker 3: by design to start start a transition the end transition
Speaker 3: that unfortunately just isn't something we support at the moment.
Speaker 3: It's something we love to look at. It's definitely an
Speaker 3: area that's lacking.
Speaker 2: Another thing, by the way that I think the platform
Speaker 2: is supporting or about support is the ability to move
Speaker 2: live components from one place in the dormitree to another,
Speaker 2: which would be also to view libraries.
Speaker 3: Yeah, that is super exciting. We have a number of
Speaker 3: issues open on the preact tracker and have been open
Speaker 3: for seven eight years where I frames or videos that
Speaker 3: when they're shifted they lose all state.
Speaker 2: Basically while the video starts over.
Speaker 3: Yeah, exactly, because unfortunately, there's just no way to move
Speaker 3: stateful elements at this time reliably, especially for a view
Speaker 3: library that relies on diffing to figure out where componentcy
Speaker 3: and move. There's no algorithm you could possibly use to
Speaker 3: be correct one hundred percent of the time. We've tried
Speaker 3: all sorts of different solutions that it's unfortunately impossible. So
Speaker 3: being able to actually move elements is amazing. It's so exciting.
Speaker 1: So are you bugs? Are you familiar with the teleport
Speaker 1: functionality in view three?
Speaker 3: I am not.
Speaker 1: No, you should look it up. That's the whole point
Speaker 1: is to be able to, you know, dynamically move content
Speaker 1: from one part of the dom to the other.
Speaker 3: That might be similar to like portals or something and
Speaker 3: react Land not sure.
Speaker 2: The bottom line though, is that at the end of
Speaker 2: the day, we're getting it from the web platform itself,
Speaker 2: and ideally solutions should be built on top of that
Speaker 2: rather than hack around it. I know that we also
Speaker 2: spoke with Carson Gross from HDMX. He was using trying
Speaker 2: to use some library that kind of hacked this functionality
Speaker 2: and at the end of the day, you just want
Speaker 2: platform support for it.
Speaker 3: Yeah, and that example for us, all it is is
Speaker 3: I think all we need is a trycatch that we're
Speaker 3: going to do the I think it's moved before is
Speaker 3: the tomb method, and if that fails, we go back
Speaker 3: to you know, inserting before. That is pretty much all
Speaker 3: the change that we need and preact which will absolutely
Speaker 3: land something like that when we can actually.
Speaker 2: By the way, in order to achieve that amazingly small size,
Speaker 2: do you minimize by hand or are you using tooling?
Speaker 3: Yeah, so we do use a lot of tooling to
Speaker 3: help do that, you know, tools like Turcerta and one
Speaker 3: on a great. We mangle properties to keep a consistent API,
Speaker 3: so that means things like render becomes underscore underscore are
Speaker 3: diff underscore underscore B. We do a lot of that
Speaker 3: kind of work by hand, and we track sizes every
Speaker 3: single PR and we have tons of prs on the
Speaker 3: preact library that are just reducing the size by four
Speaker 3: bytes here, six bytes there.
Speaker 2: Yeah, people don't realize. People don't realize the userland that
Speaker 2: even when you minify a lot, a lot of the
Speaker 2: text that exists in your JavaScript source code or typescript
Speaker 2: source code actually has to state the way that it
Speaker 2: is because it's property names, and since properties are looked
Speaker 2: up by name, they can't be changed. So you're what
Speaker 2: you're saying is that you're kind of creating aliases to
Speaker 2: properties in order to reduce the size of common commonly
Speaker 2: used properties throughout the code.
Speaker 3: Exactly.
Speaker 2: Yes, we have.
Speaker 3: In the practic code, there's at the basic the repo
Speaker 3: there's a mangle dot chase on file which has a
Speaker 3: mapping for all those properties. So you map properties like
Speaker 3: render or component def that go down to short names.
Speaker 3: On top of that, very very.
Speaker 2: Pea request animation frame here's a short one.
Speaker 3: Yeah, not quite that. But in addition to that, very
Speaker 3: smart people have looked through and seen, okay, of these
Speaker 3: mangled properties, which ones will never exist alongside each other.
Speaker 3: So you have four or five different properties essentially all
Speaker 3: using the same alias, but they're used in different contexts.
Speaker 3: There's never over any colliding that further reduces the bundle
Speaker 3: size because you have you know, underscore underscore b that
Speaker 3: could be used in three different contexts, which is you know,
Speaker 3: fewer bytes with modern jesup and compression. Yeah, there's been
Speaker 3: a lot of work that's done into that, and we
Speaker 3: have tons of prs of you know, reducing by a
Speaker 3: handful of bytes or exploring handful of bytes. Yeah, tons
Speaker 3: of time.
Speaker 2: That's kind of I have to say, it's it's technically amazing,
Speaker 2: but it seems almost vanity.
Speaker 3: To an extent. Yeah, it is an exercise sometimes, you
Speaker 3: know devs do that where you optimize something by two
Speaker 3: percent and that feels like a great day. You reduce
Speaker 3: bytes by five percent, you know, five bytest.
Speaker 2: It reminds me of that competition of writing games that
Speaker 2: fit in one k and see programs that fit in
Speaker 2: one line and all sorts of weird things that people
Speaker 2: used to do.
Speaker 3: It does add up over time, though, you know all
Speaker 3: those efforts you know, ten bytes here, ten bites there,
Speaker 3: over a couple of years. You know, that does you know,
Speaker 3: increase what we can offer and features that we would
Speaker 3: feel uncomfortable with otherwise we can fit in because of
Speaker 3: all that work done in other parts of library to
Speaker 3: reduce the size, so there's definitely a reward for it.
Speaker 2: Cool. What are you looking at for the future? I mean,
Speaker 2: if you're thinking about where you would like this library
Speaker 2: to go, what are you thinking about?
Speaker 3: Yeah, so a couple other people have been interested in
Speaker 3: frameworks and offering something more along the lines of a
Speaker 3: full track framework. We don't really have anything planned there
Speaker 3: just yet. It is in the investigation phase, and some
Speaker 3: people are quite interested in offering something along those lines.
Speaker 3: We are trying to figure out, I guess, in a
Speaker 3: large way, the future of the React compatibility. You know,
Speaker 3: for the past six seven years we have been defined
Speaker 3: by our React compatibility. That's been the major selling point,
Speaker 3: that we could just be dropped into existing React apps.
Speaker 3: But as React aims more for concurrent features and full
Speaker 3: stack framework survey components whatnot, we are starting to kind
Speaker 3: of look at, Okay, how do we differentiate ourselves. What
Speaker 3: can we offer instead that fulfills the same use cases
Speaker 3: or same problems that people are having, but in that
Speaker 3: we feel as a subjectively better experience or better fits
Speaker 3: our use cases. Anyhow, So we're starting to look at
Speaker 3: various options along those lines too. We'll always look at
Speaker 3: being smaller and faster, you know, as it comes. But
Speaker 3: we're kind of open just seeing where it goes. Right now,
Speaker 3: our growth has ballooned like crazy over the past couple
Speaker 3: of years, so we're assuming that most users are pretty
Speaker 3: happy with the current direction. So we're kind of just
Speaker 3: keeping at it, seeing, uh, keeping our own options open,
Speaker 3: seeing what users want.
Speaker 2: So I I kind of scaled when we were talking
Speaker 2: about integration with frameworks, I kind of neglected this question.
Speaker 2: When I use it with either astro or or or
Speaker 2: Fresh was the other one. I think. Do I get
Speaker 2: SSR service side rendering?
Speaker 3: Yep, yep. That's how they all work.
Speaker 2: They do, And you have the ability to do hydration
Speaker 2: on preact code, so hydration capabilities are built into the
Speaker 2: preact library.
Speaker 3: Yep, yep, just as it would with reactor view or
Speaker 3: anything else. You can have those islands of interactivity where
Speaker 3: you have static content with little bits of preact here
Speaker 3: in there. You can do full page hydration service side
Speaker 3: rendering streaming. That's all built in and available.
Speaker 2: Cool and one of the I'll mention it in my picks,
Speaker 2: but I'm actually going to be giving a talk soon
Speaker 2: at a conference I gave one and I'm going to
Speaker 2: be giving this a variation on the same talk and
Speaker 2: another conference about how more and more frameworks are adopting
Speaker 2: RPC type approaches for communication in the full stack scenario,
Speaker 2: for communication between the front end and the back end.
Speaker 2: In the case of preact, do you have anything built
Speaker 2: in or would I be using something like TRPC? What
Speaker 2: would be the rec or you don't recommend this type
Speaker 2: of approach at all?
Speaker 3: Maybe now, we don't have any opinions on that at
Speaker 3: the moment. How you do it is kind of outside
Speaker 3: the what we consider to be concerns. I think Astro
Speaker 3: has something along those lines. I'm not one nine percent sure,
Speaker 3: but in general we don't have any opinion on that.
Speaker 3: And you can use tools like RPC or any other
Speaker 3: implementation that you'd like.
Speaker 2: Cool Steve, anything else you would like to add.
Speaker 1: Or ask, No, I think I'm good for now. Like
Speaker 1: I said, not big React users, so not real big
Speaker 1: into the world, just where it it interacts with view
Speaker 1: or intersects with you.
Speaker 2: Yeah, I would say that if you ever want to
Speaker 2: try out something other than View, then I think that
Speaker 2: preact might be more aligned with your point of view.
Speaker 2: Then react and we do.
Speaker 3: I think I can tease something. We do have something
Speaker 3: coming along lines which might be a little bit more
Speaker 3: interesting to the folks who are interested in view and
Speaker 3: spelt and whatnot.
Speaker 2: Can you elaborate not too much, but.
Speaker 3: We are It's been teased a couple of times by
Speaker 3: Jason last month or so. But we have something coming
Speaker 3: along lines which might tickle that fancy a little bit better.
Speaker 2: And then we'll need to bring you on again or
Speaker 2: somebody else on your team to talk about it if
Speaker 2: and when it actually materializes.
Speaker 3: Yeah, it's been something that Jason has been working on
Speaker 3: for years and there's a number of public implementations of
Speaker 3: it for tweaks. But it'll be interesting.
Speaker 2: Is there anything that you would like to add about
Speaker 2: pre arc.
Speaker 3: Ryan, I think we've covered most of the main stuff.
Speaker 2: Okay, I'm also done from my perspective.
Speaker 1: Alrighty, So with that, we'll move on to picks, picture
Speaker 1: part of the show where we can talk about anything
Speaker 1: we want at least that won't get us censored by
Speaker 1: the FC.
Speaker 2: See.
Speaker 1: So, Dan, you want to go first?
Speaker 2: Okay? So I have a couple of picks first and
Speaker 2: foremost I'll be speaking at two upcoming conferences. I don't
Speaker 2: know if they'll happen before or after this episode actually airs,
Speaker 2: but for people listening to the live stream, they will
Speaker 2: certainly happen after because they're in the future. The first
Speaker 2: one is they are both in Tel Aviv. They're actually
Speaker 2: back to back day after day, so and I'll be
Speaker 2: speaking at both of them. The first one is called
Speaker 2: React Next. It started as a REACT conference but has
Speaker 2: kind of evolved or matured into a general front end
Speaker 2: development conference, and it's now Israel's largest front end development conference.
Speaker 2: They're about over one thousand attendees and this year I'll
Speaker 2: be keynoting it. So yeah, so I'm really excited Tory
Speaker 2: about that, and that will happen on June twenty fifth.
Speaker 2: I think they're actually sold out of tickets, so unfortunately,
Speaker 2: even if people listening are interested in going, they can
Speaker 2: join the waiting list, but I don't think they can
Speaker 2: actually buy tickets at this point in time. And the
Speaker 2: day after, in the exact same venue in Tel Aviv
Speaker 2: is the no TLV conference, which is as its name implies,
Speaker 2: a conference about everything having to do with the node
Speaker 2: and the back end usage of JavaScript. And I'll be
Speaker 2: speaking at that conference as well, not keynoting it this time.
Speaker 2: Our friend Josh Goldberg will be keynoting it, talking about
Speaker 2: modern tooling and stuff like that, which will should be
Speaker 2: really interesting. And I'll be speaking about out in that conference.
Speaker 2: I'll be speaking about using heap dumps in order to
Speaker 2: analyze performance issues and memory leaks and stuff like that,
Speaker 2: which should be fun as well. So it will be
Speaker 2: interesting to talk back, you know, back to back in
Speaker 2: two conferences. That one might actually still have tickets. Let
Speaker 2: me check. Yeah, you can buy the last minute tickets
Speaker 2: a bit more expensive, but you know, wait for the
Speaker 2: last minute, then that's what you get. But if somebody
Speaker 2: wants to join, apparently they still can, So that would
Speaker 2: be my first pick. My other pick was the fact
Speaker 2: that I actually recently spoke at a conference. I spoke
Speaker 2: at the JS Heroes conference in Clues, Romania. It's an
Speaker 2: It was a great conference. If you get an opportunity
Speaker 2: in the future to attend or speak at that conference,
Speaker 2: I highly recommend it. It's a community driven conference and
Speaker 2: they do blind selections, so there's no benefit in being
Speaker 2: well known or less known as a speaker. You just
Speaker 2: need to come up with an interesting topic. The lineup
Speaker 2: was amazing, the talks were great, well amazing and also
Speaker 2: me ah and the talks were great, and the organization
Speaker 2: was a top notch and I can only say great
Speaker 2: things about it. They took us to dinners, they hosted
Speaker 2: us the speakers in this picnic in the woods, which
Speaker 2: was great. It was just a lot of fun. And
Speaker 2: the last, my last pick is it As I mentioned
Speaker 2: that conference took place in Cluse, Romania, so my last
Speaker 2: pick would be Rominia itself because we took the opportunity,
Speaker 2: my wife and I to tour Romania a bit both
Speaker 2: before and after the conference. So we drove through places
Speaker 2: like obviously Bucharest, which is the capital of Romini, but
Speaker 2: also Brashov and Sigishwara and Cibiu and Cluge which I mentioned.
Speaker 2: And Romania is a lovely country, has a great outdoors
Speaker 2: in terms of the Carpathian Mountains, and there are a
Speaker 2: lot of castles there, including Dracula's castle known as brand Castle,
Speaker 2: and there are other lovely castles there, and you know,
Speaker 2: a lot of historical towns and cities and places to visit,
Speaker 2: and it's just a lovely place and I recommend visiting
Speaker 2: there if you have the opportunity to do so, and
Speaker 2: those would be my picks for today.
Speaker 1: All righty, I will go next, and before I get
Speaker 1: to the highlight of every episode, at least the ones
Speaker 1: that I'm on, there's interesting announcement from Avenue of View
Speaker 1: and beat Fame if you don't know. Recently he started
Speaker 1: a company called VOYD zero with the goal to sort
Speaker 1: of build a unified tool set for build processes and
Speaker 1: so on. And one of the things they're doing is
Speaker 1: in the original VAT they use roll up. They just
Speaker 1: incorporated roll up to do the build process, and they
Speaker 1: said that they were going to start building their own
Speaker 1: version of that called roll down obviously sort of a
Speaker 1: play on that, And as of about a week ago
Speaker 1: May twenty ninth, as of this recording, they have a
Speaker 1: product called roll Down VAT, which is VAT with the
Speaker 1: initial build of their Rust powered rolldown tool. So if
Speaker 1: you want to test it out.
Speaker 2: It seems that all modern JavaScript tooling is heading the
Speaker 2: way of either Go or Rust. Yes, so yeah, interesting
Speaker 2: I have to say about this. As an aside that
Speaker 2: I mentioned before that the front end framework world is
Speaker 2: kind of divided between React using component level updates and
Speaker 2: everybody else going with signals. It seems that the in
Speaker 2: terms of bundling, you've got next Gs going with their
Speaker 2: thing and everybody else going with wheat. So it's it's
Speaker 2: surely interesting again this kind of split that we're seeing
Speaker 2: in the market.
Speaker 1: All right, what is next tool that they're using? I've forgotten.
Speaker 2: I know they're using a turbo pack.
Speaker 1: I think turno pack, right, okay, right, so yeah, yeah,
Speaker 1: Beat has certainly taken the world by storm, since it's
Speaker 1: at least the frun end development world.
Speaker 2: Yeah, everybody else's using it.
Speaker 1: It's fast. I love it anyway, So that tools out
Speaker 1: if you want to take a look at that and
Speaker 1: play with that.
Speaker 2: By the way, and everybody else includes most react projects.
Speaker 1: Uh okay, so dad jokes of the week. So recently
Speaker 1: a friend of mine texted me. He said, what do
Speaker 1: you doing now? And I said, probably failing my driving test, right,
Speaker 1: I was texting back. I went to my doctor the
Speaker 1: other day. I told him the doctor I ever ringing
Speaker 1: in my ear and he says, whatever you do, don't
Speaker 1: answer it.
Speaker 2: That reminds me of this guy that goes to the
Speaker 2: doctor and says, doctor, when I put my finger on
Speaker 2: my shoulder, it hurts, and on my legg it hurts,
Speaker 2: and on my stomach it it says, of course, your
Speaker 2: finger is broken.
Speaker 1: Right exactly. The alternative answer to that is, well, don't
Speaker 1: touch him there. And then finally, so some I'm not
Speaker 1: a coffee drinker, but my daughter is, so I've observed this,
Speaker 1: and they say some people stir their coffee with the
Speaker 1: right hand, others use their left hand, but most are
Speaker 1: normally just use a teaspoon. So's the dad jokes of
Speaker 1: the week, Ryan, what do you got for us?
Speaker 2: Sure?
Speaker 3: So, unfortually, I've been in the nightmare realm that is
Speaker 3: source maps for the past couple of weeks. So yeah,
Speaker 3: so yeah, So I guess one of my picks is.
Speaker 3: Evan Wallace, the creator of yes Belt, has this source
Speaker 3: map visualization tool on the web where you can upload
Speaker 3: a bundle and a source map and it kind of
Speaker 3: maps out really nicely color coded, so you can you know,
Speaker 3: figure out, you know which function goes switch source map
Speaker 3: bit whatnot. That has been an absolute life saver over
Speaker 3: the past couple of weeks as I debug some plug
Speaker 3: ins that haven't quite set up their source maps correctly,
Speaker 3: so everything gets mangled and broken and awful. So Evan
Speaker 3: Wallace's tool is.
Speaker 2: Brilliant that it's my understanding that we are kind of
Speaker 2: slowly moving in the direct Well, i'll backtrack. People don't
Speaker 2: necessarily realize that there's no standard for source maps, and
Speaker 2: they kind of happened and put my understanding. We're kind
Speaker 2: of moving in the direction of finally get think some
Speaker 2: sort of standard for official standard for source maps. Yeah.
Speaker 3: I mean there has been a spec for years. I'm
Speaker 3: not sure how official it was. I know it's becoming,
Speaker 3: I guess more official recently. I know there's been I
Speaker 3: think some TC thirty nine work on it recently, but
Speaker 3: I don't know about this stork kind of background there.
Speaker 2: I have to mention this. First of all, we probably
Speaker 2: should have an entire show just on source maps at
Speaker 2: one point or another. And I recently found something really amusing.
Speaker 2: So as I mentioned, both a talk that I gave
Speaker 2: and the one that I'm about to give as a
Speaker 2: keynote are about RPC and modern frameworks, and I've been
Speaker 2: speaking with Rich Harris. I've been effectively speaking about RPC
Speaker 2: with all the framework creators more or less, and I've
Speaker 2: been speaking with Rich Harris about it, and he raised
Speaker 2: some security concerns that he has around RPC, and one
Speaker 2: of them is that with co located code, when you've
Speaker 2: got both front end code and back end code located
Speaker 2: in the same file, and you're counting on the bundler
Speaker 2: to make that separation, so only the client side code
Speaker 2: actually gets downloaded down. And he said that that potentially
Speaker 2: creates a full sense of security because you might keep
Speaker 2: some secrets in the back end code, assuming that it's
Speaker 2: fine because it just stays on the back end. But
Speaker 2: then you get something like source maps with all the
Speaker 2: code in its source form download it to the clients.
Speaker 2: So if you've done the bad thing of embedding let's
Speaker 2: say your AWSK or whatever in your back end code
Speaker 2: because it's just on the back end, well guess what
Speaker 2: it's now in your source map?
Speaker 1: Well wouldn't it. I mean, it isn't the standard to
Speaker 1: keep that like an environment variable or something.
Speaker 2: Well, you're supposed to keep it somewhere. Yeah, you're not
Speaker 2: supposed to keep it in the source code in any event,
Speaker 2: But there's still the potential assumption that you know, maybe
Speaker 2: it's a propriety algorithm that you don't want to expose
Speaker 2: or something like that. And you're keeping it on the
Speaker 2: back end. Well, with co located code, it can easily
Speaker 2: find its way to the front end. And source maps
Speaker 2: are one reason why that might happen.
Speaker 3: Yeah, I know that came up a lot when next
Speaker 3: Years started doing the server components thing, but I haven't
Speaker 3: even thought about that or heard anything about it since.
Speaker 2: Ideally, what you would want to do in a scenario
Speaker 2: like that is when generating the source maps file. I
Speaker 2: think he would want to do something like the type
Speaker 2: stripping that you now have its alright, with spaces that
Speaker 2: entire backend code something like that. But you know, I
Speaker 2: don't think anybody's doing that at this point in time.
Speaker 1: Alrighty, So with that we will end this episode of
Speaker 1: Joba script Jabber.
Speaker 2: When a minute, Oh oh, don't forget you need to
Speaker 2: ask Ryan about how people can contact him.
Speaker 1: Oh yes, and give him money? That's right, So please
Speaker 1: how can people do those things?
Speaker 2: Yeah?
Speaker 3: So on Twitter x I am at underscore r S
Speaker 3: Christian and then at blue Sky I think I'm rs
Speaker 3: Christian dot dev and on GitHub i am r S Christian.
Speaker 3: So pre consistent chat me scored for pre act we
Speaker 3: have a slack. I think that's it's linked on our
Speaker 3: website and I think most of our read mes. I
Speaker 3: think it's just like chat dot slack dot app or
Speaker 3: preacts slack app. It's something we have it advertised everywhere.
Speaker 3: It should be easy to find if anyone's interested. Yeah,
Speaker 3: we have a community there, talked about all sorts of
Speaker 3: things help people with various preact and non preact issues
Speaker 3: that they have on their tooling whatnot. So if you
Speaker 3: have any interests, yeah, join us.
Speaker 1: There and preact is preactjs dot com.
Speaker 3: Yep, yep.
Speaker 1: So okay, did I get everything Dan?
Speaker 2: Thank you finally did Okay, thanks.
Speaker 1: For the help. Alrighty, so that we'll end this episode.
Speaker 1: Thank you for listening, and thank you Ran for coming on,
Speaker 1: and we will talk to you next time.
Speaker 3: Thanks for having me