Speaker 1: Hello everybody, and welcome to a super exciting episode of
Speaker 1: JavaScript Jabber. Today on our panel, we have a j O'Neill.
Speaker 2: Yo ya yo coming at you live, healthy and well
Speaker 2: from the perfect temperature in the shed.
Speaker 1: It's been a while and me I'm your host today,
Speaker 1: Dan Shapier from Tel Aviv in Israel. And today our
Speaker 1: guests are Matteo Colina Hi, Matteo, Hello everyone, James Snell Hi, James, Hello,
Speaker 1: and Michael Dawson Hi Michael, Hi.
Speaker 2: How are you doing?
Speaker 1: And today we brought you all over to talk about
Speaker 1: this excellent article post you know that you've written. I
Speaker 1: loved it very much, to the extent that as soon
Speaker 1: as I saw it, I contacted Matteo and told him
Speaker 1: you have to come on our show to talk about this.
Speaker 1: All you guys is out there should also read it
Speaker 1: regardless of what we talk about it here. And it's
Speaker 1: called the nine Note Pillars Nine Principles for doing no
Speaker 1: JS Right in enterprise environments. As I said, this is
Speaker 1: an awesome article. Who wants to start talking about it?
Speaker 1: So just go read it? I mean it is.
Speaker 3: Yeah.
Speaker 4: Okay, let me start these articles cars from an idea,
Speaker 4: from start from experience, Okay, start from at the key
Speaker 4: the experience of you know, developers do no JS all
Speaker 4: the time. They think they know no JS, and they
Speaker 4: don't know no no js.
Speaker 1: Okay, that's pretty unfortunate statement.
Speaker 3: It's no, it's true, it's true. It's absolutely true. You know,
Speaker 3: Mitteil and I, you know, when both of our previous
Speaker 3: employment we were working with a lot of consulting work,
Speaker 3: going out with customers and seeing the same problem over
Speaker 3: and over and over again, and in every single case,
Speaker 3: it always came down to folks not really understanding how
Speaker 3: node worked internally, like you know, what what how does
Speaker 3: the event loop workers?
Speaker 1: And I thinks it just occurred to me that I
Speaker 1: skipped a very important point while starting this conversation, and
Speaker 1: that's like who you guys are and why it is
Speaker 1: that you guys actually do know so much about how
Speaker 1: node works and how it should be used. So maybe
Speaker 1: you should, you guys should do a brief introduction of yourselves.
Speaker 3: Yeah, yeah, we can do that. I'm going a good
Speaker 3: person and let the guys go next year. So James,
Speaker 3: now I've been you know, I'm currently with cloud Flaer
Speaker 3: work on the workers run time. But you know, a
Speaker 3: lot longer than that. I've been involved with NOTE, coming
Speaker 3: up almost on ten years involved with Node, and at
Speaker 3: the end of this year will be exactly ten years
Speaker 3: prior to my current player. You know, you know, Matteo
Speaker 3: and I were doing all kinds of consulting work around node,
Speaker 3: use of Node, how to do things correctly, help people
Speaker 3: with performance, performance problems they're having, that kind of thing.
Speaker 3: But also just I've been contributing a lot to NOTE.
Speaker 3: So a lot of the things like the r L
Speaker 3: you know, the original euro parts are not the original,
Speaker 3: but the w G H and HB two and a
Speaker 3: bunch of other things that have been involved with with
Speaker 3: with adding. So that's me.
Speaker 1: That's my fact part in your roles. That must be
Speaker 1: so easy.
Speaker 3: Yeah, no, you can, I recommend for for a future episode.
Speaker 3: Get yagis on here. He did the the eight of
Speaker 3: RL implementation that NOTE now uses and he can tell
Speaker 3: you why it's not easy at all.
Speaker 1: So yeah, I know I was just being faspicious.
Speaker 2: Yeah, I'm Michael Dawson.
Speaker 5: I'm the NODS lead for rad Hot and IBM, and
Speaker 5: I got you know, if I actually got involved in
Speaker 5: the project around the same time that James Hayes and
Speaker 5: so been working for a very long time in the project,
Speaker 5: a member of the technical Steering Committee, working a whole
Speaker 5: bunch of the different working groups, particular like note at
Speaker 5: on API is one of the ones that I'm pretty
Speaker 5: active in in the build working group. And I think
Speaker 5: back to your earlier question, is like, I think that
Speaker 5: the challenges is that you can very easily get started
Speaker 5: with GS, but actually getting it right is a little
Speaker 5: bit more difficult.
Speaker 2: And that's why we we you know, we see.
Speaker 5: Things like some specific guidance can really help people going forward.
Speaker 2: Over to Matteo.
Speaker 4: So hi, hi folks, I am a little bit under
Speaker 4: the weather today, so I'm sorry. I didn't want to
Speaker 4: defer the recording. So so sorry if I'm less, I
Speaker 4: don't know, excited as you. It's look, well, well I
Speaker 4: have I have a lot at this point, have been
Speaker 4: doing been doing the JS for a long time. I
Speaker 4: have accumulated a few hundreds MPM deployed a few hundreds
Speaker 4: modules on MPM, which more or less total a very
Speaker 4: nice one percent, close to one percent of the total
Speaker 4: number of down of downloads of MPM itself. Wow, it's
Speaker 4: it's a little bit unbelievable to be honest, the numbers
Speaker 4: are you know, it has way too many zeros in them.
Speaker 1: Okay, you've been busy.
Speaker 4: Well yeah, everybody seems to love the code that I
Speaker 4: pushed that they push out for free. So anyway, a
Speaker 4: few years back, I started this company called Platformatic two
Speaker 4: you know, to push not to the next level, and
Speaker 4: that's where what we are trying to do, and and
Speaker 4: we have been trying to fund some of those initiatives
Speaker 4: and things and promote no js.
Speaker 6: So here we are.
Speaker 1: Cool. Now, you guys all work at different companies, so
Speaker 1: you're obviously all three of you very much involved in node,
Speaker 1: but your day job is at different places. How did
Speaker 1: it happen that all of the three of you came
Speaker 1: together to write this article?
Speaker 6: Oh, I can take this.
Speaker 4: So basically it's actually one person that is missing in
Speaker 4: this call, which is Natalia that was also part of
Speaker 4: the review.
Speaker 6: Okay. And Natalia is also the lead owner and for
Speaker 6: JavaScript the X and have tools for Azure and the
Speaker 6: four of us like this started from my idea, from
Speaker 6: an idea that I had a few months back and says, look,
Speaker 6: how come we can how can we promote and solidify
Speaker 6: that knowledge?
Speaker 4: Okay? And how can we stop start pushing back against the.
Speaker 7: All the bad tutorials, all the bad all the bad
Speaker 7: practices that are out there and plugging every single not
Speaker 7: JS code base that I have that I've seen, Okay.
Speaker 6: Because that's that's frankly what it is.
Speaker 4: So at that time I started looking, and I said
Speaker 4: that I picked a few friends and decided, look, who
Speaker 4: can who can I ask? I want a presentation for
Speaker 4: a bunch of different companies and so on. So and
Speaker 4: let's try to put our our minds together and write
Speaker 4: something up that can be uh that you know, we
Speaker 4: can be happy with and can help developers you know
Speaker 4: you're doing no J as well, and stop those you know,
Speaker 4: Spaghetti's code mess that they do most of the time.
Speaker 3: So yeah, and one important point of me is like,
Speaker 3: none of none of the information in this pod post
Speaker 3: is new. It's stuff that we've talked about and talks
Speaker 3: over the years for conferences and workshops, and you know,
Speaker 3: each of us in various ways have have talked about
Speaker 3: these things before. Unfortunately, a lot of that gets kind
Speaker 3: of washed out in the noise. It's like, you know,
Speaker 3: there's so many of these tutorials that just kind of
Speaker 3: get things wrong. And it ends up washing out the
Speaker 3: good information. Uh, just kind of in that noise. And
Speaker 3: so it's like many times we can repeat this stuff,
Speaker 3: get it out there.
Speaker 1: You know.
Speaker 3: I'd like to see us like repeat this again like
Speaker 3: a year from now, just kind of keep reiterating on it,
Speaker 3: keep going.
Speaker 1: Uh, gets on again and again in the future. Individually altogether,
Speaker 1: just say the word Obviously, we will enumerate through the
Speaker 1: pillars and look talk about the positive stuff and the
Speaker 1: things that that need that should be done, and it
Speaker 1: can be done and need to be done. But to
Speaker 1: make it spicy, I do actually want to start with
Speaker 1: some of the negatives. If you don't mind. You guys
Speaker 1: said that you encounter so many bad practices and so
Speaker 1: much bad advice and bad code, and without naming names,
Speaker 1: can you give some examples.
Speaker 3: Oh yeah, we can do whole whole examples. I'm gonna
Speaker 3: a couple years ago the top guys, I did a
Speaker 3: talk called broken Promises. There there's you can you can
Speaker 3: find it on YouTube, and I credit with the work
Speaker 3: some workshops just that you know, kind of breaks down
Speaker 3: some of the really bad ways people just get things wrong,
Speaker 3: particularly around promises, because they just don't understand how they work.
Speaker 3: I had one former consulting customer I walked in was.
Speaker 8: Doing a workshop their their their lead engineer on the
Speaker 8: team started arguing with me because he believed that creating
Speaker 8: new promise was just like creating new thread and Java.
Speaker 3: So no, it's completely different model. And this is their
Speaker 3: lead engineer on on on the team. Because it just
Speaker 3: did not understand how how this works, and it just
Speaker 3: we just kept encountering that over and over and over again,
Speaker 3: that kind of stuff.
Speaker 1: I just posted the link, by the way, Uh, we'll
Speaker 1: also put it in the show notes to that talk.
Speaker 1: So yeah, that's that's pretty amazing. Like I can understand
Speaker 1: why somebody might confuse a worker with a thread, but
Speaker 1: confusing a promise with a thread that's pretty extreme.
Speaker 4: But look, we can even go to more of way
Speaker 4: more basic stuff, okay, like like the best. Let's let's
Speaker 4: talk a little bit about updating no JS updated not
Speaker 4: do not use uh deprecated code.
Speaker 6: It's unbelievable.
Speaker 4: Okay, the companies are not updating no JS like this
Speaker 4: seems you know.
Speaker 6: It's it's.
Speaker 2: Should deploy something though it's working. Just let it be right.
Speaker 2: I mean, I know a lot of companies, are you know,
Speaker 2: in some sort of hype cycle where they're just deploying
Speaker 2: the latest framework every other day. But I think a
Speaker 2: lot of profitable companies are creating a product and once
Speaker 2: that product is good, they're they're not gonna rock the
Speaker 2: boat on it every five minutes. They're gonna let it cook.
Speaker 1: Also, you know that old joke about that the developer
Speaker 1: and his son walking down the road and the boy says, Dad,
Speaker 1: why does the sun rise in the east, And the
Speaker 1: father says, it works, don't touch it.
Speaker 6: Those are good points. Those are good points. But you know,
Speaker 6: no one wants to use software that is full of
Speaker 6: security and vulnerabilities.
Speaker 2: Well, maybe they should stop putting them in.
Speaker 4: The oh, maybe they should stop putting their product on
Speaker 4: the Internet. Then that's a pretty eastern way to be pulled.
Speaker 4: The blog it's it's it's secure by default, Okay.
Speaker 3: I mean, so the application and an application that has
Speaker 3: proper isolation around it. And I say, if all of
Speaker 3: the routes coming into that thing are secured and it's
Speaker 3: not exposed to the Internet, it's just like a long
Speaker 3: running enterprise application that's there to support existing business processes.
Speaker 3: If they don't update, they don't update that doesn't matter
Speaker 3: because because they have that isolation, and the types of
Speaker 3: threats that are coming at that server, you know, are
Speaker 3: much more limited. But if something's out on the internet,
Speaker 3: if it's exposed to the internet, you know, you don't
Speaker 3: want to have software running that has these security vulnerabilities.
Speaker 3: You really should update. And as updating, you know, you
Speaker 3: can't just quite throw a new version out there. You
Speaker 3: need to see what other changes are going on. Like
Speaker 3: we'll deprecate things that we really people really should not
Speaker 3: use because it could be a security vulnerability. But we
Speaker 3: you know, but removing it or changing the way it
Speaker 3: works is too much of a breaking change, and we
Speaker 3: don't want to force a breaking change on people. We
Speaker 3: just want to strongly nudge you away, right. Yeah.
Speaker 1: Also, it's not as if those organizations aren't updating their
Speaker 1: own code. I mean, you know, if the project is dead,
Speaker 1: then it's dead. But you know, we are primarily talking
Speaker 1: about you know, living, not dead profitable.
Speaker 2: There's a difference between dead and it's not a suck
Speaker 2: of engineering resources every week, it's actually making money.
Speaker 1: Yeah, But in order to be profit afoodable these days,
Speaker 1: you need to be a service and the only way
Speaker 1: to justify being a service is continuously releasing updates even
Speaker 1: if nobody asks for them.
Speaker 2: Well, I was going to say one thing that circling back,
Speaker 2: I don't think I have seen anything breaking Node since
Speaker 2: version either ten or twelve. So I recently updated an application.
Speaker 2: Was so fraid because I'm actually using private APIs in
Speaker 2: the networking layer. I updated an application I think from
Speaker 2: it was version maybe twelve or fourteen, all the way
Speaker 2: up to version twenty, and there were no issues. So
Speaker 2: Note has become incredibly stable, probably after version I want
Speaker 2: to say after version ten. I think there was a
Speaker 2: ton of breaking changes in the version version six or eight,
Speaker 2: but version ten or twelve, it's it's been incredibly stable.
Speaker 2: In the likelihood that you'll have to go debug things
Speaker 2: is unless you're using an experimental feature. Ye had experimental flags,
Speaker 2: but even then, I don't think I've seen any breaks
Speaker 2: in the experimental features in the last several years. Few.
Speaker 3: Yeah, they're few, they count, you know, they're the usually
Speaker 3: pretty small, but they happen every now and then.
Speaker 2: One of the ones that I used, like fetch and
Speaker 2: the there was something in web crypto, and maybe there's
Speaker 2: some more niche things that are weird, like the U
Speaker 2: was that it's like a lifetimes thing. I forget what
Speaker 2: the name of it was, if I don't know if
Speaker 2: it's still a thing, but there was like some sort
Speaker 2: of a lifetimey thing.
Speaker 3: In price talking about Yeah, yeah.
Speaker 2: That might be. Like there's some of that stuff that
Speaker 2: was super experimental. I didn't touch, but anything that already
Speaker 2: had a web standard was the stuff that I was
Speaker 2: that I've been using that's been experimental.
Speaker 5: It's certainly like if you follow the discussions in the
Speaker 5: in the project, we really are careful about that and
Speaker 5: we think carefully. And you know, if even the ones
Speaker 5: that James mentioned, we do make some small breaking changes,
Speaker 5: but we think very carefully about those.
Speaker 2: We try and understand the impact.
Speaker 5: And so yeah, I think that's one of the things
Speaker 5: the project has been doing quite well over the last
Speaker 5: number of years is to try and minimize that. The
Speaker 5: other thing I wanted to add to what James was
Speaker 5: saying is like it really comes back to risk management.
Speaker 5: You know, you can continue to run on older versions,
Speaker 5: and I think if you've done your risk management, you've
Speaker 5: done your analysis, like you may you know, again back
Speaker 5: to your point of like it doesn't cost any money
Speaker 5: to leave it just running so that that isn't that
Speaker 5: is good and if you've actually thought about it, maybe
Speaker 5: you're doing the right thing. I think we just don't
Speaker 5: necessarily see that people are like thinking about it enough
Speaker 5: in terms of like should I should I have updated?
Speaker 5: You know, that's the easy answer is if you stay
Speaker 5: on the lift, you're going to get the security fixes
Speaker 5: or you know, there's some companies like like the one
Speaker 5: I work for that will give you longer term support,
Speaker 5: so you're probably okay then, But like we probably like
Speaker 5: to see a few more people either very carefully looking
Speaker 5: at their risks or sticking to the LTS releases and
Speaker 5: the ones that are active, because those are the ones
Speaker 5: that like the project is going to help.
Speaker 1: Yeah, but now you're starting to go towards the actual pillars,
Speaker 1: because that's literally one of the pillars. So I'll just
Speaker 1: pull us or push us towards that, and let's maybe
Speaker 1: start going down the pillars, unless you guys want to
Speaker 1: mention something else before we we do that, Okay, let's
Speaker 1: go do. Let's start with the pillars then, So pillar
Speaker 1: number one do not block the event loop. That's an
Speaker 1: interesting one because it's actually also very much pertinent to
Speaker 1: the browser, not only to node, and actually it's also
Speaker 1: pertinent to the Dino and bond. By the way, I
Speaker 1: will say that quite a number of these pillars are
Speaker 1: relevant or almost all of them are also relevant to
Speaker 1: Dino and to bon I think. And some of them
Speaker 1: are relevant, you know, to whatever server platform almost you're using.
Speaker 1: You know, they might be relevant if you're using Java
Speaker 1: or Go or whatever. But again we'll be focusing on
Speaker 1: a node in this conversation. So again, the first one
Speaker 1: is do not block the event loop. We've discussed the
Speaker 1: event loop in the past on this podcast, but maybe
Speaker 1: it's worthwhile for one of you guys to quickly explain
Speaker 1: reiterate what the event loop is and why it's so
Speaker 1: important not to block it. Yeah, I mean we can.
Speaker 3: We can talk about it just in very very high
Speaker 3: level general terms. You know, you know, the note has
Speaker 3: its event loop which is based on the UV. It
Speaker 3: is structured a particular way. Dino and and Bond and
Speaker 3: workers and stuff. We you know, they all have event
Speaker 3: loops that are that work slightly differently. They have different phases,
Speaker 3: different you know, slight you know, slightly different implementations, so
Speaker 3: they all work slightly differently. But they all have the
Speaker 3: same fundamental concept of it's going to be monitoring the
Speaker 3: system for we you know, certain events io, hey, I
Speaker 3: want to read a file, or I've got a network
Speaker 3: connection or whatever. And as it's turning, it's gonna you know, say,
Speaker 3: I gotta I got some io I'm going to fire
Speaker 3: a callback and that callback is going to go off
Speaker 3: and run some job script. And what's important to understand
Speaker 3: is that while that joba script is running, the event
Speaker 3: loop is not. It pauses while you go off and
Speaker 3: run that JavaScript, and then when that is done running,
Speaker 3: it comes back and the loop continues. It doesn't matter
Speaker 3: what platform you're on. That's how it works, unless you're
Speaker 3: using worker threads, which you have multiple event loops running
Speaker 3: on different threads. When you're whenever you're running JavaScript, nothing
Speaker 3: else is running, all right, You're not going out and
Speaker 3: pulling IOH, you're not looking for you know, you can't
Speaker 3: go off and accept the new connection that kind of stuff, right,
Speaker 3: So you know, it's you have to make sure that
Speaker 3: that jobscript that you're running can return fast enough for
Speaker 3: that event that to turn around and do something else.
Speaker 1: Now, on the browser side, it's it's maybe less catastrophic.
Speaker 1: But it's often more obvious when there's a problem with
Speaker 1: the event loop because user interactions starts to get jenky uh,
Speaker 1: somebody clicks a button and the UI doesn't respond because
Speaker 1: the browser is too busy processing the JavaScript for a
Speaker 1: previous event. What's the negative impact in node when you
Speaker 1: don't process stuff out of the event loop quickly enough,
Speaker 1: or when things stay in the queue for too long.
Speaker 6: I have a very nice talk on this, okay, which
Speaker 6: I recommend everybody to watch. I'm going to pass it.
Speaker 4: I'm going to summarize and then pass it into into
Speaker 4: the chat for everybody to to take a look. Okay,
Speaker 4: So the the gist is very simple.
Speaker 6: What is that? What happens? Okay? You take.
Speaker 4: Gets busy? Okay, the problem it doesn't? You say, well,
Speaker 4: the event top is busy. What problem it can be?
Speaker 6: Okay?
Speaker 4: Well, genetically, if there's only one user, and which is
Speaker 4: for example, the case for deployment on workers or in
Speaker 4: w islam DA, this is essentially the impact is very limited.
Speaker 6: Okay.
Speaker 4: However, you are also missing out on the key feature
Speaker 4: of no JS and zavaskipt itself because you can, you know,
Speaker 4: supporting multiples at the same time allow you to maximize
Speaker 4: the use of the source.
Speaker 6: Of that single process.
Speaker 4: So what happens is that once the amount of load
Speaker 4: goes over and there's a little bit of math involved,
Speaker 4: goes over a st threshold, the response time of your
Speaker 4: application will start getting will start looping into we start
Speaker 4: growing in an exponential in an exponential fashion, and therefore
Speaker 4: at that point.
Speaker 1: You are.
Speaker 4: Your application will stall completely, very quickly and not responding,
Speaker 4: not nothing, spinning wheels. Typically, the problem is if I
Speaker 4: send a request, okay.
Speaker 6: Do you.
Speaker 4: Want the if you're if you done a good job,
Speaker 4: you are going to respond. Your server is going to
Speaker 4: respond in I don't know, two und MILLI second a second,
Speaker 4: two second, okay, after what's the threshold after which I
Speaker 4: stop responding? Okay, I start I stopped waiting for a response, okay.
Speaker 4: But the problem is that when you receive an HTP request,
Speaker 4: you node you you know, not just as received that request,
Speaker 4: and we continue processing that request up independently of the
Speaker 4: fact that the user on the other end as he
Speaker 4: is still there.
Speaker 6: Okay. You can detect that. You can handle this with
Speaker 6: about signals and a bunch of other stuff, but it's
Speaker 6: definitely not definitely not common.
Speaker 4: Okay, So, and the genetic result is and when you know,
Speaker 4: gs reach a certain level of flow, it became very
Speaker 4: much unresponsible that your application became as andresponsive completely.
Speaker 6: And this is a massive, massive problem.
Speaker 3: A great example, you know, based on former customer, I'm
Speaker 3: not going to name any names and such, but we
Speaker 3: were called out to do some consulting work for them
Speaker 3: because their note application was very, very slow. They were
Speaker 3: getting a whopping four requests per second production, Like, what
Speaker 3: the hell are you doing to get only to only
Speaker 3: get four requests per second? Well, what they were.
Speaker 1: Doing apply to the trillions dig on every request almost worse.
Speaker 3: So, they were using an old version of Apollo that
Speaker 3: was not very performance optimized. Every graph COO career that
Speaker 3: they were received was very complex and it ended up
Speaker 3: being where they would do like ten to fifteen sub
Speaker 3: requests on that back in that back then, the way
Speaker 3: that propol works, it would receive the requests, it would
Speaker 3: parse it generate the AST, walk the AST, go off
Speaker 3: and submit all of the sub requests, wait for those
Speaker 3: to return, and then would have to go through and
Speaker 3: do this this process of reconstructing the response. Unfortunately, these
Speaker 3: queries were so complex that it was blocking the event
Speaker 3: All of that processing was was synchronous right now, Waiting
Speaker 3: on the sub requests that was asynchronous, but the actual
Speaker 3: parsing and walking to the AST was fully synchronous. And
Speaker 3: they were blocking the event loop from progressing every time
Speaker 3: that happened, and they were blocking it by so much
Speaker 3: that you know, it couldn't get around to take the
Speaker 3: next request.
Speaker 1: Right.
Speaker 3: The other problem that they were encountering though, is roughly
Speaker 3: maybe about fifteen percent of of their requests were failing
Speaker 3: with timeouts. And like you know, we'd understand why these
Speaker 3: are failing with timeouts. Well, what would happen is they
Speaker 3: would send, like I said, ten to fifteen back end requests, right,
Speaker 3: sub request those would go to the back end systems.
Speaker 3: Those systems were responding quickly, right and and you know,
Speaker 3: having responses pending in the IOQ in the node event loop.
Speaker 3: But if you look at the phases of the node
Speaker 3: event loop, what you'll see is almost right before we
Speaker 3: pull for pending io we checked timers, right, you know,
Speaker 3: and that loop we always checked timers first. What was
Speaker 3: happening is that the event loop was being blocked for
Speaker 3: so long that by the time the event loop turned
Speaker 3: and came to book the timers even though that those responses,
Speaker 3: the suber quest responses were waiting to be read, the
Speaker 3: timeouts on the sub requests would would fire and cancel
Speaker 3: the entire thing. Oh no, So it was just like
Speaker 3: this compounding problem that all of the synchronous activity blocking
Speaker 3: the loop from actually advancing IO tripping itself up.
Speaker 1: If I'm thinking about it, I can basically like perceive
Speaker 1: of two main problematic scenarios here and correct me if
Speaker 1: I'm if I'm wrong. One scenario is that even though
Speaker 1: events are are being handled relatively in a timely fashion individually,
Speaker 1: the rate in which they are coming in is so
Speaker 1: high that the server is simply unable to complete the
Speaker 1: processing the events at the rate that new events are
Speaker 1: coming in. That's that's problem number one. And problem number
Speaker 1: two is that regardless of the rate that events are
Speaker 1: coming in, sometimes the processing is so lengthy that the
Speaker 1: loop is just being blocked for so long that it's
Speaker 1: making the system and the system is unresponsive during that time.
Speaker 1: That that causes problems because other events time out are
Speaker 1: not processed in a sufficiently timely fashion, all sorts of problems.
Speaker 1: So the service might be even mostly not busy at all,
Speaker 1: but whenever something comes in, it just gets stuck for
Speaker 1: too long a period I understand.
Speaker 4: Incorrectly, yes, yes, yes, And if that event opens uppens
Speaker 4: too often, it gets into a catastrophic failure.
Speaker 6: And most as to say.
Speaker 5: Like the event loops really optimized to do lots of
Speaker 5: short things. And you know you talked about the first
Speaker 5: case of things coming in too quickly, Well, no one
Speaker 5: can scale to take a lot of incoming requests as
Speaker 5: long as you quickly hand them off to something else
Speaker 5: to like, you know, if you come in, you take
Speaker 5: a request, you hand it off to the database, and
Speaker 5: you do that asynchronously, it can scale to lots and
Speaker 5: lots of things coming in. I mean, I think it's
Speaker 5: a Mattel was kind of saying. But if you get
Speaker 5: to a point where you're you're trying to do too
Speaker 5: much in the event loop itself because you're you're effectively
Speaker 5: sharing a single thread, you're now going to slow everything down.
Speaker 5: And it follows over a cliff that at one point,
Speaker 5: so you know, if you've got longer running tasks, you
Speaker 5: really want to push them to worker threads.
Speaker 2: And a good example that I think is.
Speaker 1: More to or to other servers, but a microservices architecture
Speaker 1: something exactly.
Speaker 5: The one thing I think is kind of interesting is
Speaker 5: even if you have your micro service, you say, okay,
Speaker 5: I'm going to make a micro service for my very
Speaker 5: long running job, you still don't want to block the
Speaker 5: event loop for that micro service because the main event loop,
Speaker 5: because well, what if you deploy that micro service to Kubernetes.
Speaker 5: Kubernetes is probably going to have a liveness check, and well,
Speaker 5: how is that liveness check going to run? It's going
Speaker 5: to have to hit that main event loop and say hey,
Speaker 5: are you still alive?
Speaker 1: And sorry? I We literally had this problem, okay at
Speaker 1: the company that I worked at, again without naming names,
Speaker 1: we were actually using Prometheus, the Prometheus client, and without
Speaker 1: going into reasons, the Prometheus response that was being generated
Speaker 1: was huge, and it was a huge string being serialized
Speaker 1: and that just took too long. And if that happened
Speaker 1: while the liveness check happened to come in, it could
Speaker 1: literally cause the liveness check to time out and cause
Speaker 1: Kobernetes to kill that instance.
Speaker 5: Yeah, so you always want to push your long running
Speaker 5: jobs onto worker threads so that your main event luke
Speaker 5: can respond quickly.
Speaker 3: Yeah, and this problem is not unique to note, not
Speaker 3: by any stretch. Now, in other run times, it manifests
Speaker 3: differently like workers, and we have a completely different threading
Speaker 3: model and workers to note, every request is running on
Speaker 3: its own thread coming in. We can still accept other
Speaker 3: requests and that kind of thing, but and isolate, a
Speaker 3: particular worker might be used by multiple threads. So whenever
Speaker 3: one request is being processed on one thread, right, no
Speaker 3: other threads can use that isolate, that can can use that,
Speaker 3: you know, that particular instance. And we have to share these.
Speaker 3: So we have these things that are all you know,
Speaker 3: basically lock contention. It's waiting for that locks, you know,
Speaker 3: waiting for that isolate to be free so I can
Speaker 3: use it on this particular thread and it jumps around
Speaker 3: the effect. It's a different mechanism but has the same
Speaker 3: effect of blocking other things. If one particular request has
Speaker 3: too much synchronous processing, it goes on for too long,
Speaker 3: then other threads can't acquire that lock and can't progress,
Speaker 3: They can't you know, run their own jobscript and it
Speaker 3: ends up being the same basic effects blocking the note
Speaker 3: event loop.
Speaker 1: So you just sorry, you just just that I'm not
Speaker 1: used to thinking about blocks soften in the context of JavaScript.
Speaker 1: That's all I wanted to say.
Speaker 3: Yeah, I mean, but they're there, you know, And in
Speaker 3: the key concept here for this particular pillar is yes,
Speaker 3: run jobscript all you want, just do it in short
Speaker 3: span you know, first, don't do these huge, long, secretus processes.
Speaker 1: So basically, either push processing off of the main note
Speaker 1: thread to workers, to micro services whatever, don't and don't
Speaker 1: wait on them, just send it and wait for their
Speaker 1: synchronous response. Or break your long running JavaScript into multiple
Speaker 1: shorter segments might see anything, you know, the set time
Speaker 1: out zero for the wind.
Speaker 6: Typically the task the company.
Speaker 4: But yes, unfortunately, yes, okay, in that way, other things
Speaker 4: can be scheduled in between.
Speaker 6: Okay, So that's the gist.
Speaker 4: But genetically, I would say that we do have enough
Speaker 4: technologies right now to run things easily on worker threads
Speaker 4: that you should just be using trads like literally, most
Speaker 4: developers don't think.
Speaker 6: That no JS is multi threaded these days.
Speaker 4: It has been since twenty eighteen, and most developers since
Speaker 4: you know, they're still reading that tutorial from twenty fifteen.
Speaker 6: So that's a problem.
Speaker 1: I have to say that there is one issue with it,
Speaker 1: and I know that there are several proposals that are
Speaker 1: looking to address it, but so far it still exists,
Speaker 1: and it's more of a JavaScript issue than a note issue,
Speaker 1: and it's that serializing stuff across workers can be sometimes
Speaker 1: more expensive that the actual work that was offloaded. Like
Speaker 1: serializing and de serializing each way can sometimes be more
Speaker 1: expensive than the actual work that you're afloaded if you're
Speaker 1: not careful.
Speaker 6: Of course, but it means that you need to upfload
Speaker 6: staff that is beer essentially.
Speaker 3: Yeah, yeah, and there are ways around that, you know,
Speaker 3: with with you know, my shared array offfer and some
Speaker 3: of the shared data structures we have.
Speaker 1: So yeah.
Speaker 2: So Node has the ability to run multiple processes, so
Speaker 2: you can you can fork, and you can I don't
Speaker 2: remember exactly. I kind of forgot it because it turned
Speaker 2: out not to be useful for this very reason that
Speaker 2: the the communication between Node processes of doing the Jason
Speaker 2: stringifying the Jason parse makes it so that you should
Speaker 2: probably never ever do that. And the only way that
Speaker 2: you should be using Node if you're going to use
Speaker 2: multiple processes, not it is not it's it's child process
Speaker 2: forking mechanism, but rather you just run multiple processes. They
Speaker 2: handle all multiple requests and let them you know, donect
Speaker 2: to the database, separate and stuff. Yeah, well where would
Speaker 2: that where would that be profitable? Where? Where would it
Speaker 2: actually make sense to use that? Oh, cluster, it's called
Speaker 2: node cluster, right, yeah, is that what it's called. Yeah, yeah,
Speaker 2: so I think it's kind of a secure feature most
Speaker 2: people know about. Yeah, I think today what we're doing good.
Speaker 5: I was going to say today, I would defer to
Speaker 5: other things, Like you know, Kubernetes will manage multiple instances
Speaker 5: of your node application, each which should be stateless. So
Speaker 5: like if you want to scale, there's lots of non
Speaker 5: node specific ways of scaling processes out, so you can
Speaker 5: have multiple compaties of your your microwins, of your micro service.
Speaker 5: So that's why I wouldn't necessarily be using the cluster
Speaker 5: module on its own anymore. So it's really like, you know,
Speaker 5: I would typically scale using those technologies when it's a
Speaker 5: matter of just needing more than one thread's worth worth
Speaker 5: of you know, throughput, because you could have lots of
Speaker 5: little tasks, but you just still can't handle all those
Speaker 5: tasks on a single thread, in which case let's scale
Speaker 5: out to multiple processes. But if you have long running tasks.
Speaker 5: Even if you have enough to maybe only take fifty
Speaker 5: percent of your single CPU, you don't want to do
Speaker 5: those on your main thread loop. You want to still
Speaker 5: push those two workers because you don't want to be
Speaker 5: blocking all the all the work based on those lower
Speaker 5: or longer transactions, right, even if there's like one in
Speaker 5: ten every tenth second, you don't want to have something
Speaker 5: that takes a really long time and slows everybody. Yeah.
Speaker 1: I think it was Jake Archibald that said it in
Speaker 1: the context, or maybe it was a Somat that said
Speaker 1: it in the context of browsers that one of the
Speaker 1: reasons that you want to offload things to workers is
Speaker 1: not so much sorry about performance, it's more about consistency.
Speaker 1: That you don't want all of the like every x
Speaker 1: task to suddenly block your system for too long. I
Speaker 1: do have to say though, that in my experience, most
Speaker 1: of the work that I've seen done on loade is
Speaker 1: mostly as quote unquote middleware, so very often there's not
Speaker 1: so much heavy lifting being done inside the note service itself.
Speaker 1: Let's say it this way.
Speaker 6: Are you sure done?
Speaker 1: No, I'm not. I'm scared.
Speaker 4: Let's let if you if you take a look at
Speaker 4: what the all the front end meta frameworks are doing lately.
Speaker 6: They all of them, they are massively blocking the develope
Speaker 6: like they.
Speaker 1: All of the rendering code, the service rendering stuff.
Speaker 4: Yes, so in that scenario, if you are already I
Speaker 4: have a very expensive rendering pipeline and you also need
Speaker 4: to do some data processing, data mangling that can take
Speaker 4: some CPU.
Speaker 6: Time, you are really really you really really want to
Speaker 6: push it somewhere else. Okay, and you do well, not
Speaker 6: on the not on the tutorials, but yeah, you can
Speaker 6: not on their maint not on the mein.
Speaker 1: To No, I'm asking if from your experience, the framework
Speaker 1: makers are doing the the best, you know, the best
Speaker 1: that they could do to offload stuff.
Speaker 4: You know, they are in order to turn it better.
Speaker 4: It's getting better and better and better. And I think
Speaker 4: it's it's not like a lot of it comes around
Speaker 4: on the marketing side versus the framework itself. Okay, then
Speaker 4: nothing in the frameworks blocks you to do certain things, okay,
Speaker 4: But it's more about how they market they frameworks and
Speaker 4: the products that cause, like the they make, the they
Speaker 4: make those applications. You know, they teach developers using their
Speaker 4: frameworks very often that they could do certain things, and
Speaker 4: those certain things will work very well up until a point,
Speaker 4: and then they won't work anymore.
Speaker 6: But they then don't tell you that point.
Speaker 1: Yeah, and the promotereos example I think I gave is
Speaker 1: a pretty good representation of that.
Speaker 6: Yeah for that.
Speaker 4: Okay, what we have recently been done and we have
Speaker 4: losen as a product called the VA Application Server. And
Speaker 4: what we do is we keep we use one work thread,
Speaker 4: so we run the applications in the application in a
Speaker 4: worker thread and we keep the prometheus in the main thread.
Speaker 6: So in this way we can have the monitor okay,
Speaker 6: not affected by the application itself. And in this way
Speaker 6: you can keep things.
Speaker 4: We can keep things responsive and app okay and be
Speaker 4: able to monitor them correctly even if the application is
Speaker 4: under eavylod.
Speaker 1: Yeah. By the way, just to toot my own horn,
Speaker 1: I actually contributed back into the prompt client project and
Speaker 1: optimization that basically just reduced the runtime cost of serializing
Speaker 1: the string by something like fifty percent. Uh.
Speaker 3: That serialization thing, and going back to you know it
Speaker 3: is you know original point there about the cost of
Speaker 3: serializing the data back and forth across these boundaries, right,
Speaker 3: you know, it doesn't matter if you're using a worker
Speaker 3: thread or a child process or whatever, I PC doesn't matter.
Speaker 3: The serialization and de serialization back and forth those boundaries
Speaker 3: always has a cost. You can use you know, faster
Speaker 3: serialization framework so proto buff or cat and P versus,
Speaker 3: you know, instead of serializing everything as is JSON, but
Speaker 3: you're still going to have a cost. So it's like
Speaker 3: anytime you're you're distributing this load you need to do,
Speaker 3: you take effort, takes steps to minimize the amount of
Speaker 3: serialization de serialization you're going to do. You're using a
Speaker 3: child process rather than sending a large chunk of JSON
Speaker 3: just past the FD right and let the let that
Speaker 3: child process you know, read the data off the off
Speaker 3: the network and do its own you know, don't parts
Speaker 3: or whatever. If you're doing worker threads, use shared data
Speaker 3: objects like shared rape buffer rather than things that need
Speaker 3: to get copied and serialized using structured clone. The more
Speaker 3: of those kinds of things you do, the more effective
Speaker 3: this this load distribution is going to be because you're
Speaker 3: not going to eat the you know, eat up all
Speaker 3: your your performance gain on serialization de serialization costs.
Speaker 1: Well, we've been stuck on the first pillar for such
Speaker 1: a long time, it's pretty obvious we won't be able
Speaker 1: to run through all the pillars, which is just a
Speaker 1: great excuse to invite you all over again. But still,
Speaker 1: unless somebody else wants to say something about the first pillar,
Speaker 1: I think we'll move on to the second one. Is
Speaker 1: that okay with it?
Speaker 6: I think we have covered the second one too.
Speaker 3: You know.
Speaker 1: Yeah, so an extent we have. It's a monitor note
Speaker 1: specific metrics and act on them. This is one of
Speaker 1: those recommendations which is true everywhere, for every system, not
Speaker 1: just for Note. I will say that I'll be monitoring.
Speaker 3: Yeah, there's there's one here that is worth calling out.
Speaker 3: Most people, most new users, even even the long terms,
Speaker 3: aren't familiar with event loop utilization. Folks still talk about
Speaker 3: event loop delay, right, and that is a different metric.
Speaker 3: Event look utilization is a relatively new concept. It's been
Speaker 3: there for a couple of years. Most people don't know.
Speaker 6: About it, and it's amazing. James maybe four.
Speaker 1: Yeah.
Speaker 3: The evently utilization is a measurement of how effectively your
Speaker 3: event loop is processing tasks versus waiting for things.
Speaker 1: Uh.
Speaker 3: And it's it's a much more accurate metric of how
Speaker 3: well your application is performing than event loop delay, so
Speaker 3: everyone should continue.
Speaker 1: Yeah, because I would like you to explain it. I'm
Speaker 1: familiar with the term with a metric called event loop lag.
Speaker 1: Is that just an alternate name for event loop delay?
Speaker 3: Yeah, that I would think so.
Speaker 1: Yeah, so event loop, which I knew was basically what
Speaker 1: you described. It's like looking at the meantime or the
Speaker 1: ninetieth percentile between when an event gets into the queue
Speaker 1: and until it gets processed pulled from the queue in
Speaker 1: order to be processed. And obviously they're the statement was
Speaker 1: you know, you want the mean value or the ninetieth
Speaker 1: percentile or whatever to be basically as low as possible
Speaker 1: in order for the system to be responsible. But you're
Speaker 1: talking about something else. You're talking about event loop utilization.
Speaker 1: Can you explain that metric to us.
Speaker 3: Yeah, I mean there's a few things Ago went to it,
Speaker 3: but it's basically a ratio of how how much time
Speaker 3: your event loop is spending doing things versus just sitting
Speaker 3: idle waiting for things. So let's say if you have
Speaker 3: an event loop that is just going off, your application
Speaker 3: is just going up and scheduling a whole bunch of IYO,
Speaker 3: and then it has to wait a long time for
Speaker 3: that io to do anything, and in between as times
Speaker 3: it's not actually processing anything else. Right, In that case,
Speaker 3: your event loop is not being utilized effectively. It's spending
Speaker 3: most of this time being idle waiting for stuff. But
Speaker 3: if that event loop is able to turn over very
Speaker 3: very quickly accept a new request, except a new request
Speaker 3: while it's processing other things while it's waiting for that
Speaker 3: other step to happen, if it's able to keep processing things,
Speaker 3: then you're going to see a higher utilization. That basically
Speaker 3: means your event loop is doing more more efficiently. I
Speaker 3: hope that's there's a whole paper.
Speaker 1: On it, Okay, but I'd be happy to have a
Speaker 1: link to that paper. But one thing does concern me.
Speaker 1: It does seem that if I pull in like the
Speaker 1: first event, and that triggers an infinite computation, which means
Speaker 1: all the other things are just stuck in the queue forever,
Speaker 1: my event loop utilization would still appear to be great
Speaker 1: because I'm just processing forever.
Speaker 6: Like is that more?
Speaker 1: Am I missing something?
Speaker 3: Yeah? Missing some of the details. It takes some of
Speaker 3: those those things into consideration. The paper goes into a
Speaker 3: lot more detail, and this was done by trepreneurs at
Speaker 3: notes source that the blog post he wrote on this
Speaker 3: initially introducing it answers pretty much all the questions about it.
Speaker 3: It is one of the best research you.
Speaker 4: Can You can take event loubutalization and in a slightly
Speaker 4: different way. Okay, consider this an event look delay or
Speaker 4: event look blog.
Speaker 6: Okay. It's a metric okay that you can measure after
Speaker 6: there is a lag.
Speaker 4: Okay, however, you only have a lag okay if your
Speaker 4: event loop is very busy, correct, Okay. Event loopertilization is
Speaker 4: able to tell you that the event your event loop
Speaker 4: is getting busy, so you can act on it way
Speaker 4: sooner then the event loop at Okay.
Speaker 6: In fact, is it much.
Speaker 1: Basically what you're saying. What you're saying. If I'm taking
Speaker 1: too long to process user requests, but I have very
Speaker 1: few users, then I might not notice that I have
Speaker 1: a problem, and by the time I do realize I
Speaker 1: have a problem, it's kind of too late in a
Speaker 1: sense because users are already suffering. What you're saying is
Speaker 1: with event loop utilization, I'll be noticing it much earlier
Speaker 1: and be able to respond to it, you know, in advance.
Speaker 1: It's really interesting I very much would like to look
Speaker 1: at the paper it's.
Speaker 3: It does. Go ahead, and I'll just mentioned real quick.
Speaker 3: The other thing that it does is it tells you
Speaker 3: how well you're scaling, and it gives you a much
Speaker 3: more accurate scaling point. So a lot of applications previously
Speaker 3: would look at CPU usage right and when when Note
Speaker 3: process is primarily just one thread, one main application thread.
Speaker 3: Before we had worker threads, that was an okay measurement,
Speaker 3: but it was still pretty noisy. As soon as we
Speaker 3: introduced worker threads, the CPU monitoring just goes out the
Speaker 3: window because it becomes way too noisy because you're you know,
Speaker 3: because it's it's not fine grained enough to be able
Speaker 3: to show you individual event loop processes. Uh. The event
Speaker 3: look utilization is per event loop, so it's per worker thread,
Speaker 3: and it gives you a much better signal at where
Speaker 3: you where and when you need to start scaling your
Speaker 3: application to multiple processes and multiple worker threads. Uh. You know,
Speaker 3: you know, better than any other metric that I've seen,
Speaker 3: this is the one that gives you the best, the
Speaker 3: best accuracy for that.
Speaker 1: And monitoring systems these days do they expose this metric.
Speaker 6: Well.
Speaker 4: Plus formatting does so. Sorry for the for the pon here,
Speaker 4: but yeah, we would product our product absolutely, but also
Speaker 4: all our open source expose this metric on as part
Speaker 4: of the promissious integration, so you can essentially take it
Speaker 4: and consume it and so on and sup forth. The
Speaker 4: important part is that you want you want to set
Speaker 4: your out of scale to uh, look at this metric
Speaker 4: versus CPU. Okay, if you if you look at CPU usage,
Speaker 4: you are typically is too luggy.
Speaker 6: Okay.
Speaker 4: Once, once you see once the horizontal product of scaler
Speaker 4: see that stuff, you are you are already in trouble.
Speaker 6: Okay.
Speaker 1: But it's not a metric that's built into no or whatever.
Speaker 3: There's no like no evens there's an API board. Yeah,
Speaker 3: there's an a p I built into it directly in
Speaker 3: the it's part of the perfect.
Speaker 6: Say you need to enable it in from client.
Speaker 1: Very cool, very cool. We'll definitely look at it. Thank
Speaker 1: you for that. Anything else about pillar number two? Okay,
Speaker 1: the and moving on to pillar number three news node
Speaker 1: LTS versions in production. I think it even though people
Speaker 1: listening to us should be familiar with node, I think
Speaker 1: it's worthwhile to mention what node LTS versions actually mean.
Speaker 3: Yeah, long term supports.
Speaker 5: Basically, Michael, you want to take it, sure, Yeah, like
Speaker 5: long you can go to the website on the GitHub.
Speaker 5: It's like no gs slash release, it'll have our schedule
Speaker 5: the you know, every it's very predictable release schedule. We
Speaker 5: have a current which happens every April and October, and
Speaker 5: then every even current gets promoted to long term support.
Speaker 5: And long term support means I think it's thirty months
Speaker 5: of support, so it lasts from you know, October this
Speaker 5: year for example, to April two and a half years
Speaker 5: from now, and so the odd currents they only have
Speaker 5: six months of support. So you know why we say
Speaker 5: you really want to stick to the long term support
Speaker 5: versions is that you know, that's the longest period of
Speaker 5: time that you can sort of be on a version
Speaker 5: that's not going to go out of service. And back
Speaker 5: to AG's point of like, we don't want to change
Speaker 5: things any anytime. We don't want to change them because
Speaker 5: it costs us money, right, So you want to basically
Speaker 5: look at the release schedule and pet the LTS.
Speaker 2: It's going to give you the longest runway.
Speaker 5: And you know, I'd also say, like schedule, you don't
Speaker 5: have to move up to every LTS because we have
Speaker 5: multiple overlapping LTS is we either have like two or
Speaker 5: three usually going on at the same time. So if
Speaker 5: it was me, I would basically say, like, okay, when
Speaker 5: am I want to go into production, let's plan to
Speaker 5: have the closest LTS and then you know, two years
Speaker 5: later I should plan on like, okay, now let's plan
Speaker 5: for upgrading that particular version of the next LTS. There
Speaker 5: are multiple phases in LTS as well. There's like an
Speaker 5: active phase where we backport changes quite quickly, so if
Speaker 5: you want to get new features, they still go into
Speaker 5: those LTS releases, but about after the first and I'm
Speaker 5: thinking it's eight months ish now I'd have to look
Speaker 5: exactly at the numbers. It then flips into maintenance, where
Speaker 5: things are more like as needed security, security fixes, that
Speaker 5: kind of stuff.
Speaker 1: Why do non LTS versions even exist and why would
Speaker 1: I ever use one of them?
Speaker 5: See that there are people who want to be on
Speaker 5: the bleeding edge, and so those ones give you based
Speaker 5: on our schedule.
Speaker 2: We feed things into those non.
Speaker 5: LTS versions first, so if you want to get the
Speaker 5: very latest, greatest, you can try them out there, and
Speaker 5: we do appreciate that people test them out for us
Speaker 5: and give us feedback. And you know, so if you
Speaker 5: want to take advantage of a new feature, we really do.
Speaker 5: People want want people to try those out and give
Speaker 5: us that early feedback.
Speaker 2: And there have been cases were I've there have been
Speaker 2: cases where I've had to use a non LTS because
Speaker 2: there was a critical feature particular related to web crypto
Speaker 2: or fetch or one of those standards that is cross
Speaker 2: platform standard for JavaScript that was only available first in
Speaker 2: the in the non LTS. Right now, for example, nodes
Speaker 2: ESM support has finally completed, but it won't be available
Speaker 2: until what V twenty four without the flag, so I'll
Speaker 2: probably update to V twenty twenty.
Speaker 3: Twenty three.
Speaker 2: How are you sure?
Speaker 1: AJ?
Speaker 4: Now I have a very good news for you. I
Speaker 4: am really very good news. We are likely thinking of
Speaker 4: backparting it to twenty two.
Speaker 1: Yeah.
Speaker 2: Oh sweet, that's great. Yeah, that's that's that's amazing. Yeah,
Speaker 2: because that that's something I've not been using ESM because
Speaker 2: you know, like, why would I publish something to NPM
Speaker 2: that breaks everybody else's stuff and everybody else has to transpile,
Speaker 2: But then all those people using bundlers anyway, like you know,
Speaker 2: sm just didn't make any sense. And then when I
Speaker 2: saw that, I was like, yeah, finally I get to
Speaker 2: to not have to screw around with all this you know,
Speaker 2: window crap.
Speaker 3: This raises, this raises the good point. It's like why
Speaker 3: do we have this, you know, the schedule you know,
Speaker 3: back if you think back to when before node niogs,
Speaker 3: Node was originally going way too slow. I just came
Speaker 3: and was going way too fast. So the CELTS schedule
Speaker 3: was a you know, let's find a middle ground, like
Speaker 3: we're going to have one LTS per year, but why
Speaker 3: do two majors? And the reason for that is because
Speaker 3: the ecosystem needs to be able to have these features
Speaker 3: out at a faster rate than only one release per year.
Speaker 3: And so you know, the the the short term like
Speaker 3: odd numbered currents, those are primarily to help the developer
Speaker 3: ecosystem in Node, not the like enterprise you know, production users.
Speaker 3: Then it's there to help like the module developers and
Speaker 3: the ecosystem that are producing all of these dependencies keep
Speaker 3: up on a rate of change and allows Node to
Speaker 3: be you know, to know like what's actually being used?
Speaker 3: How does this need to be evolved? You know, you know,
Speaker 3: like actually get used to these things before it goes LTS,
Speaker 3: before it goes where we have to maintain something long term.
Speaker 1: And it's still considered to be a stable version, an
Speaker 1: official stable version, So I'm not like working on some
Speaker 1: beta or whatever. I am working on an official version.
Speaker 1: I just get the let's call it modern or bloody
Speaker 1: bleeding edge features sooner and I don't have to wait
Speaker 1: a full year, yes for that stuff, and I can
Speaker 1: have it ready in advance of that LTS release.
Speaker 5: It still respects semver, so you can expect that there
Speaker 5: shouldn't be really any breaking changes, but features going more quickly,
Speaker 5: and it really does help us in terms of like
Speaker 5: the versions we promote to LTS. It's great to have
Speaker 5: that six months as a current because that really helps
Speaker 5: us find out, like, are there an things that we
Speaker 5: missed in terms of like did something was it more
Speaker 5: breaking than we expected? And you know means sort of
Speaker 5: that six months means that by the time we go
Speaker 5: to LTS, we have a much better chance of it's
Speaker 5: just being worrying for everybody, which is what we like.
Speaker 1: I really want to be respectful of all your time.
Speaker 1: We are nearing the time usually where we start pushing
Speaker 1: towards picks. I'd love to continue this conversation for now.
Speaker 1: It's also easier earlier for me because we've switched to
Speaker 1: daylight savings, and you guys well off of daylight savings,
Speaker 1: and you guys are still, at least in the States,
Speaker 1: are still there. So I don't know how long you
Speaker 1: guys can go. Do we have another thirty something minutes
Speaker 1: or do we need to start thinking about wrapping up?
Speaker 3: I got time?
Speaker 2: Yeah, I'm okay, I'm okay.
Speaker 1: Okay, let's keep on going at least for a while.
Speaker 1: Let's see how far we can push it. Anything else
Speaker 1: about this pillar before we go to the next one,
Speaker 1: which is a whopper? Okay? Then, so pillar number four,
Speaker 1: it's automated testing, code review, and conformance as much as possible. Again,
Speaker 1: this is like an absolute truism of software development that
Speaker 1: has you know, it's true for note, but it's practically
Speaker 1: true everywhere else in the world. By the way, there's
Speaker 1: this click, so I don't know where it's coming from,
Speaker 1: but guys, please be aware that there's like this clicking
Speaker 1: sound going on anyway. So what do we have to
Speaker 1: say about automating tests and code reviews and conformance that's
Speaker 1: no specific or is it just you know do it?
Speaker 5: I think what my perspective on this would be is that,
Speaker 5: you know, one of the advantages white people we here
Speaker 5: use nogests is that they can move really quickly and
Speaker 5: they can innovate quickly. For me, that's great if you
Speaker 5: can move quickly, but it makes your testing and your
Speaker 5: regression tests all the more important. So while this is
Speaker 5: very important in most cases, it's even more important when
Speaker 5: you're moving fast, and because no lets you move fast,
Speaker 5: that's why it's so relevant to me.
Speaker 1: I'm totally I totally agree. Part of my job at
Speaker 1: almost everywhere that I've worked in the past over a
Speaker 1: decade is going into existing projects and starting to mess
Speaker 1: with them and literally break them. And like, the difference
Speaker 1: between between having tests and not having tests is like
Speaker 1: life and death. Literally, It's it's like, am I how
Speaker 1: confident do I feel even going into this project?
Speaker 2: Yeah?
Speaker 5: It's like if you can make if you can make
Speaker 5: a change, run the test suite and feel pretty comfortable
Speaker 5: that it's not going to the world's not gonna light on.
Speaker 3: Fire, that's what lets you move fast.
Speaker 2: Don't if you're like, oh, I made a.
Speaker 5: Change, but nothing's testing this. You're you're always very cautious, right,
Speaker 5: I think, and you're not going to go as fast.
Speaker 1: Now you did differentiate between like the three different kinds
Speaker 1: of tests that people usually talk about, which is unit tests,
Speaker 1: integration tests, and end to end tests. Now I'm curious,
Speaker 1: like because I hear people, different people putting different emphasis
Speaker 1: on different types of tests. So I hardly ever encounter
Speaker 1: people who say, you know, you don't need tests, But
Speaker 1: I do encounter people who say, you know, it's all
Speaker 1: about the end to end tests, and other people are saying, no,
Speaker 1: it's all about the unit tests and so forth. So
Speaker 1: I am curious where you guys, which camp you guys
Speaker 1: fall in, if you even do fall in a camp.
Speaker 3: For me, I don't necessarily care about the type of test.
Speaker 3: I care about the test coverage. And I know a
Speaker 3: lot of people, you know, have a problem with chasing,
Speaker 3: like you know, complete test coverage and stuff.
Speaker 1: I don't measuring test coverage.
Speaker 3: Right, I don't care necessarily what kind of test it is.
Speaker 3: I care about is this line of code tested? And
Speaker 3: too often, you know, you know, folks will only test
Speaker 3: the happy path, you know, the only the right test
Speaker 3: based on what they want the code to do, not
Speaker 3: based on what the code actually does. Uh, and they
Speaker 3: end up missing, like you know, coverage on half the
Speaker 3: branches that their code, that their code takes or could take,
Speaker 3: and then they get it into production or make some
Speaker 3: kind of refactoring change and things just break.
Speaker 1: My one of my problems with end two end tests,
Speaker 1: which on the face of on the face of it,
Speaker 1: and to end tests like like they have like they
Speaker 1: could have been the best tests because they literally test
Speaker 1: the system as it should work, but they're from my perspective,
Speaker 1: there are two main issues with it. One is that
Speaker 1: they can run pretty long, which means that people run
Speaker 1: them less often. And the other problem is that testing
Speaker 1: coverage with end to endests, or achieving good coverage with
Speaker 1: end to end tests can be pretty challenging.
Speaker 5: I think a lot of times, as I say, I
Speaker 5: think I'd agree with kind of the challenges, like the
Speaker 5: I think the end N tests like along with that
Speaker 5: is it's sometimes harder to figure out what went wrong,
Speaker 5: or like you made a tiny change and you only
Speaker 5: if you only find that in your end end test,
Speaker 5: it's probably going to be hard to figure out what
Speaker 5: that tiny change is versus.
Speaker 1: List you founders before production.
Speaker 5: Yeah, no, no, So I think it's a balance between
Speaker 5: the two, right, Like I think having unit tests, which
Speaker 5: gives you really good coverage of the very specific things,
Speaker 5: will help you find like, hey, I just made a
Speaker 5: commit and I broke something like on the you know,
Speaker 5: but worlsthing small. I can find that very easily. And
Speaker 5: so you want you want as much unit testing as
Speaker 5: you as you as you can afford to cover you know,
Speaker 5: find those things. But then you still definitely need the
Speaker 5: end to end tests. But you probably don't need to
Speaker 5: test every single thing in the end t end test because,
Speaker 5: like you said, that quickly becomes too long, and you
Speaker 5: know you can't run it as often. Right, So it's
Speaker 5: finding that right balance between you know, having your unit
Speaker 5: tests that can fail, only they won't be able to
Speaker 5: cover everything in the end to end style, but covering
Speaker 5: as much as you can, and then as much of
Speaker 5: the the end end testing is as practical so that
Speaker 5: it still gets run on a regular basis.
Speaker 1: Also, it's much closer to the actual code, so you're
Speaker 1: much less likely to miss branches, at least at the unit.
Speaker 3: Level, right, And a lot of times the integration tests
Speaker 3: are incapable of testing particular branches, like particularly if their
Speaker 3: edge cases or you know, should only happen in like
Speaker 3: critical failure situation where you're into end test isn't actually
Speaker 3: able to trigger those right because it's it's meant to
Speaker 3: be some internal failure or IO is failing in some
Speaker 3: case actually make it make likely.
Speaker 1: Yeah, we all know the remedy to to a critical
Speaker 1: problem which is consoler.
Speaker 3: Mm hmmm, of course.
Speaker 2: Yeah.
Speaker 1: Okay, anything else we want to say about tests, any
Speaker 1: recommendations about the systems you guys use for testing, Any
Speaker 1: particular system or mechanism I should be using as a
Speaker 1: node developer.
Speaker 3: Use no tests, use the new test framework, builped into
Speaker 3: the run time.
Speaker 6: What I can tell is what not to use. Okay,
Speaker 6: don't you just make yourself a faire No, this is true.
Speaker 4: Okay, if you're building a node system, just as a
Speaker 4: lot of good features. If you're building if you're using
Speaker 4: it for some of the front and meta frameworks, okay,
Speaker 4: But if you're building another app and EPI or something
Speaker 4: like that, don't use it, I recommend because you cannot
Speaker 4: test hundred percent of the branches with it, and therefore
Speaker 4: it completely defeats the purpose of a testing framework. So
Speaker 4: if I can't, why is that by the way, because
Speaker 4: the monkey branches globals.
Speaker 6: So if the no emits an error in one of
Speaker 6: his own APIs in.
Speaker 4: However, the error object is not create is different and
Speaker 4: the one that just is put in the global. So
Speaker 4: if you do error instance of error, it tron folds
Speaker 4: even though it's an error.
Speaker 6: You don't know.
Speaker 1: Well, now we have the j aspective error is error.
Speaker 3: I mean that that should that should help. But but yeah,
Speaker 3: with with Justin in the fund, just Jesment, a couple others,
Speaker 3: you know, had this issuable floor where the test and
Speaker 3: it's get the test you write ends up testing the
Speaker 3: mock rather than testing, you know, the actual run time
Speaker 3: the actual code. We had this problem workers, you know
Speaker 3: for the longest time. We're doing local tests, you know,
Speaker 3: because our test framework originally, like that client side part,
Speaker 3: the original version of many flour, was actually running a note.
Speaker 3: So when you would go to all protecting your worker
Speaker 3: and test it, you were actually testing it against nodes
Speaker 3: implementation of something like readable stream. And then you actually
Speaker 3: go to run at the runtime and oaks it breaks
Speaker 3: because we have slight differences and you know, we're getting
Speaker 3: away from that now where you can actually test them
Speaker 3: the actual production code. But a lot of these testom
Speaker 3: works like just have that fundamental problem where you're not
Speaker 3: testing the thing you're actually running.
Speaker 5: And I think Mitaylo's point might be like, it has
Speaker 5: some advantages if you're you know, closer to the front
Speaker 5: end side of things, but if you're really just a
Speaker 5: node micro service, you might be better served by something
Speaker 5: that's more no focused versus that.
Speaker 1: And in that case, just use the built in node
Speaker 1: testing framework. Yeah cool, Okay, moving on to the next one,
Speaker 1: and I think you know what we'll see if this
Speaker 1: is the last one, or we'll manage to get to
Speaker 1: number six. It's kind of stopping in the middle. If
Speaker 1: we stop in this one, and then we'll give us
Speaker 1: an incentive to do another episode. I'd love to have
Speaker 1: you guys on again. This is such an awesome conversation. Okay,
Speaker 1: then number five and again, this is just a golden
Speaker 1: rule in software development, but I think it has special
Speaker 1: meaning in the context of node and that's avoid dependency creep.
Speaker 1: Can we explain what dependency creep means in general and
Speaker 1: what it means specif defically in NOE. So this is.
Speaker 4: Probably one of the most misunderstood practice, especially lately. It's
Speaker 4: like the node has been at the success it had
Speaker 4: only because it was able to solve one specific problem.
Speaker 4: In fact, NO didn't do it, and PM did it
Speaker 4: found a way to do software reuse at massive scale.
Speaker 6: Okay, and by by what ques mechanism?
Speaker 1: Well, by allowing it turns out that your substantial portion
Speaker 1: of that reuse pretty much.
Speaker 4: I don't know if it's a good thing or a
Speaker 4: bad thing, Okay, I am one of like I think.
Speaker 1: I have that you're that guy from the x k
Speaker 1: CD strip about that. It's sortaally it ye, yes, so.
Speaker 6: The that's it.
Speaker 4: Okay, So it's avoid dependency cree so not jes at
Speaker 4: the massive success due to this software used. It allows
Speaker 4: you to, for example, use different versions of the same
Speaker 4: libraries in different dependency trees of your app.
Speaker 6: Okay.
Speaker 4: This means that you can have and this happens very often,
Speaker 4: readable stream one in your code based, retable stream two
Speaker 4: in your code based litable Steam three in your code base,
Speaker 4: and readable steam four.
Speaker 6: Okay, and when I will ship five, you likely have five.
Speaker 6: We'll have five. Okay. That's what it is.
Speaker 4: Okay, so there is there are some modules that get
Speaker 4: a lot of that are and a lot of dependency
Speaker 4: change because typically for the typically historic reason and at
Speaker 4: that point in time it's they were useful, but now
Speaker 4: probably way less. So so maybe you should stop using
Speaker 4: readable that stream and maybe start using you know, not
Speaker 4: they're not just an austream module.
Speaker 6: Because that's all of it. But however there's a lot
Speaker 6: of things where you still want to use that module.
Speaker 6: And therefore here we are. Okay, so you.
Speaker 1: Made actually two points here. I think first of all,
Speaker 1: you're saying node itself is advancing and it's offering many
Speaker 1: built in features that in the past did not exist
Speaker 1: that in the past we would have needed to bring in,
Speaker 1: like third party libraries. Now they're building features in the platform.
Speaker 1: And as with the browser, whenever I can leverage an
Speaker 1: existing part of the platform rather than bringing in a dependency,
Speaker 1: it's it's almost always a good idea. It's going to
Speaker 1: be a stable API or well tested service. API is
Speaker 1: going to be there forever, I don't need to worry
Speaker 1: about maintainability, about security, about who gets ownership of it
Speaker 1: and starts pushing malware into it or whatever. And it's
Speaker 1: probably going to perform better and so many advantages. So
Speaker 1: that's an obvious thing. But the other point you're saying
Speaker 1: is that I should be wary of having multiple versions
Speaker 1: of the same package running within my single node instance.
Speaker 1: Now I understand why it's a bad thing on the
Speaker 1: browser side, because I've actually seen a browser based application
Speaker 1: deliver three different versions of moment js which resulted in
Speaker 1: like a huge download, which is a problem on the client.
Speaker 1: Why is it a problem in my node server?
Speaker 6: Though, the first problem is related to your surface attack.
Speaker 4: Okay, the more dependency you have, the more you are
Speaker 4: exposed to potential attack. You want to have genetically dependency
Speaker 4: that you need and only the dependency that.
Speaker 6: You need in your tree. Okay.
Speaker 4: So this is the first point okay, which you know
Speaker 4: each one is a vector, is a potential attack factor,
Speaker 4: so you need to treat them like that, okay. And
Speaker 4: the other stuff is it increases significantly the install time
Speaker 4: of the application. So if you do and increases I
Speaker 4: don't know, see I time, okay, just attending bit Okay,
Speaker 4: but then another app can have easily three four thousand
Speaker 4: dependencies once all of a sudden done. And then you
Speaker 4: start saying, oh, Okay, can I just maybe remove a
Speaker 4: thousand of those?
Speaker 6: Okay? Each one of them needs to be downloaded independence,
Speaker 6: you know, I'm just like a lot of them, like
Speaker 6: some of them that are trivia, okay, and frankly they should,
Speaker 6: you know, not be molelized, but there we are. And
Speaker 6: some of them they need to.
Speaker 3: Be down leveled, right, I mean, they just people just
Speaker 3: don't update their dependencies when they can, and so some
Speaker 3: of them end up just being brought in just because
Speaker 3: somebody decided not to update.
Speaker 1: It's it's also the fact that it's like it's like
Speaker 1: like this sort of a skeleton, like the hip bone,
Speaker 1: like how that song go the hip bones connected to
Speaker 1: the high bone and so forth. So you bring in
Speaker 1: one note package and that brings in two more, which
Speaker 1: bring in eight more, which bring in sixteen more, and
Speaker 1: and all of a sudden you have like the entire
Speaker 1: universe downloaded into your node instance. And you did put
Speaker 1: that comic strip in your article about how the NPM
Speaker 1: modules folder is heavier than a black hole. How how
Speaker 1: how do I contend with that?
Speaker 5: You know, I think the principle was about, like be
Speaker 5: more intentional about that. If you're gonna you can easily
Speaker 5: pull in a package and you're using some small part
Speaker 5: of that package, and but take you should take a
Speaker 5: look at like, what all did that pull in? If
Speaker 5: that pulled in one hundred other packages and you've effectively
Speaker 5: replaced ten lines of code that you might have written yourself,
Speaker 5: maybe you should just put the ten lines of code
Speaker 5: in right, so you know, as Matteo said, the reuse
Speaker 5: is one of the fast fantastic things about the ecosystem.
Speaker 5: It's really easy to pull in code and reuse it.
Speaker 5: That's great, But I think we could use a little
Speaker 5: bit of a shift towards being a little bit more
Speaker 5: intentional and looking at what you're pulling in versus the
Speaker 5: benefit you get, so that you're you're sort of doing
Speaker 5: the right balance between hey, I'm reusing code easily versus
Speaker 5: the sort of risk that I'm taking on because you know,
Speaker 5: I've got a huge amount of code. It's not just
Speaker 5: the attack factor. What if there's a bug do you
Speaker 5: want to have fixed? You know, are you able to
Speaker 5: do that yourself? If not, that's something you should probably
Speaker 5: at least think a little.
Speaker 2: Bit about it.
Speaker 1: Yeah, maybe you don't actually need left pad right, like, yeah,
Speaker 1: you know, yeah, The sad thing is that, given the
Speaker 1: average experience of developers, there's a good chance that half
Speaker 1: our listeners don't even get that joke about left pad
Speaker 1: because they came into the industry after it happened. Yeah.
Speaker 2: Well, the question is are they still using it today.
Speaker 1: There's a good chance that they are, though, but they
Speaker 1: probably don't know it because they're probably you not using
Speaker 1: it directly, they're probably using something that uses something which
Speaker 1: uses left pad.
Speaker 2: I think we need an ethos change to be more
Speaker 2: like Go and Zig and other same languages, make the
Speaker 2: standard library great again, and get rid of all the
Speaker 2: crap dependencies that I mean, there's so much many even
Speaker 2: security dependencies where the people who are doing it obviously
Speaker 2: don't know what they're doing. You can't blame them because
Speaker 2: no one who did know what they were doing was
Speaker 2: doing it right. But I remember one of the early,
Speaker 2: very very popular OTP libraries was atrocious. You know, there's
Speaker 2: there's there in our industry, I think because of there
Speaker 2: being so much money available, and thank goodness, there isn't now.
Speaker 2: I actually think I hope that the interest rates stay high.
Speaker 2: I hope they don't go down for the sake of
Speaker 2: our industry for the sake of you know, lots of
Speaker 2: other things. Maybe I don't know, but our industry was
Speaker 2: ruined by low interest rates because with free money, there
Speaker 2: was no responsibility to a customer, and then there was
Speaker 2: no there was no craftsmanship, and and then it became
Speaker 2: it became an ego thing like, look, I don't know
Speaker 2: what I'm doing, and I'm getting so much done anyway. Look,
Speaker 2: I don't understand how this frame work works. I don't
Speaker 2: understand how the library works. But look how great I
Speaker 2: am anyway, and we need some sort of an ethos
Speaker 2: change to like, Hey, I'm able to do this with
Speaker 2: just the standard library. Isn't that pretty cool? Hey I'm
Speaker 2: able to understand how my code works. Hey I've got
Speaker 2: a handle on what my application is doing. Because if
Speaker 2: we don't have that etho shift, then we're we're gonna
Speaker 2: get stuck in this the same rut that we're in.
Speaker 2: I mean, like we're not going to leave the right
Speaker 2: We're already stuck in the run. We're not going to
Speaker 2: get out of it.
Speaker 1: So an interesting thing that I have to mention. So
Speaker 1: a few episodes back, we've had we had Ryan Doll
Speaker 1: as a guest to talk about dn O two when
Speaker 1: it came out. Now, interestingly, when DNO itself first came
Speaker 1: out dn O one, one of the things about it
Speaker 1: was that they avoided NPM and did try to provide
Speaker 1: like their own more significant built in standard library. And
Speaker 1: the thing about DNO two is that they will, surprise, surprise,
Speaker 1: they now support NPM because it turns out that we
Speaker 1: without supporting NPM, you can't really.
Speaker 2: Get enough investment.
Speaker 1: Well, not that you can't really build practical things, especially
Speaker 1: for the enterprise users.
Speaker 3: You just want to use users want to reuse NPM models.
Speaker 3: I mean, that's all it is. So that that that
Speaker 3: that the whole joke about NPM being as black hole,
Speaker 3: that's exactly it. It's got such a massive gravity in
Speaker 3: the ecosystem that you cannot avoid it, right and right.
Speaker 2: But I don't I don't say I'm not going to
Speaker 2: go use go because I don't have NPM, or I'm
Speaker 2: not going to use Rust because I don't have NPM. Right.
Speaker 2: I mean, when you create something new, when you create
Speaker 2: something that's fundamentally different, you have the liberty to not
Speaker 2: take the baggage you know from from prior years, Like
Speaker 2: you don't you don't use C and and well, in
Speaker 2: some rare cases you use see and go like seq
Speaker 2: light or something like that. But you know, in other languages,
Speaker 2: they're not They're not afraid to say, Hey, one of
Speaker 2: the reasons we're creating a new language and a new
Speaker 2: platform is because we want to leave the crap. We
Speaker 2: don't want the craft to come with us. I'm not
Speaker 2: I'm sad that Dino conceded on that point.
Speaker 5: I'm not convinced the other languages have have totally I've
Speaker 5: necessarily necessarily done better. They may be in at a
Speaker 5: different point on their journey, Like I know and Go.
Speaker 5: I'm I'm working on build packs for no jest. They're
Speaker 5: written and go. That's the place we actually have like
Speaker 5: a dependencies that's deleted, that's preventing things from being updated.
Speaker 5: And so, like you know, NPM has gone through a
Speaker 5: fairly long learning process, and some of these other languages,
Speaker 5: like it'll be interesting to see if they end up
Speaker 5: in the same place, or you know, they just haven't
Speaker 5: hit some of the challenges that you get with the scale.
Speaker 2: That note has gotten to you.
Speaker 1: I'm trying to remember who said it. It might have
Speaker 1: been Con't. I don't remember, but basically they said that
Speaker 1: without NPM, we wouldn't have had carbon. So so even
Speaker 1: even though even though NPM is not perfect, it's the
Speaker 1: most used and that definitely says something.
Speaker 2: Yes, yeah, I am said that they based Cargo around
Speaker 2: n PM because it shows and it's got a lot
Speaker 2: of the same problems, whereas the Go Package Manager is
Speaker 2: empirically as perfect as it can be, meaning that it
Speaker 2: has the fewest trade offs and you can prove that
Speaker 2: mathematically looking at the graphs, and there's attack where that's
Speaker 2: been done, so that that is really sad that we
Speaker 2: actually have something that we know both mathematically and practically
Speaker 2: works out and we still choose other things.
Speaker 6: Well, there was not there, like they go back.
Speaker 2: M I know, yeah, for NPM, I know, but I'm
Speaker 2: saying cargo, but like it's it's sad.
Speaker 6: Was not there, Sorry, it was not there. I think
Speaker 6: it's Cargo pre dates the Go back.
Speaker 1: Yeah. Yeah.
Speaker 4: I came out very very very late in the game,
Speaker 4: and for a long time, Go was in fact the
Speaker 4: original Lino one.
Speaker 6: Package package Management.
Speaker 4: We came out from Dino from GO and they just said,
Speaker 4: well you point us, do you point it to a URL?
Speaker 6: And then it downloaded and they it handled it.
Speaker 4: It handled it, okay, which was essentially our dependency we're
Speaker 4: managing go prior to that.
Speaker 2: Okay, yeah yeah yeah for the model repost, yeah, that
Speaker 2: was definitely yeah, Okay, I see what you said. Yeah,
Speaker 2: because the it came out in twenty eighteen and then
Speaker 2: it was and it was confirmed final in twenty nineteen,
Speaker 2: which it seems that's more recent than what it seems like.
Speaker 2: It seems like it was a longer time ago. But
Speaker 2: then I guess Rust wasn't really even hitting popularity until
Speaker 2: after twenty eighteen. So when I think about it, I
Speaker 2: my memory is wrong, My memory is corrupt. I'm faulty.
Speaker 2: My bad.
Speaker 3: Yeah, I mean is going back to something, you know,
Speaker 3: the kind of the original thing with the tendency creep
Speaker 3: and everything else. So NPM, like I said, it has
Speaker 3: this massive grab and if if you know, folks are
Speaker 3: using those modules, they want to keep they want to
Speaker 3: keep using them. Unfortunately, there's just so many modules on
Speaker 3: them they don't need to use. My canonical example, if
Speaker 3: you go out there, and I don't want to like
Speaker 3: pick on it too much, but there's a module out
Speaker 3: there called is even all it.
Speaker 2: Does that's parody, that's a joke.
Speaker 3: It doesn't matter. I've seen people use it. It doesn't
Speaker 3: matter if it's a joke because people I've actually seen
Speaker 3: people use this in their code.
Speaker 2: Because not a joke. They used it as not a joke, yes,
Speaker 2: because it was that's story.
Speaker 3: It is scary. But I I know, my the first
Speaker 3: time I I found that isn't even module, which all
Speaker 3: it does is is pull in is odd module and
Speaker 3: negate it.
Speaker 2: And that has a list of a million numbers, right
Speaker 2: or something like that. It's it's not even something simple
Speaker 2: like doing mod no, because I know one of the
Speaker 2: parody modules just has a list of numbers like one
Speaker 2: to a million, and then for every other one returns true. Okay,
Speaker 2: so it's not that bad.
Speaker 3: Now this actually does work, you know, and we'll check
Speaker 3: to the validate that the input is a number and
Speaker 3: you know, and that kind of thing that is odd.
Speaker 3: But all is even does is pull that in and negated.
Speaker 3: I've seen you know, there are a ton of moneys
Speaker 3: on NPM that like you just don't need, and people
Speaker 3: pull them in anyway because they're not thinking about it.
Speaker 3: They're not being intentional about it. Going back to Michael's
Speaker 3: ear their point or they don't understand what the model
Speaker 3: is actually doing, right, and that's what they need to
Speaker 3: be focusing on. Goes back to the same thing with
Speaker 3: it we have a problem intentional about what you're doing.
Speaker 1: I have a problem with that statement because, to a
Speaker 1: great extent, the whole idea if of reuse is that
Speaker 1: I don't need to think about the implementation details. I
Speaker 1: can basically just look at the API surface and be
Speaker 1: content with that. If I assume, if I can assume
Speaker 1: let's call it a good a good actor, if I'm starting,
Speaker 1: if I if I need to start looking under the
Speaker 1: hood of every n PM module that I'm using, why
Speaker 1: am I even using these modules?
Speaker 3: It comes back to the you know, being intentional about
Speaker 3: it right to some extent, Yeah, but you have to
Speaker 3: understand as a trade off, if you don't understand what
Speaker 3: the module is doing, it might be doing something incredibly
Speaker 3: you know performance, you know costly, and you and sudden
Speaker 3: your application is slowing down. You go into production. Why
Speaker 3: is it slowing down? Well, you know, Michael and I
Speaker 3: countless countless of consulting uh jobs. We went out and
Speaker 3: found Hey, it's your dependencies that are slowing you down
Speaker 3: because they're just not you know, written to be very
Speaker 3: performing in any way. In prose ball, we didn't know that.
Speaker 3: If we had known that, we wouldn't have used it. Well,
Speaker 3: you know, do some digging, you know, look at what
Speaker 3: your dependencies are doing, you know it. You have to
Speaker 3: be aware of.
Speaker 2: The a good metric because I think that with rails
Speaker 2: and I don't think that this necessarily was what the
Speaker 2: Rails community intended, but it bad pun you know, the
Speaker 2: idea went off the rails uh dry right, don't repeat
Speaker 2: yourself became it became a sacred cow that people didn't
Speaker 2: understand and they just started to say it without knowing
Speaker 2: what they were saying or what it was supposed to mean.
Speaker 2: And this don't repeat yourself became this you know this
Speaker 2: this religious uh month fervor. And I think a good
Speaker 2: metric would be what does the number of letters you
Speaker 2: have to type to search for it or or or
Speaker 2: query for it exceed the number of characters you would
Speaker 2: have to type in order to implement it. Because if so,
Speaker 2: you're on the wrong track. You should just copy and
Speaker 2: paste that code or type it out again.
Speaker 1: It'll be interesting to see if AI code generators make
Speaker 1: a dent in this if people can instead of pulling,
Speaker 1: and if they actually make an improvement. Also, if somebody,
Speaker 1: instead of pulling in a module that does something, can
Speaker 1: stell like chat, GPT or copilot or whatever, right me
Speaker 1: code that does that thing and then copy pastes it
Speaker 1: into their code, is that better or worse?
Speaker 2: I have had great success with chat GPT, writing far
Speaker 2: better code than what exists in the ecosystem that I
Speaker 2: could find. And I'm not just looking at modules that
Speaker 2: have the fifteen hundred plus stars. I'll look for things
Speaker 2: that have ten or no stars. I'm just looking for
Speaker 2: the best code that's available, and I'll go peek at
Speaker 2: the source code. Two things that come to mind. One
Speaker 2: was Shot two fifty six, because web crypto has Shot
Speaker 2: two fifty six, but it's really really slow because of
Speaker 2: the context switches and the async. So if you need
Speaker 2: Shot two fifty six for anything more than a one off,
Speaker 2: I would not recommend using web Crypto. So all these
Speaker 2: modules on NPM that have Shot two fifty six, they're
Speaker 2: all really legacy there. You know, some of them are
Speaker 2: using a transpiled buffer implementation from node like. None of
Speaker 2: them are using unaight array and modern JavaScript. They're all
Speaker 2: like decrepitly old. And I asked GPT to write me
Speaker 2: from scratch a shot two fifty six, and I was
Speaker 2: so skeptical. I spent two hours testing it, pulling from
Speaker 2: other libraries, like grabbing their tests and bringing that in
Speaker 2: because I thought there's no way it that it created
Speaker 2: a better library than anything that exists on NPM in
Speaker 2: a one shot. But it is a really well known algorithm.
Speaker 2: There's lots of training data and lots of languages, and
Speaker 2: GPT does kind of tend towards simplicity. It doesn't have
Speaker 2: a context window to be able to create seven different
Speaker 2: class hierarchies. To do something, it kind of has to
Speaker 2: be able to do it in a function or two,
Speaker 2: which I think you know also speaks to the greater
Speaker 2: average of the human consciousness. Humans are not really good
Speaker 2: at holding seven different class hierarchies in their context windows,
Speaker 2: although they like to think that they do. But in
Speaker 2: some ways I think that GPT is more truthfully reflecting
Speaker 2: reality than people are perceiving it. Another instance was a
Speaker 2: seaboar parser, and you know, seaboar is something there's not
Speaker 2: very many implementations of it. But the implementations that exist
Speaker 2: outside of JavaScript are extremely high quality, and so it
Speaker 2: was able to write me a seaboard partser in a
Speaker 2: one shot. Other than I had to make a follow
Speaker 2: up prompt because there was one function that didn't fit
Speaker 2: in it. I guess didn't fit in its context window.
Speaker 2: So I had this. I could tell that it didn't
Speaker 2: have one of the functions was missing, and so I said, hey,
Speaker 2: you're missing this, and I took that and it worked.
Speaker 2: And so it's at least in JavaScript, I can tell that.
Speaker 2: And and part of it has to do with my
Speaker 2: memories because in GPT, I've told it, hey, remember that
Speaker 2: I prefer this style. Remember that I prefer this style.
Speaker 2: So I have also prompted it to be simpler in
Speaker 2: the way that it writes code. But it was able
Speaker 2: to one shot two complex things that you know, certainly
Speaker 2: nobody could write in thirty seconds, and very few people
Speaker 2: could write and feel confident that they wrote it correctly.
Speaker 2: And you know, I was able to test it and
Speaker 2: see that it did work. So but I think it
Speaker 2: takes the senior mindset to do that in the first place,
Speaker 2: because you have to be looking for Hey, I looked
Speaker 2: at the code of this shot twoty six implementation on NPM,
Speaker 2: and it's absolute garbage. Not necessarily because it was always garbage,
Speaker 2: but sometimes just because like it's got browser of fied transportations,
Speaker 2: which hey, back in you know, two thousand and ten,
Speaker 2: that's that that was what you had to do.
Speaker 1: That was I don't think it's the senior mindset. I'm
Speaker 1: looking at my kids and you know, they're getting into
Speaker 1: dev and they make significant use of those AI tools.
Speaker 1: So I definitely think that there's a possibility that AI
Speaker 1: tools may reduce the amount of packages that we import
Speaker 1: because they they'll write those one shot type codes for
Speaker 1: us that we often need instead of you know important.
Speaker 6: And then what will happen is that a box will
Speaker 6: spread everywhere.
Speaker 2: Yeah, that's the thing is That's why I said it
Speaker 2: takes the senior mindset because you have to know to
Speaker 2: test it, you have to know to determine if it's
Speaker 2: slop or if it's real. Because depending on the day,
Speaker 2: you know, when they update to a new model or
Speaker 2: you know, do the revisions. I'll have a day where
Speaker 2: I'm coding with GPT four. Oh, and you know it's
Speaker 2: just like banger after banger and I'm like wow, And
Speaker 2: then a day or two later, I'll be asking you
Speaker 2: questions that might even be simpler or whatever, and it'll
Speaker 2: turn out just absolute crap, and it's like, Okay, I
Speaker 2: got to write this myself.
Speaker 5: I think that another aspect of the reuse is that,
Speaker 5: like if you're your own person, like if I'm just
Speaker 5: writing code for myself, I don't mind writing some new
Speaker 5: stuff and using that because like I'm the one who's
Speaker 5: going to have to maintain. If you're working in a company,
Speaker 5: I don't really you know, if I ran a large company,
Speaker 5: I wouldn't want a hundred copies of the same thing
Speaker 5: written by ten different people, even if they're using AI
Speaker 5: to do it more quickly, because there's going to be
Speaker 5: different bugs, there's going to be more investigation. So part
Speaker 5: of the sort of the reuse is being intentional about
Speaker 5: what you reuse and when you do reuse things. Like
Speaker 5: the great thing in the JAVASCRPT ecosystem is we have
Speaker 5: tons of choice. The challenges that we have tons of choice,
Speaker 5: So at least like within an organization, you should try
Speaker 5: and rein in that choice a little bit and say, well, okay,
Speaker 5: we're going to use one version of X, Like, let's
Speaker 5: not pick ten different ones because now we've just increased
Speaker 5: our surface area in our risks by ten times. We're
Speaker 5: going to pick one. We're going to reuse it. And
Speaker 5: you know that's one way of continuing to maximize the
Speaker 5: value you get to reuse. But you know, being intentional
Speaker 5: about the dependencies you have in your application and as
Speaker 5: an organization, managing the risk so that you get a
Speaker 5: good balance between benefits to reuse versus the code thought
Speaker 5: in your code.
Speaker 3: If we bring it, if we bring it back to
Speaker 3: the pillars, you know, if you look at every single
Speaker 3: one of those pillars a key ingredient, and every single
Speaker 3: one of those is intentionality, right, it's you know, get
Speaker 3: you to stop and think about your code in some
Speaker 3: aspect of it. You know, what are you testing? What
Speaker 3: dependencies are you using?
Speaker 1: Right?
Speaker 3: How are your tasks broken down? Right?
Speaker 2: All of it is just.
Speaker 3: About this, this notion of being very very intentional about
Speaker 3: what you're doing with your application. Dependencies are no different.
Speaker 3: Don't just pick a dependency because it exists. Pick a
Speaker 3: dependency because it does what you need it to do
Speaker 3: the way you need it to do it right. And
Speaker 3: you know, and understand what it's doing. And it doesn't
Speaker 3: matter if you're having AI write your code. It's the
Speaker 3: same thing, right, you have to be very intensible about it,
Speaker 3: about what you're trying to accomplish.
Speaker 6: Guys, I need to do.
Speaker 1: Yeah.
Speaker 6: Unfortunately, it's about time for me. So I just want
Speaker 6: to say thank you very much for Johnning. I Fortunately
Speaker 6: I would stay longer, but at this point I really
Speaker 6: need to drop.
Speaker 1: Okay, thank you very much for coming on. Will you
Speaker 1: are going to be a guest on our show to
Speaker 1: talk about something else in any event, pretty soon, so
Speaker 1: we'll see you then. So thank you, thank you very
Speaker 1: much for coming on today. And I'm going to push
Speaker 1: us the rest of us into picks anyway. We will
Speaker 1: just have to invite you over to talk more about
Speaker 1: the pillars, because we literally made it halfway. We made
Speaker 1: it into the middle of pillar number five, so now
Speaker 1: we have the rest of pillar number five and then
Speaker 1: six through nine, and this is such a great conversation.
Speaker 1: I'm so happy that it's turning out this way. So
Speaker 1: thank you, Matteo and uh and see you in a bit,
Speaker 1: in like a few more in a few weeks.
Speaker 6: Bye bye bye bye.
Speaker 1: Bye, and you guys, so again I'm going to push
Speaker 1: us to pigs a J.
Speaker 2: Do you want to go first, Sure, I've got a couple.
Speaker 2: So I'll go ahead and throw out my link to
Speaker 2: this show two six implementation. If you have an application
Speaker 2: where you need to be doing multiple shaws in a row, this,
Speaker 2: this is the best implementation that exists in javascripts. At
Speaker 2: least there might be one that's just as good, but
Speaker 2: I was not able to find it. So I had
Speaker 2: to publish this this and and it has been tested extensively,
Speaker 2: so I am very you know I I dollars are
Speaker 2: on the line with it. But anyway, so I'll I'll
Speaker 2: do that just as a self promo since I since
Speaker 2: I talked about it, because yeah, if web crypto works
Speaker 2: because you only need to do one or two, that's great.
Speaker 2: But the other the legacy modules that are out there,
Speaker 2: I just I would not recommend them because they're they're
Speaker 2: doing all this weird Browser five stuff or like yeah,
Speaker 2: so they're just they're old, they're old, they're dated, they
Speaker 2: need to be replaced. And uh yeah, so go put
Speaker 2: the first star on there if you want to. And
Speaker 2: then I another thing I'm gonna pick. We're heading into
Speaker 2: winter so we're we're in this season right here where
Speaker 2: I am of nearly perfect temperature, which the weather's been
Speaker 2: really odd this year and the cycle of it's been
Speaker 2: kind of strange, but the last week or two has
Speaker 2: been pretty perfect temperature. We're heading into the thirties this week,
Speaker 2: so it's in below freezing even so that's that as
Speaker 2: soon as it came, it's over. That's that's how Utah is.
Speaker 2: It's like your spring and your fall are very very
Speaker 2: narrow bands. Like even two weeks ago it was up
Speaker 2: in the eighties. This week it's down in the thirties.
Speaker 2: So that's how it goes. But with it becoming winter,
Speaker 2: static shock is a thing, at least for us here
Speaker 2: in this dry climate. And a buddy of mine introduced
Speaker 2: me to these grounding mats, and they sell them as
Speaker 2: kind of woo woo hocus pocus, like it's gonna alleviate
Speaker 2: your back playing pain problems while you sleep or carry
Speaker 2: your depression, which I don't believe that the grounding mat
Speaker 2: is gonna do any of that. If you do believe that,
Speaker 2: i'd be curious to know why. But and honestly, I
Speaker 2: actually would be curious to know if there's is there
Speaker 2: some sort of science behind it or some sort of
Speaker 2: uh like actual uh what lived experiences or whatever, But
Speaker 2: but I get I got them, and I've got one
Speaker 2: for my feet and one for my hands, just because
Speaker 2: I start to develop this fear of like touching the keyboard,
Speaker 2: because every time I did, I mean, it was a
Speaker 2: heavy shock. It wasn't just like a little like, oh,
Speaker 2: you know, I touched your sweater. It would really build up.
Speaker 2: And so I got these grounding mats so that I
Speaker 2: don't shock things. Also, real story about electric shock. I
Speaker 2: took my home network down for two days, and I
Speaker 2: kept on unplugging things and replugging them, and then it
Speaker 2: would work for another hour and it would go down again.
Speaker 2: It turned out there was a network switch that was
Speaker 2: connected to my desk, and I believe that what had
Speaker 2: happened was that I had inadvertently touched that one of
Speaker 2: the cables that went to the network switch. It had
Speaker 2: gotten into a bad state where it was just spitting
Speaker 2: out some sort of packet. I honestly believe it was
Speaker 2: from static shock, because I had unplugged a bunch of
Speaker 2: other things, but I'd missed that one switch. And when
Speaker 2: I finally found that, oh, I haven't actually power site
Speaker 2: this thing like I thought I had. I think I
Speaker 2: had power cycled it, but it had a USB connection
Speaker 2: so it would still had power from the USB or
Speaker 2: something like that. But anyway, I unplugged it, replugged it,
Speaker 2: and then I didn't have those network problems anymore. Very
Speaker 2: very weird situation, but I think just getting shocked flipped
Speaker 2: a bit. So it also could potentially protect your electronics
Speaker 2: from malfunction having one of these grounding pads. So I
Speaker 2: linked to one that it actually feels nice.
Speaker 1: It doesn't.
Speaker 2: It doesn't feel cheap and junkie. It has a it
Speaker 2: feels like real leather. I don't know if it is,
Speaker 2: but it it feels like real leather. And it's very
Speaker 2: very effective in terms of if I'm using it, I'm
Speaker 2: not constantly shocking everything on my desk. If I'm not
Speaker 2: using it, or like walk away on the other side
Speaker 2: of the room and come back, then you know, I
Speaker 2: put my hand down, and of course I shocked myself anyway,
Speaker 2: grounding mats who knew? Who knew? That could be a pick,
Speaker 2: but it is. And that's what I got for you
Speaker 2: all today.
Speaker 1: Excellent. So now I'll go with my picks. I actually
Speaker 1: have two picks. So my first pick is we watched
Speaker 1: on Netflix the limited series called Monsters. The Lyle and
Speaker 1: Eric Menandez Story. This is a pretty famous and pretty
Speaker 1: gruesome story from the end of the eighties. I think
Speaker 1: it happened. The actual event happened in nineteen eighty one
Speaker 1: about these two brothers that basically executed their parents and
Speaker 1: they were caught. They went on, they went to a trial.
Speaker 1: I won't spoil the rest of the story. There's actually
Speaker 1: three ways. The funny thing is that there are actually
Speaker 1: three ways to watch it on Netflix. There's the limited series,
Speaker 1: which is a dramatization of the story, There's a documentary series,
Speaker 1: and then there's a documentary movie. We watched the series
Speaker 1: and in enjoyed it very much, and that's the thing
Speaker 1: that I would recommend the most. It's well played, well written,
Speaker 1: it's it's just it's just good, pretty good television. Afterwards,
Speaker 1: we try to watch a documentary series because we were
Speaker 1: kind of interested in the story, but it, I don't know,
Speaker 1: it just went into way too many details for us.
Speaker 1: So instead we watched the documentary movie, which was interesting
Speaker 1: in the context of the series we just watched. But again,
Speaker 1: if you're gonna watch something and just the one thing,
Speaker 1: do just watch the limited series again. It's called Monsters
Speaker 1: the Lylon Eric Menedde's story, and it's it's it's a
Speaker 1: pretty good story. The one thing interesting about it is
Speaker 1: that recently, I think the governor California, I believe, said
Speaker 1: that he's reviewing their sentences because and people are saying
Speaker 1: that it's potentially because of the stories that came out
Speaker 1: due to these all these shows and all the the
Speaker 1: ussion about them, which is kind of interesting how art
Speaker 1: impacts life, I guess in a sense anyway, So that's
Speaker 1: my first pick. My second pick is things have been
Speaker 1: it's kind of people have stopped talking about it, maybe
Speaker 1: because of the elections in the US or maybe people
Speaker 1: just moved on. But there was a whole lot of
Speaker 1: craziness around WordPress, like it kind of seemed like the
Speaker 1: guy who's running automatic who is like the what's it called,
Speaker 1: what's it called the Benevolent Dictator of WordPress, which is
Speaker 1: Matt Mullenweg I think his name is pronounced seemly kind
Speaker 1: of went off the rails. I won't go into the
Speaker 1: entire story. It's pretty out there. A lot of crazy
Speaker 1: things happened, and if you are curious about what actually
Speaker 1: went down in what's potentially still going on, the one
Speaker 1: video that I would recommend to learn everything about it,
Speaker 1: at least everything as was as of about two weeks ago,
Speaker 1: is a video made by THEO also known as THEO
Speaker 1: three GG. It's actually in his throwaways channel. We'll post
Speaker 1: a link. He actually spoke with Dan Sottman, another podcaster
Speaker 1: streamer a bit less technical and explained to him the
Speaker 1: whole thing. And THEO was kind of involved in it
Speaker 1: because he actually spoke and interviewed Matt In to the
Speaker 1: extent that his videos became part of the depositions in
Speaker 1: the ongoing lawsuit that's related to this whole story. So again,
Speaker 1: if you're interested in this craziness and wackiness in the
Speaker 1: open source world and where open source can go in
Speaker 1: bad situations, then it's a pretty interesting video to watch
Speaker 1: and I recommend. So these are my two picks for today,
Speaker 1: and i'll and i'll post a link to the links
Speaker 1: to both of them. How about you, James, do you
Speaker 1: have any picks for us?
Speaker 3: Let's see. Well, first of all, I'm sorry if I
Speaker 3: get any audio. My earbuds just died, so I'm on
Speaker 3: laptop speakers now.
Speaker 2: So there might be some echo.
Speaker 3: I'm apologize for that. Let's see picks for for today.
Speaker 3: Next week, we've got note comf EU happening in Iowa. Uh,
Speaker 3: it's always my favorite time of year, getting back, getting
Speaker 3: back to Ireland. We're actually returning to Waterford Castle. It's
Speaker 3: the conference is an actual castle, you know, it's just
Speaker 3: an absolutely wonderful, fantastic venue. There's still some tickets available,
Speaker 3: you know. I know, folks from the US, it's maybe
Speaker 3: a little a little harder to get over there that
Speaker 3: you know, last minute, but if you're over there in
Speaker 3: Europe and you have the time available, it's absolutely fantastic conference.
Speaker 3: I'm gonna be talking about, uh, cross run time compatibility.
Speaker 3: So all this effort, like Dino to act like note
Speaker 3: bun working BacT like note workers is trying to act
Speaker 3: like note how do we ensure that the all these
Speaker 3: different run times work the same when it comes to like,
Speaker 3: you know, standard web APIs that kind of thing. So
Speaker 3: I'm gonna be talking through a lot of the challenges
Speaker 3: that that all these different run times have to actually
Speaker 3: make sure that they're compatible with the language like JavaScript
Speaker 3: that allows you to basically do whatever you want. So
Speaker 3: that'll be that'll be a fun talk. But the other
Speaker 3: other side of it, and this is just my personal side,
Speaker 3: my son is going. My son has been a contributor
Speaker 3: to Note for a couple of years. He's doing his
Speaker 3: own talk there with with with another person, Claudio. We're
Speaker 3: gonna be talking about the work that they've been doing
Speaker 3: to improve node uh release downloads based on cloud flare
Speaker 3: R two and some of the other some of the
Speaker 3: other work that they've been they've been working on. So
Speaker 3: if you have time, go, we'd love to meet folks there.
Speaker 1: And that's the family that nodes together, stays together. Cool
Speaker 1: And how about you, Michael.
Speaker 5: H Yeah, I'll my first one. I'll just agree with
Speaker 5: James not you. Next week is going to be fantastic.
Speaker 5: The other thing I've been doing lately is spending time,
Speaker 5: like learning a little bit more about AI, trying to
Speaker 5: use the libraries from JavaScript. And the great thing is
Speaker 5: often like JavaScript or Typescript is the second language supported.
Speaker 5: So if you look at a Lama Lamadex lang chain,
Speaker 5: which we're all leading libraries in the AI space, they
Speaker 5: obviously all start with Python, because really data science came
Speaker 5: out of that that sort of space, and that's the
Speaker 5: language I use. But most of the leading libraries also
Speaker 5: then support Typescript is their second language, and I think
Speaker 5: that shows a recognition of the AI ecosystem that like
Speaker 5: JavaScript and typescript is going to be an important player
Speaker 5: in terms of consuming those services. In terms of my
Speaker 5: pick I've been looking at this week, it's the b
Speaker 5: agent framework. It's actually one which started life as a
Speaker 5: typescript instead of Python, which is nice to see as
Speaker 5: a node developer that somebody started with a JavaScript implementation.
Speaker 5: It lets you write agents that call functions more easily.
Speaker 5: So I've been playing around with that, and if you're
Speaker 5: interested in you know, Node and consuming AI from JavaScript typeescript,
Speaker 5: I throw that over as my pick to go take
Speaker 5: a look at that.
Speaker 1: Very cool. Now, before we wrap up, if people want
Speaker 1: to get in touch with you guys, so talk about
Speaker 1: what we talked about today. I don't know if you
Speaker 1: still do consulting work or in general just to speak
Speaker 1: with you. How do they get in touch Michael, what's
Speaker 1: the best way to contact.
Speaker 2: I think you know Twitter? My handle's there. MH tauson one.
Speaker 2: You can just reach out to me through that.
Speaker 1: Excellent. And how about you, James.
Speaker 3: Same on Twitter. I'm Jay A. Snell on Twitter and
Speaker 3: on GitHub. I think we have to be following each
Speaker 3: other for you to d m DM, but you know,
Speaker 3: apporporate to reach out to a public chat out on
Speaker 3: me on their happy chat.
Speaker 1: Excellent. So guys, it's it was great having you on
Speaker 1: and I really hope we can organize and schedule the
Speaker 1: follow up because we do really need to cover the
Speaker 1: rest of the pillars. The ones that we did were
Speaker 1: so great. Thank you for coming on, and to all
Speaker 1: our listeners, thank you for listening in and goodbye.