Tejas Kumar is a Chief Developer Advocate. He joins the show alongside AJ and Chuck to talk about Signals. He begins by explaining what "Signals" is. He delves into its advantages, benefits, features, and what it may provide for the applications. He shares his experience in using it. Moreover, they share their perspective on Signals and React Framework. 

Hey, welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill.

 

Yo, yo, yo, coming at you live from, hey, I'm gonna go to a data center today.

 

Charles Max Wood from Top End Devs. This week we have a special guest, that's Tejas Kumar.

 

What's

 

You want to say hi? Introduce yourself again? Let people know

 

up? Yeah,

 

who you are.

 

hey, it's Tejas, pronounced sometimes like pages. Nice to be here and talk about web pages and JavaScript and all the things.

 

Nice. Yeah, we've had you on before, so you shouldn't be a complete stranger to people, but you know, we do get new listeners, so you never know.

 

Thank you.

 

Yeah, we brought you on today to talk about signals, and I have to admit, I was trying to figure out what they were, and I've seen people talking about it on Twitter and on other places, and I'm not even sure I understand what they are. Right? So, my deep thoughts, to come through this episode, but maybe you can enlighten us. So when people are talking about signals and they're going, this is the best or why the heck do we want them? Like, what are they first? Like, what are we talking about here?

 

Yeah, at the root level, it's a value that change. Like so, I'm talking about signals in the context of like user interfaces, right? That's kind of what the hot topic is on Twitter. Like signals for

 

Okay.

 

user interfaces that provide a level of fine-grained reactivity. You'll see this buzzword everywhere, fine-grained reactivity. And that just means only what changes in your user interface is effectively reprocessed or re-renders. different to how React does it because React will not re-render just what changed, but every component in the tree down from a re-render, from what changed, versus state management solutions like MobX that will give you this fine-grained reactivity, only what updates updates. So a signal to answer your question is a value that changes over time, and whose change events can trigger side effects, like updating a user interface or something. You can think of them synonymously to like observables where you subscribe to them and when they change some update happens

 

Yeah, I was gonna say, this sounds like it's not a new thing that people should

 

That's

 

be

 

the

 

going.

 

thing,

 

Oh, yay!

 

man. I feel like time is a flat circle. You know? And

 

Ha ha ha ha!

 

we were here before React showed up and said, you know what, let's just throw away the UI and put the new UI in place. React showed up with this radical idea that was criticized. But it was a direct answer to two-way data binding at the time, which some of that used signals. Like I think of knockout.js years ago observables, but they were reactive observables that were pretty much the same as signals today. The only difference really between knockout.js and what we have from signals today is the developer experience. You can write them like with nicer syntax. That's it. But it's the same thing that you're thinking of.

 

Okay, so I guess then I'm trying to figure out. what the difference is between, yeah, observables or other things where essentially have a pub sub, right? And signals, like why are people saying this is way better than anything that's ever existed before? And so, I think

 

Yeah.

 

that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point.

 

You know, I don't, I feel like the people who are saying this are people who are on some type of hype train because we have seen,

 

Okay.

 

we have seen reactive primitives in knockout JS. In fact, if you talked, first of all, I feel like I'm probably not the best person to talk about this. There's people like Ryan Carneato, who is like the CEO of Signals. But even he would

 

Uh

 

say

 

huh.

 

in documentation that he wrote that solid JS, probably the thing that started this whole signals conversation recently, the direct influence is directly influenced by Knockout.js. So like even he says, no, it's dude, it's like heavily inspired by Knockout. The only difference is developer experience because it says syntactically solid.js is like almost the same as react. You could literally like take a react app, change around a few imports and a little bit of syntax and it works in solid because the syntax is so similar. So

 

Right.

 

the difference of course is with solid, you know, what actually changes is re-rendered. So your updates are more fine grained. So that's why,

 

OK.

 

yeah. Yeah.

 

So at the end of the day,

 

Thank you. Thank you.

 

I guess what I'm wondering then is when we're talking about signals, are these just not user-generated events as opposed to user-generated events that cause these changes, or can they be user-generated as well?

 

Exactly. So,

 

So

 

a C.

 

not

 

Yeah.

 

a

 

Well.

 

click, for example.

 

Yeah.

 

I got information through the web socket back to my server, and it was checking a weather server. and so it pushes an update up to my end and that's kind of a signal or...

 

Yeah, like what we're seeing on the UI world today is, is, is now, well, okay. So again, to go back to the original definition, right? It's, it's a signal is a value that changes over time that,

 

Okay.

 

that it's changes can trigger events. But the question is, what are these events? Um, and, and are they

 

Yeah.

 

purely user side effects or are they more? And there's libraries now that kind of expose signals around three specific So there's, if you think about conceptually like, like use state in React, right? Some would say this behaves kind of like a signal in a very abstract way, because when you use state and set state, your React component effectively subscribes to the value of this state signal, so to speak. And then when you update it, and you can update just the value, but updating this value

 

Thank you. Bye.

 

would cause a respective user interface update. So that's just

 

Right.

 

updating what is called a root value in these libraries. But there's other things that you can do. So with a signals library, there's another type of value, another type of signal value called a derived value, which is basically when this signal updates,

 

Hmm.

 

that signal updates, it's dependent signals.

 

right.

 

And you'd use this for, for example, if you have a signal for total income and you have another signal for average income, they're dependent on each other. So the average would

 

Mm-hmm.

 

reflect the total divided by the total number of transactions. So that's a derived value signal and then third is just a side effect when this updates do something else. And you see these over and over again exposed in signals libraries today. It's just purely value-based signals, derived signals or computed signals and side effect signals. But all of them fundamentally are things that respond when values change.

 

Okay, so you could then implement this with observables or...

 

very

 

you know,

 

much.

 

whatever.

 

I struggle and this may be me just showing my own inadequacy but I struggle with creating like a nice tweet-sized delineation between observables and signals. They're so similar conceptually.

 

So I'm looking

 

right.

 

at the solid JS documentation and that's where that's where all this hub hub is coming from, right? It's coming from solid JS.

 

that they started the conversation. Yeah. And that's just because they brought Knockout.js observables into newer React developer experience.

 

But this just looks like, to me, it just looks like U-State. How the syntax looks the same, except for it says

 

Exactly.

 

create signal rather than U-State.

 

Yeah.

 

What am I missing? 

Yeah,

 

What it? 

 

look

 

it? 

 

at how

 

it?

 

the signal is being read.

 

Uh, I actually, uh, I only know JavaScript. I can't read react. Oh, it's a function. It's a function. Is that the deal?

 

It's a function called, exactly. So it looks so solid, solid's whole appeal is to look like react, to give people a nice bridge to move to this newer, smaller, better, faster thing, which measurably solid is. That's why syntactically they try to be very close, but if you look under the hood at what Create Store does, it's very different. For example, it doesn't need to be within the closure of the component. You can call Create Store from wherever you want. And what it will return to you is a tuple. obtaining

 

Uh.

 

a getter and a setter. This getter, so the first element in your tuple, when you call it, it looks at its context. So am I being read inside a component? Am I being read inside something else? It looks at its context and basically subscribes that component where it's called to itself, to its updates. And that's really the magic. So every time you call that getter, you opt into when the state here changes now, do something. solid case that means re-render just this piece of UI. So it looks like react on the surface works very different.

 

So why do we want magic? Why not just have it be explicit of where this is coming from and what it's related to? But wait, why are you laughing? I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm laughing.

 

وحوّد

 

I'm laughing. I'm laughing. I'm laughing. I'm laughing. I'm

 

Oh

 

laughing. I'm laughing.

 

because

 

Merry Christmas.

 

