Skip to content
Melo Podcasts Home
CategoriesLanguagesFollowing

Episode notes

In this episode of JavaScript Jabber, I sat down with Matteo Collina—chair of the Node.js project and founder of Platformatic—for a deep, no-fluff conversation about Node.js performance in the real world. We dug into what actually happens when you run Node at scale, especially with server-side rendering, Kubernetes, and modern frameworks like Next.js. We also challenged some popular assumptions—like whether newer runtimes automatically mean better performance—and explored how benchmarking, flame graphs, and smarter scheduling can completely change the reliability of production systems. If…

Transcript

Read the transcript · about 11,530 words, follows along as you listen

Speaker 1:Welcome back to another episode of JavaScript Jabber. This week, on our panel, we have Dan Shapire.

Speaker 2:Hello from a freezing wintry tel Aviv, sixty degrees fahrenheit.

Speaker 3:Thank you for rubbing that in.

Speaker 1:I know, I think it's below freezing here. We also have Steve Edwards.

Speaker 3:Yo yo yo, coming at you from a slightly warmer now Oregon, where we really need snow.

Speaker 1:Yeah. Also, Steve, word is that you are currently looking for a Laravelle view job.

Speaker 3:Yes, something slnes would be nice.

Speaker 1:All right, So if you want to hire a Steve, get a hold of him.

Speaker 3:This particular Steve would be nice.

Speaker 1:That's right. Do you want to put like contact information out there?

Speaker 4:Yeah?

Speaker 3:I was gonna wait till shameless plugs at the end, but yeah, you can my infos on my GitHub at Wonder nine to five, same handle for Twitter. It was probably the best way to get old Steve at s mg a web dot com.

Speaker 1:Cool. I just want to make sure that yeah, people hear it and they can reach you if they need to. I'm Charles Maxwood from Top End Devs And this week we have a special guest. We have Matteo Colina.

Speaker 5:Hello, I folks, Hey, Hi from for Lee Italy. It's been a rainy day here and I'm staying it home.

Speaker 1:I didn't know you. I've been to for Lee.

Speaker 4:Really like not you won't even know that is where he's on the map.

Speaker 1:Yeah, Pasatoduani in Italia. I was a missionary in Italy and yeah, so I've been to for Lee and Remini and wow, I lived in Oncona for like six months so yeah, wow, Oh so you know.

Speaker 2:And we and we, my wife and I passed really close by just when Matteo happened to be in London. Yes, so we unfortunately kind of missed each other.

Speaker 4:That would been a rag.

Speaker 5:But my calendar these days during conferences and is close to a nightmare.

Speaker 2:Well, all I can say is will probably be in Italy again because we love Italy, and next time hopefully we'll be able to actually meet.

Speaker 1:Yeah, I would love to go back. We had a foreign exchange student who also lives in Oncona and so we'd like to see her and her baby. So anyway, what are we talking about that's not travel tech or Steve needs a job.

Speaker 5:Today we're talking a little bit about the latest thing in platformatic my company, and not j yes, I think maybe with some ais pist in it, because you know, everything is AI today.

Speaker 2:Yeah, a lot of our listeners may not be familiar with Platformatic, but I think that if you're doing a think with notes, there's a good chance that you're probably using at least one thing from Platformatic.

Speaker 5:Like it's absolutely at this point, I think you're using something from from Platformatic close to one hundred percent. Okay, it's as I say, last year, I touched forty two a billion downloads on NPM some some some impossible numbers like that.

Speaker 4:So this is the state.

Speaker 2:So like every man, woman and child on this planet is downloading stuff on Platformatic like ten times a year.

Speaker 4:I have no idea.

Speaker 5:Yeah, at this point, it's it's it's it's it's everywhere. As I say, I am in everybody Dependency three.

Speaker 4:So I am the Nebraska man. I'm joking.

Speaker 1:Okay, I thought it was just your mom over there NPM installed Platformatic stuff.

Speaker 4:Look, that can be possible. You know.

Speaker 5:I fixed that laptop for for christ So that was the gift.

Speaker 1:There you go.

Speaker 5:So it's the one time over the over the year that somebody can ask me to fix a computer over Christmas.

Speaker 3:The tech support.

Speaker 5:It's it's it's it's something that everybody does. So so true talking about things we have since the last time was year so what we have released a few benchmarks okay that I think are pretty relevant for everybody to look at. So let me just get them and so that we can discuss them. I'm going to pass them.

Speaker 2:While you do. I was. I want to emphasize that while I was obviously somewhat kidding before, it is absolutely true that I kind of considue you to be sort of mister no JS, especially now that Ryan Dalla has moved on to other things.

Speaker 5:H It's well, I have been since this summer. I've been nominated the chair of the no JS project. So wow, I am effectively running the thing.

Speaker 2:Wow. I didn't even know that. Wow, that's pretty.

Speaker 5:It's an honor. Let's put it this way. It's an honor.

Speaker 2:Yeah, we talked about it slightly before we started the show officially that I'm I'm you know, Node is not new, obviously it's been around for a while, but I'm I'm seeing Node usage actually increasing. A lot of organizations that have previously been using other technologies for the back end are adopting Node as their go to technology for back end stuff. I don't know if it's because of the Lambda functions and stuff like that, or it's because you know, all the meta framework out there, Next JS and ten stack and whatnot. I don't know. Maybe it's like everything together, but I'm definitely seeing no JS technology usage pickup a lot of companies. Like I was speaking at this conference in Israel, and like every company that I was talking to was doing something with no JS on the back end.

Speaker 5:Yeah, it's everywhere, Okay, right now, if you want to build anything for the Web, you're using Note.

Speaker 4:If you're not using Note, you are probably.

Speaker 5:On a minority, and it's it might be good to be in a minority. But the mainstream stack right now is something React based plus no JS on the server.

Speaker 1:And I'm in the minority me too, I know.

Speaker 4:But you're probably using View. I've heard okay, Laravel Lvl, I.

Speaker 5:Would I would wonder, Okay, this is a how do you do server side rendering with view on Laavo.

Speaker 1:If you use.

Speaker 3:Inertia JS, which is something I'm a big fan of and I've talked about ad nauseum probably on here. Inertia has a service side rending capability. If you're using View with something like nuxt, it also has server side rending capability.

Speaker 4:Yeah, but then it's node right correct.

Speaker 3:Okay, point well, you asked how to do with view, so that's how No.

Speaker 4:No, But it's say with knox is node.

Speaker 2:Yes.

Speaker 5:Is the inertia not no, not JavaScript running somewhere.

Speaker 3:Inertia is real quick. Is basically a glue layer between your front and your back end that allows you to plug and play. So you could use View with Ruby, with Laravel, with Node, you could use you So you could use viewsvelt react Angular on the front end, and you could use laravl Node, Ruby on the back end in any combination. So it's just it's crazy fast. I have an application that I've built and maintained for a while, and it's just amazing how fast it is. It basically sort of hijacks the post request and the browser doesn't do a full reload. You passes some headers that tell it, hey don't do a full Perial railroad and communication between the two point being, to answer your question, if you go with inertia, there's service any capability.

Speaker 5:So if I want to do a Larrabell and view. Then I can do that like I am seeing. Okay, to be clear, I'm looking. I opened it up in a second and I'm showing me some not js.

Speaker 3:On Well, it's possible. I haven't used.

Speaker 5:It's like it's the way to do these kind of things typically is there is some no JS little notes thing running and doing the job.

Speaker 4:I don't know.

Speaker 5:It somewhere, okay, because in the problem is that with modern front and frameworks you need the areizomorphic. So you have the same Java skipt code that runs on the front and on the back end, and in order to do some side rendering you have to render it on on the back.

Speaker 4:Okay.

Speaker 1:So jovscripture on time on the back end.

Speaker 4:And you need a Java sleap run time on the back okay to.

