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