of the way you put it. I just think it's funny because, you know, magic or synthetic sugar or, you know, a nice, you know, developer experience or however you want to put it. I just thought it was funny the way that you put it basically, but yeah, for me, it's, it's yeah, okay. So how, yeah, my question is basically the same. How is this superior to what we already have?

 

because it allows for a different type of rendering, arguably a faster style of update, where a tiny piece of UI so it's tribes to the value of a signal,

 

Okay.

 

right, as opposed to an entire function that could contain a hundred different side effects, a lot of other use date, that is maybe subscribed to a bigger context. Like I have worked with React databases that are large and React components where the imports alone are like a hundred lines,

 

Ouch.

 

It's very

 

Yeah.

 

easy to lose track of do I use memo this, do I use callback that, and you kind of just hope you get fine-grained reactivity for free. And that's kind of a misnomer, right? Like React says it makes minimal efficient updates, so you would think, okay, it's not going to update unnecessary.

 

Well. It does make Minimal efficient updates, if you write it that way.

 

Yeah, exactly exactly, but this is the thing like the minimal efficient updates is opt-in, you know, and that's

 

Yeah.

 

I feel like That's the biggest loss whereas with solid

 

And it's... Oh, good.

 

No, I was just gonna say with solid, it's not opt-in. Like, it's minimal efficient by default.

 

Yeah, it's, how do I put it? So what I find is that a lot of the decisions that we make as far as like how we build our systems, what we bring into our systems, they all have implications then on how we write our systems, right? And so

 

Yes.

 

React doesn't, because you could do this in React. I mean, you've said this a bunch of times, right? You can do this in React. You can probably make it so that it fairly cleanly kind of updates we're talking about. But it doesn't naturally push you that way, right?

 

Yes.

 

It doesn't naturally discourage you either so much. It just doesn't, it's not kind of a first class, oh, I want to make this small change in my UI. And so I clearly and easily and quickly use something like signals, right?

 

Exactly.

 

And so, so the issue then becomes, okay, so

 

Yeah.

 

to get an update in three tiny places

 

Exactly.

 

instead of dealing with something like signals where those three tiny places are all subscribed to the event and so I only get three tiny updates and so it doesn't have to do as much work it can do it much more quickly it doesn't more efficiently and it's much more targeted so that I don't if you're re-rendering half the page you may re-render other stuff in a way that I didn't expect.

 

Exactly. And this is where I feel like React has lost because React's value proposition was you declaratively write your UI and effects and React just makes it happen. But in some way, React has kind of lied to us almost because it doesn't just make it happen. It makes it happen with an unseen cost of performance. And this is where, and then, you know, you talk about it in the community and it's like, why is half my Patreon? Oh, no, no, that's okay. Just slap or use memo on it. And then slap or use callback. And then you have to think about your dependency arrays. And then it gets way more complex. And this, I feel like, is deviating from the value proposition of, no, no, React is just declaratively describe your stuff and it happens. And so I feel like if React executed on its, this is such, it's not going to get me in so much trouble, but whatever. I feel like if React executed on its promise of you declaratively UI and it just happens performantly, then solid or signals wouldn't even have a reason to exist really, which would be describing UI left and right. Things just work great. But I think it's all not for loss because of the more recent discourse that's happening with solid, React is actually being incentivized to improve. And it is, I don't know if you all have

 

Mm-hmm.

 

heard of the forget compiler from React.

 

No, I don't think so.

 

So this is in 2021 at ReactConf. They announced the new experimental project where it's this compiler that will do exactly what I just mentioned React should, which is quite exciting. And at build time, we'll statically analyze your code and infer what should be memorized and what components are unlikely to change. Actually, what components will never change. And it automatically, at build time, them and your final bundle will have used memo and use callback in the right places. Just automatically.

 

Oh, interesting.

 

So that way React does deliver on the promise of you don't need to think about signals, you don't need to think about memo, you don't need to think about it. You just like describe your UI and it's done. That's been an experiment at Meta since 2021. It's been two years. But I think if they figure that out, then we're good in the UI space. React then delivers what it promises. It

 

Yeah.

 

doesn't. Yeah. Yeah.

 

Well, and I think because over the last several years, the way that we look at use and approach things in a React app have changed, right?

 

Yeah.

 

I think initially, a lot of the promises that you're saying that React made, it could keep mostly. And it was because we weren't using it in the way that we're using it now. A lot of times, we were just saying, OK, these are the things that I need you to handle, and then everything else was mostly static and it was fine. But then as we've kind of moved into single page apps, we've moved into areas where you have huge components with a giant tree of subcomponents, right?

 

Yeah.

 

If you have it re-rendering too far up the chain, then that's where you're getting into trouble. But it's easier to just have it manage the changes, you know, a lot of

 

Yeah.

 

times things that we're talking about. And it doesn't give you that, like I said before, it doesn't really push you to do the fine-grained stuff.

 

Yeah.

 

And so what you're doing is you're doing the easiest thing to program, which doesn't necessarily lend you to the most performant or targeted way of building your app. And

 

Yeah.

 

so I think it's less that React doesn't give this to you and more that the common coding discipline for React has not encourage developers to go that way. And some of that, yes, is the framework and some of it's the culture or lack

 

Yeah.

 

thereof around it, right? And so

 

Yeah.

 

there are a lot of different ways to approach this to make it better. But where we're at with React, yeah, I think the best way to handle it is something like tooling where you effectively add signals or signals like stuff to React in order to give people that approach because at this point, community back in and say, hey, you all are doing it wrong. I just don't think a lot of people are going to pick that up. I think the people who are active in the community and are speaking into the community, paying attention to the community and working in the community may pick that up. But there are a lot of people out there writing React that they go to work, they write React and go home and they never listen to a podcast or read a blog or watch a conference talk. And so those people are just going to keep doing it the way they're doing it. And then what will happen is is that when this comes out and it's announced as the new feature in React, whatever version it comes out in. That's when it'll... oh, this is there. Oh, this does this. Oh, that's really nice. And then they'll start using it.

 

Yeah, which to be fair to your point where you said, you know, it would also be hard if react comes out now and says, hey, you all are doing it wrong. I feel like there's an argument to be made there of if everybody does it a certain way is it still wrong, you know, because again

 

Yeah,

 

coming

 

wrong

 

back.

 

isn't the right word, but

 

Right.

 

yeah, it's suboptimal

 

But come.

 

or I don't know how you say that without hurting people's

 

Right,

 

feelings,

 

but

 

but yeah.

 

I feel like the, I keep going back to the initial motivation for React too, which is what if we could just describe what we wanted without getting into the details.

 

Uh huh.

 

And that's, yeah, I think that's where a lot of, even the motivation for, or even preact. So I don't know if you all have seen this, but preact released a library where you can add signals with fine grade reactivity to react.

 

Oh, interesting.

 

Yeah. use signal and you import this

 

Mm-hmm.

 

from Preact in your React app.

 

Oh wow, okay.

 

Right, and people are solving these problems for React, but really I feel like in the developer community there's a man why can't Meta just solve this since we all want this? And you know literally man at least once a week I will hear someone complain about use effect right? Someone's saying things

 

Uh huh.

 

like why would the default of any libraries exported be an infinite loop. Why? And people, they're mad about it. And I feel like they kind of hope that the core team solves this. And to be fair, I see them listening and solving it with things like the Forget Compiler. But I feel

 

Mm-hmm.

 

like it must be very hard to be on the React team because like anything they say is so heavily scrutinized on especially Twitter.

 

Yep.

 

Like if they say something, they'll be, if they say, you know, hey, signals aren't the right solution for react right now or something like this, I can already see like a huge angry mob showing up and saying, hey, react, why are you punching down on solids? All it's great. You know?

 

Yeah.

 

So it's, it's, yeah, it's complicated.

 

I mean, they

 