Speaker 3:Do this it's underneath. Yeah, okay, I get you.

Speaker 4:So this is why I'm saying.

Speaker 5:This is the point of there is always some no JS everywhere in in In.

Speaker 2:And then kind and then PLATFORMA. They kind of flipped the script there where you kind of put WordPress and Narvel on top of note or something.

Speaker 5:Yes, So last last year we shaped a few experiments. We were able to run full pitchp inside no JS. It works really well. It's actually very performant, to be honest. So there is literally nothing stopped that kind of those kind of deployments. But it's let's see what the market says, and if there is, if they are attractive for the market, we will keep for showing those.

Speaker 2:Is it raging or something?

Speaker 4:No binaries.

Speaker 5:It is the actual PHP right high from the operating system. It's the same thing. It's it's the same hooks that the patchy uses.

Speaker 2:Hm hmm, Okay, now I understand what you're doing. That's interesting.

Speaker 1:So we were talking about benchmarking. Does how does this tie back in?

Speaker 5:Yeah, so we've been doing this is the benchmarks. Okay, we've done a few. I just wanted to point out chew one is and let's see where the chat is. Here is a chat.

Speaker 1:Yeah, there's a chat. It's on the right. It's got a little chat bubble.

Speaker 4:Okay, here we go. I'm passing in the chat. So this is one. I am passing it.

Speaker 5:The second one that we have done, and then I have a few more.

Speaker 4:To talk about.

Speaker 5:So the first one is we've done last year. It's a benchmark showing next JS performance. Okay, under very high traffic. So for Next, yes, so what happened, What is happening is we have done a lot of tests, okay, and it's with a lot of tests for example, with one thousand requests on per second for I mean, for a couple of minutes on against next JS and those were hitting essentially saturation.

Speaker 4:This was a hellower page.

Speaker 1:Okay.

Speaker 5:It's very normal for your system to go to if you're using Next or a React based server side system, to go between eight twenty, between eight and twenty maybe fifty requests per second at.

Speaker 4:Best, okay.

Speaker 5:If you have a very complex system like it's low okay in the genetic terms of things, okay. So the critical point okay of this was the success rate, but more important in the latency okay. The latency for this kind of system is very bad okay. And this is affecting a lot of companies out there, okay. And a good chunk of that problem is due to our scheduling is done of of multiple parts in kubernets okay, round robin. Unfortunately, it's it's not the best algorithm most of the time, okay, But the one that's the one we have. And last, but not least, there is the problem of event look blocking.

Speaker 4:Event look blocking it's critical.

Speaker 5:So if the if the event look blocks, then know the system becomes responsive after this, So it's it's it's problematic.

Speaker 2:But then the whole thing about note that the event loup is kind of never supposed to be blocked.

Speaker 4:Well, tell that to all the developers using React, like, that's the absolutely, that's the world point the idea. Yeah, that's the idea.

Speaker 5:But reacts over side rendering is super expensive, okay, and it's super expensive.

Speaker 2:So yeah, a lot of string operations and stuff.

Speaker 5:No, it's a massive So basically what React does It creates a full virtual dam of all the elements in the page and then it stringifies that and you need to walk through a massive tree for every request.

Speaker 4:So this create a massive pressure on the GC as.

Speaker 5:Well as the computational cost of a locating of stringifying all of those elements.

Speaker 2:That's really unfortunate given that it then immediately discards that entire virtual dome exactly.

Speaker 4:You know why I've been a pretty like there is.

Speaker 5:The only framework that does better is solid I think is significantly better on the topic.

Speaker 2:Okay, maybe because it doesn't have a virtual dome.

Speaker 4:This is a good point. This is actually a good point.

Speaker 5:Okay, And yeah, so the word point of note is not blocking the end loop and I can really subscribe to that sentence. Okay, So to the point, so to the point that if the event look blocks for a long time, it's better to kill that node process and start a fresh one up because keeping that running is useless.

Speaker 2:Yeah, if you're going to be doing really significant GC, then why I mean, just you know, I'm reminded of what the Apache I think the approach was about, like managing like the heap in in like sort of chunks and then discarding the entire chunk rather than trying to do fun grain GC.

Speaker 5:Well, it's to some extent is relatively similar what we are doing. So with what or not just application server we have based on this on this thing, we can monitor the state of the event loop from the outside and if you detect it, it is totally blocked. Nothing comes true, nothing is going to come through. We just shut the shut the thing down. So and because we can, we shut the thing down and we started from and restart, we can essentially recover a really broken pad back to life and let some traffic pass through.

Speaker 2:So the basic idea is saying, instead of trying to do this really really complex GCS at a high frequency, because of all the incoming requests, every once in a while, just kill the pod and start fresh.

Speaker 5:Well, it's when the event will be is blocked. So it's literally like when there are too many like. The problem is also that there are all those requests are piling up to be processed and after five seconds it's no point.

Speaker 4:There's no point in processing them. You' just abort them.

Speaker 2:And it's because of the GC, because of the virtual dome.

Speaker 4:It's all of both of them.

Speaker 5:It's it's a very it's a very superre intensive operation, especially with a lot.

Speaker 2:Of interesting You would think that they would have figured it out a way to offload it to workers.

Speaker 4:Or something, which is what we did.

Speaker 2:Is that a different thing or the no.

Speaker 5:So basically with what we can have multiple workers listening to the same socket so that you can do the load balancing easier. It's very similar to say, oh, it is similar to nod cluster or PM two and not cluster, but instead of doing the load balancing inside not JS, which is what nod cluster and pmhould do with in that we use a new node feature that let us do load balancing inside the kernel using scores, a flag calls so on the score reuse port, which is significantly faster.

Speaker 2:Can you elaborate a little bit about what actually is?

Speaker 5:Because it's an application showy for not JS, you can just give it your app. It will run it inside a worker thread and the main thread will just minor it and you can scale it up and down multiple threads, multiple course, and if you want, you can even have aterogenerus system. You can have multiple different applications running there and they can communicate via message passing or just h GDP over memory.

Speaker 2:See so what does it compete with? What are they like? When would I use what? And would I put like next JS? On top of what?

Speaker 5:If you're if you're deploying not JES in Kubernetus, you're probably not doing the not doing the right thing if you're not doing it today using what?

Speaker 2:Yes, what does it stand for? By the way?

Speaker 4:What come on? What can what be? Can that be? Come on?

Speaker 2:How do you exactly spell it?

Speaker 4:W A T T. It's an honor to over James vat.

Speaker 2:Ah Okay, yeah, the power. Yeah, so we need a name.

Speaker 4:So on MPM is VATPMH.

Speaker 2:I now I sit in your blog post. Yes, so whenever I use node in Kubernetes, you recommend using it on top of what I.

Speaker 5:Would say, Yes, it gives you more reliability in this example with jes that I've shared in the chat, essentially we can move down P ninety five from a second to two one hundred and thirty five milliseconds.

Speaker 1:Oh wow. And just for those who don't follow along with benchmark stuff of P ninety five, is ninety five percent of your requests take this long or less?

Speaker 2:So in other words, yeah, beneficial for the five percent slowest users.

Speaker 4:Is beneficial for everybody.

Speaker 1:If fits for everybody. Yeah, essentially, Yeah, so all the all the requests now, so ninety five percent of the requests instead of taking up to a second, now take up to two hundred and thirty five milliseconds. Now you assume that the other five percent it also speeds up for But yeah, that's kind of the measure, and it's it's one of the more common ways of measuring how fast your application is because the load and the requests and what it has to do and what else is running on the machine can vary from time to time, and so this kind of averages it out.

Speaker 2:Also, think about it from the perspective of a business loto you like, you want to think about the customers that have it the worst, and you can't really afford to lose five or ten percent of your business because it's just too slow. Exactly. But I'm thinking about what you said. It does mean though, that you want to allocate more than one CPU per yes, no instance in your kubernets in how.

