Hey, folks, welcome to another episode of JavaScript Jabber. This week, on our panel we have Steve Edwards. I'm gonna stop in for aj and say yo yo yo, coming out to you from his Sonny in Blue Portland. We also have Dan shapiir Hey from a warm and sunny Tel Aviv. And here we lost Steve right nice Sonny. There it goes Charles Maxwood from top Endevs. A couple of quick things. One, I'm looking for work, so if you want to hire me to help you with podcasting or with
programming, let me know Chuck at topendevs dot com. And then I'm also launching JavaScript Geniuses this week, so go check that out at JavaScript Geniuses dot com. I usually hold that to the end, but I anyway, we have a special guest this week, and that is Rich Harris. Rich, do you want to say hello? Hello from Brooklyn, which is not sunny at all today? It is in fact quite gray out there. Yeah. So you know, I think everybody knows you as the guy behind sveelt I
think that's the big thing. Are there any other things that people ought to know? Uh? Yeah, I ow I was the original creator of roll up. Although I haven't been maintaining it for many years. It was taken over by by Lucas who has been a much better maintainer than I ever was. And it's really since then that it's become this sort of essential piece of the Jilbdscriet ecosystem. Yeah, it's part of FAT, isn't it on top
of it? Although its amazing It just came out that Beat is starting to write their own tool for that based on Rust, so that they can sort of have complete control over that portion of their process. But yeah, until
now it has been part of BEAT. Dan invited you, and I don't know if he had something in particular that he wanted to go to first, or I'll start with a story because I know that's what you like, Chuck, and it's something were Yeah, it's something we spoke about a little bit before the we started recording, which is about the first time that I actually met Rich in person, and that was at a conference called YGLF or you got a lot front end where Rich gave what turned out to be like a
seminal talk. Kind of blew my mind at the time, And the name was Rethinking Reactivity, Right, that's the name, and it was right when you introduce SWELT three, which kind of turned everything on its head in a lot of ways. And now it seems that you're about to do it all over again with the swelled five and ruins, and you know, you tell us, so I thought it would be a great opportunity to kind of speak with you again and listen to what the new hotness is going to be.
Yeah, you could say that we're rethinking, rethinking reactivity. You know, we had a we had a lot of really interesting ideas with felt free. The idea was to see how far you can take a compiler centric framework design and push that in order to have like this really idiomatic way of describing a
reactive user interface, and a lot of it really succeeded. Like people, it turns out, love this style of authoring components, and we've got it to you know, to power some really larger and complex applications, and people have had a great time working on it. People have had a great time building stuff with it. But as the years have gone on, we've started to like butt up against the limits of what you can do with static analysis.
And at the same time, there's been this renaissance of the idea of Signal based reactivity really spearheaded by the SOLID team, taking ideas that were like first being explored in the jovscript world in like around two thousand and nine twenty ten, maybe with Knockout, and bringing that into the modern era. Nowadays, most frameworks are using signals through their reactivity. SPELT was really one of the two odd people out s Felt and React, both doing things very differently
to everyone else, and essentially we decided to fall in line. We decided that it's it. Signals are the right primitive to build a reactive framework on top of, but we have a slightly different relationship with them than other frameworks, and so I guess we can get into what I mean by that over the course of this podcast, but essentially we are rewriting SPELT from the ground
up. It's going to be the same authoring experience that people are familiar with to a very large extent, but it's going to get rid of the rough edges that people have found with the old static analysis based reactivity. And I'm pretty excited about the things that we're able to do now on top of this new foundation. I think a good thing to do just for folks that aren't
as familiar. Can you just give people like a really short explanation of what signals are, and then you can explain what's felt is doing and why you're
changing it. Absolutely. So. The idea of signals is that you have an object that represents some value that is changing over time, and then you have other parts of your code base that read those signals, and then you have a scheduler that is sort of aware of which functions are running and which functions are reading these reactive values, and so when those reactive values change, the scheduler is able to re execute that code to for example, keep a
text mode up to date with some piece of state that has changed in your application. And where signals differ from some other related primitives like observables is they're very effective making sure that your code runs in a efficient and glitch free manner. The code that relies on these reactive values doesn't overfire, It never fires prematurely. Everything just kind of flows in a very natural way down from your reactive state down to what we call the effects, which is the updating in
response to that state changing. And by building on top of signals, we're able to achieve this very surgical approach to updating the page. Instead of having to re render things frequently or having to do a lot of checking to see if things are dirty or not, we can just sort of let the reactive graph do its thing and things naturally at in the optimal fashion. So you mentioned Solid before, and of course the guy who created Solid, Ryan Corneato.
Sometimes people refer to him as the CEO of Signals, and he we had him as a guest several time on the podcast, and he likes to say about the Solid that Solid is effectively a state management framework which happens to update the user interface or the door, that it's almost like a side effect of what it is. Is your approach with the SVELT or swelt five kind of similar or is it more you're just leveraging signals but still very much staying
you know, front and framework. So I think the outcome is essentially the same, but we are approaching it from very different directions. Ryan and I we have almost opposing approach, which is to a lot of a lot of problems. Ryan is really incredible at thinking in terms of primitives and how those primitives fit together, and Solid is just this really elegant example of that we have these primitives that represent these reactive concepts and they tie together in a really
beautiful way. Whereas on the Spelt team, we tend to sort of work backwards from what we want the authoring experience to be like, and so, you know, we have this idea of what it should what should go into a web framework, like what features are involved in creating a user interface, and from there we work backwards to what do we need to implement for that
to work, and they kind of meet in the middle. These two approaches meet in the middle, but we have these slightly different emphasies and it's actually, I think really healthy to have two projects like these in the same sphere because we can sort of bound off each other a little bit and learn from each other a little bit, but also give people multiple options for how they
want to build their applications based on their preferences. I think one interesting way in which we have sort of converged on that idea of it being a state management system with you know, domb manipulation bolted on top is the previously Spelt was a component library essentially kind of bills the same niche as react or view or something like that, but we're Spelt five. We're introducing this idea of
universal reactivity. And so whereas previously you had this sort of magical reactive behavior inside your components, but then as soon as you needed to write code in javascripts, you were sort of left out in the in the boring, old black and white world of normal JavaScript. With Felt five, you can take your reactive constructs and you can bring them into your JavaScript modules and your tuches withrop modules, so that we no longer have this nice, exciting reactive world
inside components and then the world outside. It's all one thing. And we've done that by kind of bringing reactivity into the language itself rather than by exposing these primitives for people to use. So functionally, then if your writings felt it's Felt four versus Felt five, how is it going to feel different? How is it going to look different? So the most obvious example would be it would be how that you how you represent state in a component in s
Felt three and four. Somewhat famously, if you have a variable that needs to update and you want to have your component update in response to that changing, then you would just declare it using let va. So you might have let count equals zero, and then inside a click handler you might do count plus equals one, So you click on a button that invokes that handler, and then wherever count is referenced inside your ten plate, it will update.
And that's still true, but now instead of that just being automatically reactive, you do let count equals dollar, state parentheses zero. And what that is is an instruction to the compiler. We call it a roun that is telling the compiler of this piece of state right here, or this variable count is a reactive piece of state. It's going to be part of the reactive graph that you need to track, and when it updates, everything that depends on
it is also going to need to update. So we've made things a little bit more explicit, and in return, you now have code that is super easy to refactor. It can be moved between components or outsider components, multiple things can reference the same reactive primitives throughout your application, and it really gives you a lot of flexibility and power in how you define the like which parts
of your application are reactive and which parts are not. So when you talk about state, you know, I'm a primary view developer and haven't done a lot of Spelt. I'm thinking of, you know, view X or where you have a separate state you know, I think it's what does it react uses for state management? I forget or yeah, reducts or something like that. Okay, so is this am I understanding that this is as simple as
if you declare a variable with your your ruin inside a component. Is it automatically available in other components without having a separate library like a redux or a view X to manage that or how is that working? Yeah? So you can you just use that inside a dot spelt file, which is where you all feel components. You can put it inside a dot spelt dot JS file or dot spelt dot ts file and then you can just export that and use
it in the context of other components. It's pretty unlikely that you would need a full blown state management library because it's all just kind of built in, and you can pass these things around as component props, and you can you know, pass them into functions and so on, and you know that that idea of state management just kind of falls out naturally from the way that the way that Spelt is designed. It's pretty unlikely that you're going to need to
have a State Management library. On top of that, the one exception that I would maybe consider worthwhile is if you had some complicated logic that you wanted to model as a state machine. Like we don't have a state machine primitive built into the framework, but it's really easy to build those sorts of abstractions on top of the ruins that you get with the framework. So how do
you handle mutability issues then? So you know, it seems to me if you're just you're declaring a state variable in one of your spelt dot whatever files, right, and then you've got it available somewhere else, maybe you mutate it in one place and it messes up something somewhere else Whereas you know, I'm used to the viewx pattern where you have state actions and where you commit
your change. They cant believe on blanking out on it. You can control where the mutability happens, where the actual changes happen, so you're not accidentally you're mutating something somewhere else. And it seems like if you just have a variable okay here, it is not available over here, you could actually mutate it in another place and you're screwing up where you really don't want to mute,
you know, affect your person template. Yeah, so it's up to you how you expose the state that you create other parts of your application. And there's a few ways that that manifests. If you define some state inside a component and you pass it down to another component as a property, then if that component tries to mutate that state, we will actually say, hey, you shouldn't be doing this. And the way that we do that is
we have this concept of ownership validation. So if one component, say component A, owns a piece of state, and it passes it down to component B, component B then tries to mutate it, it will say component B
is trying to mutate some state that it does not own. That state was created in component and if you want component B to be able to mutate it, because actually it's very often quite useful, like if you're building something you want to break it up into multiple components, then it's kind of useful if they can all share ownership of a piece of state. And the way that
we do that in SPELL is with bindings. Instead of just passing a property down to a component, you can pass it down as a binding and that effectively gives the child component read write access to the original piece of state.
So that's sort of like passing something by reference, you know, like a PHP you talk about how you pass something whereas just you can just see it versus you can actually mutate it, you know, in terms of mechanics, no, but in terms of like conceptually, yes, that's exactly what it is. You're literally passing ownership of the same piece of state as opposed to giving someone else a read only view of it. You have to specifically declare
that possibility on both sides. Yeah, So the component needs to say this is something that I want to mutate. This needs to be a bindable property, and then the consuming component needs to actually invoke the binding with the So where you pass in a proper you do bind colon count equals count instead of
just count equals count. So here's the thing about it, and I've encountered it in the context of Solid, where you know, Solid is kind of deceptively similar to React in the way that it looks because it uses gsx and
the syntax looks very, very similar. But then you realize that the concept of components in Solid is much more diluted than it is in React because in React, components are really self contained, and you really need to be explicit about how you pass stuff into them or out of them, whereas in solid you can share signals around or you can put signals totally external to components. And and therefore components just kind of become a unit of code rather than necessarily
a unit of of of rendering or of logic. How how does where it does svelt kind of stand in this regard, if anything, we've taken that idea to its logical conclusion. So some years ago I wrote a blog post called virtual dom is pure overhead. Oh yeah, this is this is about people cry, I'm sure. Yeah, this is about trying to correct some misconceptions that people had about reacts rendering model and whether it was faster than the
real arm or whatever. The details of that aren't so important. It was just that this X is the new overhead became sort of a a theton that I could like to be head with by Ryan who wrote an article called components are pure overhead, And so it's become this this fun little meme. I think there's a quick blog post somewhere called hydration is pure overhead and so on, and what components of pure overhead was arguing was that you know, a lot of frameworks, as you say, have this idea that a lot of
the stuff lives in the component. In reaction, you don't qualifying as you do like React dot create component, and then you pass in the component constructor, and then when that component is rendered, there's all of this book keeping that happens, so that like all of your hooks belong together and you know, so on, whereas in solid it's it's a lot more kind of transparent, Like a component can literally just return the result of calling document dot create
element and that's that's totally legitimate and solid. And that was, you know, a really smart blog post and it's spelt five. I think is probably the purest expression of that idea. Because in spelled vive, components are literally just function calls. If you have you know, angle brackets, capital left,
foo to create a food component in your inside another component. The compiler takes that and it turns it into a function call whose carey is just the foo function and whose first argument is the anchor node that it should be prepended
to, followed by an object of properties. And there is a little bit of book keeping that happens in side components, you know, we push onto a stack so that we can have a context API for example, and for some life cycle purposes, we keep track of when effects are running so that we can control the timing of effects because we think it's very important that things run in a certain predictable fashion. But there's almost no work happening when you
create a component. And it was really Dominic Ganaway who opened my eyes to the power of this when he joined the team and had been working on an experimental framework of his own called Optane, sort of showed that if that's what your components are, if they are literally just function calls, then tooling can take that and it can inline some of those function calls, and it can really be smart about minimizing the overhead that is involved in composing multiple components together.
And so, you know, Ryan was right, and we have absolutely no shame about stealing the best ideas from other frameworks, and that is no exception. So components are really just a method of organizing code rather than having any runtime consequences. What you're saying, if I'm understanding you correctly or hardly any runtime consequence that is, yeah, that is sort of the north star.
There was the talk that you referenced earlier in this podcast, rethinking reactivity, had a slide in which I say frameworks are not a tool for organizing your code, they are a tool for organizing your mind. And I don't think Spelt prior to version five really lived up to that, But now I think we we really are. Like how you offer your components and how that manifests in terms of the code that gets actually executed in the browser, they
don't need to be the same thing. You can you can optimize things by treating them as something other than than how you wrote them, if that makes sense. So, going back to the practicalities, you said that if I want to create a reactive value in spelled five, instead of just doing let counter equals zero, I do let counter equals dollar state zero. First of all, it's interesting that you put dollar at the front rather than at the
end like solid and quick. I actually approve I like dollar in front because I think it makes it clearer you don't need to be dollar key. And then you see a drop down list of all of the ruins that are available to you. Yeah, there's that obviously. Also the fact that just when you read the code. It's up front. You don't need to read the entire word to realize that it's not, you know, just a regular function.
And I'm guessing it even makes parsing simpler because you see dollar upfront, and you know you don't need to like but you know, put it aside. My question is actually different. What happens if I have old Spelt code that just has let counter equals zero. Will my counter stop being reactive? Will I need to do a global search and replace across my entire code base? What happens? This is an excellent question, and I'm very happy that you asked it. The answer is, it will can seem to work.
We have spent a lot of time making sure that Spelt ve is as backwards compatible as it possibly can be. In fact, the first thing that we did when we started working on this code base was we ported over the Spelt for test suite. So as we've been building Spelt five, we've been building it against that existing test suite. So essentially there are two ways that you can write a Spelt component. Now, there's what we internally call legacy mode.
I guess it would be nicer to call it classic mode or something like that so that people don't feel like their code is now technical debt. And then there is Rune's mode, and you can opt into runs mode explicitly by setting a compiler flag. But really the way to do it is just start writing runs. If you have a roune in your component, then the compiler will opt you into runs mode and then you'll get the new style of reactivity.
But if you don't do that, if you have an existing component, or if you're using a library that was built for Spelt free and four, then even though the mechanics under the hood it's still signal based, it's using this modern ultrafast system, the authoring is exactly the same. And it's very important to us that people are able to migrate their applications incrementally upgrade from Swelt
part to five. Everything should in theory keep working, and then as you have time, you know new components will be runs mode, and you can gradually migrate your own components to runs mode to take advantage of some of the new features. But it's a very important question, and I'm very glad that you gave me the opportunity to answer it. This is something that we take very seriously, so I now have a new role for components in Swelt.
There are a unit of versioning of Swelt. Basically, if I'm understanding you correctly, you're saying, if I in my component, I had let x equals one and let y equals two or both of them are reactive. But now if I do let X change just the x, let x equals state a dollar state one and leave the wise it is X is still reactive. But why is no longer react? That's right. You need to migrate the
entire component to runs mode, otherwise things will stop working. We plan to offer some automated migration tools to make that a little bit easier for folks, although at our current stage of development that's not our top priority. But before we have a stable then that will be something that we offer. So who is the fantasy fan that named things ruins? Is that you? Or is that so? I have one of one of these guys? The this is the the meta Quest three and on there there is a game called Ragnarok.
Oh yes, and it is the Drumming one. So the like I'm sure a lot of people are familiar with games like Beat Saber, the rhythm games where you have sort of things flying at you and you need to either bat them away or punch them away, or like simulate playing some sort of musical instrument. The stick of Ragnarok is that you are the drummer on a Viking ship and you need to motivate your rowers to row faster to Valhalla by smashing the ruins as they come past you, and you have these drums in front
of you. It is so I don't play a lot of video games. I don't. I wish I had enough time to, but I don't. I love this game so much. It is incredibly fun and a really good workout. And so one day, you know, we're thinking about what what can we call this concept? What is a good name for something that is it's sort of like it's a magical symbol. You're adding some you're invoking some magic within your code, and it's it's changing the nature of its surroundings.
We want a word that is memorable that a lot of people would associate with with that sort of thing, ideally a single syllable, and that is what we settled on. And the idea very much came from this stupid game where you have to make your Viking rows row faster. Well, funny story. I mean when I think of Elf runs, I think a Lord of the Rings because they're mentioned quite a bit and worn runs or ruins. Yeah, anyway, I thought it was Elf. Anyway, the Elphins have an Elvis
script, right, okay, or runs and Elvis scripts. Sorry I failed in my lot R terminology. But you talk about Ragnarok. A couple of years ago, my company were remote and we had a get together in Arlington and Washington, DC area and for a fun activity, we went to a place that uses the quest metaquest had said it was a whole br experience.
This little is down in a basement and we had a couple hours to play games and I came out of there sweating like a pig and had a killer workout at the first game we played for probably a half hour, was Ragnarok, and so yeah, I was that was just crazy, just trying to keep up. There's like five different levels. You know, when the first
level was you know, pretty straightforward. You get to level five and it's like, you know, drummer for a rock band is just some of the craziest rhythms that you have to try to keep up with, and it has You're on the ship and you're racing with each other, and the faster you
go, the faster your ship goes as compared to the other people. And there are circles coming at you, and you have your you know, your actual it looks like drumsticks in the video game, and you have to hit on the ones with the ex or however they mark them to get the right rhythm. And so the more accurate you are, the better your score is, and the faster your ship goes. But man, it's a workout. It's really a ton of fun too. It's a lot of heavy rock type
music. For sure. I actually have a son who's a professional drummer, so maybe he would probably do well. Yeah, he would do well with that. Me not so much. Does it play on the ocula or the ocular metic quests whatever? Does it play it on the quest too, because that's the one I have? Yeah, it does it does. Going back to spell, this was directly relevant, you know that. Yeah, So we spoke about one room, which is a dollar state. What are the
other routes? So there's the three runs that form the sort of holy trinity of reactivity, which is state derivations and effects state creates the what are sometimes called the sources derived dollar derived is the second run which creates a value that is derived from state. So you know, obvious toy example would be you've got let count equals dollar state zero, let doubled equals dollar derived parentheses count
times two. And it's a little bit different to other frameworks. If they have a computer primitive, then typically you'll pass in a function that returns a value. You can do that with a roune called derived dot buy, but typically you'll just use derived by itself and you pass in an expression and that expression becomes reactive. And we do that to discover as people from writing side effects inside their derivations, which is you know, bad news bears. But
it's like a trap that people will fall into quite often. And it's also just like more concise and nice little look at and uh these derived To be a compiler, it is, it is, it absolutely is. We say this a lot. Every time we're weighing up different designs. We're like, well, what what can we do that everyone else can't because we don't have the same constraints And being a compiler, that's exactly true anymore. I mean,
everybody is becoming a compiler these days. It's it's true, but a lot of a lot of frameworks are using compilers as kind of like an optimization step. But ah, you know, they're religious about not allowing the compiler to change the semantics of the code. Whereas we sort of take this view that changing this romantics of code is it's exactly what frameworks are for. Like,
all frameworks are changing the semantics of code. You know, hooks don't behave like normal functions, like these sort of functions that remember what the value was the last time you call them. That's weird. Angela has these things called zones where like if you do something inside a set time out, like it will track the stuff that happens inside the set time out. That's weird. That's changing the semantics. You a view does a lot of stuff with
property assignments because everything is a proxy. That is also kind of weird. And we just draw the line in a slightly different place. We say it's okay to change the semantics as long as we're doing it in a clearly understandable
way that improves the authoring experience without sacrificing user experience. And so yeah, being a compiler just it gives us this this broader design space, and it gives us a slightly different mentality when when we're figuring out the best solutions to various problems, and so dollar arrived is it is one example, it's just a nicer way of declaring derivations than exists in other reactive systems. And the third one. The third one is the effect room, which basically just defines
a piece of work that happens when some arbitrary dependencies change. A good example would be you have a canvas element and you want to draw something to that canvas. You can't really do that declaratively using using markup, because that's not how canvas works. So that is a case where you would have to use the escape patch of being able to write imperative code inside and effect. Anything that you reference inside the effect, if it's a reactive piece of state,
then when that changes, the effect will rerun. So you know, inside that canvas effect you have canvas dot fill style equals color, and then color is a piece of state that changes, or it's a property that's passed into the component and that changes, then that effect will rerun. But what you don't have to do is explicitly tell the system which things your effect depends on. Because this is the beauty of signal based reactivity. It will just figure
that out for you. That's the whole purpose. So similarly with dollar derived exactly. Yeah, so you basically analyze the code inside that rule, identify which signals it depends on, and then automatically updated execute it whenever any of these signals changes. Yes, so that this all happens when the application is running. And this is a big difference with spelt free and four and steal
three and four. We would actually look at the code that you wrote, and if you had a reactive statement that contained a reference to something, for example, your canvas dot feel style cause color, we would look at the code itself and we would see that that reference to a reactive piece of state, and the compiler would emit code that depended specifically on that piece of state.
But that doesn't scale very well because if you want to take some part of that code and refractor it out into a helper function, then you're sort of out of luck because the compiler can no longer see it. And so the big difference was spelt five is we're relying on the reactive dependency graph to figure that out at run time, and that turns out to be a lot
more scalable, a lot more efficient. Not quite as cool, honestly, like, there's something a little bit fun about using static analysis for this stuff. But it turns out that there are enough cases where that model falls apart the signal based approach is the right one. Interesting. So in a lot of ways, even though you're very much still a compiler base, they're actually
much close to JavaScript than you previously were in certain ways. We are, yes, we are still take in this compiler centric mindset, but I think we're using it in a slightly more responsible way than maybe we did in the past. But yes, we will. I have to say that previously this was one of my hang ups about Sevelt. That I know that you put it in a cevelt file, which really highlights the fact that this is not
just a regular JavaScript file or a typescript file. But in certain ways, I used to say that Sevelt was deceptively like JavaScript in terms of syntax, but very different in terms of semantics, and that that's a problem and at least in my opinion, And I really like the fact that you're able now to kind of to create the extend to eliminate this semantic disconnect that existed before. Yeah, and it means that we don't have to have two separate approaches
to reactivity. Previously, we had let count equals zero inside your component. But then if you wanted to have some piece of reactive state that we shared between components, you couldn't then do that. You had to use something that we called a store. Stores still exist in Spelt five, but they are sort of de emphasized because now you can create reactive state anywhere in your application, and you can share it between components very easily, and so everything is
just a lot more unified than it ever has been before. But it still leads to be inside svelled files. I mean, I can't just use one of them inside of a regular JavaScript file because then the compiler won't see it, require my misunderstanding. Right. So, because we are essentially changing the language, we are adding something to the language, we took the decision to only do that inside dot spelt dot JS and dot spelt dot t S files.
So you still have the entirety of you know, everything that works with job scripts and types with it, like all of the tooling works as you would expect, and these are just normal modules, so you can import things, you can share things between them as you would with any other module. But the spelt language extensions will only apply to those dot sell dot s files.
But it gives you a place to put that shareable logic. So as opposed to previously in the past, a dot svelt file would always be a component file by definition, and now prom my understanding, it could be a utility file containing you know, just ruine declarations or helper functions or stuff like that that just need to undergo the compilation step in order to work with the
rooms exactly. Yeah, that's really cool. I really like that. Yeah, for a while, we considered just doing it for every file in your code base, but we decided that that was a little bit irresponsible. Firstly, it's going to mean that the compiler has to look at a lot more files, and it means that in any case of ambiguity, we're a little bit stuck. But it also means that we're sort of squatting on on this room name space. And if other frameworks were to come along and say,
hey, you know what, that's actually a pretty cool idea. We want to do some version of it ourselves, Well, that would be really difficult. But you know, if in the future, say Preact wants to do some version of this, then you could do dot Preact dot js and they
could have their own runic name space inside their own code. So it's mostly out of kind of being trying to be a good citizen, but also some obviously practical considerations of are you thinking about maybe trying to standardize or even spect the run signature so different implementations might be interoperable. We have not because we're still in this kind of exploratory phase where we're figuring out what needs to be a room and what is potentially just a function that you can import from the
library. And I think it makes sense to start with a working implementation and then see what happens in the wild, see if it makes sense to collaborate with other frameworks on something that is a little bit more standards flavored. It's interesting that at the moment we're having this conversation the day after the signals proposal was made public. So for the last several months a team has been working across framework team has been working on designing a signal primitive that will exist in
the language itself, and that was released yesterday. So it has a concept of there's analogist to our dollar state, and it has a concept that's analogist to hour dollar derived. And then on top of those two things, you can build effects and all of these other things. And the idea is that all of these different frameworks are doing their own signal implementations. Wouldn't it be
great if a there was interoperability between the frameworks. You know, if I had a library that was emitting some sort of signal, then it could be used in all of these frameworks. And b potentially these frameworks could get rid of some of their own runtime code in favor of just using the platform. And so there's these two things. Does the mechanics of signals themselves and having that primitive in the language, and then there's the like how do you reference
them in your code? And what we're focusing on is like this idea that that signals should be essentially a part of the language, not just a primitive that you interact with like any other object. It's a part of the language because reactivity is so fun mental to the task of describing a user interface that it deserves to be a language level concept, and so that those two things,
I think are like separate but parallel conversations that are worth having. So you keep saying, like the language and the platform, right, And I think when I talk to people about Spelt usually they're just kind of referring to
it as a framework. Can you kind of explain the different concepts here, Yeah, it's difficult because Spelt sort of spans a lot of different categories and it's not it's not a traditional UI library, and in the manner of what came before, it is a compiler, but it is also a language. It's a super set of HTML. Compiler takes that language and it compiles it down to JavaScript. That JavaScript imports code from the Spelt runtime library. That's how it it, you know, does it's, it's it's updating, and
it's it's rendering and everything. And then on top of that, we have an application framework called spelt Kit. And the boundaries of all of these things are a little bit fuzzy. When I talk about the language, what I essentially mean is in the same way that you have things in the language like dynamic import looks like a function, but it's not a function. Wouldn't it be great if there was something akin to that that described reactive values and that's
what we're trying to do with runs. Okay, the other question I have is it seems like a lot of this is focused around sort of developer ergonomics and you know, a good developer experience. And I guess you probably won't know completely the answer to this question, but when people are talking about web applications, they're also then talking about performance and you know how well it works in scales and things like that. You know, can I have you know,
fifteen signals or eighty signals or two million signals? You know, how do the ruins play into all of this as far as you know the capabilities of the application, but also you know how it's going to perform if I go and build out some application on it. The performance, honestly is breathtaking. There is a framework that's very widely recognize, the JASS Framework Benchmark, which is a really good sanity check for how well your framework does, and
it fluctuates a little bit as we add and remove things. But spelt is it's basically the fast Felt five is basically the fastest mainstream framework. There's like a couple of other like very small ones that are very very focused on on the sorts of tasks that this benchmark tests for. But you know, SPELL five, it looks like it's probably going to be a little faster than Solid,
which is sort of the gold standard for this thing. Okay, and you know publicism is that sorry go ahead, no, and oh go on, you were saying, part of the reason for that, I'm really interested. Well, again, because we're a compiler, we have luxuries that other frameworks don't. So you know, for example, in Solid, if you create a signal and a function that updates that signal, you're creating a pair
of closures, and closures aren't expensive, but they're also not free. And Spell when you create a source signal, it's just a very simple object. And when you read that signal, and when you write that signal, you're using these get and set functions which are shared by all of these sources. So that's just like one small example of how having the ability to transform your code allows us to use a slightly more efficient way of reading and writing state
without any ergonomic compromises. You know what this kind of reminds me of. I'm old enough to remember compilers for languages like C and C plus plus, and back in the day we are usually for these compilers we had a developer mode and release mode, where in the developer mode it optimized for compilation time, whereas in you know, release mode or production mode, it optimized for execution time, so it would run the compiler much longer, but generate much
more optimized code. And I'm starting to think that that might start being relevant for you know, some of the stuff that you're doing that maybe during development you might you know, be willing to generate less optimal code but just compile as quickly as possible so that the development environment would be nice and friendly.
But then you know, in a release mode you could theoretically like do really significant compilation, maybe even looking across components and stuff like that one hundred percent of the case. So we already do a lot of developer time checks. So earlier I talked about the ownership validation, you know, the mutates state owned by A then spelt will yell at you, well, we actually only do that in development, because in production that's just overhead which no one is
really going to benefit from. And so there are certainly cases where we do the slightly slow but more helpful thing in development mode. But the kinds of things that you're talking about, like cross component analysis is very much where we want to take a lot of these ideas. We actually had some experimentation early on Dominic. It had like a whole trench of work that was looking at this exact thing, but it was difficult to keep up to date with the
rest of the framework when it was all so very much in flux. But that is something that we're at the bit to revisit once Spelt five goes stable. We think there's huge upside here. Yeah. Well, premature optimization is the root of all evil, you know, son he is. So it's interesting though again I kind of mentioned it before, but you know, so obviously you were probably maybe I wouldn't say that you were necessarily the first framework
to use a compiler. I wouldn't be surprised if that's Marco, because Marco is at first that everything turns out. But you were certainly, I think, the first one to really promote it in popularize it. But now it seems like, as I said before, that all frameworks are kind of to a lesser greater degree embracing compilers. Even React with React forget is embracing compilers. So how do you see the different compiler the different approaches in this context,
or all of the frameworks effectively converging on the same place. It's a great question. There's definitely been a lot of convergence just in general in the space over the last few years. And what I think tends to happen is there's there's sort of compression as everyone converged on the same ideas, followed by a period of innovation in which people sort of go off. And you know now that we've centralized on a course set of ideas, like how do we
differentiate ourselves from one another? And I think we're probably entering into that period right now when we start to see, you know what, what our different foundations allow us to do differently, and for us, the kinds of things that we're thinking about are you know, as everyone else is thinking about a server first mentality, like everyone is sort of retreating from client side javascripts in general, we're thinking, well, you know a lot of people still want
to build these richly interactive client side applications, and yes, it's very essential that you have really tight integration with a back end, like, no one's disputing the importance of progressive enhancement and service sign rendering and all of these other things. But at the same time, are we forgetting that there is a place for local first thinking and for you know, on device computation thinking and all of these other things that some frameworks candidly are starting to deprioritize in a
way that worries me a little bit. So no spelled server components in the near future. We do not have a plan right now to make spelt server components. So rsses are obviously this fascinating, brilliant idea, and they've sort of shaken up how everyone thinks about a lot of things. Yet again, because you know, this is what the reacting does, they'll sort of sit quietly three years and then just blow everyone's minds with some new radical innovation.
But to my mind, there are the good parts of reacts server components, and there are the bad parts of React server components. And I think a lot of the proponents of r scs would probably say that the good parts are different, But in my experience, just seeing people struggle with the concept, I would say the good parts of reacts over components are the ability to do asynchronous data loading. You know, the fact that you can have acyn components
and that just sort of works is very cool. But the bad parts are the idea that you have these these two separate things running in two separate environments and the ways that you can combine them the subject to certain constraints, and like the things that you can use in one environment that you can't use in another environment is like super hard for a lot of people who don't do this
day and day out all the time to get their heads around. And so, you know, the kinds of things that we're thinking about are can we have the benefits of this asynchronic state loading approach, Like can we have a weight in components in a way that is really orchestrable and and and and and makes sense from the point of hydration throughout the application life cycle without any of those sort of offering drawbacks and the confusion that arises from having these two worlds
sort of interleaved like that. And you know, we we have some we have some ideas, but a lot of it is unfortunately going to have to wait until after we ship spelt five point oh, because otherwise otherwise we'll never ships spelt five point zero, so no so for speled five point zher no innovations associated with hydration. Uh So, our our approach to hydration is it's
pretty efficient. It's it's certainly faster than it was in spelt for because we have decided that it's acceptable to assume the structure of your application on the client side is the same as it was on the service side, like you're rendering the same components, and so as soon as you have that constraint as part of your model, you can make your hydration a lot faster than if you try to like gracefully repair every piece of slightly mouthformed done that you encounter.
So right out of the gate, hydration is really fast and spelt five. Because we're a compiler, we're able to do things that might be a little bit trickier if you're using say JSX, we can do you know, if you have I don't know, and if browser block and then you have some code in there, and then in the else bit you have some other code. A lot of hydration algorithms will choke on that. They'll be like, hey, we've got a mismatch here. We might need to throw away some
work and start again. Well, Spelt handles that just fine because the compiler can can just drop in a little annotation that the run time then knows how to deal with. So I wouldn't say there are a hug genovations around hydration. But it's fast, and it's reliable, and it's it's flexible, it's robust to things changing between the server render and the client render. Yeah, but you're not trying to avoid let's say, sending down certain code. You're
basically just saying my code is smaller because it's it's generated by compiler. But I'm going to download the code for for components for client for components because they might be re rendered on the client. Yeah, because it's a waste of time. Honestly, there's I know a lot of focus is paid to the cost of hydrating and application, and that is not where the problem is.
That is not why the performance of websites is sometimes not great. I mean, it might be if you have like a really slow framework that is slow to hydrate, but generally speaking, the problems lie elsewhere. And so I know that there are some frameworks whose whole deal is avoiding hydration cost quick but I was going to say, you should talk to me because he tells a little bit different story. Yeah, I mean, of course he does,
because that's like, that's why that framework exists. But you know, every time we profile SPELT sites that we see in the wild, the problems are things like, well, they've disabled SSR, so they have a waterfall and they disabled SSR because of some business requirement, or it's because they've got big images and we didn't do a good enough job of providing them with the tools
to make sure that images are tightly optimized. It's pretty rare. The hydration moves the needle in our experience, and so our position is make it as fast as possible. If there are opportunities to skip hydration in some cases, then take them. And there are some places where we do that in Spelt five, like if we have a big blob of HML from a markdown post or something like that. Just assume that it was the same between Severn client render. But by and large, I don't worry about it. It's not
where the problems lie. You were also, as I recall, one of the first frameworks, if not the first, to introduce the concept of progressive enhancement as related to hydration or am I mistaken? So I mean we've been on the progressive enhancement bandwagon for some time now. I think the first release of spelt Kit's predecessor, SAPA was in twenty seventeen and the twenty seventeen and you know, we launched with service side rendering, but I wouldn't say that
we were the first people to do that. We were essentially copying Next and Next and even they were copying other prior up Remix was maybe one of the first. No No Remix was actually pretty late to the game. Oh yeah, because it was a big thing with Remix, as I recall, like their first demo where they showed everything effectively running to police server side without anybody
noticing, or something along these lines. Maybe it's worthwhile to quickly explain, like this is not the point of this podcast, but maybe it's worthwhile to really quickly explain what progressive enhancement means in this context. Yeah, I mean, it's possible that we're even talking slightly past each other by using it to mean different things. But essentially the idea of progressive enhancement is or take the
analogy of an escalator when it's running. When the electricity is on the escalator, you stand on it and it takes you to the top or it takes to the bottom. But if the electricity fails, or if there's a mechanical failure or something, it becomes a staircase and you can still use it. So we say, yeah, so the escalator is progressively enhanced from a staircase. You can still use it, but it's just nicer if you have the
things running as as you're using them. And in the context of a website, what that means is that if you have a page that doesn't have JavaScript for whatever reason, maybe you're on the subway and the JavaScript failed to load before you lost connectivity, or maybe you're on a browser that doesn't support some new JavaScript feature that is being used by that website, or one of the hundred possible reasons why someone might not be running JavaScript, that website should continue
to work. And that means that links should still take you to their destination. It means that you should still be able to interact with form elements. It means that you should be able to submit a form and send data back to the server. And it's that latter part where Remix added some innovation.
They really prioritized form submissions in a way that other frameworks had kind of said, you know, this is a problem that is solvable in Newserland, whereas Remix said, no, no, we're going to make this like a core part of the framework's offering. And that was a very welcome change. Like other frameworks certainly sat up and took notice and started doing the same thing progressive
enhancement. More broadly, this idea that if you have a website it should work without jobs is something that I think frameworks have been prioritizing for many, many years at this point. Oh and there was one more thing I wanted to ask. Oh yeah, one of my last questions. A lot of frameworks, it seems to me, are kind of embracing in certain ways in very different ways. Concept of RPC as a means of communicating between the front
and the back end. Now this is more a meta framework question than a framework question, but basically it means that you invoke code on the server side in a way that's kind of that looks semantically like calling a function. Is that something that you're also looking at, or thinking about or considering. I have some real qualms about RPC as it's being implemented by by frameworks today. I think there is a real value and at least having to switch between different
files if you're crossing a network boundary. There are too many ways in which it can go wrong. If you have some code that access a database directly and you just put that inside some code that is running on the front end, then even though the compiler is going to get rid of it, you know there is a non zero chance that you are going to have some sensitive
information in a source map or something like that. And in general, any type safety that you get across the network boundary is fictional, and I don't think that these RPC systems give you as much type safety as they as they purport to. So all typescript type safety is effectively fictional because it's all it never happens at rue time, and so in a lot of ways it's no
different than whatever other type safety you get from typescript. But it's really funny because we actually had Sam Salukov on one of the episodes talking exactly about the scenario just described, because he's the one that did that presentation with a slide that became a meme about the terrific presentation. Yes, it was embedding some SQL in line inside the React component, which was yeah, a lot of people didn't like that. Yes, a lot of people were on one of
two sides of that screenshot. There were the people who were like, oh my god, this is a giant security hold because they didn't understand that the sequel in that screen shop was being escaped by the library. And then there were all of these other people on the other side of the spectrum being you
idiots, it's being escaped, there's no problem here. But the reality is, yes, that code was being escaped, but it would be so easy for someone to write a sequel querid that was not being escaped, and by creating these arbitrary mini end points throughout your application and just like exposing this massive
surface area to you know, to would be evildoers. I think there is you know, there are some security questions that arise from this way of thinking about things, and like, look, smart people are thinking about all of these things, and I don't expect that we're about to experience, you know,
a security apocalypse of RPC causing like all manner of new attacks. But I do think that just at a conceptual level, as you're writing the code, it's much easier to understand what's happening if there is a just a tiny bit of friction between what's happening in the client side and what's happening on the server side. And for me, like a file boundary is a good place
to express that distinction. In the context of a VT application and spelt get applications of VAT applications, you can use something like telefunk, which will allow you to do our PC by importing quote unquote a function from a service side module and in the client that is essentially, you know, an RPC interface which allows you to call that function on and stuff, but it's not inside the same file that is running client side. And this is you know,
maybe a matter of preference. And maybe I'm being overly paranoid about this sort of thing, but I think there's too much Your scientists are so preoccupied with whether or not they could they didn't think about whether or not they're not they should. Everyone's trying to be the like the slickest and most convenient thing, and sometimes that's right. I mean, I s felt certainly tries to be slick and convenient in a lot of places, but sometimes friction exists for a
reason and we forget that at our peril. So just final question on my part because you mentioned sveld Kit, is sweld Kit staying the same in this release? I mean, the swelt Kit that runs with Spelt five is effectively going to be essentially the same as swelt Kit that's running with Swelled four. Is there some are there some changes on that front as well? It's going
to be exactly the same at release, I believe. I don't think we're going to introduce any new things that you know, use the new state primitives for for example, straight away, because everything is just going to continue to work. It should just be like a Seams's upgrade. You can take your existing spelt Kit two app and upgrade Spelt four to Spell five. Everything's going
to be fine. That said, once we do get Spelled five out the door, there are certain ways that we're going to be able to capitalize on it within spelt Kit and longer term, I think we have some some ideas of where we want to take spelt Kit that are going to be easier because Felt five exists. So do you have do you have a date. I know people are wondering, Come on, Charles, don't do me like that. Oh somebody was going to ask it. Okay, let me ask a
different way then. So I'm figuring you have the roadmap pretty clear. It sounds like you know what you're putting in, how this is going together. It looks like you've got a lot of this kind of you know, bolted in. You know, are are you still bolting pieces in? Are you polishing? Are you i mean, where are you at? And the life cycle of releasing something like this. So, in terms of the design of
the framework, I think we're pretty much done. There might still be one or two little API design questions that needs to be resolved, but it's at this point it is mostly implementing the things that we said we're going to implement and fixing bugs. I wouldn't say that we're on the glide path yet, okay, but we are pretty close. I think we're going to have a release candidate in the not too distant future and a stable release not too long
after that. I'm just very hesitant to commit to specific things because in the past, whenever I've done that, people have got mad at me. Makes sense, It looks like from the comments on YouTube that some folks have been able to try out Spelt five right, So whatever state it's in and then able to get you feedback. So let's say that I'm thinking, oh, I want to try it out, right, whether I'm an experienced Felt for developer, whether I'm just you know, I'm trying it out, and I'm
like, I may as well just try the cutting edge thing. Where do I go pick that up? And how do I give you feedback? So the beach is available on MPM, the NPM installs felt at next you will get the most indevelopment of version, the most cussing edge stuff. If you have an existing spelt Kit app, you can do that and hopefully things will
continue to work. If you're creating a new application and you want to try it out, then when you create your spelt Kit application with MPM create Spelt, it will present you an option to try out Spelt five and if you accept that, then you'll be opted into the new stuff. If people have feedback, it is extremely welcome. Come to get hub dot com, slash felt JS, slash spelt and there is an issue track of there. When
we are accepting issues and pull requests for Spelt five. A lot of people have already contributed, and it's been super helpful, really great to have like an enthusiastic community who will take this very unfinished product and actually start putting it through its paces. It's helped us find a lot of things that might have slipped under the radar otherwise. And if you want to be one of those
people, then please come on by. I have to say that I really admire how brave, very brave you are in the scope of changes that you're making in this version. I mean, it's not totally not a trivial thing to take a framework that's already at version five or approaching version five and literally turning it on its head in a lot of ways. It's like it's a big gamble, and and I really appreciate you for doing it well, thank
you. And you know, it's a testament to the spoke community that this has been met with by and large, a lot of excitement and enthusiasm and not too much grumbling and why did you have to change it? You know, we have this really great community that I'm very appreciative of, and they've been super encouraging and helpful throughout this whole process. Yeah, I guess one
other thing that I'm just curious about. Do you do you have some idea how large the community is out there using spell Let me see the I guess the best proxy acting give for that is, let's see how many people are in our discord server right now? I think solo dev slash chat. So there's eight and forty five members online in our discord right now. I have sixty five, one hundred and four members. So it is, you know, next to React and View and Angler and these other things, we are
ten hands product projects. But that's not a small number of people. No, I'm not exactly sure by the way. I mean, obviously React is the biggest and and it's effectively as big as all the other frameworks put together. But once you go beyond React, the order is not as as trivial as you might expect. From what I've seen. I've been kind of using the Crux, the Google Crux database as a reference. Now, obviously, you know, it only shows a certain subset, you know, effectively just
sites that certain sites at Google ranks. But it's better than nothing. And uh, and then I'll try to look up to see what the current situation is, but I'm not sure it's it's quite as linear as as you might think. That's you know, that's what I'm thinking. Well, we're growing, but you know it's it's mostly upside as far as we're consented. Awesome. Well, I'm gonna go ahead and slide us into the wrap up of
the show. Rich, you kind of talked about people giving your feedback, but if they want to follow you or see what you're working on, or connect in some way, where do people find you on the internet? For my sins, I still hang out on twister dot com, slash rich underscore Harris H Yeah, I guess that's where I do most of my opinion thing. But most of my time is Spelt is spent on getthub. So it comes to the Spelt organization on GitHub and and joined the join the threads there,
and I thought discortical spelt dev slash chat. Yeah, that seems like an awesome thing. I just joined the discord. Sorry, I love Discord. All right, Well, let's go ahead and do some picks, Steve, do you want to start us off with the picks? All right, so you want to get to the high point of the episode, first, I get that, I get that speak early, right, So I didn't really have any other picks here other than the dad jokes of the week,
which are the high point. Rich. I'm not sure if you're aware of this, but anyway, uh So, recently I found this diet diary that I was keeping when I was losing weight, and it says day one, I removed all of the fattening food from the house. It was delicious. Side note, I found another diary I kept when I was first born and said day one, still recovering from the move. In day two, everybody talks to me like an idiot. I borrowed that one from Stephen Wright.
Continuing along with the food theme, a lot of French words have actually crept into the English language over the years, or durs for starters, right, and then you know, I've never really had pets because I'm just not good with pets. For instance, once I had a fish that could break dance, but only for twenty seconds and only once. Those are my picks of the week, all right, Dan, what are your picks? Okay?
So we saw this movie on Netflix which I well, I really enjoyed, which is called I Care a Lot It's described as an American satirical black comedy thriller film. It's with Rosamund Pike and Peter Dinklage, and like I said, we really enjoyed it. It's kind of gritty, dark comedy and it
has a certain message. So yeah, I recommend that. And the other thing is we've kind of been clearing out our library at home, Like we've got, like our library got to the point where we had three or four rows of books, so we thought that we needed to make some space. And I've been looking through my collection of science fiction and fantasy books and trying to see which ones I like to keep and which one I toss away, and some of the ones that I've decided to keep, I'm kind of reviewing
or rereading and thinking about also maybe recommending for our listeners. So an interesting series that I recall enjoying very very much when I read them, so I'm now going to reread them and see if I still enjoy them is a series of books by a woman author. Her name is Julian May. It's called Saga of Leosen Exile. It's kind of a cross between science fiction and fantasy in the sense that everything is kind of described in a sciencey sort of a
way, but the settings is actually more similar to a fantasy series. Now, I will make a certain caveat in some reviews have stated that it has transformed some transphobic views in it, So if you might find that triggering, maybe this is not for you. I'm not sure that's the case or not, because as I said, it's been a really long time since I've read it, so now I'll reread it again and see if that's indeed the case.
But so that that would be a series of books that I reco that I'll recommend based on my recollection of it being just an excellent series of books that I enjoyed reading like a few decades ago, and those would be my picks for today. Awesome. I'm going to jump in with some picks here.
And I probably picked this board game in the past, but we were playing it and my eight year old wanted to play games, and so we pulled out some of the board games, but she wanted to play an adult game, and so you know, we were pulling out off the kiddie games right right. And you know, for those of you who haven't listened for a while, are new I pick a board game every week, so this
one is actually a card game, not a board game. This week it's Sushi Go Party, and it does have a little board, but it's just kind of for keeping track of your points, and you have the different sushi options, right, or sometimes you have other things like a spoon or chopsticks or something, and so what you do is it's a drafting game. So
you have the cards in your hand. You keep one and you put it down face down, You pass the left, and then you reveal your card, and then you pick from the hand that was just handed to you and do it all over again until all of the cards are exhausted, and then you score, and the scoring is based on the whatever the different sushi options are, right, So the nagiri are just straight up the points that they you know, that are on their face. You've got like miso soup.
Whoever has the most of those I think it's a certain number points. Anyway, there are a whole bunch of different things and you can trade them out right, So there are different kinds of sushi that you can swap in, right, and then you score the desserts at the end, and whoever has the most points wins. Board game geek has a weight of one point three zero, so you know, really simple game. She could pick it up
and play it. She actually won the second game we played, but it's mostly on sheer luck because you know, she's not quite to the point where she can look at all of the options and put them together in the right way that works right. But she happened to collect enough of the right cards to make it happen for her the second time, which is kind of nice because you know, then she can play it and win. So that Sushi Go Party. I think it takes twenty minutes half hour to play around of
it so and it'll play up to eight people. So if you have a big group and you're wanting a game that will play all those people, then that sometimes that's the issue, and you can definitely do it Sushi Go Party at home. And I've yet to win. Oh really, that makes me sad. We don't play Settlers anymore. We have it. I think it's called Katan now. I think they dropped the Settlers off. Could be and they have a bunch of variants of that too, which are fun. So
anyway, I'll put an Amazon affiliate Lincoln there too. If you click it, I get kicked back, but you can just buy it wherever. It's been around for quite a while, so it's not it's not like a hot game that's hard to track down. But yeah, if I do it this way, then people just click and buy it. So other picks. I've been connecting with people a lot on LinkedIn, which I'm really liking, so
I'm gonna pick that. Mostly what I've been doing is I've either been reaching out to people that I've worked with in the past or have some connection to us, like, oh, I'd like to connect with them again. You know. As I mentioned at the start of the show, I'm looking for work, and so you know, sometimes people will throw me a connection or something. You know, they're like, hey, connect with this person because
they may be able to help you. But for the most part, it's just been nice to connect with people while I'm trying to figure out my work situation. And then the other two things are going to be the things that I'm putting together. So I'm I'm putting together JavaScript geniuses and Ruby geniuses. I think I've mentioned it on the show before, but I've finally got kind of all the platforms put together and everything, so you can sign up and
do it. It's going to be a weekly call. We talk about JavaScript stuff. You know, we may invite people like Rich or Dan or you know whoever else that we've had on the show to come in and just chat with us about what they're working on. Right, so maybe we'll hit Rich up when Spelt five comes out and you can talk to us about what's involved there, or you know whatever when people are available, and then yeah, just kind of do some coaching, some career connecting. But it's kind of
that weekly meet up vibe that you get. And so if you're into Ruby or JavaScript, I have basically one for each, and then I just the
other thing is I just barely set up on spreaker. I set up the premium podcast, so you know, we do insert ads into the audio of the podcast, and so if you want the version without the ads, or if you are just you just want to support the show at nine bucks a month, that really helps because anyway, yeah, I'd like to eventually not have sponsors, but in the meantime, if you want to help us out, that'd be great, and you can just get that at JavaScript jabber dot
com. Slash premium. All right, Rich, what are your picks? Well, after being reminded about it during this conversation, my pick has to be Ragnaro, go get yourself a quest three down O Ragnarok, You're going to have a great time. So the reason that we have a quest three is because I was able to convince my wife that if I spent five hundred dollars on one of these, I was much less likely to spend three and a half thousand dollars plus tax on a vision pro And so far that's how
true. Yet to yield to temptation. Can't you get it for cheap now that everybody is trying to return them? Maybe? Maybe? Honestly, I haven't even tried one yet, and I'm scared to do so in case I am then compelled to drop all that money on something that I will end up probably not using very often. But you know what, I think people are sleeping on virtual reality generally. I think that it's obviously early and there's a
lot of things that has yet to be figured out. But if I had more time to spend on hobby projects and I wasn't working every hour that ends on spelt, then you know, forget about all this AI nonsense. VRS. Where's it's going to be? I have to mention this. So that's something like fifteen years ago, I think, more or less. I gave a talk at a conference where I said that if in a decade from now, we are still using the same old laptop form factor, I'd be extremely
disappointed with humanity. And here we are still waiting on VR. We're so close, We're so close. Yeah, all right, well this was really really interesting, and we do these episodes and then I'm always like I want to go fry it right now. So anyway, thanks for coming rich, This was a lot of fun. Yeah, thanks having me. All Right, folks, we're gonna end it here. Until next time. Max out