Yeah.

 

could just come out and say, hey, if you're not Facebook, React might not be the right thing for you.

 

That's true.

 

You

 

Yeah.

 

know, if you're not building Facebook.com, React may not be the best framework for your use case.

 

I would love to see

 

You

 

that

 

know,

 

blog

 

it's...

 

post.

 

Well, I've talked to a number of people that are either involved heavily in the React community or are on the React team. And yeah, they'll admit that it's not the right solution for everyone. But the trick is figuring out where the trade-offs are. And then, you know, a lot of times when people are looking at React and saying, well, maybe it's not the right framework for me, then they start looking at Angular and Vue, which are also have some of the same problems. Not all of the same problems, but some of the same problems. And so then they're looking at it and going, they all have the same problem that I would need to work around and they don't go look at a solid or a quick or something like that. The other thing that's interesting in this discussion here is that and this came out when we talked to Miesko Hevery about quick, right? Because he left the Angular team and was working on quick and he talked about how some of these things, the Angular team, by virtue of the way they designed Angular, they kind of painted themselves into a corner where they couldn't easily solve the problem without breaking changes. Now, maybe the community will come up with something that is a workaround and you have to know that, you know, it has these certain quirks to the way that it interacts with Angular, but it wasn't something that the Angular team itself could do. And, you know, and I think sometimes we get into that with React and Vue as well, where now we've got this large code base. there are things in there that just aren't flexible enough for you to go in and, and really change. And so some of these things might be a little bit hard to do. So they may have signals like with something you import from preact, but it may not be the same as what solid does because solid has made other decisions in the way that they've architected the framework. And so

 

Exactly.

 

it's it's really fascinating just to see okay, where does this leave the landscape because people want it. people think it is.

 

Yes, but this is why I'm really excited about, gosh, I'm about to use a like a taboo word, but this is why I'm excited about react becoming decentralized. And, you know, most of the core team moving away from meta to a Vercel, I think is brilliant

 

Huh

 

because Vercel's motivation is not Facebook's motivation, right? Vercel's motivation is

 

Right.

 

twofold. One, they like to flex and show off their massive pecs in the in the web space. So while I don't know how people feel about that, it's a net positive because they're like, look, we run React at 0.001, MS network delay now. But

 

Mm-hmm.

 

also, they're a hosting platform who's incentivized for performance. So worst case,

 

Right.

 

your React apps are really hard to deploy elsewhere except for self. Sure. Still, I think the framework itself, Next.js and so on, have every reason to be performing now because of that. So I feel like, The Angular failed, well, I can't say Angular failed. Angular is really great. But Angular had its issues, especially with breaking changes and so on, because it did serve one master. That was Google at the time. But

 

Uh-huh.

 

React now being the baby of mostly Vercel and Meta, and soon I predict multiple Meta engineers over time will just go to Vercel. It becomes more decentralized. And there's now also community working groups and things. So I do think even if it was architected for Facebook in the beginning, I think there could be plenty of work to optimize it for a modern web. I see some of this already in the open source world. For example, I spoke with Mishko about how quick has code splitting and lazy loading as a first class citizen. The whole framework is built around and reliability. That is, this stuff comes from the

 

Right.

 

server, like minimal, and only like when I click on something interactive, only then we incrementally load interactivity, which is quite nice because it's like tree shaking interactivity. But, and his argument to me is React wasn't built for this, so they can't add it now. And I don't know that

 

All right. Thanks for watching. I'll see you in the next video. Bye.

 

that's fully true because if you go on GitHub.com slash Facebook slash React, they're talking about what they call selective hydration, which is very close to resumability. It's almost

 

Hmm.

 

there. So maybe it may not be true resumability, but I think the benefits come very, very close, which selective hydration is you hydrate absolutely nothing. So you server under your entire page, and then when a user goes to interact with an element, you hydrate them on demand, which is

 

Great.

 

very similar loading on demand, your code split closure.

 

Hmm.

 

And I think this is a direct product of React being maintained by more than just Meta, which we haven't seen

 

Right.

 

from Angular or Svelte or Vue or others.

 

Yeah.

 

So yeah, I think, I don't know, I'm still a little optimistic about React to be honest. I think it's because it has the momentum and now the decentralization and the incentivization by Vercel. stuff coming up with quick and solid is cool, but by no means like withdrawing eggs from my react basket, you know what I

 

Right.

 

mean?

 

No, I, and I don't know. I mean, if you're heavily invested in React and it's working for you, it's doing what you need it to. I don't know that, you know, withdrawing eggs is necessarily the right thing. But one thing that has been awesome as we've moved through, I mean, how long have we been doing this stuff now, you know, 20, 30 years, JavaScript, right, is that initially it was, hey, we're going to drop a script in your page. And then it was, hey, we've got nice things like prototype and the jQuery, right? And so as these things advanced, hey, now we've got standards around the DOM, now we've got standards around other stuff, you know, now we're going to pull in backbone, backbone uses underscore, hey, we can do underscore better now we have low dash, hey, we can do a lot of the low dash stuff in some of these other frameworks and, you know, you know, as we kind of adopt that, and then we get like backbone and backbone made it easy to organize all your JavaScript. And you still got the benefits of jQuery and everything else and then it was hey well now We've standardized the DOM to the point where we don't need a jQuery to kind of paper over all the inconsistencies and all the browsers so the The frameworks kind of picked up a lot of the DOM magic because it wasn't so hard anymore and Then you know and then we got into like yeah We had an angular and angular was kind of taking the world by storm and then react came out and pioneered a bunch of stuff and so it's nice to to see that, you know, if the killer feature that I need, right, that makes more difference than, and then all the other features put together is the thing that Solid has or Quick has or Alp, what is it? Astro has or,

 

Yeah.

 

you know, one of these other ones, right? I can go pick that up, right?

 

Yeah.

 

If I just want kind of the, you know, or stimulus, stimulus is what I've been playing with, it's kind of a favorite of mine. But, you know, I can go do that, right? It does exactly what I want, where I want.

 

Yeah.

 

But if I have a big investment in React, I have a large React code base. It's serving us well. It's doing the things we need it to. But yeah, I wish that it had the resumability. It's nice to see that they're still paying attention out there, and

 

Exactly.

 

that they're going to go pick up this stuff. And so to the point that it would and cost me a ton more money and be a giant headache for me to move off of React and onto solid. If they're continually picking up these good ideas and it's not gonna kill my company in the short run to not have them, yeah, I don't see any reason not to just stay with React. But if they stop pulling, you know, they stop looking at these features, they stop looking at innovating the future and creating these opportunities for my application to do what I need it to. going, okay, they're not going to serve my needs long term, right?

 

Exactly.

 

So I may have to undergo some short term pain to rewrite this in something that will.

 

Exactly. And even so, like to double down on what you said, like, you know, you may have heard a lot about React server components.

 

Mm-hmm.

 

React server components didn't get buy-in at Facebook at all. Like nobody wants that. And

 

Right.

 

this is when you thank your stars that React is maintained at more than just Facebook, at Purcell, because it's no longer

 

Right.

 

this thing that's built to serve just Facebook. And server components, I'm sure, as you're aware, is like extremely important for having highly performant React applications at the edge. And at a certain level of scale as well, what's the alternative, man? Otherwise, you just ship huge JavaScript bundles. And maybe

 

Right.

 

you lazy load and you do all of that. You Gzip and Brotly all your whatever. But to be able to just ship components only when they're needed is a game changer from UI. And in some ways, it does come back to server rendering. and so on. As I said, time is a flat circle, but yes, the fact that they're investing in these things I think is key. So that's actually been the deterrent for me going like all in on. If I was to go all in on something that is not React, it would be quick or solid. Purely because of syntax and learning curve. Both of these look exactly like React. They both use JSX.

 