Speaker 4:You absolutely this actually helps. Okay, let me explain why it helps.

Speaker 5:Okay, The cost of spinning up a new pod in Kubernatis is more or less fixed independent of the amount the amount of resources that are attached, okay, or anyway, it's not very much different.

Speaker 4:Okay.

Speaker 5:If I am scheduling largest things, each unit of scale gives me more power to handle my spikes better. So it's the edges of scaling are a little bit steeper. But this actually helps smooth the curve way quicker because these new things.

Speaker 4:Make it.

Speaker 5:Can handle more load per unit. Okay, So this is one thing.

Speaker 1:Okay.

Speaker 5:The second thing is Kubernatis takes minutes to scale, so when the load typically reacts in one two minutes is very slow, tiny to to to schedule things up. And by having this system you can actually absorb the shock completely inside your pods.

Speaker 2:Interesting, very interesting. I need to think about this some more. I will definitely make sure that our develops people see this. I mean literally everybody is using kubernets these days, whether they need.

Speaker 4:To exactly exactly.

Speaker 5:We also have built, but it's not mentioned in this benchmark, built another product called Intelligent Command Center that is open source as well, that reduced the decision time of kubernets from minutes two seconds. So the pod starting is down is making less than five seconds the decision to start a new part.

Speaker 2:Doesn't that make the system kind of more noisy.

Speaker 5:Yes to some part, not to the other, because it's actually it's actually very fast in scaling up. Okay, but it can scale up on very specific signals from the app, so it and so it can be a little bit more noisy, but it actually allows you to reduce your baseline of instance significantly.

Speaker 2:So you can scale up when you need to.

Speaker 5:You can scale up way quicker when you need to, so you can reduce your baseline and during off peak hours you can actually save a lot of Yeah.

Speaker 1:I guess that's always the thing that I'm concerned with when you have this kind of automation, is, you know, does a scale up too much? Does it? You know, does it handle things when you know when I need it to scale down? Because yeah, it costs a lot more when you scale way up. But if that's what you're getting in traffic, and usually traffic translates in some ways to money, not always, but yeah, so that anyway pretty cool.

Speaker 4:So this was part of our results.

Speaker 5:We published this study, okay, and hopefully we can get some results from our rock click customer down out soon. But this is our own and all the benchmarkt and ernests done for this is open source, so you can check it out and run it yourself.

Speaker 4:If you're this.

Speaker 2:Should be making a lot more noise than it is. I think I was kind of aware of this, but I was not fully aware of this. And like I said, literally everybody is doing non kumberinators these days. So if the impact is so dramatic and so significant and so readily achievable, yes, you know, there's literally no reason not to try it out. This is.

Speaker 5:Partially the reason why when you asked to come to join the show. I said, I'm coming join the show. This is the research that we published. So we published late last year, I think, and it's pretty solid.

Speaker 4:I would say. Then we have done another article.

Speaker 5:Okay, I'm more spicy one if you if a more spicy one, I would say, okay. And we benchmarked on the same benchmark on the first one, slightly different traffic load whatever, Okay. We benchmarked the note the tree no dress run times in Kubernetes so bunn no JS as well as our own way of scheduling things with what so we got some really unexpected results, not the results that I would expect, and it showed that bun So.

Speaker 2:Just before you you tell what you found, just to clarify, what is only for node, it's not for the other For the other platforms, you can't use it to DNO with bun.

Speaker 4:No you can't.

Speaker 5:Well like you can't because those other platforms are not fully not GS compatible. And the approach that we have taken with what is instead of creating a custom built not just run time with our patches, we have upstream all our patches up to note core of the things that we needed, and that is only is written mostly in JavaScript mostly every now and then we had to have a little bit of C plus plus to implement some feature for all not Jazz versions.

Speaker 4:That are not being released yet.

Speaker 5:So if we need a feature, we need to extend support for it.

Speaker 4:But it's right now, I think it's all JavaScript.

Speaker 1:I have to say before you go too much further that I like this idea of hey, we needed this in node in order to make what work, and so you contribute it back and so it's stuff that other people can use.

Speaker 5:Exactly one like this is the whole point. Like part of the reason why I funded Platformatic was can I try to build a business that can uh make the open source economically viable and and allow us to grow with it? So let's try. This is the this might try Okay, I might succeed, might not succeed. I hope I succeed, but I needed to try this. So my journey.

Speaker 1:I'm going to go into a tangent here real quick because I'm kind of curious. So when you say make the open source uh economically viable, what do you mean?

Speaker 2:Like?

Speaker 1:What what the fundamental point is?

Speaker 5:The fundamental point is there is a substantial lack of investment in core technologies from companies, and we need more companies that are that invest significant amount of money into the commons.

Speaker 4:In order to do so, we need them.

Speaker 1:To be.

Speaker 5:Economic, to be good businesses so they can contribute back and up. Okay, And you cannot rely on the sponsor model because it's too little, too late. So you need if you need to pay to do payroll, you need to have significant sales involved. So the goal is to build a significantly big enough company that can afford multiple people and working full time on the core technologies, and not because it's it's a good thing to do, but because it needs them to be there as a core function of the business so that it's not a donation, it's a function.

Speaker 1:Okay.

Speaker 5:And because it's a function and it's a core part of it, it will not stop.

Speaker 2:And what is that company selling them?

Speaker 1:That was what I wash.

Speaker 5:So our current business model okay, after several pivot iterations and stuff, we sell enterprise version of all our technologies plus support and on boarding. So if somebody needs anything related to no JS, we can provide support, We can provide and we can provide an enterprise license for our core technologies and include.

Speaker 2:What does an enterprise license.

Speaker 5:Mean this is an answer for Michael question for micro founder. Okay, so there is for the Intelligent Command Center.

Speaker 2:There is a.

Speaker 5:Premium version with added features for example like more audit controls, loggins, these kind of things so far, but it will grow more. It's more related to SLAS and response to incidents and being available that.

Speaker 4:Like other things.

Speaker 1:So it's more on the support side than the future side.

Speaker 5:It's the future side is more on all these technology are moving dynamically, so they our customers can steer, can steer the wheel and I'll pass the side.

Speaker 4:Where we go next?

Speaker 5:And what what they need? What features are missing? And you know their partners.

Speaker 2:I think that esslas are the way to go, to be honest, To.

Speaker 4:Be honest, I would say they sell very.

Speaker 2:Well because like literally, if I'm running your back in my back end on node, I need ESLAS and and if you know, if I if I can out kind of guaranteed by licensing your services, then it's no brainer.

Speaker 4:That's what it is. So anyway, that's exactly the point.

Speaker 2:Cool. So now let's go back to where we were before we went on the tangent.

Speaker 4:If we can remember, yeah, okay, we can go on the tangent all the time. So anyway we are, I was chatting, I've over the break, I've done this extensive benchmark on band Dino and note okay, and I got very surprising results. The benchmarks included running the same next Jaess application that.

Speaker 5:We talked about before. Okay, reactions are rendering? Have your memory? Have you on CPU?

Speaker 4:Really like.

Speaker 5:Possibly the worst load but also the most common load that you can have running on OJS these days, And I got very surprising result that I didn't expect them to be so specifically.

Speaker 4:I got but p ninety nine of.

Speaker 5:Seventy four milliseconds for ban one three dot five they did new versions of.

Speaker 2:So approximately one second.

Speaker 5:Yes, well not JS was one hundred and seventy four. Do you know at one hundred and not JS with what at one hundred and fifteen?

Speaker 2:So Bun was noticeably slower than everybody else exactly. To be honest, I know that Bun has a reputation for being fast, but the people need but people need to understand that fast can mean different things in different situations.

Speaker 4:Exactly that.

Speaker 1:Well, I hear people tell other things about Bun too, but yeah, you run a different application the different engines manage memory differently and concurrency differently than other things differently, and so yeah, it's.

