Hey, welcome back to another episode of JavaScript Jabber. This week, on our panel, we have a j O'Neal yo yo yo, coming at your live from the Is my audio in sync? It looks like it is. That's a new place. I haven't heard of that place before. Yeah. Well I was on the boot dot dev podcast and when it got released on YouTube, I'm like half a second off. Oh yeah, it looks terrible and I was trying to figure it out. And as far as I can
tell, my audio is in sync on this end. And look, I can see lag too, now that you say it, Yeah, there is a slight lag. Really you're looking for it, you can see it. Well, that's what we need to know because I can fix that extremely easily. I can fix that with Okay, is the lag better or worse? Not, bab, that's the same. How about now is it is double shooting live on the show? I know, yeah, I think it looks
better now. I think yeah, okay, deal a right hundred millisecond to like, this is how the sausage is made, Yes, this is how the sausage is made. Coming at your live from how the sausage is made, I think there is still an I would add another one hundred millisecond by the way, all right, thanks, all right. We also have Dan Shapier Hey from an Israel still at war, Steve Edwards Yo from I'm only one yo, not yo yo yo from uh that's very foggy Portland area where
we need more snow. Yeah, I'm Charles Maxwood from top End Devs and I'm gonna tell you all to go over to top endevs dot com slash calendar. We have a whole bunch of stuff coming up and I'm super excited to be uh working with folks to help them get ahead and figure things out. So yeah, this week we're going to be talking about typescript and JavaScript.
And Dan, you've done a whole bunch of Twitter polls that you wanted to talk through, and I think that's kind of an interesting thing that you're doing there. Do you want to give us a little bit of backstory though on what prompted you to ask these questions and why these particular ones. Yeah, Well, as you said, over the past couple of weeks, I've been running a series of polls. They're actually fairly easy to find on my account
because i've more or less phrased all of them the same way. All of them start with a question what kind of a JS slash tsdev are you? And then I pose a particular question and we will go through the list of
questions. Now. The reason is that, as we know, and as AJ loves, there are multiple ways to do anything in JavaScript, and over the past number of years, the number of ways has been steadily increasing, and all the tooling is also influencing the way in which we're using JavaScript, and it kind of made me curious about, you know, our developers primarily using the new ways the old ways. I've seen I've been surprised by some of the things that I've seen people do. You know, I review a
lot of code. I've been surprised by things that I've see in code. Now, you know, we've got tools like Prettier and whatnot to kind of rectify a lot of the you know, various discrepancies that creep into our code.
But be that as it may, I was really interested in, you know, how people, you know, what are their default preferences as it were, you know, And so I started running these polls just you know, various questions that popped into my head about the ways in which people are using JavaScript or typescript or both, and sometimes I was surprised by the answers,
sometimes less so. And I thought that it would be a great topic to discuss, you know, especially in this episode, which we are recording on January first, So it's kind of like the beginning of the new year and trying to kind of take stock where we all are as web developers or JavaScript developers. So, as you said, I've ran all this whole bunch of questions. I doubt that we will have time to go through all of them, but we will see, you know, maybe we'll have more for
an additional episode. Maybe I'll run I'll have ideas for more questions to ask following this episode. But I've copied all the other questions and the answers that I got. I didn't organize them according to the order in which I asked them, because that was pretty random as things occurred to me. Rather, I tried to group them and also kind of sort them from the more general, you might say, to the more specific, so we will see how
it goes and how farther far down the list we can get. So the first question which I asked, the first question on the poll, and one of the questions that got the most votes, it got something like three hundred and seventy six votes, not like exactly, and the question was about the usage of you might say, typescript versus JavaScript. So I basically gave four options typescript without any, typescript with any JS doc, and JavaScript without any
explicit types. Now it's important to kind of emphasize that when I'm what I meant by typescript without any is not that there's absolutely positively no use of any anywhere in the code, rather that then an effort is made in order to get rid of any as much as makes sense. So it's about people who take a more strict attitude towards typescript versus those that take a more relaxed kind of attitude towards typescript. But you might say that both these groups actually use
typescript. In fact, I might argue that anybody is using jastock is effectively also using typescript, just with a different syntax and different tool chain. And the makers just felt would agree with that, Yeah, for sure. And it's also worth mentioning that, you know, one of the Twitter brew ha haas that we had back in twenty twenty three, you know, so long ago was the one started by Dagge about whether or not using explicit types is
a good thing or not. And you know, whether we should be just using javascripted dynamic types or should we be you know, converting to static typing as much as we can. And it's important to emphasize that difference between uh a Dhege takes take and the one taken let's say in Spelt, which you mentioned where they they ditched the typescript syntax, but not the typescript approach because
as as Steve said, they embraced jaystoc. So if we go, if we look at the results, we see that almost fifty five percent use typescript without any then another, yeah, how do I do that? Is there? Oh? Yeah, a present that's the one? Okay, sure, screen, Okay, just keep in mind that most of our audio only, so we need to make it friendly to that. Yeah, obviously, here we go. Can you see it now? Nope? I got to add it to the Oh there we go. Good deal. Okay. The only
problem is that then now I don't see you guys. But you know, be that as it may, it can be a good thing. Yeah. So again the numbers are fifty five percent almost used typescript without any, twenty percent used typescript with any, another fourteen percent use JS stock and there and then and then percent just use JavaScript. I think I vuted in this one, and I think I was the last because I've just I've been too lazy
to really deeply go for any of it. So you're you're just using JavaScript and benefiting from the type information that the VS code can provide for you regardless, because yeah, basically for the libraries and whatnot. Yeah, but you also have to understand that my contract is a Ruby contract and so right, so a lot of those people are probably not writing full stacked JavaScript, right, They're they're doing something where hey, you know, it pulls in the
JavaScript stuff and it does the JavaScript stuff. M Does that make sense? Yes? It does so, And and you know, if your usage of JavaScript is kind of minimal, and especially if you're working solo, it makes a whole lot of sense. In my opinion, I once tweeted, joked or shit tweeted or whatever you call it, that my optimal use of typescript is everybody uses typescript and I just use JavaScript and benefits from everybody else's hard
work. So I totally get it. And most of the organizations that I see using typescript actually are you know, multiple developers working together on the same code base. It could be like five people, it might be fifty people. And in those environments it makes sense to be as strict as you possibly can about stuff well the moment you have to refactor something. Okay, first of all, I'm not talking about typescript, I'm talking about types. I'm
not even talking about types. I'm talking about tooling. Because all of this is completely it really is just completely bogus, entirely because there's no such thing as types. There's only tooling. Once it runs his machine code, the machine runs whatever the machine code says. The machine does not care about types whatsoever. That's how we get all the security vulnerabilities, uh in memory corruption and and you know, all of that stuff, right, because the machine
doesn't know what types are. The types are in the tooling, and the Typescript checker is probably the best tooling that we have in JavaScript. I think we could have something way better. I think it pales in comparison to what somebody just looking at JavaScript as a language could come up with if they had the resources that the typescript team had, Right. But jas doc and the typescript checker gives you tooling that lets you know when things are out of alignment.
So you change you missed, you misspell something, you misspell a property name, you get the spell check on it. You you need to change the name and type of something. Say that. Know, you did the dummy thing and you put in as a float, but you realize, oh, that should be a string instead, because it's money and money and floats don't mix right, and you know, so you change it to a string. It gives you that capability to get errors where you forgot something, and
I think that's really where the core value of it is. Well, I have to say first of all that these days, if you're using doing money in JavaScript, you should be using like a big int rather than strings. Oh sure, pardon my French. Yeah, but it's interesting that I agree with the gist of what you said, but I do disagree with some of the details. I think you're correct about the run time carrying, you know, not caring that much about types in terms of the machine code, although
you know it does. You know, these days, if used to differentiate between floats and ends and stuff like that. But the types in many programming
languages do determine the code that gets generated. It's interesting that in the typescript JavaScript combination, you know, all the type information is effectively jettisoned, and then the JavaScript engine kind of needs to infer the stuff dynamically at runtime and generate the code based on that on what it actually encounters and sees, and totally disregard the information that it had probably you know, probably correct information that
it might have had in typescript. Yes, but if you are using and again not typescript, but if you're using JavaScript types and you're using them consistently, if you're only using you know, if you never switch a variable name between what type it is, so you do strict typing, and then you also use specific types for specific purpose strong typing, then you will when the
when the JIT optimizer looks at your object. If you provided the object that you're going to use from the start and you use it the same way throughout, then it's going to be optimized. If you're stretching up the way you're using it, it can't optimize it. Again, I'll slightly rephrase, you're I if you are consistent in terms of the type information, you're making it much easier for the JIT to optimize it. It still may not optimize it. For example, if it's only run once, then it might decide that
it's just not worth the effort. But but yeah, by by doing things poorly in terms of type consistency, you're effectively preventing GIT from optimizing it, even if it wants to. The Other point that I wanted to make is that I don't know what surprised me more. Is was it the fact that eighty eight percent effectively used typescript or that twelve percent don't. Well we had a comment somebody said that fifty percent is lying, and I I'm gonna agree
with them. Well, just to back up, you know, you said that typescript with any is or without any is, you're making an effort to minimize any But I don't know if I get that from this question. So oh, I added it in a follow up comment. I should have probably specified it more explicitly in the original original question. But if that's the case, if people read it to be, you know, really without any than fifty five percent, Yes, it's very optimistic. It is very optimistic.
Yeah. Yes, from what I'm seeing in the real world, then there's much more use of any than we would like. By the way, Ah yeah, I remember one more thing that I wanted to say about what you mentioned before a J. I actually think that the Typescript team have done an amazing work of corraling what is likely the most dynamic of any of all dynamic languages into some sort of static type system. You know, JavaScript was not designed with static typing in mind. This is not okamal, this is not
Haskell. Uh And being able to retrofit a sane static type system, you know, you can argue the same part, but you know, being able to retrofit something like that on top of JavaScript is pretty amazing. I'll give you an example. Think about a method like document dot create element. The
type returned depends on this value of the string passed into the function. So you know that's something that's really kind of difficult to do if you think about it, you know, making the return type conditioned on the value of the
argument. Well, I think I think this is where languages need to go, and this is one of the things that ZIG has maybe not pioneered but advertises there's no reason that your tooling shouldn't be able to look at your code and effectively run whatever is runnable at dev time, Like it shouldn't have to wait until its machine code to be able to understand, Oh, this string,
it's obviously the word div you know. So I'm not as impressed by that as I am disappointed that it's taken this long and has so few implementations. There's a whole other topic which I think is beyond the scope today,
which is about the fact that typescript really has effectively like two levels. There's the level of usage by most application developers, and then there's the level used by library creators, which is much more difficult and is much more use of things like generics and stuff like that in order to make the interfaces as type safe as possible, and sometimes that does require a lot of know how an
effort. But again, I think that kind of goes beyond the scope of you know, how much we want to talk about that particular question, otherwise you'll never get to any of the others. Yeah, but so to that end, did you hear about a floppy bird being implemented in Typeescript? Well, yes, I did. And it's not surprising because in order to do. You know, once you introduce generics into the type system, you've effectively made your type system a programming language. Yeah. And by typescript I meant
not typescript, but type the types of type. Yeah, the typescript types. Yeah, the type. Yeah. I've seen similar things, by the way, done in for example, in C plus plus once when C plus plus got generics, the C plus plus template system. Because again, once you throw in generics and and stuff like that, and effectively it becomes a programming language. You can start doing conditionals and loops and from that point on, you know you're after the races. Okay, next question. The next
question was, and here I need to thank a few people. You know, we will link to I won't try to read the names. We can link to the to the actual list of tweets and the people can see it. Basically, it was to see whether or not people are using semi colons or not, because again this became a whole Twitter debate all over again. Surprisingly so I really didn't expect it in twenty twenty three, but here we are whether or not you use semi colons at the end of JavaScript statements.
Now, obviously we've got tools like prettier that can add it or remove it depending on your preferences. My question was mainly about what is your preference, what do you prefer to do, how do you prefer to write your jobscript code? And I'm happy to see that the majority prefer semi colons, because that's also my preference. Anybody here likes of, you know, not using not putting in semi colons explicitly something from the PHP world where they're required is
to sort of have it anymore for me. It for me, it just makes neater and easier to read code. You know. That's and there's times where code won't have a semi colon, but that's pretty rare for me. Yeah, at the risk of dragging DHH back into this, so most of his JavaScript code samples don't have them, which is kind of funny because I prefer putting them in. I get that we have automatic semi colon insertion and other things that make it so that, you know, generally you don't have
to put them in. I just I don't know for me, it's kind of just an explicit hey, you know, anyway I put them in I'm actually I feel like seventy percent right here. Yeah. My take on this is that, again, it's not that semi colons are optional in JavaScript.
It's that we have asi automatic semi colon insertion, which basically means that the JavaScript parser parses stuff errors out because there's a missing semi coolon, and when it does, it catches that error and then tries to figure out where's the most logical place to insert that missing semicolon. And I don't like my tooling doing guesses about, you know, where semi colons should go. You know, I like magic in my code, but not this kind of magic.
That's one of the things that's nice about Prettier is when you accidentally forget a semicolon or whatever, Prettier reformats your code in such a way that it is clearly obvious that the structure of the code and the way it's executing has changed.
But I will also say one of the reasons that I'm against not using semi colons is that they are required because there's a list of edge cases that you have to be aware of, and you can either choose to just always put a semi colon, or you can carry around in your head that list of like five or seven checks, and then always be thinking about, like, every single time you don't insert a semicolon, is it breaking any of these five or seven rules? And if you are willing to do that mental
gymnastics, then you don't need semi colons. However, I've found a very very simple list of rules that I believe also would eliminate the need for semi colons, which is if you either all capture the result of a function or use the keyword void to explicitly disregard what the return of the Java and JavaScript
are the same. I knew it. And you know, if you never do something that requires parentheses, uh in the order of operations fashion, you know, like if you never if you always split multiplication in addition onto two lines, or you know, something like that, anything that would require parentheses to be able to yeah, and be careful of the return keyword and other various rules just easier to semi colons. Uh yeah, Yeah. I agree with the tooling that we have, but I I believe that we could have
a a version of JavaScript that doesn't require semi collins. Oh, which would be nice if we could. If we could get there, but it would require it following other rules that people anyway, Yeah, it's called python. I was I was actually gonna call it ai script, but there we go. Yeah, exactly. Okay, moving on to the next one. Another question about how people write, or style more precisely, their their JavaScript code.
And this one is about how do you write a named function? And the two options are either to be old school and use the function keywords, So let's say it's function foo open parentheses, bar close parentheses, and then
you know, open curly brackets and so forth. The other option, which I'm seeing a lot in code these days, is using an assignment of the function expression, so you would do something like constant fou equals a bar arrow and then the curly brackets, so it's assigning function expression into an named variable or identifier more precisely. Now Here it was fairly evenly split, but still fifty five percent preferred the good old fashion function keyword, which I'm happy to
say is what I also prefer. And by the way, an important point to make here is that when I look at the code base, if it doesn't use the approach that I prefer, I don't change it. I maintain consistency with a code base. Wow, that's very mature review. I know, Dan, I know, I have to say the readability wise, I prefer the bottom one, but I am freaking lazy, and so I very often do the top one. Why just a macro like if you want to
be lazy, be really lazy, like use the tools. Why are you typing out the whole word cost when you could just type fn and tab. Now I feel bad, to be honest, I really don't know why people preferred the assignment of the arrow. You know, maybe it's look it. There is the one benefit which or there are a few benefits. First of all, it does explicitly make the identified immutable, which is probably what you want in a function in like ninety nine point nine percent of the time.
Another advantage is that you don't that this is not bound, which is again is what you generally want these days. Uh. And another advantage is that you don't there's the arguments object doesn't exist, and the argument object is something that you probably don't want to use anyway these days. Other than that, it's I don't see like it's it seems less readable to me, like being saying something is a function is a much more explicit way of saying something is
a function, and I like my god to be explicit. The other thing is hoisting. I like hoisting with with the assignment. It's you know, it's not hoisted, and you can get into trouble in unexpected scenarios. What do you think about exports dot foo equals or exports being a stand in for the larger object people dot get name equals, et cetera. I'm not sure I follow. Well. Most of the time you have a function, it's not an object, right, so you just no, not necessarily a lot
of My code just has a lot of exported functions. Not necessarily a lot, but uh, you know one or more exported functions from a fire, from a module. Right. So what I'm saying is you just assign the function to the object that gets exported. No, I use the export keyword. You can't so your then so you can do structure. No, he's just using common JS. That's that's the thing. It took me a moment
to realize what he meant. But even if it's not common JS, I mean just having you know, whatever object you're exporting be the thing that you attached. The functions to, But why why not just have export on the functions or on the identifiers as you know, as you can these days in modern JavaScript. Well, because then you have a lot it's just a lot
more to parse. It's a lot like if you try to grap through the code, it's a lot easier to see the get name function attached to person than it is to see a bunch of get name functions across the code base through the different you know, like there's a get name in person, there's a get name and dog there's a name. I get what you're saying things.
Yeah, I get what you're saying. The way that I deal with it is, first of all, that's the kind of the First of all, the reason that I like hoisting is that I put the exported stuff at the top, so it's not as if you're likely to you'll see something exported and then a lot of unexported stuff and then another exported something you know as soon. So that's one thing. Another sting, just to back up for
people who are really new to JavaScript. So what hoisting does is if you declare a variable, it'll move it to the top of your you know when it does it stuff, And that way, you can put the exported stuff at the top. And since you have by the property of hoisting, anything you don't declare lower that's going to be used by the stuff you're exporting will
get moved up above. Right, it's available to the things at the top exactly you haven't declared it yet, exactly, assuming you use a function keyword right. And so that's that's one. Another thing is that I tend to keep my module small, so it's not as if I'm going to be exporting one hundred things out of the same file. Again, unless it's like this special like you know, some people like coalesce a lot of the exports like it into the like sort of an index file at the root of a library
or something, so to make it easier to import things. But for most actual implementations, I don't export a ton of stuff, So again you don't need to scan an entire and a large amount of code just to find all the exports. So but but I do get what you're saying, AJ there is merit in that, you know, if if if you're exporting something that looks that feels like an interface, it makes sense to like put it all
within an object or something. I just just so you can see what's public at a glance, and when you grap through the code, you can easily find like, show me everything, show me all the methods that are exported from person at a glance, I can just grab person dot right, and you also can get the potentially easier completion. I don't use completion, but
maybe so it takes too long to pop up on the screen. I can finish typing it by the time we did have a comment here, And I think it's an interesting kind of I know you're talking about name functions here, but and I'm sorry if I butcher your name. Bollogi, Ballage, Jaco. Anyway, he says good old function every day all day. The only time I use the aero function are in callback. So I guess the question that I'm aiming at here is do you ever use aerow functions for a function?
Or for sure the name implies the describes their use. There are function expressions, so whenever I need a function alambda effectively within an expression, I
use arrows. So you know, I'm a big fan, for example, of chaining, you know, using stuff like map or filter, stuff like that, and in those you know, unless it's some sort of a reusable code or really complex let's say filter that I you know, you probably don't want overly complicated filters and their functions anyway, but if but otherwise, I definitely use function expressions there or lambdas, and then I definitely use arrows. I never, I never. You know, you can use the function keyword
for lambda's. You know, that's the old that's the old school way of yeah, exactly, I I don't do that, okay. So the problem with that, with the the lambda expression style is that the opening and closing curly braces become ambiguous, and so it's very difficult to tell whether you're returning an object or whether you're defining a block. That's that's my beef there.
I've had bugs pop up with that multiple times. Yeah, it's always a block, and if you really want it to be an object, you need to surround it in parentheses with yeah, so then it looks yeah anyway. Yeah. Yeah, So I'm I'm hard against the implicit parentheses. Mhmm. Yeah, but again this has to do with the whole expression thing that it's you know, but yeah, I can see your point. You know, nothing's perfect moving on to the next one. I was just I was just
curious how people use you know, how people write strings these days? Do they use single quotes, double quotes, backticks? What do they use for simple strings? And not surprisingly, the majority prefer single quotes. It's not surprising to me because why press the shift key when you don't have to. I looked at that one and I was trying to decide why anybody cared.
Oh, I was just curious. You know you do you by the way, Interestingly, in the old days of JavaScript, you know, like I'm talking like fifteen twenty years ago, is I recall, most people did the double quotes, and it's and it's kind of changed over the past decade or two from what I'm what I experienced. So I write the single quotes, but I commit the double quotes because every time I write single quotes, it
just gets transpiled to double quotes with prettier. The reason for that is that in every other programming language, single quotes are constants and double quotes are expressions. So I tend to only use single quotes intentionally when it's something that is a constant value, and I use double quotes in general because it's because usually you're doing expressions, you're not doing constants. Well I'm not sure what you mean by expression versus constant really yeah, never mind, Yeah, I can't
say. The difference is is that you can interpolate within double quotes and you can't within single quotes. Yeah, so Ruby double quotes are like the backticks, aren't they kind of like kind of but yeah. But but the thing is is that people try to make all kinds of arguments about like performance and stuff like that, and I just haven't seen anything there the holds water. So that that's why I'm saying. You know, if people look at it and they know it's a string, then why why do you cat? I
will make one more, the one real. There are two reasons I initially when I got into JavaScript, I initially tended to use double quotes. Was because I come from C C plus plus and in those languages, double quotes are zero terminated or now terminated, and single quotes are not. And usually you want the string to be no al terminated usually. So yeah, now, the only vulnerabilities you definitely want the exactly now the only comment. I'm
not really surprised that hardly anybody chose the backticks. The only thing that's kind of surprising about that is that we will see later on people do like backticks for template expressions. Yes, and uh. And it's kind of funny that you if a string becomes templatet and a template expression, which it might, you need to change the quotes. And then if it stops being a template expression for some reason, you need to change the quotes again rather than just
leave them as they are, which works. So you could just use backticks everywhere, but apparently people don't like that. Can't You can't? Actually, so why I was actually on full backtick everywhere train for a while. You cannot use backticks for a key name. So if you were to an object and you put double quotes around you know, name and then colon double quotes AJ, you cannot do backtick name colon backtick AJ, you can't do that.
And I think this just goes to I. This is very confusing to me because we have a template syntax for keys and an object, which is to put square brackets around it, and to me it seems I guess they were standardized at different times, Like why this is seems redundant? And silly. We should just be able to use the backticks as the template expression, but instead, if it's an object key, the template expression is you put
brackets aroun round the variable name. Another interesting thing is that JSON uses double quotes. Yes, that's sewn me off before more times, and I care you remember. Yeahah, I think everybody NPM install fixed Jason, and it'll usually get picked up by your editor automatically. And then when you're editing Jason and you put a single quote by mistake, it'll just swap it to double quotes. It'll also deal with the trailing commas and stuff like that. Yeah,
that's the other annoying thing. So my rule DAN is generally default to single quotes everywhere double quotes if I have to quote something inside a single quote, like say an attribute inside of a template like an abuse single file component in the template portion, and then the only time I ever find myself using
backticks is when I needed to do a template string. And the example that I've been using a lot lately is if I'm defining a poster at get url within my view component and it requires a dynamic value like an ID value, you know, as part of the string or something dynamic, and I use the backtick with the dollar sign curly brackets around it. But general rule is single unless I have to otherwise. So the vast majority agree with you,
Steve. And that also exactly goes to the next question on my list, which was about building a string from a static value and the dynamic value. So would you write greet equals hello plus name or greet equals backtick hello, dollar curly bracket, name, curly bracket. And it's amazing to see how popular template strings have become. You know, people have told me that it's not really surprising because most default y lint rules or linting rules. Now we
kind of enforced this approach so people really got used to it. But still it's interesting that so many people just prefer to use the template the template literals. Well, it makes sense. It makes sense because basically you're not switching in and out of your of your context. You don't have to do like hello plus space plus string, variable plus comment and quotes. But you know, in this you can just do it all in one fell swoop with having
to switch context like that. Well, and in my opinion, it's easier to parse because the plus with the quotes, it blends into one line more easily. The dollar bracket stands out more and so you know where you're sticking dynamic values into that sucker. Yeah, and my at least in might id and I'm assuming I use PHP storm. I'm assuming it does the most. It will highlight those colors, highlights your template strings, and they stand out
more easily. So I know exactly what I did. And that's always my issue is how can I make it easier for future me or some other idiot, But it's usually future meet. It's the idiot right to look at this and go, oh, I can easily see what's going on here. Yeah, and the vast majority agree with you, like eighty eight point four percent.
Yes, AJ. So what convinced me on this? Because I've gone every which way with the template strings unfortunately, because there's no consistent way to use them, Like I wish that there was a consistent way to use them, but there's an edge case where they don't work. No, like, no matter which style of coding you prefer, that like you just run into something where you can't you can't be consistent in the way you use strings in
jonascript. But three sixty five JS things, which is well, I guess the Twitter handle is actually at unique name, but this is Corey Brown. He made the argument that it's easier for you and the interpreter because you don't have to worry about order of operations errors or concatenation type changes. So if you think putting the two things inside the template string, you know they're both
going to be strings. So if one happens to be a number and the other happens to be a number, if you use plus, but you were thinking that you were assigning a string, you're actually you know, I mean, that's kind of a weird case. But still, I mean weird cases
are what where the rugs come from? I know. And by the way, one of the most like if if I could have gone back in time and whispered on berendan Ike's years back when he was creating JavaScript, one of the things that I would have suggested to him would have been to use a different operator for audition versus concatenation of strings. Yeah, and this gives you that this, so that's yeah, effectively it does. Yeah. Okay, moving on to the next one, where now we're entering a new topic,
which is array processing. So I asked a bunch of questions about, you know, the ways in which people work with arrays. And the first question is kind of like the most basic one, and which is, how would you iterate over an array in the scenario where you're you kind of you know, in the side effect scenario. So forget, for example, about something
like a map or a filter. Let's say I want to log all the values of an array, or I want to send over the network all the values of an array, or I want to add to the dom all the values of an array or something like that. How would you iterate over the array? The first option is the old school one, which is, you know, I equals zero ie less than a dot length I plus plus. The next one is more modern use of four of you know, it might be four cons to v of A And the last one is the dot for
each and it depends what you want to do. Oh, by the way, is an area like an array? Just kidding you? So yeah, it's interesting. I generally like to use four each. I guess the caveat here, DAN is what you're trying to do as compared to something like a map or filter. Right, you just want to do something twitter item is you don't necessarily want to filter out certain items or only extract certain items from Yeah, as I said before, I like chaining, so when I can
chain stuff, I usually go for chaining. But I explicitly wanted to look at the scenario where you're just looping over the u an array and just doing something with the values, like I said, maybe sending them over the network, or or adding them to the dom or something like that. I've seen arguments that for each is performance inhibitive. But it's funny some of those arguments I see. They say, well, there are a performance here and here,
but the difference is like microscopic. First of all, First of all the different First of all, let's say this, I'll be surprised or shocked if that's the actual performance issue in your code, and it is, you know, prove it to me with a profiler. That's point number one. Point number two is I can't think of scenarios in which four each would actually
have better performance. Because JavaScript, the JavaScript engines actually optimize functions as a whole in most cases, so they either optimize the entire function or they don't optimize the entire function. With each they can optimize the function being invoked in the function expression being invoked inside the four each, even if for some reason
they cannot it optimize the containing function. And in that scenario, you'll actually get the optimization of the code called on each iteration sooner or faster or more easily than with the others. So here's a scenario where that one might actually execute faster. But again, I highly doubt that that will be the performance bottleneck in your code either way. So it's very much more of a stylistic
choice than anything else. Yeah, I just want to chime in here because this was the debate in the Ruby community between the single quotes and the double quotes. If somebody did the profiling and it was like a twenty pcos second difference, right, and so they were saying, see, it's more performant, and I was just like, so what you're telling me is I could just keep being lazy and I'm gonna add twenty pico seconds here or there to my code. Okay, great, I'm just going to keep using the whole
quotes. So what you guys prefer, which which approach to you would you take? I use four each whenever I can, I I got on the four each bus early, but then when promises were introduced, I'm not when a sink await was introduced, eventually I had to get off the four each chasing or the for each bus because then you you you end up with this what color is your fore loop and I just don't want to deal with it.
So I've stopped using four each map filter all it just like I've thrown it all away because it's just not worth the the overhead of having to go back and refactor code for something that is I mean it's one line anyway. Just just saying, yeah, just saying that once a sink iterator for helpers hit the language, whenever they finally do you sorry, you get in there, yeah, and now you need to stop. Well it had it on
looping, yeah, and looping is the topic. All I was saying is that if and when perfectly timed, that's the best one of all ten year run. Uh. If and when sync iterator helpers actually land in JavaScript AJ, then you would be able I don't know if you want to, but you would be able to go back to those US iteration methods. But yeah, you can start doing it right again. It'd be hard it'd be hard to get me back on that bus because iterators introduce their own set of problems.
Somebody needs to go through the the twelve different standard bodies that govern JavaScript and just come out with like a unified standard of javascripts so that we have one language, not a language, and six implementations by different committees that don't communicate with each other. And I think that's what Winter CG is trying to do. Well. No, Winter Winter Oh, that's not exactly the case.
You know, it's an aside. Winter CG is about the library code, so it's about the fetch and stuff like that, not things that are actually part of the language. So part of the language itself is still owned by TC thirty nine and will continue to be there, but we kind of deviated. I have to say that I was kind of surprised that more people preferred four of over four each. It was pretty close. It's forty two percent versus forty point five percent, so it's kind of neck and neck,
but you know, it still surprised me. I was expecting far fewer people to actually use four all. I'm guessing aj that it's probably because of the reason that you mentioned. You know, people really like a sink of weight, and it's much easier to use them with the four of rather than four
each. Uh. And I am happy that people are ditching four I, although you know, eighteen percent using it is still a lot simply because it's it's too much, it's tmi, it's you know, it's it's why are you in the nitty gritty of you know, the index and whatnots teaching your computer science class. But this is again, this goes this goes back to a lack of foresight in these committees. Right, most languages that have an iterator construct it would be four K com a V of A. You can
actually do that here. You can actually kind of do that. You can do constant v let's say v I of n trees, so you can have both the key and the value. Okay, so you can't do four you do a constant open square brackets key comma value of a dot entries. I'm gonna have to try because Yeah. The reason that I do revert back to the I plus equals one loop is because there are occasions where I need access
to the index for some reason. Sometimes it's modifying the original array. Sometimes it's so so instead of keys, you use the you use entries that returns a sequence of arrays of like well tuples where you've got like the first is the key and then the value. Uh, and then you destructure them into a key and into a key and of value. Okay, I I might play with it, but I I just have a sense that something will go wrong there. The one more important thing to mention, of course, is
that four of is not that well. Let's put it this way. All three actually do a different thing. So they're used for the symp for the same purpose or the very similar purpose, but each one really does a different thing. Four I literally you know, goes over all the values from zero to lengths. Four of actually uses an iterator, so it's syntactic sugar for iterator, which is why A doesn't need to be an ara. It can be anything which exposes an iterator. It could be a map or a set
or whatnot. Okay, yeah, because it's not intuitive when it works and when it doesn't, I always convert things to a raise before using it, because I thought it worked in a case where the thing was an object. But then it works in the case so that where A is an object, assuming A is an object that has an iterator. Yeah, and for each depends on what the implementation of for each is on that object. You can,
you know, so if it's standard javascripts. Yeah, again, as I'm saying, you know, I was saying, they effectively do the same thing in most cases. It's just important to understand that the implementation is different. Well to the point of iterators. They feel like, I guess metaprogramming.
It's but that's the thing. But that's the argument we keep having a j I totally agree that iterators kind of failed in JavaScript in that nobody explicitly uses iterators in JavaScript, but everybody, but everybody uses iterators implicitly in JavaScript. First of all, as you can see, almost half the people use four all, which is built on top of iterators. Everybody he uses the spread operator, which is built on top of iterators. So everybody's using iterators
without thinking about the fact that it's iterators under the hood. Sure, but you don't, okay, so, but promises you If you're using a sync and await without knowing the how promises work, you're probably creating bugs in your code or otherwise doing it wrong. The iterator stuff. Thankfully, you don't have to have ever used an iterator explicitly to use the spread operator. I totally agree, and that's a good thing because iterators iterators were meant to be
used explicitly by library creators. Library It's like, you know, it's like as a library user, you just get a nicer interface to the code and you don't need to think about how it actually works on the inside. Yeah. Anyway, moving on to the next one, which is kind of related, it's about how do you concatenate two arrays. The two options are again either go old school and use the concat methods. Yeah, you can see
it here here it is, which is Garcius. So you can either do like A equals B concat C, or you can do the new spread thing, which is A equals open square brackets three dots B comma three dot C closed square brackets. So again, the code is not the same, and there are various edge cases in which the code can behave really differently. For example, what happens if C is not an array, But you know in most case is when A, B and CR are all of them. When
B and C are raised, the results of the same. So it's it's interesting to see, you know, what people use and it's interesting to see that most people eighty percent, almost eighty percent of the people these days now prefer the spread operators inside square brackets the deep side. I love it. I heard somebody give a deep sigh. Yeah, yeah, Why am I not surprised? Why are you? Why? Why are you signing AJ for
a couple of things again? Committees and every other language. If you're doing a spread, the spread is on the right side, not the left side. That is a collect The dots on the left side are a collector. The dots on the right side are a spreader. Okay, synax a side. It just is so much more complicated, Like I don't get the preference for people to use symbols over words when the words are more clear to the
most casual of observer. Right, you do open bracket clothes, bracket dot can cat, B, comm a se, which is an option you didn't list there. But that's the way I actually do it. Just sorry, just just a new array dot can cat and then b and then ce. Okay. But it's just it's just so much more explicit, it's easier to read, and and just I just see so much code that's like aero symbol brackets dots, and it just it's really difficult because people people it's line noise,
that's what you're saying. Line noise. Sure, And and so there's a lot of JavaScript that ends up looking like pearl because it's just like arrows dots, and you know, just like one thing after the other. And I'm looking at I don't know, five lines of code that probably should be fifteen, trying to figure out what the does this even do it it's worth By the way, I had an interesting conversation about this with Evata we've had
from Meta, We've had on the show. He spoke about the vest testing library, and he actually prefers concat, and there are two reasons that he gave. One is that concat works well with chaining, which he likes. Now, of course you can add stuff after the closing square brackets, you can change stuff there, but then the chaining looks less natural because you got some of the chain inside the brackets and then some of the chain after the
brackets. And the other reason that he liked it, which I'm more ambivalent about, and I told him so, is that concat works when c is of value rather than a collection that's bad, that's not good. That's what I think. But he likes it. Yeah. I have gotten a little bit scared sometimes because of concat Yeah, not knowing how it will interpret something, because I want the error in that case right, Like I want to be like, oh, you you have done you put the wrong variable in
here. By the way, once we get through a race, we should probably call it an episode. Yeah, for sure, So let's speed things up. We've got two more things about arrays, which is great. You know, we've got things for next time, and I'll probably have you know, by the way, if either you or the listeners have ideas about you know, additional such polls that I should run, I'd be more than happy to if you just send me a link, you know, either DM me
or send me by the way to all our listeners. You know, if you're not following us on Twitter, why you know, I'm Dance Shapee on Twitter exactly, I'm just Dance Shapiro on Twitter. You know, follow me. I'll probably follow you back, and you know we can all be friends. You like me here on the podcast, you you'd probably like me just as much on X anyway, moving to the next to the next one,
it's how to get the last item of an array. So again we've got the old school approach, which is, uh, you know, just use the dot length minus one inside the square brackets. Uh. Then we've got I'll go to the other extreme. We've got the latest and greatest, which is the at method, and the works exactly like an index, only it also supports negative values, so exactly exactly like slice. So you know, doing an act at minus one gives you the last value. By the way,
I am slightly miffed that it's minus one rather than minus zero. So zero based going one way and one based going the other. Is that what you're saying. Yeah? And by the way, JavaScript does have the concept of a minus zero as an almost distinct value from zero. Yeah. This is one of the underscore versus low dash things. This low dash handles negative zero perspec so so yeah, but anyway, it isn't so the last item
is minus one rather than minus zero. And the and the the kind of the middle of the road is to do, uh, is to use the dot slice, which supported minus one from way back when. Uh. And then you can just destructure the result because the slice returns an array, so it was like zero. If you don't want your code to look weird. Yeah, and uh, I like slice. Yeah. It's the only downside, of course, is we were talking overhead in the Pico seconds. It
actually allocates an array and and copies into that array. So there is a slight edition of my memory allocation. Yeah, exactly, it's gonna be a tiny bit bigger. You know, I've always used slice, I haven't used AT, but just looking at the code, to me, it makes more sense. I like that. Yeah, looking at the difference between slice and splice and and uh yeah, and AT is pretty much universally supported these days. It's it's obviously Node, the this version of Node, and I think
all the all the browsers now support it. So it just works even if you don't use some transportations a step or whatnot. But it's interesting to see that the majority of people fifty five percent still go old school, but they don't know about it. They're finding out about it today on this podcast. Yeah, or when they say yeah, but I get I gave the option on the poll. They could have said, hey, that's cool, I don't use it, but I'll start using it today and they yeah, But
then they would have still answered the pole honestly. Ah, yeah, okay, maybe maybe yeah, I'm I'm I'm with with the act, but but yeah, uh, it's not complicated. It's easy to understand. The only potential downside that I see if it's not an actual array but rather an array like object, you know, those abominations. But other than that, you know, just use that so weird thing. AT is not on Can I Use? Are you sure you can't search for it? Probably because it's a
two letter search term. I'm trying to see if I can get it. Not it is not there. AT is not on Can I Use? So, but I have started using AT for my node code because now it's gotten mature enough in node that I feel comfortable using it. Last time we had mentioned it on the show. It I don't think that it had been in an LTS release yet or something like that, but I believe that now it
actually has been in an LTS release, so it's mature enough. But I'm not sure on the browser side if browser's actually support it yet or not. Oh, browsers too, you know what, Oh, I found it. I found it on Can I Use. It's just it's it's weird. Okay, Yeah, So basically it doesn't work on any of the Asian browsers, So qqby do coos doesn't work on the WIU or on feature phones on Android. Yeah, but you'll probably use it built when you built for those,
you probably use a transpolation. Then you're fine. Well, but if you don't want to use transporlation, if your target is people on feature phones, meaning non paying customers or Asians, then you don't want to use it unless you dresspile. Okay, and now moving on to the last question of the day, the last question in the ARA category. This one is slightly contrived,
or more than slightly, but still it was interesting. Let's say you want an array where the values match the index the index values, so it would be an era with the value zero, one, two, three, four all the way up to nd or what that. So there, how
would you create this in uh in your code? And and it does come up, you know, I've I've I've run into this scenarios where you want it, and it's kind of annoying that the there there's no easy way to get it, although in the spec they are working towards something and we can mention it at the end. But the options that I gave are using. It's you know, I'll basically be reading out code. It's easy using using
RA a dot from where you can provide it with two arguments. One is just an object with the length property that you you know, whatever your end that you want to go up to, and the other is kind of a map function that you can provide this as an optional second argument to the from and you can use it to actually fill in the values into the array that
you're generating. So that's option number one. Option number two is to create you know, you might call it an empty array of length n by just using the array constructor with the value n. Then use the dot fill to actually fill it with something, because it so that it won't be empty, so you can fill it with zeros. And then you can use the map
to actually put the indexes into the array. And then finally there's the old school approach of just using whatever loop construct you prefer with a push to push the values into what was initially an empty array. So yeah, and interestingly, it kind of split almost well almost equally between all those between these three options. Interestingly, ay from is in the lead, which kind of surprised me. On the other hand, only this one was the one that got
the least amount of votes. Only seventy one people voted on this particular poll, and it might be skewed by, you know, the people who tend to follow me, So that's definitely a possibility there. I'm curious what you guys would have used in this scenario. Preferring readability and being that looking at that screenshot is absolutely no clearer than listening on the podcast. I prefer the
obvious. I create a function called range, and then I do whatever I do in there, and I can't remember what I do, but it is a pain in the butt. Yes it's it's weird, but I create a function called range so that it's clear what I'm doing. How about you, Chuck, what would you use? I do the loop and push. I didn't even know you could do the other stuff. And Steve, how about
you? What Jack said? By the way, so again, if you tell I've mentioned before you know, reminded me that an advantage of ray from over the array and then the fill is that you iterate over the loop once rather than twice, because with phil you first iterate to fill it with zero, and then you iterate again in order to fill it. With the actual index values, so it is a couple of picko seconds slower. Yeah, it's interesting. I don't you know, I really don't know what I would
use. To be honest, I probably do what Aj just said, which is why it's really great that JavaScript standard is working on introducing a built in range method so that you will be able to get such ranges, you know, out of the box, built in without you having to implement them yourself. Yeah. So I'm definitely in support of that making it to the standard library. Hopefully it's done in a way that isn't incompatible with all the other
types of loops we do. Let me let me slightly and slightly annoy you. It's iterator dot range, so it will be a method on the iterator object. They're going to force people to accept the one iterator object. Huh. Yeah. But it does mean that it will work with four of, So if you want to do a four I over a range of values,
you'd actually do a four of over a range. And the advantage of doing it over as an iterator is that it would never actually allocate the error, so you could do theoretically an infinite range and then break out of it when you don't need it any know, when you reach the point that you're done with it, I just I've got to ask the question though, because this is this is you know, the thing that people say about iterating, Oh, it doesn't allocate the memory in what real UK use case? Are you
generating such a big number of things? No? Actually, actually that's not the right way to think about it. You either you either generate uh, something that has a limited size, in which case you're absolutely correct, or you generate something that looks as if it's infinite sized and then you break out of it when when you're you reach the point where you don't need to go any further. Okay, I I'm not I get the sense of what you're
saying. I'm not sure where it's of practical think about and think about think about, for example, I've got the sequence of all the all the odd numbers, and then I go as far as I need to go again. It's it's like one of those things that people say for mathematical purity. But okay, show me the use case baby. Ah. Anyway, this is it for today. Uh. You know, we've got like something like five more questions remaining that we can do in some follow up episodes or not.
You know, hopefully I'll have more questions, more polls by then, but you know, like we're we're essentially out of time. So Dan, did you calculate your margin of error for this pulling? No? I did not, but I'll put it this way, And that's another reason to follow me.
I am betting that there's a certain skew in my answers, given that, you know, thinking about the people who follow me, people like Dan Abramov and Mitch Harris and Ryan Carniato and Adiosmani and mischigiol hevery just throwing out the names, you know, So if you want to be amongst that refined crowd, you should follow me, and then you can and then you'll see my polls when they come out and you can participate. All right, well,
let's let's get to some picks. And yeah, by all means if you have a question you think Dan should ask, throw that at him too, All right, A j why don't you start us off with our picks? Okay, picks, dang h. One thing that I was thinking about recently is I got I'm now in the third book of the Chaos Walking trilogy, and that is pretty good. I'm going to be interested to watch the movie after I finish the books and kind of see which trilogy is that Chaos
Walking. It starts with the knife of Never Letting Go. It's about it's about a colony. It's kind of like a space western, but the people have crash landed their ship on a planet and they're not going to be able to get off of it. And then they you know, it's been almost a generation of people living there, and then the next settlership is on its way. And so there was a movie in twenty twenty one that sounds about
right. Okay, yeah, so but the movie got really bad reviews, and I think the problem was that they tried to turn it into I think this is what I heard, is that they tried to turn it into a story about sexism, and it just didn't land with people because people didn't want to get preached at that wanted to watch that movie. They wanted the story. And so a lot of people said that they're really upset that they abused
the movie. Uh, and that the book, you know, if they followed the book instead of creating their own story arc that you know, the movie could have done well. And so That got me interested in the book because I liked the trailer for the movie and I didn't know it was based on a book. But the reviews were so bad that I just didn't go see it. But I saw a review that said, look, you got
to read the books because the books actually are an interesting story. And the reason that it would be an easy movie to turn into, you know, a political message about sexism is because there is a divide the mint. So everybody is infected with a bacteria or some pathogen or or parasite or whatever that, but it only affects males. It doesn't affect females. Oh I remember, I now remember the trailer. Okay, so did they project their thoughts
something like that? Yeah? Yeah, So all males project their thoughts as as something that and the females can sense it. And this goes for animals as well as humans. So the females can sense the males, but the females don't project their own thoughts. So, you know, every impulsive thought that a man has, including about women, you know, like, is immediately available on display to anyone within earshot, let's say, of the man.
And so this creates this rift in society and there is a psychopath who wants does not like that women can hear his thoughts, and the women mysteriously disappear, and that I'm in the third book and that's still not entirely resolved. I'm still kind of waiting for the reveal of what happened. But yeah,
so there is there. There's there's like this psychopath who needs complete control and the ability for others to hear thoughts or like, it's it's it's kind of difficult to explain because of the nature of the sci fi noess of it, but essentially, settlers land on the planet, the women disappear, the men can see and hear each other's thoughts, and a woman is discovered in the woods by the protagonist about like two or three chapters in and and it's
his first encounter with a woman, and and uh, and she is from the other settlership that had been on its way for a generation. So that's kind of that doesn't spoil too much, you know, other than the first you know, it doesn't spoil any more than what's in the trailer for the movie, right, So I'll just I'll just stick with that because we talked about it a whole bunch, and I don't want to take up the remainder of the hour with that. But interesting. Yeah, so Chaos, the
Chaos Wall the book trilogy really interesting to me. We'll we'll see what I think about it when I finished the third book here, but I'm about two thirds through the third book and I'm excited to see how things wrapped together, and I think there's gonna be a twist ending. I'm not sure if I'm gonna like it or not. All right, Steve, what are your picks? Well, before we get to the high point of the episode, I
will I do have another semi legit pick. Some blog posts. I came across a hacker news from Ours Technica and it's one of my favorite topics to read about. And it's titled how Archaeologists reconstructed the Burning of Jerusalem in five eighty six BC or BCE, if you're politically correct. Basically in the Old Testament the King Jim Chronicles. It talks about how Nebbe Canezer came and completely
destroyed Jerusalem in five eighty six. He had captured it and taken off a lot of the Jews to Babylon, but a couple of the kings that stayed there decided to try to rebel and he said, screw this, I'm taking
the yell down. And so he basically completely destroyed the city. And so the article talks about a study that was done there that used analytics of fire and how fire behaves and a lot of the things we can tell now, you know, with forensics, and how what fire did to a building to pretty much nail down the app about that time is when Jerusalem was completely burned and destroyed. It's really pretty fascinating, especially if you're into fire science as
I am. So anyway, we can put the link in the show notes for sure. And now it's time for the Dad jokes of the week. I have been posting for a couple of weeks, sins I've been on vacation, but I think I can dig up a few that are worthy of being quoted here. So, in the spirit of Christmas, did anybody hear about Rudolph's riot on the roller coaster when he went to the amusement park? You
can say he held on for dear life. Now, I am a I think true pizza aficionadus would call me a heretic and shoot me on site for saying this that I do like pineapple and pizza. The pine and swine. Pine and swine aka Canadian bacon and pineapple is for me the best pizza. So the other day I was cooking some but I actually burned it. I found out it was you know, it's called the Hawaiian pizza, you know,
as one of the names. I prefer pine and swine. But in the spirit of Hawaiian pizza, I should have cooked it at aloha temperature. Right. I love the drones. And then finally, apologies to pets fans, but I love this one. When I saw it. Does anybody know why there are no cats on Mars? Because curiosity killed them? All right? Curiosity is the was on Mars. You know, there's curiosity with the other one, oh, Discovery, I think, yeah, something was at
the space shuttle. Yeah that was a space shuttle anyway. Anyway, those are the dad jokes of the week. All right, Dan, what are your picks? Okay, so I've got to my first pick is and despite your frequent recommendations, Chuck, we've not really I've not really been into board games that much. But now, as as a birthday present our kids bought us settlers of Katan. Is that how you guys pronounce it? Uh? And and we've been playing it like, uh, you know, in the
family and it's been lots of fun. I've yet to win, but uh, I'm trying. Uh and uh it's very enjoyable. Uh. And it's a good game. I really like it. So so yeah, we will see how long we're able to persist. Uh. We play it like once a week something like that. We have a game night. And so that's that would be my first pick. My second is, you know, as as everybody in the world knows, there's a war going on here, and everybody seems to be picking sides. And what I've what I've noticed is that
a lot of people don't really have the context. They they don't know the history. Now it's it's you don't have to know the history to have an opinion. You can certainly have opinions about things that are happening, you know, at present, without you know, thinking about what happened fifty one hundred years ago. But I do think that having more contexts usually is helpful.
And in what I would like to pick is this documentary Israeli documentary. So I can't you know, say about it that it's objective, it's from the Israeli perspective, but it does try to be even handed. I have to say. It's a documentary that came out in the eighties called Pillar of Fire. It starts when Zionism started in the like eighteen seventies and goes all the way to the founding of Israel and a bit after that. And there's an
English version that you can find on YouTube. By the way, one big advantage of the fact that it was done in the eighties is that they could still interview people who were there or you know, even as kids. You know people or have you know, deceased since then. And what's really great about this series is that they were able to uncover a lot of original, uh, you know, films from from the various periods. So it's it's really great in that regard, uh And it was, you know, it's
really good. I highly recommend it. So again I can't say that it's like objective or you know, you won't get as much of the error perspective as you would get of the Jewish perspective. But still again I think, you know, they do try to present all the facts, and it's it's highly recommended for anybody who's really interested. So I link a link to the first a link to the search in YouTube that will find it. You will
see like episodes two and three there. I don't know if all the episodes are on YouTube, but I think at least the first four or five are there. So it's as I said, I highly recommend that. And those would be my picks for today. Awesome. I'll jump in here with a few of mine. Let me get that in the comments so people can find it on the YouTube video. All right, So the first one is I am excited to be going to another board game convention. This is my first
time at this one. If you all remember Joe Eames used to be on the show, he and his wife would often go to this one. It's called Salt Con and it's here in Utah. It's up in Davis County, so it's like an hour a little more than an hour from here at the convention center up there, and uh yeah, it's four days. It goes Thursday through Sunday, and it's the same deal as most of the other ones.
Right, You just go and you play a bunch of board games, A couple of my friends are going, so we're all gonna I think we'll hang out some of the time and then just go find fun games the rest of the time, you know, maybe without each other, but it'll be fun. I'm really really looking forward to it. So I'm gonna pick that as one of the board game picks that I have, and then I really do feel like I ought to pick a board game my So we played this
with my kids last night. I know I've picked it here before. It's called Mysterium, and effectively, you've got this ghost who's trying to give clues to a set of psychics regarding the murders that have happened in this house. And then if the psychics all solve the murderers, each solve their own murder, you know, the murder that's assigned to them. Then then the ghost, which is just another player, gives the final clue, which is a clue to the their own murder. Right, so one of the murders of
the murders that the ghost is getting clues to is their own murder. And anyway, it's been a lot of fun to play. It says play times about forty two minutes. I think we've played. Every time we've played it has been an hour, maybe a little longer. It has a board game weight of one point nine, so, you know, it's kind of a
party game, casual gamer level game. And yeah, anyway, the clues are basically cards that have just random pictures on it, so you're trying to the ghost is trying to pass these clues over to the psychics, and then the psychics have to figure out what in the picture would lead them to pick the right culprit, the right location, or the right murder weapon. And yeah, I've been the ghost a couple of times, and I've you know, I've played as the psychic, you know, one of the psychics a
bunch of times. And it's tricky because a lot of times what you wind up doing is you wind up getting a card or passing your card. It has one or two elements in the card that indicate the thing that you're trying to get them to pick up on. But it's got a whole bunch of other stuff going on, right, They're all kind of random, weird, you know cards. So anyway, it is fun. It's a lot of
fun. A few other things I'm just kind of giving people some context for where we're going with Top End devs Now, I want to preface this just by saying I had kind of a major family event happened right before Christmas, and so I have been dealing with the fallout of that and helping my mom figure out some of the fallout from that. And I was going to have all this stuff ready by the beginning of the year, and so I'm playing a little bit of catch up. But by the time this comes out,
you should be able to sign up. You can get there the premium podcast episodes that don't have the ads in them for each of our shows. But the other thing that I'm doing is every month I'm gonna have a producer call, And so if you're if you buy the premium membership, you're a producer and you can get on the call and you can talk to us about, Hey, you haven't done a show on this, or hey, I think
it'd be really great if you talk to this person. Right, So, maybe there's something we didn't cover with Mishiko hevery, or maybe we should get Adi Smani back on, or you know, maybe you know there's some thing that you know is inspired by one of Dan's polls, right, so you can get on the call and you can tell me, I'm gonna invite these guys, but I don't know what their schedules all look like, so I can't guarantee anything that way, but you know, then then we'll get those
scheduled and so you can kind of have a voice in what we talk about on the show. The other thing I'm putting together is I'm putting together videos for be JavaScript and React, and those are going to come out every week. And what I'm doing is I'm just building apps, and then we'll talk about some of the ideas or ins and outs of any libraries or techniques or
anything that I used to build them. So you know, the React ones are obviously going to be React. If it's not React and it's JavaScript, I think I'm going to build a discord bot in JavaScript for the JavaScript one, and then for the Ruby one, I've got a library I want to modify. There are a couple of apps I want to build, and I may or may not build them in rails, so that kind of gives you
an idea. And then finally, if you're looking for content from other experts that you can participate in more of kind of a I don't want to say webinar, but it's kind of a webinar, but it's also going to have a very strong Q and A element to it. Then you can go check out JavaScript Geniuses. I'm doing that for JavaScript and React as well, but you can get the JavaScript Geniuses and you can just show up every week and we'll either do a Q and A or we'll have an expert on or you
know, something like that. So it's kind of like your JavaScript meetup, except it'll be online and we're gonna make sure we have networking events so you can get to know each other because I feel like that's a critical part of having a successful career these days. So anyway, putting all that together, if you go to JavaScript jabber dot com Slash Premium, you can see where to get onto the premium podcast. The other one is called JavaScript what is
it JavaScript Clips? I think is what I called it, JavaScript Clips, and then JavaScript Geniuses and I have the domain, so if you go to the domains, it'll take sign up pages. So anyway, that's that's what I got for picks. Yeah, I don't think there's anything else, so we'll go ahead and wrap it up until next time folks max out