Yeah.

 

I have nothing. The learning curve is very, very shallow versus something like view. For example, I feel like I would never learn view. because I just don't, I tried to write the new syntax and it just doesn't, my brain doesn't seem to pick it up as easily, yeah. Also Svelte is

 

Yep.

 

different syntactically, but I find it somehow more approachable than Vue, so.

 

Right. So I'm going to kind of push us back towards signals for a minute.

 

Yeah.

 

You know, because I think we've kind of, I think this was an important tangent because we're looking at, okay, you know, how does this affect the broader ecosystem that we're looking at? But have you, what have you done with signals? Like what examples do you have as far as like plugging this in and letting it rip?

 

Yeah, I'm building a personal finance app just for myself. I started a business

 

Uh-huh.

 

this year and taxes,

 

Congrats.

 

you know? And thank

 

There

 

you.

 

goes all

 

And

 

your

 

then

 

spare

 

you see,

 

time. I mean,

 

Yeah, it's I know exactly what you mean, dude, like I've been waking up at like eight o'clock in the morning going to bed at 11 at night working constantly.

 

Yeah.

 

But but it's it's it's meaningful work. So I don't even mind like I actually enjoy it

 

right.

 

anyway. Turns out I owe a lot of money to the IRS, the German IRS. But I want to be sure to prepare for the huge amount of money I'm going to have to just lose or pay. So I naturally go look at bookkeeping apps, but nothing

 

All right.

 

hits the spot, you know? And I don't wanna pay

 

I know exactly

 

like,

 

what you mean. Believe

 

yeah,

 

me.

 

yeah, and I don't wanna pay like top dollar for some like Zendesk or whatever it is they use. So anyway, long story short, I decided to make one, bespoke for my business to meet my business needs. And what I'm noticing

 

Huh.

 

is, dude, like when you have numbers, dashboards, across the board, not just with personal finance apps, you have tons of state that depends on other state. And you also have tons of UI elements that are very computationally intense, even if it's just a time series like, hey, this is your income and expenditure over a year.

 

Uh huh.

 

Like this is UI complexity on a different level. And, you know, making the jump from like React to React.memo everywhere and lazy load everything and be extremely cautious. To implementing this with signals has been a real experience. For the reasons we've covered, like with signals, it's like I write React code or rather would solid I write React code but I don't think about performance unless it's network performance. In which case you can't avoid that with a UI library. But with React, I'm constantly having to think about, okay, where do I use memo? Memo eyes are these props gonna change? Oh shit. I have stale props here. What happened? Like this conversation is just Constant when you're working with a personal finance or dashboard app. So that's kind of what I know So with signals, I've been able to go quite far Create because solid JS has no opinions about the location of your state You could create signal literally anywhere like inside the declaration of your component or in some separate module somewhere else you could even like of just signals and export them and import them into your project. You can do whatever you want. And so with that, you know, I got to play with what if I had all of my state declarations in one file? How would that work? Turns out not very good because when you mutate it, then it becomes hard to track. Solid does have some dev tools that shows you like a graph with nodes and edges of where your signals are, which has been helpful.

 

Oh, interesting.

 

But yeah, yeah. It's actually very nice. I can recommend that. But longer story short, the fine-grained reactivity makes my shit performant, and I don't have to think about performance. So that has been very helpful.

 

Yeah, that makes sense. I just read for so far, book club on TopendEv's, by the way, if you're all interested, topendevs.com slash book club, I'm not going to give you a pitch, but you can go sign up. Anyway, we're reading Pragmatic Programmer, and they talked about reactive programming, and they basically use the spreadsheet as an example of that, right? This cell depends on this cell, right? And so you're talking about your finance, and I'm sitting there going, Yeah, that's pretty much what it is, right? It's a specialized, spreadsheet where this value depends on that value depends on that value, right? And so, I mean, that makes total sense because effectively what you wind up doing is you have, yeah, uh, this value depends on that value. But yeah, you don't, you don't want to re-render the whole sheet, right? You just want

 

Yeah.

 

it to update if the other value updates, you just want it

 

Yeah.

 

to react to one other value. And so

 

exact.

 

when you call the, the use signal, the question I have now is if you do create signal, do you do create signal like and then pass in the value in the other cell? And then when you update the signal, do you have some other function that pulls it for like, how do you how do you manage the reactivity that way? Right? Because the example on solid JS, it just has a set interval that it updates the count on.

 

Yeah.

 

Okay, well, now I've got this element that has this value in it. So how do I hook that in so that when it changes, it updates the signal?

 

Yeah, so in that set, in every example, it should be calling the updater. So when you create a signal, you get back a getter and a setter. The getter does more than

 

Uh-huh.

 

just get. The getter does it just get, but it also subscribes the context to the value.

 

Right.

 

So it does two things. And then the setter, whenever you set, also does two things. It mutates the value and then calls an update function on each subscriber. So the getter and

 

Okay.

 

the setter both Yeah, they both do that and then you know

 

Okay, so

 

that

 

whenever

 

then

 

you change it, it calls the setter. And that updates the signal.

 

Exactly. Whenever you change

 

No,

 

the

 

whenever

 

center,

 

you

 

yeah.

 

change the value, it calls the setter and that updates everything else, or it

 

Exactly.

 

triggers everything else.

 

Like one way to implement this, I believe quick influence this with proxies in JavaScript, right? Because you can just use a proxy and say, when you get to do this, when you set to do this, and then it just looks like object property assignments in JavaScript, but you can do more with them by hooking into them with proxies. So yeah, that's kind of how they work. Now, I have to say just for balance, like I've said a lot of negative things about how React has missed its declarative promise how signals are great and solid, but signals also have been a pain to use in my personal finance app in their own way. And this is, I think, the real meat that we should discuss, which is there's always trade-offs and nothing is great, and nothing is inherently just better than the other thing. And I tell you this because, like, with signals, you accidentally opt out of reactivity just without knowing. So kind of like in

 

Thank you. Bye.

 

React, you opt out of reactivity by using use memo or something, but without updating that dependency array,

 

Right.

 

would solve the same thing. If you think and react for one second and destructure reading a signal, you've lost. It's no longer reactive and you will never know why. And you will sit there going, but I'm reading this. Because destructure syntax assigns a variable to a value. a signal read

 

Oh.

 

exactly right but you have to think about this

 

So you're

 

and

 

not

 

that

 

subscribed anymore, you just

 

exactly

 

assigned the value.

 

exactly so again you have to think about this you have to think about this is 100% the same as in react thinking should I use memo should I use call it's the same cognitive load that they're supposed to solve you know so yeah they're not perfect and every tool has its trade on us

 

No, it's interesting, right? Because this is the same thing that when I got into Ruby on Rails, I really loved, right? Was there was a convention. And so as long as you followed the convention, I could make a dozen assumptions about how things were that

 

Yeah.

 

I didn't have to think about anymore. And yeah, like you're saying, the second you deconstruct it and pull it apart, you've basically removed all those assumptions you can make now. And

 

Yes.

 

you've got to think about what the exceptions are to the thing that you kind of naturally move toward.

 

Yeah, yeah, exactly. So I've been burned by my UI not updating by both SolidJ as Android Act almost equally. So

 

Oh wow.

 

really, it's like just pick your poison. Now, I have to say, maybe if I've been writing solid for 10 years and I've just never destructured because you just don't do it in solid, would have

 

Right.

 

been a different story. React has been around for 10 years, so it hasn't. So it's quite likely that people just be destructuring stuff left and right. Yeah.

 

So are you familiar with call bags?

 

done.

 

call bags with a G like

 

Oh,

 

a

 

that's Andre Stelz's

 

bag.

 

library.

 