Speaker 2:Beyond a different application. I think it's it's like a different scenario, yes, because you've got you've got startup times, and you've got and you've got run times, and there's a question of when optimizations kick in. If they kick in, what do you do in the jet stage stuff like that. So what could be really fast for a long running a no type service could be really slow when you're building a utility that just runs, does something and then terminates, and an expectation that a certain platform will do everything better is well, it's happened before, but it's not always realistic.

Speaker 4:It's so a few notes.

Speaker 5:Okay, after chatting with a few people, they gave me this informal feedback. You can take what we do with a gain of salt jsc which is the JavaScript run time behind ban and Safari is optimized for cold starts to start very immediately. Imagine when you open Safari on your iPhone, it opens up super quick.

Speaker 4:Okay, while V eight is more optimized for running or wrong running application. Thanks Jmail.

Speaker 2:Yeah, that's the thing, you know, people talk about like the various You know, there's this been trend of rewriting the JavaScript utility ecosystem in other programming languages, be it go or be at rust or be it whatever, instead of doing it in JavaScript or typescript. And you kind of hit your head on the nail there, matel Because, for example, if we think about.

Speaker 3:And that's a nail on the head, not head on the nail unless you really want to hit your head on the nail.

Speaker 2:Or is that what I said? Yeah, okay, just.

Speaker 1:To point ound was painful.

Speaker 2:Well know Hebrew we right, we right right to left.

Speaker 3:So well, but I mean, gives gives new gives new meaning to the term hammerhead, doesn't it.

Speaker 2:Yeah? Anyway, what I was saying is that the JavaScript optimizer in EA, I always forget the name whether is a turbo fan or what.

Speaker 4:A turbo fan. We also have mag Lab now.

Speaker 2:But yeah, it's basically based on identifying hot code and then optimizing that while the code is actually executing. But in order to identify hot code, the application needs to be running for a while. And if you're running a tool that just starts up, does its job and then finishes, you'll never get to that optimization stage.

Speaker 5:Exactly, which is long enough you get into that optimization state.

Speaker 2:Which is kind of my concern by the way, with some Lambda function usage.

Speaker 4:Well, I let me say this, if you are moving serious traffic, you are probably better served using ECS or cobnetis or whatever long running process. But to be honest, Lambda actually okay, let's let's go. Let's open the lambda point because it's actually a validation of that to some extent.

Speaker 5:So if you if you have followed what has been launched by a w as in the latest the latest rainvent in December, is a new Lambda run time for I troueput scenario I traffic scenario that is not actually one request per process, okay, but it allows one process look at this to have as many threads as it wants to end or requests in a lot of things. Is actually similar to how that works internally in how the things are scheduled. So this kind of system allows Lambda to.

Speaker 4:You know, use all the potential of no js essentially and actually leverage these long running optimizations that we talked about.

Speaker 2:Interesting.

Speaker 5:So it's actually very interesting model, and a lot of people are not you know, tapped into this yet, like they think, oh, no, jes single treded or mostly single traded, while in reality it's not, and you can do a lot of interesting things with it, and they just you know, ignore the point.

Speaker 2:Well to be to be honest, no, JavaScript is a single threaded language, but Node and the JavaScript Virtual Machine has never really been single threaded.

Speaker 4:So it's exactly so for.

Speaker 2:Those of you who don't know. For example, the VGC actually runs off of the main thread to significant extent.

Speaker 4:Yeah, well it has been, not at the beginning.

Speaker 2:Not at the beginning I'm talking about currently.

Speaker 4:Yeah, yeah, it's it's it's off the of it.

Speaker 5:So anyway, I just wanted to say we got these incredible results, like not expected, to be honest, I didn't, like I had to check them five times and have to have some friends check them with me.

Speaker 2:So why was it expected? You you didn't expect such a band to be that slow in that particular test, yes, And did you expect Dino to be that fast by the.

Speaker 4:Way, yes, yes, significantly. I was expecting Dino to have those kind of numbers.

Speaker 2:I think that's a scenario that they've been optimizing for, right, No, no.

Speaker 5:No, it's the way so they their dino event loop is based on Tokyo, while no event loop is based on libuv.

Speaker 4:Okay, and Tokyo is.

Speaker 5:Be a decade later than libv type of thing, and by things have improved, you now you do those kinds of things, okay, And it's very hard to chase something like libuv understood, So there is that is the problem, Like it's it's not just LIBUV by the way, it's also the node machinery in entirety. So how we get the data out of libuv, how we schedule new connections and we do all Like there's a lot of work over there and a lot of over it, but some of that over it is essentially legacy, and it's very hard for us to like it's possible, it would be possible to optimize, but it's a hell of a lot harder.

Speaker 2:So could you remind me again what the numbers are for node versus note with what.

Speaker 4:So on p.

Speaker 5:Nineteen nine we add one hundred and seventy four millisecond I may we measured one hundred and seventy four million second with node and with what one hundred and fifteen.

Speaker 2:One hundred and fifteen that's one one five.

Speaker 4:Yep, one seven four versus one one five.

Speaker 2:So we're talking about close about thirty percent reduction, forty percent reductions.

Speaker 1:Something like that.

Speaker 2:Yeah, that's significant.

Speaker 4:I know last Dino VAT and Dino are very close.

Speaker 2:And that's the SSR scenario.

Speaker 4:Yes, by the way, So I guess.

Speaker 1:What I'm wondering is is so for the people watching at home right this, you're throwing out numbers and scenarios, But what does this look like for me? Right? So I have a next JS setup, or i have a note application that I've written, and I've got React on the front end and I've got server side rendering setup or whatever, like, how does this actually translate? And what does this look like when I'm troubleshooting or you know, measuring my own benchmarks or things like that.

Speaker 5:So the key difference is the point of so when you're doing in your is when you do saturation or stress testing. Stress testing, so you're putting it to a very high load scenario and you want to know when your up breaks.

Speaker 4:And essentially.

Speaker 5:These numbers tells create more or less ranking of where your applications stay responsive and is usable by the end user.

Speaker 4:Okay, in those scenarios, I'll.

Speaker 2:Give another way to look at it. You're doing SSR to improve application startup times. Yes, that's the primary motivation of doing SSR. And what we've literally learned now is that you might be doing SSR with the goal of improving startup time and end up part of my French screwing yourself because your back end will not be able to properly handle the extra load. And I'm actually looking at the Crux data. We've spoken about it on the show on several occasions, so a quick reminder what it is.

Speaker 2:Google collects anonymous performance information from all browser sessions or Chrome browser sessions and unless you opt out, and it's not really easy to opt out, so assume it's more less everybody. And they are looking and then they are breaking it down by technologies used using the HTP archive. So basically for each domain, they're looking if a domain has sufficient amount of traffic, so they're looking at the top ten million domains more or less in terms of traffic.

Speaker 2:They're segmenting them by technologies used, and then they actually release this information to the world so you can actually see which technology is more likely to give you better performance. And I'm currently looking at the graph that compares all the websites within cracks, the WordPress websites, the Wix websites, and next JS websites. And I'm looking at what percentile of websites get good performance results. According to Google, it's the cob vitals. Okay, wow, yeah, And if we're talking about all technologies, we're talking about about fifty one percent, So approximately half of websites get good coed vitals and about half get poor web vitals. If we're talking about WordPress, the number is forty six percent. So WordPress is slightly lower than all technologies at large, but pretty close. So WordPress and all technologies is more or less the same.

Speaker 2:Maybe also the fact that like half the web runs on WordPress. Wis currently is at seventy three percent.

Speaker 4:And what is this website? Is the cracks data set? Right?

Speaker 2:Yes, I can send you. I'll put the link in the chat.

Speaker 4:An Houp going fantastic. I found it.

Speaker 2:So Wix has seventy three percent. So if you're building a website on Wix, there's a seventy three percent probability that you will be getting good performance. Okay, what's the number? Sorry, what's the number for next JS? Now you assume that next YS would be great because the whole thing about next GS is that it's as SARRD. So what's the probability for next gs?

