Speaker 1: 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.
Speaker 2: We had one snowfall, which is kind of normal for
the coast, and now it's things are warming.
Speaker 1: 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.
Speaker 2: But you can control the amount of light, and so
you got control over your space till right, Yeah, exactly.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Yeah, and I don't know.
Speaker 2: This is also forty three was the era of the
first generation of antibiotics.
Speaker 1: That's right.
Speaker 2: Yeah, yeah, so, and there's some funny stories around that,
like they found the perfect bacterium for growing penicillin on
a cantalope.
Speaker 1: 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.
Speaker 2: Yeah, but that's when it was first developed and it
was the first treatment for tuberculosis.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 3: Well glad to be back. Thank you for having me.
Speaker 1: Sure.
Speaker 2: 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.
Speaker 1: I should talk to Martina.
Speaker 2: 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.
Speaker 1: So, Martine, what is on your mind these days?
Speaker 3: 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.
Speaker 1: Never, never, never, never.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: So the whole dot then that that is that the
promise syntax like fluent. Is that how it works.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: You're trying not to hang the UI.
Speaker 2: Why you do it right that I send off the
fetch you can.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: Yeah, window do resize all that stuff.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: That's convenient.
Speaker 3: 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.
Speaker 2: 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?
Speaker 3: 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.
Speaker 1: 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?
Speaker 3: Well, if you get into some of the frameworks like
our XGS, and you have the entire observable game as well.
Speaker 2: React right, yeah, yeah, then is what the other frames
will provide you on top of everything else.
Speaker 3: And then there's a handful of listeners too, which I
think are just callbacks if I remember, well.
Speaker 1: 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?
Speaker 3: 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.
Speaker 4: Right.
Speaker 3: 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.
Speaker 1: Yeah, yeah, you were talking about this.
Speaker 2: Some of these more advanced features in jabscript promises like
all settled that this is where you get some power.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 4: You know.
Speaker 1: Yeah, first, first person to give me a chicken sandwich,
I'll eat it.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: Doesn't fail, right exactly.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: If it always drops the connection. Well, that's good.
Speaker 3: 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.
Speaker 1: Look at that, But that would be smart. That would be,
you know, in a perfect world.
Speaker 3: In a perfect world. Yeah, because the Internet is perfect,
it has yeah never never, and JavaScript is perfect, it
has no flaws.
Speaker 1: It's the best language ever.
Speaker 3: It was totally thought through when it was created, right.
Speaker 1: 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?
Speaker 3: 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.
Speaker 1: Here's your hammer, find the nails exactly.
Speaker 4: They'll learn I go.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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?
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: Yeah.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: We'll be confusing at all, not at all, no.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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?
Speaker 1: Right? So it's like, as long as something got returned, right, if.
Speaker 3: My dude entered his wrong password, I don't really care
to send that to my server.
Speaker 1: 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.
Speaker 3: Yep, I've seen those two not good. I've seen those
good or.
Speaker 1: 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.
Speaker 3: Race conditions are fun too, when you've forgotten away somewhere,
oh right, or.
Speaker 1: You forgot yeah, oh yeah, that's right.
Speaker 3: 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.
Speaker 1: Right.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: I appreciate that. I've never had this clearer in my
head than right now.
Speaker 1: 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.
Speaker 2: 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?
Speaker 3: Well, I don't know. You know, if you have a
hammer might as well.
Speaker 1: No, here's a hammer.
Speaker 3: Yeah, I can CSS important everything. It'll be fine.
Speaker 1: No, I can't believe you said that. That's something i'd say.
Speaker 3: I have to make fun of it. I have to
make fun of my own world a little bit.
Speaker 2: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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?
Speaker 3: Where did you get your estimates?
Speaker 1: Yeah? What lines have you told?
Speaker 5: Oh?
Speaker 3: You just rolled a handful of dies?
Speaker 1: 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.
Speaker 3: I've never used I've never used the F word in relationships,
my job, or anything I was doing.
Speaker 1: 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.
Speaker 3: We had a q I person we called the Harborder
of Doom for a long time.
Speaker 1: I like that the Arbor of Doom approaches.
Speaker 3: In terms of fun titles.
Speaker 1: Yeah, definitely.
Speaker 2: When I was in my INFOSEC roles, it was like, oh,
here comes the business impediment off.
Speaker 3: Now which role was that? Because I can think of
multiple roles for that.
Speaker 1: 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.
Speaker 4: 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.
Speaker 1: Remove and also just like comments like wtf what was
I thinking? My family clearly wrote this because nobody else
could have No.
Speaker 3: 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.
Speaker 1: 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?
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: Yeah. The curse the curse, curse on your head comes
your Liam Neeson. I will find you and I will
kill you.
Speaker 3: Yes.
Speaker 1: Oh what the heck? Were we talking about JavaScript?
Speaker 3: Of JavaScript and where we love it?
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: If you weren't frustrated enough with no JS, try ASNC
and no j as.
Speaker 1: Yeah.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: Have Martine dot dev. Can you code and chat at
the same time like that? I can't really challenge that's crazy.
Speaker 3: 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.
Speaker 1: And your your personal website is Martin dot dev right correct?
Speaker 3: Yes, And all the links are all there.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: A story from rage to delight exactly.
Speaker 1: 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.
Speaker 3: Yeah well, I mean it has the advantage of not
being too common of a name, so got lucky.
Speaker 1: 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.
Speaker 3: Yeah, well, I'll be delighted to come back anytime you
want me.
Speaker 1: 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.
Speaker 5: 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.
Speaker 1: 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.
Speaker 5: You got you
Speaker 3: D that Bess home and my taxes a line d