Yeah, well it's not a library. It's a specification.

 

Okay.

 

Or

 

Tell you more

 

I

 

about it.

 

Well, it's essentially what promises are, except for events that will happen over and over again. So promise resolves once, a call bag resolves multiple times. Also, it's a two-way communication channel, or it can be, it doesn't have to be. Anyway, when I hear this stuff about signals, to me, It seems like it's a concept that should be usable aside from any framework. It seems like it should be something like promises. I don't have React promises and solid promises and whatever. I just have promises and promises. Well they don't really work in React, but if they did that would be great, or at least they don't propagate up. So it sounds like we're talking about a design. design pattern, but we're only talking about it with respect to the implementation. And that's why I brought up callbacks because callbacks is the design pattern that you can implement in any framework or you can implement it in a library just like promises were implemented in libraries before they were they were

 

standard.

 

standardized and whatnot. But I'm just wondering if you see if it sounds like you don't you don't know that much about it. I don't know that much about it, but I watched a presentation on it. because for me it clicked. It's like, oh, this is what I've wanted. This is composable events. And that sounds like what Signals is trying to do. So yeah, do you have any thoughts on any of that blah, blah, blah that I just said?

 

Yeah, I think, I think, I think

 

The blah, blah, blah. Good stuff. Incidentally, you said Andre Staltz. So call bag. If you look at the repo, it outlines that, yeah, it's a spec, but then there's a repo from Andre that is an implementation. So you work correct.

 

So this is nice. Is that the scuttle but thing? Is that what is, anyway.

 

No,

 

So this

 

it's

 

is

 

callbag-basics.

 

nice.

 

I'll put a link in the, I put it in the chat, I'll put in the show notes.

 

Okay, yeah, it's interesting. I think a couple of things. I think call bags, observables, and signals cry to solve the same problem in different, like there's so, I feel like maybe it's just that I don't know enough to delineate them, but these three, they effectively do similar things. They respond to changes in a way that we can easily reason about. with you, I think specification would help a lot. Because this is also a problem in the UI world where I can use the notion of a signal in Quick. So both Quick and Solid, both these libraries have their own implementations of signals. And they work differently between them. So some of these trade-offs that I mentioned where I felt pain with my money app in Solid don't exist in Quick. because their implementation is different. And their implementation is different because there's no standardization. So I agree with you. I think to some degree, I would love to see a language primitive for reactivity. I think we got close to that, right? With what was it? Observable, that's part of TC39's approval. That's currently being discussed as far as I know. We should ask Ben Lesh to come on the podcast and

 

Mm-hmm.

 

talk, that would be a great episode. I feel like a lot of people would

 

Yeah.

 

want listen to that. But yes, that's in progress, but like this is the problem. I feel like TC39 is blocking progress on these reactive primitives. I feel like if there was more traction with the observable proposal, we'd have, you know, less differing implementations and more adherence to some type of reactive

 

I'm not, I'm, well, as you may have gathered, I prefer explicit over implicit. I don't like magic. I rather use a library than be consumed by a framework. You know, when I write a function, I want my function to call other functions. I don't want my primary mode of operation being that my function is called by another function. That being the distinguishment between library is functions as the primary, your main function. Whereas the framework is the main function is somewhere else in your supplying code. That's kind of the thing with it. So for me, I would much rather see what's happening and know the cause and effect, be able to look at the code and understand from the code what's going on, which in some ways is kind of the imperative versus declarative argument. I am definitely in favor of imperative code. I prefer code to, I mean, I like the idea of information hiding, yeah, let's have a function. I mean, essentially every function is declarative because you're hiding implementation details behind a name that's descriptive of what will happen, not how it happens. So at that level, I like declarative, but I like to be able to see things so that there is no magic, so there's no guesswork. If I have a bug, if something's going wrong, issue, I can go to where the thing is and be able to see, hear the, you know, 10 things that are being called or dealt with or done with. So I'm not, the observables from the way I understand it kind of puts a lot of the magic behind the scenes. And I actually prefer the idea that you have more of a chain, more of a, you know, a chain an explicit signal that I call this action and there's a tree of things that that's going to fire off. And I think that that's just easier for me to read. It's more lines of code when you look at, I'm going to write more lines of code because instead of having nested dependencies, dependencies going deep, the dependencies go wide, but that's easier for me to reason about. So I kind of hope that the observables, I think it's kind of lost steam I hope it stays that way. I'd much prefer to see something like the callback spec than the observable spec from what I understand.

 

Can you maybe like outline a little bit what you like about the callbag spec, speaking to this like imperative versus declarative point you mentioned and also like how that concretely differs from the observable spec? I feel like people listening would be very interested. I think that's a good point. I think that's a good point. I think that's a good point. I think that's a good point. I think that's

 

So

 

a good point. I think that's a good point.

 

I may be misunderstanding what the observable spec is because we've had, I pretty much don't dig into things that don't. I don't play with ES20xDX. If something is implemented in browsers for the past two years, that's when I play with it. Because I don't want to have to have transpilers around code that may or may not work at a future date when it usually ends up being syntax sugar anyway. But the presentation that I watched, what I saw was that just like a, so from the readme and the repo, This information is not as clear. It is pretty clear in terms of it's basically, the protocol is basically one function signature. Well, I guess, no, it's three function signatures. And that's basically, that's it. It's just, if something implements all three of these function signatures, then it's a callback. But. The way that I saw it used was just like a promise or an async function. Anytime you create an async function or you create a promise, you returned an object which I learned that's what a monad is. A promise is a monad. A monad is an object that contains a method that can pass the value into a new context without the value being explicitly referenced from the object itself. So promise. Anybody want to know what a monad is? A promise is a monad. But the promise contains the value and the promise can be passed around and the promise can be composed. So you can pass a promise to another promise, you can create a stream of promises. And so that's what I liked about callbacks is just that. You get an object that contains information about a stream and you can pass that stream around and other streams can compose with it and they can use it. a very functional style of programming. But when you look at the code, it's really, really clear, at least from the code that was in the slides, and I'll link to the presentation, it was by Travis Barney and he did an excellent job. I could I could easily tell from looking at the slides, this thing feeds into this thing feeds into this thing. And just like we have dot then and dot catch. being its methods that are not part of the spec, but, or at least I don't believe they're part of the spec, but they're part of one of the reference implementation libraries. So the callback itself is like 10 lines long.

 

Bye.

 

It's almost nothing. It's like a callback, you know, what's a callback? It's literally a function signature. That's all a callback is. A callbag, which I think is a terrible name for this reason when we're doing audio, but the callbag is like that, where The callbag itself is just the function signatures and the interface. But the implementation had some things that were functional style or low-dash style, where you have your collection manipulation functions that help you to orchestrate how the event happens. So with that, it was just nice to be able to look and to see and to be able to read and know And I contrast that with use state and also signals.

 

Yeah.

 

That, what you don't see is that your code is running inside of a function and there's a framework that is consuming your code. And when it gets to your function, it sets a counter on a stack that you can't see and it has the name of the component and some state details in it. It runs that function which must be synchronous. And then when that function is completed, it goes and it runs the next function the stack counter and so every time you use use state what you don't see behind the scenes is that it is managing the state of that function and that's why you can't use use state at the top level and then what signals do from what I understand is that it just handles the the state pushing popping differently so that you can if you put it outside of something and there's nothing on the stack at that moment so a function is marked as not having start completed being run, then it can put that in the higher level scope. So I, conceptually, I understand it because I've actually looked at the React code to see where this actually happened in React. And I can, I can visualize in my mind's eye the way that you would need to tweak that in order for the signal thing to work. But most people, I would say probably 99 would be a low guesstimate on how many people can intuit how you state works, even course code.

 