Speaker 1:Can you guess feel like you're setting me up to let me down so well, I would have assumed before you said it, kind of skeptically that it'd be you know, yeah, somewhere around wis you know, sixty seventy percent, but you're making you're making it sound like it's probably like thirty percent.

Speaker 2:Exactly, it's twenty nine percent. So the probability of getting good performance when you're using NEXTJS, you know, you're you're putting all this effort into building let's say AI is not doing your entire job yet you're doing putting all this effort in encoding your website and react and hosting it and whatever you and your probability of getting good co ed vitals is less than thirty percent, And that's really unfortunate.

Speaker 1:Yeah, that's bad. So the stuff that Mateo is talking about, then do you do you get those kinds of performance increases kind of for free just by upgrading your note or make.

Speaker 4:It better by using what on top of next which it just works.

Speaker 2:So it's not and I can do it on versall, no.

Speaker 5:Versall ransom your own thing. So the fundamental problem, the fundamental point is next JS is designed to run well on versall and to run it well on your own infrastructure. You're missing a few components, and we added those few.

Speaker 2:So with verse cell out of the box, I'd be getting comparable performance to what I have.

Speaker 5:Absolutely no idea. I've not measured. I've not benchmarked their cloud. To be honest, I don't even it's a good product. I am a customer like Performati is a customer overrsell. Okay, we are as most startup. Is the greatest thing ever to be using perself. Okay, yeah, it's easy, it's easy. There are a lot of companies out there that cannot use yourself for all sorts of reasons, okay, from and that is critical.

Speaker 2:I know that the companies are running next gs on top of Amazon a.

Speaker 4:W Yeah exactly, So this is what I'm saying.

Speaker 5:Okay, they are running those things, and there is even a thing called open next run it on top of cloud Flare and other stuff. Okay, what we've done make it run very well on top of Kubernetus.

Speaker 2:By the way, I'm curious, what's your opinion of nest JS.

Speaker 5:You're asking me tough questions, then I am not I am I do have opinion.

Speaker 4:I have one opinion.

Speaker 1:Nest is the back end framework, specifically, isn't it?

Speaker 2:Nest is like NOE for Java developers I have.

Speaker 5:I have a problem with it. Okay, the problem I have with nest is its reliance on the old time skip decorators. So I don't know if you've been following the story of Java skip decorators with the year thirty nine.

Speaker 2:That standard that never ever materializes. It's been stuck in stage two and a half like forever exactly.

Speaker 4:So the problem is that.

Speaker 2:Just you know what, before you do, let's just clarify that all our listeners I kind of assume that listeners were familiar with Kubernetes, which might have been either correct or incorrect. An assumption to make, but let's not assume the same for decorators. Decorators are a language feature in JavaScript or typescript which allow you to decorate function method classes and methods and properties. You put the ad sign and then some words, and basically it wraps the declaration in a function call and that function call can modify the actual class definition or the method definition. So for example, let's say the canonical example is I want to print out a log whenever a method enters and exits. Instead of explicitly adding a log everywhere, I can decorate the class maybe and thenates automatically. It basically modifies the behavior of all the class methods. Whenever I instantiate the instance, I get this functionality automatically. So it's a it's a way of implementing cross cutting concerns.

Speaker 4:Yes, it has two problems though, Okay.

Speaker 2:Oh, just to finish it's it's been a part it's it's very very popular in in Angular. Uh, it's been part of typescript for a while, and there's a proposal to add it to the JavaScript language itself, which, like we said, is kind of stuck in purgative.

Speaker 4:Yes, okay, let me explain the situation there. Okay, So the current so this pack.

Speaker 5:As it was originally proposed and done in typescript okay, all types types four and something okay, and before was was very hard to poly fil Okay. If you look at the JavaScript code that is being those syntax transpiles to, you can get very scared.

Speaker 4:Okay, lets let's go eight. It's like regenerator style things. I don't know if you ever looked at the cover of what our generator does, but is pretty ugly, okay, because there is a lot of global state. There is a lot of things happening. It's not nice.

Speaker 5:Then the standard changed in a way that it's essentially Java is essentially function wrappers okay, which can be attached to classes because classes are functions okay, or functions okay, which makes it way easier to to reason about this thing, okay. And also it's just a function, so it literally is easier to you know, implement some extent.

Speaker 2:The function that gets cold with the function as its argument and in context, and then it returns a function that gets used instead of the original function.

Speaker 4:Exactly, Very straightforward, Okay.

Speaker 1:I was just thinking, Yeah, it sounds like I'm still not sure I follow anyway.

Speaker 4:Anyway, It's it's simple, but there is a difference, okay.

Speaker 5:The old standard allowed to attach decorator to.

Speaker 4:Arguments parameters hmm.

Speaker 2:Yeah, and nest chess uses that a lot.

Speaker 5:Exactly, and in the new standard this is not possible.

Speaker 2:Anymore because they're not functions. They're just parameters.

Speaker 4:Exactly, and and that is my world problem.

Speaker 2:Okay, that nest chess is tied to a syntax which goes against the grain of where JavaScript is heading exactly.

Speaker 4:Also, its transpiled is really bad. That's it.

Speaker 5:I care a lot about the Java skity is being executed, and that is transpiled to some really two things that I would not have running on my servers.

Speaker 2:I'll say it again. It's really popular with people that come to note from Java, so I know a lot of back end developers that literally swear by it. It's a back end that you use as a back end for API. Course. Yes, it's it's not about necessa or anything like that exactly.

Speaker 4:But I am, I am.

Speaker 5:I have a side on all of this, so you can take all of what I said with a gain of salt. I have built to Fastify to solve this problem. Been using it for the last decade and very happy with it.

Speaker 2:Yeah, it's really opinionated anyway. Moving But in terms of performance, what can you say aboutn SGS.

Speaker 4:I have not benchmarked it signific Okay.

Speaker 5:I suspect is slower than Core Express or Fastify. You can use Express or Fastify underneath, and I suspect is slower and it adds a little bit over it on top.

Speaker 2:Yeah, it has to kind of because it's literally built on top of it.

Speaker 5:So yes, I hope is as little as possible. But look, you're asking so you might get an article on it. So I'm my co found is telling me to do it, so to do the research. So I'll do the research.

Speaker 2:I can say that it's pretty popular. It's popular to the extent that it's boring, you know, like the best compliment you can give about the technology is that it's boring.

Speaker 4:Yeah, I know, I know, I do the same.

Speaker 2:Okay. So moving back to what we were talking about with so you talked about the surprising results that you got. Now, so obviously, if I'm running the bottom line is that if I'm running currently node on Amazon, and especially if I'm using it for a s SR, not necessarily, but especially if I'm using it for as SR, then I should be looking at what because bun won't save me pretty much. And okay, cool, anything else to add on that particular.

Speaker 4:Topic, Nope, I think I covered it all.

Speaker 2:So you had a list, let's go to the next one. Yay.

Speaker 1:So so just just on the issue of time. We have been recording for about an hour, which I'm totally fine sticking around for however long, but I need.

Speaker 5:To probably go at when these meeting ends that I have on my calendar.

Speaker 2:So that doesn't it just means that you want to bring it on and I bring you on again.

Speaker 5:Absolutely, I'm coming again. I'm coming again, of course.

Speaker 4:Okay.

Speaker 5:So the second one that I wanted to cover is the topic of flame graphs. Now, in all of these benchmarking to do a lot of optimizations and look at things, okay, and we created a brand new frame graph tool to do performance analysis.

Speaker 1:I don't know what a flame graph is, So imagine that you are.

Speaker 5:You want to do a performance optimization. Okay, you have you know your application is low, and you want to know where it's low.

Speaker 4:Okay. A flame graph shows.

