How'd you like to listen to dot net rocks with no ads? Easy? Become a patron for just five dollars a month. You get access to a private RSS feed where all the shows have no ads. Twenty dollars a month, we'll get you that and a special dot NetRocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey, welcome back to dot net Rocks episode number nineteen forty three. I'm Carl Franklin at amergri Gabel. How you doing, Richard?
What's up? I'm all right. This is weird to be in the twentieth century of shows, but you know, yeah, and so much happened during these years. Yeah, so we'll talk about that in a minute. But uh, how's the weather up there in otter Town? Yea, we gotta break today, little suddy. You know it's it's definitely springtime. So yeah, here too, things are changing.
We had one snowfall, which is kind of normal for the coast, and now it's things are warming.
Up here too, and it's kind of nice. Yeah. I install the camera right outside the studio nice and brought the big screen TV and from the living room, which we don't really use anymore and sort of mounted it right in back of where the camera is, so I have like a digital window out on my outside.
But you can control the amount of light, and so you got control over your space till right, Yeah, exactly.
So it's fun. All right, it's good. Let's talk about nineteen forty three before we do better. No framework going to do that first, sure, all right, Well, from what I know and what I read, nineteen forty three, the tide of World War two began to turn against the Axis powers, with significant events including the Soviet victory at the Battle of Stalingrad, the Allied invasion of Sicily, and the beginning of the Warsaw Ghetto uprising. The word ghetto
comes from Poland. Not a lot of people know that in America anyway. And what's crazy when you go to Warsaw is the chunks of it that are still there. Yeah, the Polish are taken very seriously the ownership of those buildings, and well, it's entirely likely there's no one left alive that owned some of those buildings. They just won't do
anything about it. Yeah, they're holding off on the chance that they could find some relations to the point now where they've built these protective screens up one floor over the sidewalk because there's Yeah, it's the building falling off. They don't want to hurt anybody. Wow, there's still billet holes in buildings in Warsaw from that. At that time, Zootsuit riots happened in Los Angeles. White servicemen and police officers attacked Mexican American youth, which turned that into the
Zootsuit riots. The Harlem race Riot occurred in Harlem, New York after a white police officer shot in African American soldier. In the good News section of nineteen forty three, the Pentagon is completed, the Chinese exclusion acts are repealed. Actually is that good news? Does sound like it? I'm not so sure. But also two things were invented in nineteen forty three that we need to thank the people for duct tape, nice and LSD.
It's funny also when the Colossus computer, which arguably is the first electronic programmable computing device, of course, built Blenchley Park for cryptanalysis. Wow, although that's also the same. Forty three is a year where the contract for ANIAC starts, but they won't get finished until forty five.
Yeah, and I don't know.
This is also forty three was the era of the first generation of antibiotics.
That's right.
Yeah, yeah, so, and there's some funny stories around that, like they found the perfect bacterium for growing penicillin on a cantalope.
I thought it was on an orange randomly. There were are versions there, but the thing they call the golden mold, it was actually on a canalope in Illinois. That's so cool, and that maybe they already knew how to make penicill at that point. But it became the master mechanism destructimyas and was developed in forty three. I think that it was really released in forty four, wasn't it.
Yeah, but that's when it was first developed and it was the first treatment for tuberculosis.
Wow, take a lot of that stuff for granted, now, don't we We share doom to the point where people forget. Yeah, we used to have friends that died. He stepped on a nail. You were going to die? Yeah, and you everybody had somebody who died in tuberculosis. Many people oculosis. It was untreatable, tetanus too. Yeah. Okay, so let's get to better know a framework, roll the music. Awesome, A man, what you got? This one comes from our friend Damian Edwards.
You know him. He's overdue for a show, isn't name? We should totally is. Yeah, we need a little signal, our reminiscence and all that good stuff. So he wrote this tool. It's on GitHub called dot net purge. It's a dot Net tool that runs dot net clean for each target, framework and configuration and then deletes the output directories. Okay. Can be run in a directory containing a solution or project file because you know what disk space is low. No,
I'm kidding. I'm kidding, of course, Damien. That's not the point. The point is you have all these dangling frameworks and tools that you don't need anymore. Yeah, why confuse the issue? Just clean them up, Just tidy stuff up. Yeah, so that's cool. As you can see, it's a it's a dot net tool. It's a command line thing. You can add it to Windows Explore. There's a little registry hack that you can add dot net purge to Explore a context menu. Turn it into a shortcut. Yeah, very cool.
You know, at least it'll it'll it'll help with your large lene you're programming large language model lature is not navigating old files. Ooh, there you go. Yeah. And also Simon Crop was a contributor to that. There's Damien and Simon basically another guy you should probably be back on the show. Yeah, so there you go. Clearly they both had the problem and decided to fix it. Yeah. Maybe it only happens in Australia, though I don't know. I don't know the answer. Okay, he's talking to us today.
Richard grabbed a comment on a show eighteen eighty five, the one we did with Martine back in February of twenty four. We were talking about improving your CSS skills. Yeah, and Vladimir Jirgov commented this about a year ago. Hees hi, guys, long term listening to the show, writing in reference to using chat GPT for creating CSS code. I found this comment hilarious because it was a year ago when we just didn't know. I've recently used the free version of
chat gpt for a small CSS h schmael and JavaScript project. Well, I could say it's pretty good perspectives matter.
I'm an infrastructure engineer recently turned web developer, so my appraisal of quote good CSS code is limited. Nevertheless, chat GPD was able to produce clear, readable, almost eighty percent accurate code. The other twenty percent I compensated by pointing me to the right direction to fix it or just it when I couldn't do it itself.
All this is good. It really blew me away a positively. When I asked to refactor the code, it gave me clear and concise, simplified Yeah, and ask it to comment it as well, that's another trick. Yeah. Well, and again, imagine this is a year ago, like so much has happened in this space in a year. That's the problem I find with chatchipt and things like CSS, because there's so many posts like on stack overflow of people who are posting bad CSS right and saying why is in
this work? And then their discussions and by the time you get to the to the good one, you know, to the solution, it might be three years old. And so there's just a lot of confused CSS on the internet. So I'm probably true for all code. But in general, these tools have moved so quickly, and being aware that we're coming up on a bills and there's some interesting announcements coming, like you know, Microsoft's a tooling company first and foremost, so expect amazing things in this space.
Yep, that's for sure, Vladimir, Thank you so much for your comment, and a copy of music Cobey is on its way to you. And if you'd like copy music Cobey, I write a comment on the website at dot at rocks dot com or on the facebooks. We publish every show there and if I comment there or if you comment there and I read it on the show, we'll send you copy of music go bay.
And of course music to Code by born of a conversation that we had on dot net rocks and it turns out that music at a certain with certain attributes really help you focus, and it's based on science. Was that Dan North or was it Mark Semen? Mark Semen? Was Mark Semen? Yeah? Yeah, So you know, we just did track twenty two. So you can get that track by itself, or you can get MP three flak or
wave collections. Go to music to Code by dot net. Okay, awesome, Let's bring back Martine Dowdin, an award winning CTO ux UI designer and developer, International speaker and author. Martin focuses on web interfaces. That are beautiful, functional, accessible, and usable. She approaches user experience from both art and science, drawing from her degrees in psychology and visual communications. Martin has worked as a developer, artist, educator, and consultants since two
thousand and five. Currently, she's the CTO at Andromeda Galactic Solutions good name where she that's a great name as opposed to like Minutia Incorporated right where she continues to learn work on. Sorry, I didn't mean to make you laugh, continues to learn work on and share her passion for front end development. Welcome back, Martin.
Well glad to be back. Thank you for having me.
Sure.
Yeah, it's great to have you back, and I'm happy to not be talking about CSS this time around. Not that your conversation CSS aren't brilliant. Yeah, but admittedly I think I pinged you saying it's been about a year and I had been poking through your sessionized and saw you doing a talk on promises and I'm like, you know, those things have driven me crazy since they were first talked about in the W three C.
I should talk to Martina.
It's like, as soon as I get that urge, like I want to call you and talk about it we should probably make a show.
So, Martine, what is on your mind these days?
Well, the I've been writing blog posts and one of them that you mentioned was about promises and also made it as a talk, and so I realized when I was I was, I've been working with some junior devs and some dot devs recently, and uh, we were arguing about, you know, better ways to write code and how something should be architected, because you know, de've never disagree on such things.
Never, never, never, never.
And I realized that one one of the one of the guys I was talking to, didn't actually understand what
promises did or how they worked. And so that's kind of what prompted me to write that article because as I did some digging, I realized that not only do it's not as common knowledge as I originally thought it was on how they work, but also that there's so much with them that can be done that like, sure people can remember how to do a dot then or dot catch or maybe even in a sink away, but there's so much more to them than those three things, which is kind of what a lot of people think
of when they think promises, Right, you get your fetch you get your then and go on and go forth and conquer. But there's a lot more to it that you can do in terms of parallelization or how you want things to happen, or if you want, you know, just give me the first response or things like that. And so that's kind of what prompted me to write it.
And just to back up, we're talking about JavaScript here, yes we are. You know, we didn't really introduce the topic unless you read the title of the show, but so we're talking JavaScript promises, and you know this is the way to do one way to do things asynchronously. Right you mentioned a sink a weight, which we do and c sharp all the time, but turned into JavaScript as.
Well, yep, which is it's kind of cool. I just I mean, the thing with them is the I found that the ear handling becomes a little different if you're doing the a a sek away where you have to wrap the trycatch and so on, and then depending if you want to where you want to catch your things
and how ends up being a little bit different. But oh, in all, I find they I personally like it because I find it more readable to just be able to go, you know, especially if you have multiple private promises you're doing in sequence to just be able to do a weight one A wait two, a wait three, And it's really instead of having to do the whole that then that then that then that then I find it less worthy, but it's a personal preference really.
So the whole dot then that that is that the promise syntax like fluent. Is that how it works.
Yeah, So in JavaScript, fetch is a promise. I'm just going to use that as the example because it's the same one I have in the in the article. But you would do like fetch whatever the U R L, right, and then you would do after that you do dot then and then you're going to get the results and
that that's that's going to be a function. So you get your result and you can do whatever you want with that result at that point, right, And you can chain those dot dens, so if you get what you sometimes see is like where it starts, people try to nest the dot dens instead of chaining them, so you get kind of that that Christmas tree pattern like that, but you can just know and the fun thing with that then and it doesn't actually require you to return
a promise. You can put promise one that then promise you know, take my results and then put it in for promise too and so on. But you can very easily, very easily just do some kind of transformation on the data and return that site. Once you're in that that then sequence. It does not have to be a promise. You can do then whatever you want to after that.
At that point it kind of sounds like a task and see sharp the concept anyway, where you know, when you have a promise, what do you do with it? Right? That's yeah.
For JavaScript, the most common use would be for like fetching data, like whether whether it's whether you're doing using a framework or something or you're just doing raw JavaScript. Most of the time it's because you're fetching data that's ninety nine percent of the timeline, it's going to be four and.
You're trying not to hang the UI.
Why you do it right that I send off the fetch you can.
It doesn't matter that more depends on how you're calling the function more than more and where more than the fact that it's a promise. The other one would be to turn that I use it a lot for is to turn callbacks into a promise because they're easier to chain and handle and deal with. I find so like when you're doing an image upload or a file upload and you want to do a preview for it, there's the whole file reader thing, and that's always a that's one of the common ones, or even the set time
out technically speaking, you know, is callback. So like those sorts of things so that I can chain them easily with other things. I'll tend to turn them into promises because it makes my life a whole lot easier than living in and trying to figure out which callback is doing what and going where. And I find them gross personally, But just.
A just a for full disclosure, It's been a long time since I've looked at that kind of complexity in JavaScript. I mean, ever since I found Blazer, I've been as much c Sharp as possible and as little JavaScript as possible, And usually the JavaScript that I'm calling is just something to get something from the dom that I can't get with sea Sharp.
Yeah, dumb manipulation doesn't have too much in terms of callbacks or anything else. They have a couple, I guess, especially when you're getting to events like.
Yeah, window do resize all that stuff.
Or even what a fun one. That's always a h Be careful how you type that in your Google searches everything related to drag and drop because dom drag events can can make some fun fun Oh yeah, fun search results if you're not careful.
Oh boy, yep, Tom drag pictures of Dom Delawi's. So does the fetch approach have an advantage when you want to call off like multiple data sets you want to fetch and you don't really care what order they come back in you're populating different divs kind of thing. Yes, if that word shines.
So fetch literally just goes and gets the data. So if you wanted to call multiples, what you might do is do it in a You could do a promise that all which you would put a series of fetches in it, and it would only return the data once all of them have returned.
That's convenient.
So if you had to get if you needed all three sets of data in order to populate or do whatever you were going to do, that wouldn't return until all of them have returned. Now, the downside is if one of it fails, it fails everything. So that can be good or bad, right, It depends on your use case, but it.
Is nice if you do need three sets and you don't want to wait for each one to come back, to do it that way and they run in parallel and once they're all back, then you act. If you got three different sets that just render in three different dips and you don't care whatever that comes in, can you still use it?
Then you would probably do three. You would do either three functions or three fetches, and then in the response from the that fetch. But what I wouldn't do is try to go a sink a wait for a second and third because then you're literally waiting for a second
and third. Right, So at that point I would probably do either separated into three functions that I would call and not wait on right, or if I wanted everything in the same function, I would do, uh, fetch a dot, then do whatever I'm gonna do, fetch b dot, then do what I'm going to do and do it as a dot. Then structure, because then they're not waiting on each other because JavaScript is going to fire the first one, the second one, the third one because it has the dot.
Then it's not waiting for that to be finished. It's just going to fire and go and move on to the next but it will wait. Where it will wait is to do what's in that dot then then I'll wait for that data to come in. So if I wanted them in peril, well, i'd probably use and in the same function, I'd use dot then and definitely not a sync away because then you're forcing for the way.
How is one doesn't help that there's multiple JavaScript async methods like call there's callbacks, there's promises, there's a sync away. Is that all of them?
Well, if you get into some of the frameworks like our XGS, and you have the entire observable game as well.
React right, yeah, yeah, then is what the other frames will provide you on top of everything else.
And then there's a handful of listeners too, which I think are just callbacks if I remember, well.
How does one do a resilient strategy like we do with poly in c sharp, Like you know, if if a service is down and you call it, how can you do like easing, you know, back off multiple retries that kind of thing. Is there such a thing like that built into JavaScript?
So our XGS does have a if you're dealing with observables, does have a retry function. But you can fairly easily do or retribe, because what you're gonna you're gonna utilize your catch for that, right, So we're either going to do in a trycatch block or as a dot catch you're gonna say, you're going to have a variable outside of that how many times have I retried? And then you can call itself again and increment your retry.
Right.
The other thing you can do in your catch is say, okay, this one's down, give me a different one. There's promise not all settled that you can use. So if you have like say, three three different APIs that you want to hit, but you know that one of them is likely to fail. But if you can get the data, great,
If not, we'll move on, it's okay, situation. Or if you want to handle depending on let's say you've got your three calls, but you want to handle your failures a little bit differently, you can do and all settled. So what happens with the all settled is like, let's say one of your three of them dies in the middle, right, Unlike the promise at all, which goes ahead and and
will throw an error if any of them fail. What they all settled does is it will return for all three a status of either okay or there's been an error, and then if there's an error reason so you can get you can still get your data for say like one in two and then you'll get your error for three. But then you have to make sure in your once you get the data that you realize that it's not
just the raw data. It's got like the value and the status or the value or the status in error depending on So you've got to remap that to whatever you need. But that one's convenient if you have a service that you know is maybe a little flaky, that might but you still want to do whatever you're going to do with the rest of the data, or if you're okay with only partial information. That's one that's that's pretty useful for that.
Yeah, yeah, you were talking about this.
Some of these more advanced features in jabscript promises like all settled that this is where you get some power.
Yeah. The other one if you know you've got that's that's part that I find particularly powerful. The only use case I've ever really seen it used for networking type of stuff, but is the race and where it's like you just want the first one that can get me an answer, get me that one nice. So you can put like, let's say one, two, and three in there, and once one of them fires, you're good. You've got
an answer. You run with it, right, and it's going to give up on the other two, right, So from a speed perspective, that's super nice.
Whether they come back or not, you're just going to ignore the results, right. So, yeah, you've got multiple services that can bring you the result. You just want the fastest one.
Yeah, Now, raise will if one of them fails, it will fail out the same way as promised at all. If you do promise that any it will try until it gets an answer, it will give you the fastest answer that hasn't failed, and it won't fail until all of them has failed. So if you really want, just give me whatever as fast as humanly possible, ignore all failures unless everything fails, obviously, but it's promised that any
which is kind of really powerful. I have not found a use case for that one yet, but one day, one day, I.
Will literally are you know, calling three different services from three different places that are going to provide the same result, and any of them will do.
And I don't care if any of them fail as long as one of them doesn't, right, sure exactly. Yeah, it's nice. Yeah, that is powerful. It's powerful and a bit weird, but you know, well strange. I mean, I'm thinking about the alternatives. The alternative is using sort of round robin dns. You know, if you've got like three services that are all trying to share the load or whatever.
But what you're doing is you're hitting all three of them all at the same time rather than a round robin, So may put a little more load on the network, but you at least get the result that you want.
You know.
Yeah, first, first person to give me a chicken sandwich, I'll eat it.
The other actually, the one of the US because I could think for that would be if you're calling something like from a CDN, so you could call multiple CDMs so that if one of them is down right.
Yeah, yeah, sure you do want that any sense, because I don't care if there's a failure as long as there's one that.
Doesn't fail, right exactly.
Yeah, that's what's important. But you do have to throw the other two chicken sandwiches away, I mean, there isn't if they if you're.
Goin of like, well it would I'd have to double check the network. But the network calls from the browser, but I think it actually abandons the network call, like it terminates.
If it always drops the connection. Well, that's good.
I think I'd have to double check that, and it might that might even be browser specific, so that that would be don't quote me on that one, because I'd have to actually.
Look at that, But that would be smart. That would be, you know, in a perfect world.
In a perfect world. Yeah, because the Internet is perfect, it has yeah never never, and JavaScript is perfect, it has no flaws.
It's the best language ever.
It was totally thought through when it was created, right.
Oh, definitely. I think it took a weekend, right, So let's yeah, Well, let's talk about some challenges when approaching acink JavaScript programming for the first time. What are people getting hung up on?
One of the common one of the common things I've seen when I'm teaching people how to use promises is they'll learn a pattern and they'll try to use it everywhere, no matter what. And I don't think this is specific to promises.
Here's your hammer, find the nails exactly.
They'll learn I go.
Let's say they'll learn a sink await right, and they will regardless of whether it needs to be parallel or not. They'll just like await everything right. And so I mean, in the end it works, and this is the piece. Right, in the end, it works if even if you need it technically to have them in parallel, you await everything you you're gonna you're gonna take a performance hit, but it'll work. Right. So I think those are the most probably nefarious things because it's.
Not like it's broken, and we have the same problems sea sharp Right. Once you learn a sync awight, you want to do everything a sink and don't necessarily need to a perfect example of this is data access right. Data access can be completely done with adeo dot net, which is sort of the lingua franca of dot net, sql access or whatever, and it can all be done synchronously, and it should be done synchronously because there isn't any
reason not to. When you add a sync to it, even though you're not using it now, you're requiring the method that calls it to be a sync. So property getters and setters become more difficult, you know, just standard events that aren't marked a sync that you don't want to mark a sync that kind of stuff. So, yeah, we have the same problem over here.
The other one I see, which is again is a little bit more advanced, but it's the trying to mix and match two things and make them work well together.
So like not realizing that you can fairly easily transform a call back into a promise and then trying to mix your callbacks and your promises and ending up in some weird, kind of weird Christmas tree jumbold mess because you're trying to mix the two or same with So if you're using RXGS and you're using observables in an RXGS chain, so let's say you have your first you know, you get your your calling, your observable you get, and then you're going to do a pipe with your maps
and your switch maps and your all of those things. You can actually return as part of a switch map a promise instead of an observable, and it'll take it like a champion on the output return and observable. So that's kind of but what I see is people not realizing that they can do that and that that promise as long as you're starting with an observable in RXGS, you can stick and promise in the middle or call that's actually to a promise in the middle, and it's fine,
and it'll take it. I mean, you're going to get a one time value. It's not going to be a stream, but it'll it'll work. And so I see some weirdnesses in trying to like shoehorn in various often very creative ways the pieces together with not not quite understanding where they line up and how you can either turn one into the other or where chaining can just work and
doesn't have to. And the other big one is like the Christmas train I talked about before, or instead of dot venning as a chain, they just kind of start nesting the dot bens forever and ever amen, which again works but not ideal and hard to read.
Right right, did you say forever and ever amen? Yes, Hodding Randy Travis, there, I saw what you did there. All right, let's take a break and when we get back, we got some more questions from our tin doubt and we'll be right back. Don't go away. Did you know you can easily migrate asp net web apps to Windows containers on aws. Use the app to container tool to containerize your iis websites and deploy to aws Managed Container
services with or without Kubernetes. Find out more about app to container at aws dot Amazon dot com, Slash dot net, slash modernize, and we're back. It's dot net rock some Carl Franklin. That's my friend Richard Campbell. Hey there, Martin dubtny is here. We're talking javascripts and let's see if you don't want ads. By the way, if you don't want to hear these breakads, you can become a patron at Patreon dot dot Nerocks dot com five bucks a
month and we'll give you an ad free feed. Uh okay, Richard, you had a question, then I want to I have a question to change course. Yeah, well, just before the break Martine should have just dropped RxJS in our laps. I'm like, wait what yeah?
Uh, Because I always thought that the reactive extensions were important before promises had been standardizing the browsers, like reactive js came along like twenty fifteen, twenty sixteen, and we didn't get uniformity on promises to like twenty twenty one, so it seemed like rxchas's a safe way to go.
Right, it's fairly recently. Yeah, well they have very different purposes, So okay, like, can you do similar that you? So, let me back up with rxs and the concept of observables, assuming it's not an and and I think observable, which is a whole different ballgame. Let's let's muddel the two while we're at it, because of course we can't but an observable, whether it's just a dumb subject, a behavior subject, or a replace subject, is going to be a stream, right.
Promises are one and done. So the fact that you can mix and match the two and the fact that you can kind of make both of them work together is a nice city. But they have a very different purposes in the grand scheme of things, Like if I want to continue listening to something, I can't use it. I mean, I can do things with promises, but like I still have to have my listener versus the observable with Once you subscribe to the observable, you're going to
get that stream until you unsubscribe. Of course, because everything JavaScript has to be complicated, We're going to add the async subject in the mix, which is a one and done, which is an observable you subscribe to as if it was any other of the observable types, which but it's not going to fire off the result until it's completed, so it'll only ever have that one value.
The way I think of reactive extensions is a way to turn event handling in the classic sense, where you have event listeners and you do something in the event handler and just turn that into like you said, a stream or something that you can query, hey, how many times did this event occur? And quantify that and give
me the data that was passed in. And that came really into sharp focus when we interviewed remember Bjorn and the guys that did the helicopter whatever the drone programs at NDC, and they wrote a little tool to handle those because there's a lot of events that come right when they when they're flying around and they're moving, and they use the reactive extensions to to manage that, which would be absolutely impossible trying to do it with event handlers,
timers and things. So anyway, that's that's my understanding of the reactive kind of observable model.
The I think the most the most. There's kind of two places I use it a lot. I'm from going to use observables. I would say one of them is I do tend to work a lot with Firebase and Firebase as a real time database and the fire store. But either way it's it's a real time situation, right, So I can subscribe to my data, and as data changes in the database, I'm just going to get the latest and greatest directly so to me using this, you know,
using the their system. So that's one of the ways where it's legitimately a stream that I'm you know, connected to my database directly and I want to get that stream now. Where that gets interesting, and then you have to worry about, Okay, I'm piping this to a form I maybe don't want my form values to go ahead and update just because somebody else updated the data day. So there's use cases where you have to start thinking, okay, where do I want it feeding me the stream or
where do I want it to get the stream? Call it a one and done, and you know there's there's months is there. And the other piece is let's say I have a piece of data in a service, right that I'm keeping up to date so that I can potentially send to multiple components or multiple places in might UI, right, and it might be something local too. I don't know, let's say it's a let's do the number of visitor tickers something dumb, right, it doesn't matter what it is.
And so that would be something where I can feed whatever the latest value is and any component Okay, I usually use Angular a lot, so any component would go ahead and you know, get that value an automatically update and automatically do what it needs to do in the UI and update the UI according or do some math or whatever. But those are kind of the two places.
Is either for uy stay in terms of or maybe turning something off and on and being able to listen to an action happening anywhere and turn something off and on, or like dark mode is a good example that way doesn't matter where the button is and then or because then I can have the button trigger the update and then whatever's list switching over the theme is listening to that to that observable or connected to the database. But that's a little bit different. Then let's say your your
promises where it's like a one and done. Once it's done, it's done. It's not there's no continual listening. But it also means that when you're dealing with the observables, you have to make sure to stop listening to them at some point, because otherwise you end up with them. Yeah, there's a cleanup step that now needs to happen, which doesn't happen in promises because obviously there were when I'm done.
Okay, so I'm preeting pretty clear on our xas is for observers connecting to streams and being able to react to them accordingly. Yeah, maybe I'm not a clear on where i'd use promises versus async a weight and JavaScript, because you know, when I look at the rafts to async a weight, they basically say, hey, this is making promises nicer.
Yeah.
So yeah, so acync await is just is just a uh a way to do promises. It's not changing anything. It's just a how do you want to think of it? Maybe grammar like how do you want to structure your promise? That's all that's all it is to It doesn't change anything about the functionality. It's not do I want to use asink or promises? It's like I'm using promises and do I want to write do I wanted to you know, write it this way or that way? Essentially, that's all.
It's just a syntactic sugar at that point.
And you mentioned that you prefer using asnk a weight because you can do everything line by line rather than having dot the n's all over the place.
Yeah, I just it's but it's not going to be. It's not I'm not going to be able to write it that way for everything because of the wholeation we
were talking about earlier. Right, it depends on. But if I'm doing very much A, then B, then C very programmatically one two, three, four five, then I find it a lot easier to to handle, especially if I really don't care about error handling outside of it worked or it failed like my function worker failed, in which case I track at the block and I'm done, right.
And you still have access to the ane and all settled and all that stuff, whether you're using the ACN syntax or just the promise intex Yeah.
Oh yeah, yeah, because instead of doing promise dot all, you know, my array of promises dot done, I would do my results equals away promised dot all, my array of promises essentially.
Right. Okay, a while ago before the break, you brought up map, and I'm not so sure many of our listeners know what that is in another one map switch or maple switch up.
So those are all various RXGS functions that do various things. So in our which is okay, so map, there's your XGS map and then there's map in terms of mapping in arrays in JavaScript, so of course reduce the same name. So it's great, and they do different things. It's great.
We'll be confusing at all, not at all, no.
Not at all, but no, those are just ways to chain in ox in our XGS in order to do things with the data once you subscribe, you know, once you're doing something with your observable, right, So map would allow you to just transform the data and return switch map allows you to call another observable or promise and then return that. It's just with various ways of chaining. And there's I don't know how many, there's at least
twenty or so, if not more. Various ones won't bore you with the details, really, people can read the dogs.
But yeah, yeah, no, I think the main thing to know is there's a way to do this. Just go look at the docks. Yeah, very good. Any other gotchas that people find when they're starting the ACENC got down the ACENC path.
I'd say where to put your catches, like where where, and how to catch your errors, like because you can say await my promise, dot catch and then return a different value if it fails in a series of your asinka weights and then still put it in a try catch block, which so means that if anything else in your function fails, then it would just go ahead and catch.
So I would say, think through where your catches are and what they affect, so that you can know how and where you're handling your errors, because you can't actually do put a dot catch something dot catch inside of a try catch block and then figure out where your is being caught and by what and how right and the fact that a trycatch block the catch doesn't return
a value. However, a dot if you do my promise doc you know, fetch my url whatever, dot catch, so my promise dot catch, you can actually take the air or swallow the air and return it if a value should at sale. So you could potentially have something where if you can't get a value, you're going to return some defult object. Right, you could totally do that or no, yeah, but then what do you do with that air? Or do you just swallow it and never know what happened?
Do you send it somewhere for air handling? What do you like if you're going to swallow it, what are you going to how do you want to handle that in terms of you knowing it happened or do you even care?
Right? So it's like, as long as something got returned, right, if.
My dude entered his wrong password, I don't really care to send that to my server.
You know, right, Like yeah, and c sharp reez that catch handlers for logging primarily and transforming whatever data is going to be returned if it's in a method. Right, If you have a method, you put the whole thing in a try, but you put the return value up the top before the try, and then modify it if everything is fine and it's not all I fits if you get an exception and return it at the bottom no matter what, or in a finally. But you know, that's just a pattern that I use a lot. I've
seen it abused. I've seen try catches nested within catches for example.
Yep, I've seen those two not good. I've seen those good or.
Hidden dependencies where every time you tested it, it loaded in a particular order, so you never realize that actually it had an order dependency that you weren't protecting yourself from. Oh no, yeah, it's terrible. Yeah.
Race conditions are fun too, when you've forgotten away somewhere, oh right, or.
You forgot yeah, oh yeah, that's right.
We do have finally as well. On javascripts we do have finally as well. But finally in an observable one, finally and I promise don't work the same, because of course they don't. Course not, what do you want they do when they they do when they don't. So finally in a promise does exactly what you think it's going to trigger, whether you've succeeded or failed.
Right.
Finally, in a stream will only hit when the stream completes, so it's not after every successful value. Once the stream completes, that means you've closed off, or you've said dot complete or you've shut that down. Well that's once the stream complete. So, but it's worth noting the difference that it's not going to be every time you get a value.
Right, this is back to that stream versus one and done mindset right, correct, It actually is the same. It is actually I responded the same event it's the closing of the socket that raises the event. It's just that in an observable, it doesn't close to you complete exactly.
Can I just make an observation? What's really amazing to me? We've been doing this show for how in years? Twenty three something like that, all right, and you've been there for most of them, Richard, So don't say you're the new kid. But when I started it, I said, we are never going to read code on this show, right, right, But we're getting very close with this. We are well, and I think we've been close before. I'm following it, and I'm thinking that a lot of people are following
it too. Yeah, I know.
I appreciate that. I've never had this clearer in my head than right now.
Yeah, right that. This is why I wanted to call Martine in the first place. It's like, oh good, if she's explaining it, I'll probably understand it.
So yes, now, now you see all the roles for each of these pieces, So that's good. It just makes sense to where and why you would use this but don't use it everywhere all the time. Why is that just complex?
Well, I don't know. You know, if you have a hammer might as well.
No, here's a hammer.
Yeah, I can CSS important everything. It'll be fine.
No, I can't believe you said that. That's something i'd say.
I have to make fun of it. I have to make fun of my own world a little bit.
Sure, I appreciate that, and we all do that, but I do feel like it introduces complexity, and it's only if you need it you should be asynchronous. That this does delay the rendering of a page. This isn't essential for people being able to do their work. Oh yeah, I really like a web page.
I've that's crafted in a way where I'm still able to click on what I need because I knew where it was before the page was even finished loading. And it'll continue. It's fine. And an ACYNC tolerates that.
Yeah, And that actually has more to do with how the JavaScript is loaded into the I mean there's two aspects to that. There's one, how are you loading that JavaScript while into the browser? Right, because you you might have browser you might have JavaScript that's needed immediately on the page load, versus you can get there when it gets there and then you can the actual the If you're doing dumb HTML, you've got the source on the source attribute. You can go ahead and put an acinc
decorator and go ahead and make that, I think. But so that's part number one, and then part number two is how did you structure your HTML and what not to render based on when? When things load right? And what data do you need to load? Wet But there's two there's two aspects to that, which is also how is this JavaScript itself being loaded into the browser that may or may not block the rendering of the browser. And now you're getting into the whole core web vitals thing and all that fun stuff.
But yeah, just because I'm too impatient away for a whole patient render. You know, a lot of these rules that Martine is talking about also apply in Blazer programming. Yeah, I mean it's basically web programming, you know, in web is web. So that's a good if any of the Blazer programmers listening too. It's a good rule to only
use a sink when you need a sinc. Very good rule. Yeah, your environment's still the same, it's just the coding language chain, that's right, because it presumably the user's needs are the same, like users.
Are impatient presumably Yeah, yeah, yeah, one the faster you get it up there too. I mean there's from a pure marketing and se O. Your SEU has good. If you've got a quicker to click time, your SEO is going to go up. Your marketing people are going to be happier, Like, there's all the reasons right right.
People are never happy happy? Did I say that out loud? I feel bad. You want some fun when you're working in a development shop, go talk to the sales guys. Oh yeah, oh yeah, they don't like us. You know, they do not like us in the end, and we don't like them because they promise features you know that you don't even know about. You don't even know about much less know when you're delivered. Good idea to have lunch with a sales guy once a week. What have
you promised this year? A good idea for the manager?
Where did you get your estimates?
Yeah? What lines have you told?
Oh?
You just rolled a handful of dies?
Got it? I remember working for a software company and he basically used the word on all the time as a verb. Something of part of his job description was constantly unaff ing the things that need that were screwed up. He was an angry man.
I've never used I've never used the F word in relationships, my job, or anything I was doing.
Never, no, no, never never never. Okay, you heard it here first, folks. It's actually not a bad job title, you know, Carl Franklin. It's like, oh, you're the as man.
We had a q I person we called the Harborder of Doom for a long time.
I like that the Arbor of Doom approaches.
In terms of fun titles.
Yeah, definitely.
When I was in my INFOSEC roles, it was like, oh, here comes the business impediment off.
Now which role was that? Because I can think of multiple roles for that.
Yeah. Yeah, there's a bunch of folks like that. You could argue the QA guys that, but INFOSEC especially, Yeah. Yeah, you will authenticate this person before anything proceeds. Sellers to that. You know what though, I mean, you know, if you have special roles in your database for users that they're never going to see what they are, you can make them whatever you want, right, So get creative. Some day that person realizes you tag their role as Harborder of Doom. Some day Harboringer of Doom.
I did have a client once. One of the first things I had to do for them is they asked me. They're like, okay, we've been laxed, but unfortunately now we're shipping you know, this bundle to our clients, and so they can see our code. You need to go through and find all the profanity and.
Remove and also just like comments like wtf what was I thinking? My family clearly wrote this because nobody else could have No.
My favorite was the number of times I all because I E. And I've written this in code basiness before. So it made me double laugh because I was like, I haven't touched this before. How is my comments in here? Because I E. Is being a little sleep.
Yes, that's legit. They shouldn't even be removed. That's just being honest, right right, I E. I E. Defect resistance requirements. Yep, Like wtf I see that in code all the time? Who wrote this crap? Well?
I had a standard tag, you know, like a paragraph at the top of each of the perform misdoing things. Just like if this doesn't make sense to you, do not touch it. Yeah, ask someone else.
Yeah, yeah, I do have a I do have a phone on a project. If you think about touching this file, I will haunt you.
Yeah. The curse the curse, curse on your head comes your Liam Neeson. I will find you and I will kill you.
Yes.
Oh what the heck? Were we talking about JavaScript?
Of JavaScript and where we love it?
Yeah, the wonders. That's why we got to profanity. It was inevitable. I mean, oh man, oh man. Well I'm really grateful. This is a great explanation. It seems it seems like you shouldn't be afraid of this stuff. It's been and it's been true for a few years now. Like I just double checked, and like since roughly twenty twenty one, every browser responded more or less the same to this, so you can count on it.
That's good and available in Node as well, so if you're in you know, if you're in that side of the universe, it does totally work there too, which is super cool.
If you weren't frustrated enough with no JS, try ASNC and no j as.
Yeah.
Well that's the thing though for a node for a long time you had to have a package for doing a sync and so now it's actually legitimately available in node.
They're using the engine. Yeah, because it's part of the language. Yeah right, yeah, that's good. Uh well, Martine Is there anything that we missed that you want to anything? You want to plug or talk about your book? You said you wrote a paper.
Oh, I'm I mean I have my blog articles up on the blog for Andromeda Galactic dot com. I also twitch. I'm working on moving my Twitch to Monday nights. So definitely come look food, look for me there. Don't hesitate to come say hi. It's kind of hip random what will hit but it'll be front and dev something and you.
Have Martine dot dev. Can you code and chat at the same time like that? I can't really challenge that's crazy.
As long as it's something like there's so much in UI that's memorization, that's the same stuff no matter what. Like yeah, I might do my column with's through my robe. Height's a little bit different depending on the layout. But realistically, writing a writing the CSS to write a great is going to be more or less the same every time, or a flex or whatever. Yeah, as long as I figured out what I'm going to write most of the actual typing it out, I can do well. Chatting nice, not too difficultly.
And your your personal website is Martin dot dev right correct?
Yes, And all the links are all there.
Yeah, stream links there, the blog links there, like everything you need is there. You told us the story, but tell the users how you got that.
So when the dot dev extension came out for being able to get domains, the first thing I did, and like right came out. I want to look, I wanted to get Martin dot dev and it was Bob, and I cussed up because I never used the F word, so it was definitely not used in this use case. Cursing of whoever might have bought it, et cetera, et cetera, et cetera. It turned out that my partner Michael had bought it for me, so so nice.
A story from rage to delight exactly.
I mean, that's that's like if I had Carl dot com. You know, that's really good Martin dot dev fantastic, really good.
Yeah well, I mean it has the advantage of not being too common of a name, so got lucky.
I'm not well, this has been great, Thank you very much, Martine. And uh, well we'll talk to you probably in a year or so, because we seem to be talking to you once a year. Yeah.
Yeah, well, I'll be delighted to come back anytime you want me.
Great, Thanks all right, and we'll talk to you next time on dot net rocks. Dot net rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t R O c k S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded.
In September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now, go write some code, see you next time.
You got you
D that Bess home and my taxes a line d