Yeah, yeah, but I mean, there's, there's so much to unpack. There's just one note about the signals. It's there's no, the whole claim to fame is that there's no, like a rare stack, depending on the implementation. Usually you just return an object with a proxy. And when you get, you subscribe something. When you set, you notify subscribers. So there is no stack.

 

But you said earlier that the way that it knows which component it's in, it knows which component it's in, even though you don't pass the component to it, which means that there is a stack

 

great.

 

because the component has to be called and it

 

Let's

 

pushes

 

see.

 

the component into the state management so that it knows, because normally when you call a function, a function, you know, a peer function has no state to it, but use state and the create signal, their state is based on which function being run. So when useState runs, if it's being run while another function is running, the state of that useState becomes the function. So correct me if I'm mistaking this, but that is happening. Otherwise, it wouldn't know which component it's in.

 

Well, as far as I know, and again, it varies, it's not as much important to recall the component function because the component, as far as I know, is not re-executed in solid, but instead just the getter is re-executed. And the getter doesn't, doesn't, is in a way decoupled from its surrounding component context. I don't know the details, but that's why I hear it. They get this fine-grained reactivity executing your, if you have a component app and that thing opts into a signal, reads a signal, the component is not re-executed, just the getter is, and it returns a new value in place, hence fine-grained reactivity.

 

So are we saying that when it transpiles the code, it's looking for the call to the function, and then it's taking the code that surrounds that, and then it's wrapping it so that it can execute it? Cause obviously HTML doesn't have this functionality, or I shouldn't

 

Yes.

 

say obviously cause HTML is, the DOM is updating quite frequently, but I don't

 

Yeah.

 

believe that this is using any native technology of the DOM. I

 

They are not definitely not.

 

believe this is using a transpiler app.

 

Yes, yes, yes, yes. It does you a hand.

 

And React

 

So I'm going to go back to the slide.

 

for

 

I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide. I'm going to go back to the slide.

 

use state does not use a transpiler hack. At first I thought it did,

 

Yeah.

 

but it actually is not using a transpiler hack. I believe both quick and now from what you're saying, I think that perhaps solid

 

Yeah.

 

use transpiler hacks, which I don't think that React is really any better because the way that it's doing what it's doing, it's very difficult to intuit how it works and it seems like it's a transpiler hack. It's actually not with use state at least. The other ones, using transpiler hacks, it's like, well, now we're again, another step removed from JavaScript, which people are already, they're deeply struggling to get the basics of JavaScript. And I think part

 

Yeah.

 

of that is because they're thrown in the deep end without, without really even in the, you know, the boot camps or college or whatever it is, people don't learn. I don't think there's a lot of learning of JavaScript. I think it's a lot of you get thrown into a framework and you have to figure out what JavaScript is and how it's different from the transpilation or the framework, whatever, fact. And some people say that they wish they'd learn JavaScript first. Some, I don't know if I don't know which is the better approach, honestly,

 

Yeah,

 

but

 

yeah, no, I like the way I like the way you say, um, I like the way you reason about this my only I feel like if you're an imperative person, if you prefer the imperative approach, my, my question to that is like, where's the line, you know, because like promises became declarative, though we used to imperatively implement them until.

 

If you're asking where the line is, you've gone too far.

 

Okay.

 

Because I'm not looking at this from a cultist or religious

 

Thank you.

 

standpoint, right? It's not subscribing

 

preference.

 

to

 

Yeah.

 

imperative. I'm simply saying that people often use the term declarative to basically mean

 

at you.

 

the maximal declarative is a JSON file. If

 

Yeah.

 

you could write a program in a JSON file, that would be the most declarative program would possibly write. There would be no imperative in it because there is no, there is no instruction. There would

 

Yeah.

 

only be declaration. And the maximum imperative you could do would be a single main function with go-tos and, you know, everything all the way down. That's the maximum imperative you could do, have no abstraction whatsoever. And I don't, I certainly don't subscribe to but I don't view declarative as something to strive for.

 

Yeah.

 

I view readable function names and composability as something to strive for and people might say, well, that's declarative and maybe it is, but I don't want my dream come true is not a drag and drop interface that creates a JSON file that is the program.

 

Yeah, that's so well said. I like how it very, like, you told the line of nuance very well with that statement. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that. I appreciate that.

 

Thank you.

 

I appreciate that.

 
Charles Max_Wood:

All

 

which

 

right,

 

was

 

well

 

the line of the

 

work

 

once. Thank

 

Well,

 

you.

 

because like tech Twitter would hear, it's either declarative or imperative, right? And I say, by towing the line of nuance, I mean, you outline very well, very clearly, that you can name functions well and abstract in a healthy way, instead of, you know, create a JSON file effectively. Like you draw a nice distance between what people would think of as either this or that and show that actually work happens in the middle and that's what I wanted to appreciate.

 

Thanks.

 

All right, I'm gonna push this into picks and stuff. I guess the first thing that we do is the self-promotion. So we always ask the question, what are you working on that people should know about? So AJ, what are you working on that people should know about?

 

Well, still doing the beyond code course, really excited about that. And a new thing is a buddy of mine and I have talked about doing a hosting service for a long time. He sent me a server and a blade server and held my hand to set it up. And there was definitely a lot of bits that I would not have, would take me hours and hours to search to figure out what to do, You know, we were able to get it up and running really quickly and Now I've got time machine backups and stuff running off of it for my home and so anyway after seeing how simple it was and Understanding the features. It's basically digital ocean in a box. We are starting a hosting service So if you are interested in that Feel free to ping me. Why would you use our hosting service over over digital ocean? You probably wouldn't I probably wouldn't recommend it but We're going to have basically the same reliability as DigitalOcean, and our thing is going to be economies of scale rather than economies of SaaS. So if you buy more, you pay more. If you buy less, you pay less. And if you, so by buy less, you pay less. I mean, for example, DigitalOcean charges four times what they charge you to run a database cluster as what it would cost if you set it up yourself. less resources and you're paying more for it for basically a script that runs one time at the start, like that kind of thing. And then we are also committed to a very liberal viewpoint in the current dictionary definition of liberal as I understand it, meaning if it's legal it goes and if it's not legal, then it doesn't go. So no conditions. upon usage other than it be, you know, it be legal.

 

Right. So if people, if you don't like the thing that people are hosting on there, you don't shut them off, basically is what you're saying.

 

I don't want to know what people are hosting on there. I mean, when we get started, it's going to be very high touch. You know, it's going to be invite only,

 

Yeah.

 

you know, so somebody's going to reach out to me and whatever. So we're going to have some, I, there are organizations and people that I would not want using our service, but we have to have some level of discrimination. And I don't want people that have a history of scamming or fraud or whatever. You know, it's,

 

Yeah, but

 

it's

 

that's not

 

not

 

legal

 

a.

 

either.

 

Yes. But someone. have a bad reputation but not do something presently that's illegal or Can

 

Okay.

 

it there's there is there is some sort of line there? I don't want to attract bad actors That's what I'm trying to say. It's not

 

Yeah,

 

a place to

 

fair

 

harbor

 

enough.

 

bad actors but it is a place that you can be a wrong thinker and Have dumb opinions

 

Ha ha ha!

 

or a right thinker and have dumb opinions.

 

Yeah, or a right thinker and have great opinions.

 

All right, good deal. All right, so what I'm working on.

 

a lot. That's what you're

 

How much

 

worth.

 

do

 

That's

 

I

 

what

 

say?

 

you're worth.

 