Speaker 5:You the hottest points in your code base that consume the most time.

Speaker 1:Okay, I've seen them, I just didn't know that's what they were called exactly.

Speaker 4:Okay.

Speaker 1:So Cinema GRAPHA and a new relic, so yeah.

Speaker 4:They can.

Speaker 5:You can click a button and get the flame graph. The key point is you the flame graph abstract time. So it takes an internet of time and says, let me represent this the function calls that happen in this interval of time. Okay, because in that way, I know how much a function is being called compared to the others.

Speaker 4:So I can make a comparison.

Speaker 5:Okay, so I can, so we can detect how much function was called and how hot it is.

Speaker 4:Okay, but I've been doing this for for a long time.

Speaker 5:I created the second kind of two third generation tool that I create with these kind of things. Okay, a new version of note require differently tools to get it done. PingER Cross is the last, but probably there will be another one in a few years.

Speaker 4:Okay.

Speaker 2:Now, somebody who's listening to us and here's a flame graft to measure NOTE performance might be thinking, Hey, why do I need this from a platformatic where I have it built into dev tools for like forever for why do I need at another one? What's wrong with the one that's built in death tools.

Speaker 5:The tools gives you a flame shart, not a flame draft. It's not as readable, it doesn't give you the full picture. Also, it's the way. The part of the problem is the collection of that data is very expensive, so by running it in the tools, you are essentially altering, like the act of observing something modifies the behavior.

Speaker 4:Quantum mechanics, right, Yeah, it's quantum mechanics at play.

Speaker 2:Yes, just to clarify, I'm aware of the issues and I totally agree with you. I'm just bringing it up so you can rebut it perfect.

Speaker 4:Okay.

Speaker 5:So it's quantum mechanics at work. You observe it, you change it.

Speaker 4:Okay.

Speaker 5:The way the what we have done instead of relying on the inspector to to get that data, okay, we are using a C plus plus module from our good friends at Data Dog that they're using their agent to collect those data from C plus plus straight out of the eight in the fastest possible way. So it does not interfere much with the application itself to the point that you can use it in production to collect those flame graphs. Now, if you try to enable the inspector, you are looking at a fifty percent performance job.

Speaker 2:It's beyond that. First of all, let's start with the fact that you probably don't want to attach the development tool to your production environment. Yes, somebody might click pause, Oh yeah, you're not going to be running in production Node servant production with as inspect you know, yeah, yeah, and you're not and you're not going to believe that that port open. Well, you know, you can do it as such tunneling and whatnot. But anyway, and like Matteo said, the overhead of actually doing a flame chart is really high.

Speaker 2:And by the way, also for that same reason, it's time constrained. You can't run it forever. You can run it for a very limited amount of time. Now, I have in the past implemented certain scenarios in certain applications where we sent a signal or an event into a process to kind of trigger it. But it's you can again, you can only run these sort of things for a really limited amount of time.

Speaker 4:Exactly.

Speaker 5:You can also still run this kind of tool for a limited amount of time, So it's a you know, you can even the way you do it, you run it for essentially one minute to collect what's happening. And in our platform, we can even start collecting it when usage goes over a certain threshold, so that you know, you don't you're not wasting money. But it's actually very good, so you can actually.

Speaker 4:Even running in production get good data out. Data Doctor is running this in production all the time. It's fantastic.

Speaker 2:By the way, I have to say, it was really funny. So when I found out about this tool and I started using it, and I started experimenting with it, and I reported like six issues or something like that back to Mateo and the guys and the gang, and like within one day it fixed all of them. It was it was really amusing.

Speaker 5:Yeah, very fast. It's so there is that. Okay, tool was great. Last week. I think we shaped something new. We shipped a way to get the representation of the flamegraph as marked down, so you can essentially feed it to an l LM and it will just fix things.

Speaker 2:So it will basically understand where your bottlenecks are in terms of performance and focus on them automatic exactly. Like this function is slow, but it's not just slow. It's impacting. It's being called a lot, so it has a significant impact. Or that function is hardly used, there's no point in optimizing exactly.

Speaker 1:Yeah, but like you said, Matteo, it seems also that some of the fixes are pretty commonly understood and easy for the LLM to implement, and so I can also you know, it's like add add a database index or hey, if you can't if you do it this way instead of that way. This structure is more performant than that one. And you know it's it's it's little changes, but they're low risk, low risk, and the LAM is great at it.

Speaker 5:Okay, I called the low hanging fruits. Okay, so the low hanging fruits are super easy to do.

Speaker 4:For the alarms. Okay.

Speaker 5:Now from the frame graph you can even spot some bad architectural patterns happening. And the bad architectural patterns are harder so to figure out.

Speaker 4:So during my research I've done, I opened a few bugs. Okay.

Speaker 5:One is on a React router. I found that it for every rendering its schedules a timer that's never cleared, so it runs to completion. It's it's like five second, but that cause it's becomes a hot spot for the garbage collection.

Speaker 1:Right. I was going to say, it's a memory leak, but it's nice. It does get it.

Speaker 5:Eventually, yes, but it's enough that it gets by. It'll keep memory located for more and it's enough for that memory to be moved to old space. So it's actually creating a some problems for the wrong time that's actually not needed. That could avoid could be avoided. Okay, I sent a patch. Another one that I found recently is a bug on with this tool is on GT.

Speaker 4:I don't know if you know GT.

Speaker 5:By the way, I found this a very horrible bug and I am really bad.

Speaker 4:Let me pass it to you because.

Speaker 5:And GT is a module a lot than sixty million times per week something like that.

Speaker 2:GT.

Speaker 4:Yeah, GT, this is a bug. I passed the bag in the chat J I T I yeah.

Speaker 5:It makes any any function that export in a function between sixteen seventy times lower.

Speaker 2:What is chitty.

Speaker 5:It's a module to load the typescript straight from node, similar to tes what tes no does, but that differently typed syme of things is used by yes, lint, nxt, netro, post CSS.

Speaker 4:I don't know.

Speaker 5:Tailwind is very popular in front and I have I had no idea this even existed until it showed up in my flamegraphs.

Speaker 2:Man, don't you love it when people use proxies?

Speaker 4:Yes? You see see I have you know it's it's it's one of the most misused technologies that you can get in that Like, if you're using a proxy, you should ask am I doing it wrong?

Speaker 2:And the answer would probably be yes, yes, not always, not one hundred percent of the time, but you should definitely be able to justify yourself.

Speaker 1:Yeah. So I'm going to kind of push us to wrap up this particular topic because we only have like eight minutes left.

Speaker 2:So I just have to say that before we conclude on this, that the ability to gather performance information throughout the lifetime of a process in production is invaluable. You know, we've had similar technologies in other programming languages, like the what's it called in Java? Java has the Java black box sort of thing, I forget the name. That they have the ability to collect performance information without usually without significantly impacting runtime performance, that you can do it in production.

Speaker 2:The ability to do the same thing or similar thing in for node is really invaluable. And I'm really grateful for Mattel and everybody Platformatic for releasing this game.

Speaker 5:Is there free tried out if you want, if you need, you know, talk a little bit about my company enough. But if you using this tag and you it's core part of what you do, you can reach out.

Speaker 4:We'll be very happy to help you.

Speaker 1:Cool. All right, Well, I'm going to push us two picks. Uh, this is where we do shout outs about stuff we like and uh yeah, I know that you're kind of under a time crunch Matereo, do you want to go first? Or do you want one of us to go first?

Speaker 2:Oh?

Speaker 4:Let me let you go first and then I go last.

Speaker 1:Okay, Dan, what are your picks?

