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