Yeah, I don't want to take up too much time, but effectively. So what I've been trying to build with Top End Devs for a long time is a platform where people can come and level up in various ways, right? I have the Top End Devs method. I think I've talked about it on a couple of shows where you're learning something new every day, you're committing code every day, you're meeting somebody new every day, you're posting content every day, so you're building your network, you're building your portfolio, you're building your personal brand, right? You're going to meetups and conferences, and you're making a plan for how you're going to move forward, right? And so I wanted to create that. And what I found is that I was trying to do all of them, and it didn't work, because I am not the do all of the things person, I just can't, I don't have time. So what I've decided is I'm just going to roll back to the learn something new every day and commit code every day. focused on and then I'm pulling in the meet somebody new and the meetup piece And adding those and so it's just one product. So I'm creating that product where you get two videos a week One of them will be out on YouTube it for free but the other one will be premium only and then We're throwing in a monthly meetup where I either bring in people I know who can come and speak to a particular topic or we just do a Q&A You know kind of what people whatever people need. Maybe it'll be a you know Hey, we're gonna do a group setting, coaching, where everybody can kind of chime in and help this person and this person and this person in the hot seat for 20 minutes each for an hour, right? But then you can, we're gonna have some networking after the meetups is basically what I'm saying, where we're gonna use some system. I think I'm gonna use like gather.town, I think is what it's called, where you can virtually walk around a room and join a conversation and chat with, like audibly chat with people and get to know them So that's what I'm putting together, but the meetups are kind of a Minimal effort add-on thing for me. I have to prepare for whatever's being presented But beyond that right and then putting out the videos. So the areas I'm looking at doing are Ruby and Rails JavaScript I keep getting stuff for reacts are probably in a way to do in react. I'm doing code tools like git Docker VS code that's all gonna be one series if people just really want something on some I might split it off If you're interested in helping author some of these videos, by the way, I open to that and I'm willing to compensate you for it. And then the other one is career, right? So, because I have a lot of people asking, how do I go become a senior developer, stuff like that? So I'm working on that. But the other thing that I figured out is that if I'm writing the code to deliver all this stuff, then I'm not delivering this stuff. And so we're moving everything off of stuff that I have to maintain and build. Not everything. Podcasts are still going to be hosted on a system that I've written Because I couldn't find anything else that does it but everything else is going to be on circle.so And you can go sign up because I'm gonna have some free content in there, right? So you can come and join and be part of the you know part of the party and part of the conversation Also all of the preparation for all the podcasts is going to be in there from now on and so you can see what episodes are coming up And if you have a question you want us to ask You can ask it anyway so that's what I'm working on now that's the thing that I'm putting together and you can either message me for an invite link I'm hoping to get it up on the website before this goes live but if you can't find it just email me chuck at topendevs.com and I will send you an invite link so you can join and that's that's pretty much what I'm working on. Tages what are you working on?

 

Nice, I'm working too much. I'm just kidding.

 

I feel that dude, I so feel that.

 

I'm working on a new consulting company that I just started for. Developer Relations, it has no name, it has no marketing, it has no advertising, because a good problem to have, we've got a lot of customers more than we can handle. Well, maybe that's not true, but we've got plenty of work to go around. So I'm working on hiring really just building out a really nice kind of organization where, you know, when companies, developer tools companies have questions about DevRel, how do we do it well? What conferences do we go to? What meetups do we sponsor? Should we even create content, written or video? Like, you know, strategy, they have a place to go. They have a go to, all right, let's call them up and they'll sort us out. And also, like that's strategy, but like my company also just like does the work. A lot of company, DevTools company especially,

 

Hmm.

 

are super understaffed, and they're stuck in months long cycles of trying to hire. And then it's even more complex because they usually want equal representation, so they want to get a good, diverse team of women and people of color and underrepresented minorities and all of this. And so hiring just sometimes gets stalled, and they need videos, but we have no one to make them. So that's what my company does as well. Videos, written content, talks, whatever it is. it's going very well. Thankfully, we've got a lot of very happy customers. And I think the reason I'm working too much is because you know how it like when you start something, you feel like the sense of identity. Like if my customers aren't happy,

 

Mm-hmm

 

I'm in trouble. So I can say confidently that everybody's very happy and there's just more coming every day without any marketing. I'm so really trying to build out a team that can reliably sell. service these people is what I'm working on. But also, I'm working on my finance app, and I'm working on YouTube content. So I decided to be a regular YouTube content creator. I

 

Hmm.

 

have a channel, youtube.com, slash, at tagesk, where I made videos about signals, but also talk about, on Thursdays, talk about web dev topics that are interesting to me and relevant to the industry. This week, we're putting out a video how, I don't know if you all have heard, but CSS has nesting now, just like that, out of the box. Yeah, it's part of, yeah,

 

Ha ha ha!

 

right now. So we're putting out a video.

 

Is

 

I

 

it

 

love

 

in browsers? It's in browsers?

 

it. As far as I know,

 

Browsers

 

yeah, it is.

 

support this?

 

Sure, yeah.

 

That's the last thing. That's the last thing we need. We can burn sass. We can let it

 

So

 

die.

 

we might be able to research for the video that it's maybe under a flag or something, but I did see a blog post from Chrome Web Dev that it's out in CSS. So that's cool. So we're putting out a video on that on Thursday, and that's kind of the vibe. Because on Thursday, we just talk about awesome new stuff that is happening

 

Mm-hmm.

 

on the web. And on Sundays, we talk more about career focus and mentorship and soft skills. But honestly, man, those two things keep me really busy. I'm also writing a book on React.

 

But.

 

things that that takes away most of my time. And I have a family as well. So quite quite of it going on somewhere in there. I have

 

Yep.

 

to find time to shave my head. You know,

 

Yeah, I keep putting that off

 

Thank you. Bye.

 

All right,

 

Yeah.

 

good deal.

 

Yeah.

 

All right, well, let's roll into PIX. AJ, do you have PIX? PIX.

 

So

 

Thanks.

 

if that spec is finally completed and approved,

 

Yeah,

 

and

 

it is.

 

it's not just Chrome saying, we're implementing a draft of this, and maybe or maybe not, but it's approved, it's happening, it's done, it's a done deal, we can count on it being available. I am gonna look so forward to using that in about a year and a half. I'm gonna look so forward to using that in about a year and a half. I'm gonna look so forward to

 

Yeah.

 

using that in about a year and a half. I'm gonna look so forward to using that in

 

No,

 

about a year

 

as

 

and a half.

 

of

 

I'm gonna

 

after.

 

look so forward to using that in about a year and a half.

 

Dude, as of five days ago, it's been shipped, and I'm looking at my browser right now, and it says it's supported.

 

That is sweet.

 

You can, on browsers that are not supported, you can use app supports. You can use the supports thing to check. So anyway.

 

That is so cool. So I'm gonna pick that first and foremost. I've been waiting for that for a long time. I don't really do that much front end, but that is one of the things that's the only thing that I think that CSS needs as far as I can tell from my conversations with people that keeps people in transpilation tools for CSS with a good excuse. So with that landing, we should be able to kick the transpilation on CSS to the curb and use the browser. And that sounds amazing to me, Tailwind is now a big thing and people, I think I kind of get it, but it's basically, it's every common option you'd ever want in a big list of 50,000 options, and then it just selects the ones you actually use to include in the CSS. It's like, I kind of, is that what Tailwind is? Did

 

Oh, it's way

 

I do that

 

more

 

justice?

 

than that.

 

Oh no,

 

We should do a whole episode

 

oh no,

 

on Tailor. I would

 

oh no.

 

love that. We can just debate, okay?

 