Speaker 2:Okay? So I've got two picks. The first pick is. We've been playing this amusing game in our family these past couple of weeks. It's called Hitster. It's this kind of a game where you've got a certain like deck of cards and each card has this QR code that you scan, and it goes with your phone and it goes to the and it actually starts playing that song. I think it uses Spotify, but I'm not. I don't remember off the top of my head. And the idea is that you play every you divide into teams. You play the song for about twenty seconds, and then the team that turn it currently is needs to guess the artist, the title of the song, the artist, and the year in which it came out. If you need to guess at least two to get a point, If you guess all three, you get two points. Something along these lines.

Speaker 2:And we've been playing this in our family, and it's songs from all eras. In the case of Israel, it's both Israeli music and you know international or American music or British music, and it's really a lot of fun. We enjoy it very very much. You know, you listen to music, what's you know and and try to guess the songs. It's it's a lot of fun. So that would be my first pick, and the second pick is again is actually Matteo. I want to mention that on X Matteo, you put out videos on a fairly regular basis.

Speaker 2:It's they're relatively short usually I think they're like twenty minutes each, usually about a variety of topics related to know the Jass development obviously, and they're uniformly excellent, and I highly recommend following Matteo and watching the videos that come out. So that would be my second pick, And those are my picks for today.

Speaker 1:Awesome, Steve, what are your picks.

Speaker 3:Before I get to the high point of every episode, which are the dad jokes of the week. An interesting video that popped up on YouTube last night by Jeffrey Ray. Jeffrey Ray, who is the owner creator of Larra Cass, which, if not Larabelle Community is a pretty well known training platform for Larabell and on many many other topics as well. And he titled it I'm Done, and it's just sort of a a it's about thirteen fourteen minutes where he's just talking about the impact that AI has had on Larrakass and they just had to layoff a bunch of people, similar to what happened with Tailwind and the you know, sort of the use of AI and coding and you know, the pros and cons and sort of almost having to use it or get left behind. He's a I gotta agree with him in a lot of what he says.

Speaker 3:It's only about fourteen minutes, so it's it's a good watch, but it's I think it addresses the reality of AI encoding and how it's impact impacting things both I think, I think both for good and bad.

Speaker 2:I think we should probably bring a bunch of open source creators, people like Matteo, like maybe uh, we've had a of the Joel we we've had on the show talking about the slint and t slint uh and and basically talk about the impact that AI is having on on open source developers. It's really cutting the branch that a lot of them are sitting on financially.

Speaker 3:On that upper Ever note, I'll get to the dad jokes of the week. So, first of all, pretty straightforward question here, what do you call a pony with a sore throat? A little horse?

Speaker 2:Right?

Speaker 3:So good, thank you, Mateo.

Speaker 2:I love that.

Speaker 3:So everybody knows who Alan Turing is, right, the term touring complete Uh, you know in computer science Enigma and yeah, he cracked the Enigma codes in World War Two, but nobody knows his sister Kay, who provided drink, snacks and sandwiches for him and his colleagues. I was in catering, Yeah, right right.

Speaker 1:It took me a minute. Yeah.

Speaker 3:And then finally, uh, why does Spider Man hate driving with his evil twin because he's a bad parallel parker? Oh? Thank you. Those are the dad jokes of the week.

Speaker 1:I usually don't laugh at the dad jokes, but Mateo's reaction was priceless.

Speaker 3:That's half the fun sometimes.

Speaker 1:Oh all right, I'm gonna jump in with some picks. The first one I always do a board game pick, and this one we got for Christmas. Man, has it been that long since I've been able to get on and record. Yes, thanks Steve. He made me feel better. Anyway. The game that one of the games we got was Everdell came out twenty eighteen. My wife and I played it, so it was just two players with us. It probably took us an hour, maybe a little longer to play. We were learning it as we went though. I think I played it with my sister and my wife another time and it took us about the same amount of time because at that point we knew what we were doing.

Speaker 1:And anyway, what it is, it's actually the board's kind of cool because it's got this tree that you kind of slide together. It's made out of cardboard, but it looks really cool when it's set up and it's sitting on the board. Reminds me a little bit of the Tower in Fate of the Fellowship, which is a pandemic like game based on Lord of the Rings. But anyway, so Everdell plays up to four players and you're trying to collect resources in order to fill missions, and you're building a little town of animals in you know, basically in front of you, and that gives you special ability.

Speaker 1:So it's a pretty standard kind of game. It's just you know, a couple of little nuances and stuff. Anyway, it was fun. Definitely enjoyed it. It's not.

Speaker 4:It's not so.

Speaker 1:Novel or different or whatever that I would just go and reach for it on my own on a regular basis. But I did enjoy it. It's definitely a game worth, you know, having him playing, and the artwork on it is incredible. So I'm going to pick Everdell board game has a board game weight of two point eighty three, and that means that it's it's it's a fairly involved game, but if you've played a lot of the other resource gathering deck building kind of games, it's nothing outside of the realm of what you're what you've probably already played.

Speaker 1:So I'll pick that, and then what else. I started watching land Man and I've been enjoying that. That's on Paramount Plus, and so I'm going to pick that. And then I watched My wife and I started watching the show, and she's a little bit sensitive to people dropping f bombs during shows, and so if there's too much of that, she won't watch it. And so we watched like the first episode way back when of eleven twenty two sixty three, which is, uh, there's this history teacher. His friend's been going back in time to try and save JFK from being assassinated. And so anyway, he takes all of his friends research and you know, all the preparation that he's done, and he goes back to save JFK and right then come back to the future where it's supposed to be better because you know, Linda Johnson wouldn't have gotten us into the Vietnam War and a whole bunch of other things that other people did that you know, this particular guy didn't like wouldn't have happened. And anyway, so I'm not going to spoil how it changes the future, even though the show's like ten years old, just in case you want to go watch it, because honestly, it's it's

Speaker 1:actually pretty like the whole journey's pretty pretty interesting to watch him go through and you know, encounter people from the past and stuff like that. So I'm going to pick.

Speaker 2:So you've got to pick Prime Month plus. How are you enjoying Star Trek Starfleet Academy.

Speaker 1:I have not watched it at all. I've seen ads for it, but I haven't watched it. Is it good.

Speaker 2:I've not watched it. I'm going based on the reactions and the critics. You know, the story that they released the first episode for free on YouTube and a nerdratic in competition with him basically just put a video of doll of Spock sitting on a chair and he got more views.

Speaker 1:Oh funny. I have to say that.

Speaker 2:I understand that they did. It's Star Treks Acolyte.

Speaker 1:Okay, Yeah, I've I've liked a lot of stuff on Paramount Plus, but yeah, that's not That's not one that I've been watching. We liked Star Trek Discovery and Star Trek Piccard, but anyway, I haven't watched that one yet. So yeah, so Landman and eleven sixty three, which I think was originally on Prime and is now on Netflix. Anyway, Tayo, what are your picks?

Speaker 4:So the first one is.

Speaker 5:I've been taking a lot with Ai thinks, Okay, as everybody and I have having a lot of fun these last few days on a project called PI. It's a little open source codeing agent that is highly customizable. The heart of malt Bot now cloud bot whatever is what that thing uses internally to do work. Okay, and it's super fun to use and very fun to modify and change things and so on and so forth.

Speaker 4:Is really fun. So I've been tinkling with that.

Speaker 5:Also, I can use it with Ulama and even have a local model running very easily, and I add some success, some success, so I can run the full AI think on my machine. Not that I want to, but it's possible. So I can literally use those things on a plane if I want to, which is something that I really wanted to achieve.

Speaker 4:So I have done had fun with that. Okay, yeah, it's very easy. The other thing it's we're talking with the eye is tile scale. If you're not using tilescale, tailscale is you're missing out. Okay. You can interconnect all your devices, servers and so and so force in a single network. It's phenomenal. Okay, I'm a fan. So try that and combination with those two together, I can more or ize call things on the phone if I want to, and whenever I go, I can just have you know, checking on my agents doing things. And yeah, I'm becoming one of those people apparently.

Speaker 2:So the problem that I have right now, I know that a lot of people are running multiple agents at the same time. I'm having problems with that multitasking between different tasks myself, so it's difficult for me to schedule enough agents to do things all the time in the background. I maybe it's a fault of my own as a manager or something, but the end result is that I often end up waiting for AI to finish something.

Speaker 5:Yeah, which is you know, doesn't spit things up essentially, Well, yes.

Speaker 2:And no, but but yeah, it's kind of like going back to the early two thousands when we had slow compilers.

Speaker 4:Yep, a little bit.

Speaker 1:All right, well, Matteo. If people want to continue to follow along with the things you're working on, where do they find it.

Speaker 5:They find me on Twitter at mate Hoolina, or they can subscribe to my newsletter and.

Speaker 4:At nodland dot dev and yeah, that's kind of.

Speaker 5:It cool, and of course follow at Clubformatic and contact us if you need any help.

Speaker 4:Very happy to chat.

Speaker 1:Sounds good, all right.

Speaker 2:Support the people who are making no literally work.

Speaker 1:Yeah all right, yeah, we'll go ahead and wrap up until next time. That's out. Mm hmm.

Transcript supplied by the publisher with the episode.

JavaScript Jabber

by Charles M Wood · English · Tech & Science

Stay current on JavaScript, Node, and Front-End development. Learn from experts in programming, careers, and technology every week. Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support .

More from JavaScript Jabber

  1. 25 Feb 2026 · 57 min

    Mongoose 9, AI-Powered Database Tools & the Future of Server-Side JavaScript with Val Karpov - JSJ 703

    This week on JavaScript Jabber, we’re joined (again!) by Val Karpov — the maintainer of Mongoose — to talk about what’s new in Mongoose 9, how async stack traces are changing the debugging game, and why AI is quietly reshaping the way we build developer tools. We dig into stricter TypeScript support, the removal of callback-based middleware, and what it really takes to modernize a massive codebase. Then we shift gears into Mongoose Studio, a schema-aware, AI-enhanced MongoDB GUI that brings streaming query results, map visualizations, and even LLM-powered document generation into your…

  2. 30 Jan 2026 · 1 hr 13 min

    TanStack Start, AI, and the Future of Frontend Architecture - JSJ 701

    It’s great to be back behind the mic! In this episode of JavaScript Jabber, I’m joined by Dan Shapir and our guest Jack Harrington from Netlify and TanStack for a wide-ranging, high-energy conversation that covers everything from modern frontend architecture to AI tooling—and a few entertaining detours along the way. We dig into what’s new and exciting in the TanStack ecosystem, including TanStack Start and TanStack AI, and explore how these tools rethink the balance between frontend-first development and server-side capabilities. Along the way, we unpack React Server Components, AI SDKs,…

  3. E700 · 8 Jan 2026 · 1 hr 16 min

    What’s New in React 19.2: Compiler, Activity, and the Future of Async React - JSJ 700

    In this episode of JavaScript Jabber, I sat down with Shruti Kapoor, independent content creator and longtime React educator, to dig into what’s actually new — and worth getting excited about — in React 19.2. While it may sound like a “minor” release on paper, this update delivers some genuinely powerful improvements that can change how we build and reason about React apps. We talked through React Compiler finally becoming stable, how the new Activity component can dramatically simplify state management and UX, what View Transitions mean for animations, and why new tooling like Performance…

  4. 24 Dec 2025 · 47 min

    Can You Really Trust AI-Generated Code? - JSJ 699

    AI is writing more of our code than ever before—but should we actually trust it? In this episode of JavaScript Jabber, I sat down with Itamar Friedman from Qodo (formerly Quoto) to dig into one of the biggest questions developers are wrestling with right now: What happens when AI is generating code, reviewing code, and shaping how we ship software? We explore where AI fits into modern code review, whether developers should be worried about job security, and how human responsibility still plays a critical role—even in an AI-powered workflow. From guardrails and quality standards to the future…

  5. E698 · 10 Dec 2025 · 1 hr 5 min

    The Real State of Tech Hiring: AI, Ghosting, and the Developer Drought - JSJ 698

    In this episode of JavaScript Jabber, Steve Edwards and I kick things off by catching up on life — from winter weather and marathon training to health journeys, CrossFit, and some behind-the-scenes personal stories that shaped how we think about wellness and longevity. After warming up, we shift our focus to the state of the tech job market, something both of us have been watching closely and experiencing firsthand. We dive into the challenges developers are facing today — especially juniors — and compare our hiring and job-hunting experiences, the impact of AI on resumes and screening, the…

  6. 23 Nov 2025 · 1 hr 4 min

    Why Astro Is Winning Developers Over with Sagi Carmel - JSJ 697

    In this episode, I sit down with developer and speaker Sagi Carmel to dive deep into Astro, why it’s gaining so much traction, and how it compares to frameworks like Next.js, Nuxt, Remix, and SvelteKit. We explore what makes Astro uniquely powerful — from its server-first approach and island architecture to its simplicity, speed, and ability to integrate with any front-end framework you want. Sagi also walks me through real-world use cases, including how he built Israel’s official Census website with Astro, why scoped CSS and server components simplify the development experience, and how…

  7. E696 · 14 Nov 2025 · 1 hr 15 min

    The Truth About AI in Everyday JavaScript Development - JSJ 696

    It feels great to finally be back on the mic after a stretch of travel, work, and general chaos, and in this episode we’re diving into a topic that’s been coming up more and more in everyday developer conversations: how to actually use AI in your JavaScript development workflow. This isn’t about adding AI features to your app — it’s about using LLMs and AI-powered tools as part of your day-to-day coding practice. We talk through the tools we each rely on, how they’ve changed the way we write code, where they fall short, and where they can save hours of work. We also dig into the real…

  8. 1 Nov 2025 · 1 hr

    Guarding the JavaScript Supply Chain: Preventing NPM Attacks with Feross Aboukhadijeh - JSJ 695

    Hey everyone—it’s Steve Edwards here, and in this episode of JavaScript Jabber, I’m joined by returning guest Feross Aboukhadijeh, founder of Socket.dev, for a deep dive into the dark and fascinating world of open source supply chain security. From phishing campaigns targeting top NPM maintainers to the now-infamous Chalk library compromise, we unpack the latest wave of JavaScript package attacks and what developers can learn from them. Feross explains how some hackers are even using AI tools like Claude and Gemini as part of their payloads—and how defenders like Socket are fighting back…

  9. E694 · 24 Oct 2025 · 1 hr 14 min

    Making Monorepos Breakproof with Anton Stoychev - JSJ 694

    In this solo-hosted episode, I (Steve Edwards) dive deep into the world of modern monorepos with special guest Anton Stoychev from Yotpo. Anton shares his journey from the early days of PHP and IE6 nightmares to his current work in front-end infrastructure, performance optimization, and developer tooling. We talk about the challenges of managing dependencies, upgrading tools without breaking your codebase, and the evolution of developer experience across teams and companies. Anton also introduces Breakproof, Yotpo’s open-source monorepo template designed to make dependency management and…

  10. 9 Oct 2025 · 44 min

    Spec-Driven Development and the Future of AI IDEs with AWS’s Kiro - JSJ 693

    In this episode of JavaScript Jabber, I sit down with AWS’s Clare Liguori and Erik Hanchett to talk about Kiro, a brand-new AI-powered IDE that’s reimagining the way developers build software. We dive into how Kiro takes “AI-assisted coding” to a new level through spec-driven development — a process that focuses on defining requirements and collaborating with AI to break projects into clear, manageable tasks. We unpack what sets Kiro apart from tools like Cursor and Copilot, explore its supervised vs. autopilot coding modes, and even talk about how it handles UI design, planning, and complex…

Every episode of JavaScript Jabber →

Take it with you

The Melo app keeps playing with the screen off, works in the car and on your watch, wakes you to your station, and browses the whole catalogue offline. Free, no ads, no account.

Get it on Google Play