But I do have a couple of, non-spontaneous pics or at least less spontaneous pics if I can find out where the little thing went here. Okay, so, call bags, I'll link to the presentation on that and the spec. The presentation I think really did a justice although I think you need to watch it through because I personally am interjecting with questions and as those questions are getting answered and the slides are continuing, my... because when I first looked at it I was like, ah, you know, the first couple slides. And as, you know, so, but I'd recommend anybody that's interested in that kind of stuff, whether you're front and or back end, I think this is, it's a design pattern. It's, it's a spec. It's a design pattern. The implementation of it, you could write yourself if you just wanted to bare bones thing in something like, I don't know, he fits it on a slide. So, but just like Douglas Frocker fit an entire promise implementation on a slide back in the day, but then there's a lot of extra stuff that if you want it to be nice and yada yada. Anyway, there's that. Also, I'm gonna pick Breath of the Wild because here's the Kingdom's coming out, which I'm also gonna pick. And, well, I can't pick that yet because it hasn't come out, so I don't know. But I'm playing through Breath of the Wild again because my daughter started playing it because she just basically picked one of the cartridges at random and stuck it in because it had a pretty cover on it or something. And so that got us kind of playing it as a family again. And, oh my goodness, I've spent over, Definitely over a hundred hours probably over 200 hours very likely over 300 hours in that game playing through it again And I am realizing wait. I never turned right here. Oh There's an entire section of the map that I've never explored There's an additional 15 hours of you know if not more than that of just Exploring that I could do in this section and I've heard other people talk about that too where they've put 300 hours into the game and and then they still find new places on the map and new cities and towns and new fruits and new. It's an amazing, expansive game. It beat the completionist out of me because you cannot complete it. You have to live life. You have to spend time with the family, go to work, and even if... Yeah, but Breath of the Wild, it's a phantasmagorical game. And I was kind of bummed about Tears of the Kingdom because it's taken so many years and I thought, you know, that flames kind of burn out looking for the sequel to Breath of the Wild and more of it, you know, five years ago or whatever it's been now, six years ago, maybe they're not looking for that now, maybe the single just flopped. But for anybody that replays Breath of the Wild, and just, yeah, I think, I think it'll renew your vigor if you're unsure about tears of the kingdom, I think it'll renew your, your sense of faith that Nintendo's going to pull it off, it's going to be a success. Yeah, those are my, those are my picks. Oh, and, and the ballad birds and snakes. Still listening to that, just getting to the point where I think President Snow is going to become the President Snow more that we know. But

 

He's going

 

very

 

over

 

interesting

 

to the dark

 

book,

 

side.

 

Hunger Games. Well, he's, he's, there's an event that I predict is going to happen that is going to take him from morally gray to utilitarian. So,

 

All right.

 

but excellent prequel to the Hunger Games.

 

Nice. All right, I'm gonna jump in with my picks here. So the first pick that I have is, I always pick a card game or a board game. This one's a card game. And the name of the game is The Crew. It's this, there are a few of them. This one's The Quest for Planet Nine. It came out in 2019. And it's a pretty easy to pick up game. And effectively what you do is you have quests that you're trying to complete. There are four suits. There's a blue, green, pink, and yellow. And then there's a black suit, which just is numbered one through four. And those are your Trump suit. And what you're trying to do is you're trying to arrange it so that certain people capture in a trick the card that is in front of them, right? And so you lay out the cards for the quest. And then you go around whoever has the highest Trump picks. first and they, you know, and then it just goes to the left, you know, picking which one you're going to try and take. Sometimes you get into some tough situations, right, where you wind up with a card you have to take that you don't really have a hand to be able to do. And so there's a communication mechanism and some other things that make it easier to, to make it through. But yeah. So there are 50 quests. And you know, it's like, Hey, you're communicating. Communications were raised down and so it limits the way you communicate or You've got to fix to this right and so then you just got to capture so many cards or so many cards in a certain order or things like that Anyway, it's really fun. I think we played I mean some of the rounds we did in like five ten minutes Some of the other rounds. I mean there there are only ten tricks So it goes pretty fast You know some of them took maybe 20 minutes it at 1.98. So anyway, it's been a ton of fun. We've been playing it with my sister-in-law and her husband. And so I'll put a link to Board Game Geek in Amazon so you can go get it. But it is, it is really fun. We've really been enjoying it. It is three to five players. So this is not a game, I guess, that I could just go play with my wife on our own, right? We have to have another person. 14 year old. She's 14 now. Math, years, anyway. My 14 year old was playing it with us and she really enjoyed it so, yeah,

 

How

 

just...

 

you for zero wild.

 

I have a 17 year old.

 

Thank you. Thank you.

 

Anyway, but yeah, good stuff. And then other picks, my wife and I are watching Star Trek Picard. We're only like two episodes in, but we've been enjoying that. That's been pretty good on Paramount Plus. And I think that's all I've got in the way of picks right now. Circle.so

 

Thank you. Thank you.

 

I guess is another pick. And just connecting things in, Zapier to manage a lot of the stuff in Circle.so, so I'll pick that too. All right, Tejas,

 

Hmm.

 

what do you want to pick?

 

I love picks. So I have three things I wanna pick. They're three different things. They're not tech things. I can maybe start with the tech things and then go less tech. First one is flight control. I don't know if you all have heard of flight control, but when it comes to deploying, especially I'm thinking of AJ who's starting a hosting company, like flight control is the best way to deploy on AWS that I found. Like you literally, so how it works, right? You sign in. wire up your AWS account. And it just like is like a UI proxy to AWS where you interact with the best UI ever. You are your whole team. And behind the scenes, it kind of just like does AWS thing. So you get AWS infrastructure, but like with nicer UI and UX. And it's so needed because the AWS console is painful, but also working with Terraform and Pulumi's, like AWS is never easy from what I hear from the community. And so something like flightcontrol.dev makes me very excited, especially as somebody who cares about experiences a lot. That's

 

Mm-hmm

 

pretty cool. Second pick is a conference. I go to a lot of conferences and I have to shout out a conference called WorkerConf that is the sister to another conference called AgentConf. But AgentConf, I mean, it was in February, it was incredible. It's two days of talks and two days of skiing in the Alps with speakers. So the counterpart to that, the spring version of that, worker conf, I guess the summer version is happening in September. And I think that is a pick because it's, so again, it's similar concept, one day of JavaScript talks or one day of talks

 

Mm-hmm.

 

and the next day is like hiking. So all of this is in like the Alps. So

 

Oh

 

in the

 

nice.

 

summer you can't see, but you like mountain bike down. I was there last year and Michael Arnaldi, who is he does work in the functional space, had a BMX on the way down of the mountain and had a big fall and flew and scraped. There was a whole thing and we grow together through injuries, but

 

Ha ha ha

 

also through... But it's one of those things that you go, wow, did you really spend your conference mountain biking? Yeah, so that's a cool pick. And then the

 

Nice.

 

third pick, probably the least tech is my favorite TV show of all time, whose new episode is out today yet seen it and I'm kicking myself the last of us on HBO. Oh my god. Like this is, there is no better TV show that I've seen. Like I don't know if you all have watched

 

Hmm.

 

The Last of Us, but as somebody

 

I haven't.

 

who has played, dude, I've played the PlayStation game, which is one of the best games ever made. And then Sony, the same creator of the game, makes the TV series. Like I've never seen a TV show executed this well and also this crew to the source material. really into the last of us right now on HBO. Yeah, those three,

 

Oh

 

whoo.

 

nice.

 

I'm so like, I'm so like invigorated just talking about these three things.

 

Awesome. Alright,

 

Yeah.

 

one last thing. If people wanna find you online, where do they find you?

 

Good question. They find me on Twitter.com slash Tejas Kumar underscore. They find me on YouTube.com slash at Tejas K. Tejas is spelled like Tejas, you know, like Texas. Anyway, that's where they find me. I'm also on LinkedIn, but I mean, you know, I don't, I don't know that people want to go to LinkedIn to find me.

 

All right, very cool. Well, let's go ahead and wrap it up.

 

All right, man.

 

Thanks for coming. Till next time, folks, max out.

Peace.