Speaker 1: Welcome back to another episode of JavaScript Jabber. This week,
Speaker 1: 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
Speaker 1: have Steve Edwards.
Speaker 3: Yo yo yo, coming at you from a slightly warmer
Speaker 3: now Oregon, where we really need snow.
Speaker 1: Yeah. Also, Steve, word is that you are currently looking
Speaker 1: 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,
Speaker 1: 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
Speaker 1: out there?
Speaker 4: Yeah?
Speaker 3: I was gonna wait till shameless plugs at the end,
Speaker 3: but yeah, you can my infos on my GitHub at
Speaker 3: Wonder nine to five, same handle for Twitter. It was
Speaker 3: probably the best way to get old Steve at s
Speaker 3: mg a web dot com.
Speaker 1: Cool. I just want to make sure that yeah, people
Speaker 1: hear it and they can reach you if they need to.
Speaker 1: I'm Charles Maxwood from Top End Devs And this week
Speaker 1: we have a special guest. We have Matteo Colina.
Speaker 5: Hello, I folks, Hey, Hi from for Lee Italy. It's
Speaker 5: 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
Speaker 4: he's on the map.
Speaker 1: Yeah, Pasatoduani in Italia. I was a missionary in Italy
Speaker 1: and yeah, so I've been to for Lee and Remini
Speaker 1: and wow, I lived in Oncona for like six months
Speaker 1: so yeah, wow, Oh so you know.
Speaker 2: And we and we, my wife and I passed really
Speaker 2: close by just when Matteo happened to be in London. Yes,
Speaker 2: 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
Speaker 5: to a nightmare.
Speaker 2: Well, all I can say is will probably be in
Speaker 2: Italy again because we love Italy, and next time hopefully
Speaker 2: we'll be able to actually meet.
Speaker 1: Yeah, I would love to go back. We had a
Speaker 1: foreign exchange student who also lives in Oncona and so
Speaker 1: we'd like to see her and her baby. So anyway,
Speaker 1: what are we talking about that's not travel tech or
Speaker 1: Steve needs a job.
Speaker 5: Today we're talking a little bit about the latest thing
Speaker 5: in platformatic my company, and not j yes, I think
Speaker 5: maybe with some ais pist in it, because you know,
Speaker 5: everything is AI today.
Speaker 2: Yeah, a lot of our listeners may not be familiar
Speaker 2: with Platformatic, but I think that if you're doing a
Speaker 2: think with notes, there's a good chance that you're probably
Speaker 2: using at least one thing from Platformatic.
Speaker 5: Like it's absolutely at this point, I think you're using
Speaker 5: something from from Platformatic close to one hundred percent. Okay,
Speaker 5: it's as I say, last year, I touched forty two
Speaker 5: a billion downloads on NPM some some some impossible numbers
Speaker 5: like that.
Speaker 4: So this is the state.
Speaker 2: So like every man, woman and child on this planet
Speaker 2: 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.
Speaker 5: 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
Speaker 1: 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
Speaker 5: the gift.
Speaker 1: There you go.
Speaker 5: So it's the one time over the over the year
Speaker 5: 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
Speaker 5: true talking about things we have since the last time
Speaker 5: was year so what we have released a few benchmarks
Speaker 5: okay that I think are pretty relevant for everybody to
Speaker 5: look at. So let me just get them and so
Speaker 5: that we can discuss them. I'm going to pass them.
Speaker 2: While you do. I was. I want to emphasize that
Speaker 2: while I was obviously somewhat kidding before, it is absolutely
Speaker 2: true that I kind of considue you to be sort
Speaker 2: of mister no JS, especially now that Ryan Dalla has
Speaker 2: moved on to other things.
Speaker 5: H It's well, I have been since this summer. I've
Speaker 5: been nominated the chair of the no JS project. So wow,
Speaker 5: 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
Speaker 2: show officially that I'm I'm you know, Node is not new,
Speaker 2: obviously it's been around for a while, but I'm I'm
Speaker 2: seeing Node usage actually increasing. A lot of organizations that
Speaker 2: have previously been using other technologies for the back end
Speaker 2: are adopting Node as their go to technology for back
Speaker 2: end stuff. I don't know if it's because of the
Speaker 2: Lambda functions and stuff like that, or it's because you know,
Speaker 2: all the meta framework out there, Next JS and ten
Speaker 2: stack and whatnot. I don't know. Maybe it's like everything together,
Speaker 2: but I'm definitely seeing no JS technology usage pickup a
Speaker 2: lot of companies. Like I was speaking at this conference
Speaker 2: in Israel, and like every company that I was talking
Speaker 2: to was doing something with no JS on the back end.
Speaker 5: Yeah, it's everywhere, Okay, right now, if you want to
Speaker 5: 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
Speaker 5: be in a minority. But the mainstream stack right now
Speaker 5: 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
Speaker 5: 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
Speaker 3: and I've talked about ad nauseum probably on here. Inertia
Speaker 3: has a service side rending capability. If you're using View
Speaker 3: 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,
Speaker 3: 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
Speaker 3: your front and your back end that allows you to
Speaker 3: plug and play. So you could use View with Ruby,
Speaker 3: with Laravel, with Node, you could use you So you
Speaker 3: could use viewsvelt react Angular on the front end, and
Speaker 3: you could use laravl Node, Ruby on the back end
Speaker 3: in any combination. So it's just it's crazy fast. I
Speaker 3: have an application that I've built and maintained for a while,
Speaker 3: and it's just amazing how fast it is. It basically
Speaker 3: sort of hijacks the post request and the browser doesn't
Speaker 3: do a full reload. You passes some headers that tell it,
Speaker 3: hey don't do a full Perial railroad and communication between
Speaker 3: the two point being, to answer your question, if you
Speaker 3: go with inertia, there's service any capability.
Speaker 5: So if I want to do a Larrabell and view.
Speaker 5: Then I can do that like I am seeing. Okay,
Speaker 5: to be clear, I'm looking. I opened it up in
Speaker 5: 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
Speaker 5: things typically is there is some no JS little notes
Speaker 5: thing running and doing the job.
Speaker 4: I don't know.
Speaker 5: It somewhere, okay, because in the problem is that with
Speaker 5: modern front and frameworks you need the areizomorphic. So you
Speaker 5: have the same Java skipt code that runs on the
Speaker 5: front and on the back end, and in order to
Speaker 5: do some side rendering you have to render it on
Speaker 5: 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
Speaker 4: 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
Speaker 5: JS everywhere in in In.
Speaker 2: And then kind and then PLATFORMA. They kind of flipped
Speaker 2: the script there where you kind of put WordPress and
Speaker 2: Narvel on top of note or something.
Speaker 5: Yes, So last last year we shaped a few experiments.
Speaker 5: We were able to run full pitchp inside no JS.
Speaker 5: It works really well. It's actually very performant, to be honest.
Speaker 5: So there is literally nothing stopped that kind of those
Speaker 5: kind of deployments. But it's let's see what the market says,
Speaker 5: and if there is, if they are attractive for the market,
Speaker 5: 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.
Speaker 5: It's the same thing. It's it's the same hooks that
Speaker 5: 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
Speaker 1: tie back in?
Speaker 5: Yeah, so we've been doing this is the benchmarks. Okay,
Speaker 5: we've done a few. I just wanted to point out
Speaker 5: chew one is and let's see where the chat is.
Speaker 5: Here is a chat.
Speaker 1: Yeah, there's a chat. It's on the right. It's got
Speaker 1: a little chat bubble.
Speaker 4: Okay, here we go. I'm passing in the chat. So
Speaker 4: this is one. I am passing it.
Speaker 5: The second one that we have done, and then I
Speaker 5: have a few more.
Speaker 4: To talk about.
Speaker 5: So the first one is we've done last year. It's
Speaker 5: a benchmark showing next JS performance. Okay, under very high traffic.
Speaker 5: So for Next, yes, so what happened, What is happening
Speaker 5: is we have done a lot of tests, okay, and
Speaker 5: it's with a lot of tests for example, with one
Speaker 5: thousand requests on per second for I mean, for a
Speaker 5: couple of minutes on against next JS and those were
Speaker 5: 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
Speaker 5: you're using Next or a React based server side system,
Speaker 5: to go between eight twenty, between eight and twenty maybe
Speaker 5: fifty requests per second at.
Speaker 4: Best, okay.
Speaker 5: If you have a very complex system like it's low
Speaker 5: okay in the genetic terms of things, okay. So the
Speaker 5: critical point okay of this was the success rate, but
Speaker 5: more important in the latency okay. The latency for this
Speaker 5: kind of system is very bad okay. And this is
Speaker 5: affecting a lot of companies out there, okay. And a
Speaker 5: good chunk of that problem is due to our scheduling
Speaker 5: is done of of multiple parts in kubernets okay, round robin. Unfortunately,
Speaker 5: it's it's not the best algorithm most of the time, okay,
Speaker 5: But the one that's the one we have. And last,
Speaker 5: 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
Speaker 5: 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
Speaker 2: loup is kind of never supposed to be blocked.
Speaker 4: Well, tell that to all the developers using React, like,
Speaker 4: that's the absolutely, that's the world point the idea. Yeah,
Speaker 4: that's the idea.
Speaker 5: But reacts over side rendering is super expensive, okay, and
Speaker 5: 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
Speaker 5: creates a full virtual dam of all the elements in
Speaker 5: the page and then it stringifies that and you need
Speaker 5: 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
Speaker 5: all of those elements.
Speaker 2: That's really unfortunate given that it then immediately discards that
Speaker 2: 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
Speaker 5: 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
Speaker 5: not blocking the end loop and I can really subscribe
Speaker 5: to that sentence. Okay, So to the point, so to
Speaker 5: the point that if the event look blocks for a
Speaker 5: long time, it's better to kill that node process and
Speaker 5: start a fresh one up because keeping that running is useless.
Speaker 2: Yeah, if you're going to be doing really significant GC,
Speaker 2: then why I mean, just you know, I'm reminded of
Speaker 2: what the Apache I think the approach was about, like
Speaker 2: managing like the heap in in like sort of chunks
Speaker 2: and then discarding the entire chunk rather than trying to
Speaker 2: do fun grain GC.
Speaker 5: Well, it's to some extent is relatively similar what we
Speaker 5: are doing. So with what or not just application server
Speaker 5: we have based on this on this thing, we can
Speaker 5: monitor the state of the event loop from the outside
Speaker 5: and if you detect it, it is totally blocked. Nothing comes true,
Speaker 5: nothing is going to come through. We just shut the
Speaker 5: shut the thing down. So and because we can, we
Speaker 5: shut the thing down and we started from and restart,
Speaker 5: we can essentially recover a really broken pad back to
Speaker 5: life and let some traffic pass through.
Speaker 2: So the basic idea is saying, instead of trying to
Speaker 2: do this really really complex GCS at a high frequency,
Speaker 2: because of all the incoming requests, every once in a while,
Speaker 2: just kill the pod and start fresh.
Speaker 5: Well, it's when the event will be is blocked. So
Speaker 5: it's literally like when there are too many like. The
Speaker 5: problem is also that there are all those requests are
Speaker 5: piling up to be processed and after five seconds it's
Speaker 5: 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,
Speaker 5: especially with a lot.
Speaker 2: Of interesting You would think that they would have figured
Speaker 2: 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
Speaker 5: to the same socket so that you can do the
Speaker 5: load balancing easier. It's very similar to say, oh, it
Speaker 5: is similar to nod cluster or PM two and not cluster,
Speaker 5: but instead of doing the load balancing inside not JS,
Speaker 5: which is what nod cluster and pmhould do with in
Speaker 5: that we use a new node feature that let us
Speaker 5: do load balancing inside the kernel using scores, a flag
Speaker 5: 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
Speaker 5: just give it your app. It will run it inside
Speaker 5: a worker thread and the main thread will just minor
Speaker 5: it and you can scale it up and down multiple threads,
Speaker 5: multiple course, and if you want, you can even have
Speaker 5: aterogenerus system. You can have multiple different applications running there
Speaker 5: and they can communicate via message passing or just h GDP
Speaker 5: over memory.
Speaker 2: See so what does it compete with? What are they like?
Speaker 2: When would I use what? And would I put like
Speaker 2: next JS? On top of what?
Speaker 5: If you're if you're deploying not JES in Kubernetus, you're
Speaker 5: probably not doing the not doing the right thing if
Speaker 5: 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?
Speaker 4: 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
Speaker 2: whenever I use node in Kubernetes, you recommend using it
Speaker 2: on top of what I.
Speaker 5: Would say, Yes, it gives you more reliability in this
Speaker 5: example with jes that I've shared in the chat, essentially
Speaker 5: we can move down P ninety five from a second
Speaker 5: to two one hundred and thirty five milliseconds.
Speaker 1: Oh wow. And just for those who don't follow along
Speaker 1: with benchmark stuff of P ninety five, is ninety five
Speaker 1: percent of your requests take this long or less?
Speaker 2: So in other words, yeah, beneficial for the five percent
Speaker 2: slowest users.
Speaker 4: Is beneficial for everybody.
Speaker 1: If fits for everybody. Yeah, essentially, Yeah, so all the
Speaker 1: all the requests now, so ninety five percent of the
Speaker 1: requests instead of taking up to a second, now take
Speaker 1: up to two hundred and thirty five milliseconds. Now you
Speaker 1: assume that the other five percent it also speeds up
Speaker 1: for But yeah, that's kind of the measure, and it's
Speaker 1: it's one of the more common ways of measuring how
Speaker 1: fast your application is because the load and the requests
Speaker 1: and what it has to do and what else is
Speaker 1: running on the machine can vary from time to time,
Speaker 1: and so this kind of averages it out.
Speaker 2: Also, think about it from the perspective of a business
Speaker 2: loto you like, you want to think about the customers
Speaker 2: that have it the worst, and you can't really afford
Speaker 2: to lose five or ten percent of your business because
Speaker 2: it's just too slow. Exactly. But I'm thinking about what
Speaker 2: you said. It does mean though, that you want to
Speaker 2: allocate more than one CPU per yes, no instance in
Speaker 2: your kubernets in how.
Speaker 4: You absolutely this actually helps. Okay, let me explain why
Speaker 4: it helps.
Speaker 5: Okay, The cost of spinning up a new pod in
Speaker 5: Kubernatis is more or less fixed independent of the amount
Speaker 5: the amount of resources that are attached, okay, or anyway,
Speaker 5: it's not very much different.
Speaker 4: Okay.
Speaker 5: If I am scheduling largest things, each unit of scale
Speaker 5: gives me more power to handle my spikes better. So
Speaker 5: it's the edges of scaling are a little bit steeper.
Speaker 5: But this actually helps smooth the curve way quicker because
Speaker 5: these new things.
Speaker 4: Make it.
Speaker 5: Can handle more load per unit. Okay, So this is
Speaker 5: one thing.
Speaker 1: Okay.
Speaker 5: The second thing is Kubernatis takes minutes to scale, so
Speaker 5: when the load typically reacts in one two minutes is
Speaker 5: very slow, tiny to to to schedule things up. And
Speaker 5: by having this system you can actually absorb the shock
Speaker 5: completely inside your pods.
Speaker 2: Interesting, very interesting. I need to think about this some more.
Speaker 2: I will definitely make sure that our develops people see this.
Speaker 2: I mean literally everybody is using kubernets these days, whether
Speaker 2: they need.
Speaker 4: To exactly exactly.
Speaker 5: We also have built, but it's not mentioned in this benchmark,
Speaker 5: built another product called Intelligent Command Center that is open
Speaker 5: source as well, that reduced the decision time of kubernets
Speaker 5: from minutes two seconds. So the pod starting is down
Speaker 5: is making less than five seconds the decision to start
Speaker 5: 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
Speaker 5: actually it's actually very fast in scaling up. Okay, but
Speaker 5: it can scale up on very specific signals from the app,
Speaker 5: so it and so it can be a little bit
Speaker 5: more noisy, but it actually allows you to reduce your
Speaker 5: 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,
Speaker 5: so you can reduce your baseline and during off peak
Speaker 5: hours you can actually save a lot of Yeah.
Speaker 1: I guess that's always the thing that I'm concerned with
Speaker 1: when you have this kind of automation, is, you know,
Speaker 1: does a scale up too much? Does it? You know,
Speaker 1: does it handle things when you know when I need
Speaker 1: it to scale down? Because yeah, it costs a lot
Speaker 1: more when you scale way up. But if that's what
Speaker 1: you're getting in traffic, and usually traffic translates in some
Speaker 1: ways to money, not always, but yeah, so that anyway
Speaker 1: pretty cool.
Speaker 4: So this was part of our results.
Speaker 5: We published this study, okay, and hopefully we can get
Speaker 5: some results from our rock click customer down out soon.
Speaker 5: But this is our own and all the benchmarkt and
Speaker 5: ernests done for this is open source, so you can
Speaker 5: 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.
Speaker 2: I think I was kind of aware of this, but
Speaker 2: I was not fully aware of this. And like I said,
Speaker 2: literally everybody is doing non kumberinators these days. So if
Speaker 2: the impact is so dramatic and so significant and so
Speaker 2: readily achievable, yes, you know, there's literally no reason not
Speaker 2: to try it out. This is.
Speaker 5: Partially the reason why when you asked to come to
Speaker 5: join the show. I said, I'm coming join the show.
Speaker 5: This is the research that we published. So we published
Speaker 5: 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
Speaker 5: spicy one, I would say, okay. And we benchmarked on
Speaker 5: the same benchmark on the first one, slightly different traffic
Speaker 5: load whatever, Okay. We benchmarked the note the tree no
Speaker 5: dress run times in Kubernetes so bunn no JS as
Speaker 5: well as our own way of scheduling things with what
Speaker 5: so we got some really unexpected results, not the results
Speaker 5: that I would expect, and it showed that bun So.
Speaker 2: Just before you you tell what you found, just to clarify,
Speaker 2: what is only for node, it's not for the other
Speaker 2: For the other platforms, you can't use it to DNO
Speaker 2: with bun.
Speaker 4: No you can't.
Speaker 5: Well like you can't because those other platforms are not
Speaker 5: fully not GS compatible. And the approach that we have
Speaker 5: taken with what is instead of creating a custom built
Speaker 5: not just run time with our patches, we have upstream
Speaker 5: all our patches up to note core of the things
Speaker 5: that we needed, and that is only is written mostly
Speaker 5: in JavaScript mostly every now and then we had to
Speaker 5: have a little bit of C plus plus to implement
Speaker 5: 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
Speaker 5: 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
Speaker 1: that I like this idea of hey, we needed this
Speaker 1: in node in order to make what work, and so
Speaker 1: you contribute it back and so it's stuff that other
Speaker 1: people can use.
Speaker 5: Exactly one like this is the whole point. Like part
Speaker 5: of the reason why I funded Platformatic was can I
Speaker 5: try to build a business that can uh make the
Speaker 5: open source economically viable and and allow us to grow
Speaker 5: with it? So let's try. This is the this might
Speaker 5: try Okay, I might succeed, might not succeed. I hope
Speaker 5: I succeed, but I needed to try this. So my journey.
Speaker 1: I'm going to go into a tangent here real quick
Speaker 1: because I'm kind of curious. So when you say make
Speaker 1: 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
Speaker 5: investment in core technologies from companies, and we need more
Speaker 5: companies that are that invest significant amount of money into
Speaker 5: 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
Speaker 5: and up. Okay, And you cannot rely on the sponsor
Speaker 5: model because it's too little, too late. So you need
Speaker 5: if you need to pay to do payroll, you need
Speaker 5: to have significant sales involved. So the goal is to
Speaker 5: build a significantly big enough company that can afford multiple
Speaker 5: people and working full time on the core technologies, and
Speaker 5: not because it's it's a good thing to do, but
Speaker 5: because it needs them to be there as a core
Speaker 5: function of the business so that it's not a donation,
Speaker 5: it's a function.
Speaker 1: Okay.
Speaker 5: And because it's a function and it's a core part
Speaker 5: 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
Speaker 5: and stuff, we sell enterprise version of all our technologies
Speaker 5: plus support and on boarding. So if somebody needs anything
Speaker 5: related to no JS, we can provide support, We can
Speaker 5: provide and we can provide an enterprise license for our
Speaker 5: 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,
Speaker 5: 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,
Speaker 5: these kind of things so far, but it will grow more.
Speaker 5: It's more related to SLAS and response to incidents and
Speaker 5: 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
Speaker 5: are moving dynamically, so they our customers can steer, can
Speaker 5: 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
Speaker 5: you know their partners.
Speaker 2: I think that esslas are the way to go, to
Speaker 2: 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
Speaker 2: my back end on node, I need ESLAS and and
Speaker 2: if you know, if I if I can out kind
Speaker 2: 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
Speaker 2: before we went on the tangent.
Speaker 4: If we can remember, yeah, okay, we can go on
Speaker 4: the tangent all the time. So anyway we are, I
Speaker 4: was chatting, I've over the break, I've done this extensive
Speaker 4: benchmark on band Dino and note okay, and I got
Speaker 4: very surprising results. The benchmarks included running the same next
Speaker 4: Jaess application that.
Speaker 5: We talked about before. Okay, reactions are rendering? Have your memory?
Speaker 5: Have you on CPU?
Speaker 4: Really like.
Speaker 5: Possibly the worst load but also the most common load
Speaker 5: that you can have running on OJS these days, And
Speaker 5: I got very surprising result that I didn't expect them
Speaker 5: 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
Speaker 5: did new versions of.
Speaker 2: So approximately one second.
Speaker 5: Yes, well not JS was one hundred and seventy four.
Speaker 5: Do you know at one hundred and not JS with
Speaker 5: what at one hundred and fifteen?
Speaker 2: So Bun was noticeably slower than everybody else exactly. To
Speaker 2: be honest, I know that Bun has a reputation for
Speaker 2: being fast, but the people need but people need to
Speaker 2: 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,
Speaker 1: but yeah, you run a different application the different engines
Speaker 1: manage memory differently and concurrency differently than other things differently,
Speaker 1: and so yeah, it's.
Speaker 2: Beyond a different application. I think it's it's like a
Speaker 2: different scenario, yes, because you've got you've got startup times,
Speaker 2: and you've got and you've got run times, and there's
Speaker 2: a question of when optimizations kick in. If they kick in,
Speaker 2: what do you do in the jet stage stuff like that.
Speaker 2: So what could be really fast for a long running
Speaker 2: a no type service could be really slow when you're
Speaker 2: building a utility that just runs, does something and then terminates,
Speaker 2: and an expectation that a certain platform will do everything
Speaker 2: 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
Speaker 5: this informal feedback. You can take what we do with
Speaker 5: a gain of salt jsc which is the JavaScript run
Speaker 5: time behind ban and Safari is optimized for cold starts
Speaker 5: to start very immediately. Imagine when you open Safari on
Speaker 5: your iPhone, it opens up super quick.
Speaker 4: Okay, while V eight is more optimized for running or
Speaker 4: wrong running application. Thanks Jmail.
Speaker 2: Yeah, that's the thing, you know, people talk about like
Speaker 2: the various You know, there's this been trend of rewriting
Speaker 2: the JavaScript utility ecosystem in other programming languages, be it
Speaker 2: go or be at rust or be it whatever, instead
Speaker 2: of doing it in JavaScript or typescript. And you kind
Speaker 2: of hit your head on the nail there, matel Because,
Speaker 2: for example, if we think about.
Speaker 3: And that's a nail on the head, not head on
Speaker 3: the nail unless you really want to hit your head
Speaker 3: 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
Speaker 3: meaning to the term hammerhead, doesn't it.
Speaker 2: Yeah? Anyway, what I was saying is that the JavaScript
Speaker 2: optimizer in EA, I always forget the name whether is
Speaker 2: 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
Speaker 2: then optimizing that while the code is actually executing. But
Speaker 2: in order to identify hot code, the application needs to
Speaker 2: be running for a while. And if you're running a
Speaker 2: tool that just starts up, does its job and then finishes,
Speaker 2: 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
Speaker 2: some Lambda function usage.
Speaker 4: Well, I let me say this, if you are moving
Speaker 4: serious traffic, you are probably better served using ECS or
Speaker 4: cobnetis or whatever long running process. But to be honest,
Speaker 4: Lambda actually okay, let's let's go. Let's open the lambda
Speaker 4: point because it's actually a validation of that to some extent.
Speaker 5: So if you if you have followed what has been
Speaker 5: launched by a w as in the latest the latest
Speaker 5: rainvent in December, is a new Lambda run time for
Speaker 5: I troueput scenario I traffic scenario that is not actually
Speaker 5: one request per process, okay, but it allows one process
Speaker 5: look at this to have as many threads as it
Speaker 5: wants to end or requests in a lot of things.
Speaker 5: Is actually similar to how that works internally in how
Speaker 5: the things are scheduled. So this kind of system allows
Speaker 5: Lambda to.
Speaker 4: You know, use all the potential of no js essentially
Speaker 4: 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
Speaker 5: people are not you know, tapped into this yet, like
Speaker 5: they think, oh, no, jes single treded or mostly single traded,
Speaker 5: while in reality it's not, and you can do a
Speaker 5: lot of interesting things with it, and they just you know,
Speaker 5: ignore the point.
Speaker 2: Well to be to be honest, no, JavaScript is a
Speaker 2: single threaded language, but Node and the JavaScript Virtual Machine
Speaker 2: 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
Speaker 2: 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
Speaker 5: incredible results, like not expected, to be honest, I didn't,
Speaker 5: like I had to check them five times and have
Speaker 5: to have some friends check them with me.
Speaker 2: So why was it expected? You you didn't expect such
Speaker 2: a band to be that slow in that particular test, yes,
Speaker 2: And did you expect Dino to be that fast by the.
Speaker 4: Way, yes, yes, significantly. I was expecting Dino to have
Speaker 4: 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
Speaker 5: is based on Tokyo, while no event loop is based
Speaker 5: on libuv.
Speaker 4: Okay, and Tokyo is.
Speaker 5: Be a decade later than libv type of thing, and
Speaker 5: by things have improved, you now you do those kinds
Speaker 5: of things, okay, And it's very hard to chase something
Speaker 5: like libuv understood, So there is that is the problem,
Speaker 5: Like it's it's not just LIBUV by the way, it's
Speaker 5: also the node machinery in entirety. So how we get
Speaker 5: the data out of libuv, how we schedule new connections
Speaker 5: and we do all Like there's a lot of work
Speaker 5: over there and a lot of over it, but some
Speaker 5: of that over it is essentially legacy, and it's very
Speaker 5: hard for us to like it's possible, it would be
Speaker 5: possible to optimize, but it's a hell of a lot harder.
Speaker 2: So could you remind me again what the numbers are
Speaker 2: for node versus note with what.
Speaker 4: So on p.
Speaker 5: Nineteen nine we add one hundred and seventy four millisecond
Speaker 5: I may we measured one hundred and seventy four million
Speaker 5: 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
Speaker 2: 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
Speaker 1: at home right this, you're throwing out numbers and scenarios,
Speaker 1: But what does this look like for me? Right? So
Speaker 1: I have a next JS setup, or i have a
Speaker 1: note application that I've written, and I've got React on
Speaker 1: the front end and I've got server side rendering setup
Speaker 1: or whatever, like, how does this actually translate? And what
Speaker 1: does this look like when I'm troubleshooting or you know,
Speaker 1: measuring my own benchmarks or things like that.
Speaker 5: So the key difference is the point of so when
Speaker 5: you're doing in your is when you do saturation or
Speaker 5: stress testing. Stress testing, so you're putting it to a
Speaker 5: very high load scenario and you want to know when
Speaker 5: your up breaks.
Speaker 4: And essentially.
Speaker 5: These numbers tells create more or less ranking of where
Speaker 5: 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
Speaker 2: to improve application startup times. Yes, that's the primary motivation
Speaker 2: of doing SSR. And what we've literally learned now is
Speaker 2: that you might be doing SSR with the goal of
Speaker 2: improving startup time and end up part of my French
Speaker 2: screwing yourself because your back end will not be able
Speaker 2: to properly handle the extra load. And I'm actually looking
Speaker 2: at the Crux data. We've spoken about it on the
Speaker 2: show on several occasions, so a quick reminder what it is.
Speaker 2: Google collects anonymous performance information from all browser sessions or
Speaker 2: Chrome browser sessions and unless you opt out, and it's
Speaker 2: not really easy to opt out, so assume it's more
Speaker 2: less everybody. And they are looking and then they are
Speaker 2: breaking it down by technologies used using the HTP archive.
Speaker 2: So basically for each domain, they're looking if a domain
Speaker 2: has sufficient amount of traffic, so they're looking at the
Speaker 2: top ten million domains more or less in terms of traffic.
Speaker 2: They're segmenting them by technologies used, and then they actually
Speaker 2: release this information to the world so you can actually
Speaker 2: see which technology is more likely to give you better performance.
Speaker 2: And I'm currently looking at the graph that compares all
Speaker 2: the websites within cracks, the WordPress websites, the Wix websites,
Speaker 2: and next JS websites. And I'm looking at what percentile
Speaker 2: of websites get good performance results. According to Google, it's
Speaker 2: the cob vitals. Okay, wow, yeah, And if we're talking
Speaker 2: about all technologies, we're talking about about fifty one percent,
Speaker 2: So approximately half of websites get good coed vitals and
Speaker 2: about half get poor web vitals. If we're talking about WordPress,
Speaker 2: the number is forty six percent. So WordPress is slightly
Speaker 2: lower than all technologies at large, but pretty close. So
Speaker 2: WordPress and all technologies is more or less the same.
Speaker 2: Maybe also the fact that like half the web runs
Speaker 2: 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
Speaker 2: the chat.
Speaker 4: An Houp going fantastic. I found it.
Speaker 2: So Wix has seventy three percent. So if you're building
Speaker 2: a website on Wix, there's a seventy three percent probability
Speaker 2: that you will be getting good performance. Okay, what's the number? Sorry,
Speaker 2: what's the number for next JS? Now you assume that
Speaker 2: next YS would be great because the whole thing about
Speaker 2: next GS is that it's as SARRD. So what's the
Speaker 2: probability for next gs?
Speaker 1: Can you guess feel like you're setting me up to
Speaker 1: let me down so well, I would have assumed before
Speaker 1: you said it, kind of skeptically that it'd be you know, yeah,
Speaker 1: somewhere around wis you know, sixty seventy percent, but you're
Speaker 1: 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
Speaker 2: good performance when you're using NEXTJS, you know, you're you're
Speaker 2: putting all this effort into building let's say AI is
Speaker 2: not doing your entire job yet you're doing putting all
Speaker 2: this effort in encoding your website and react and hosting
Speaker 2: it and whatever you and your probability of getting good
Speaker 2: co ed vitals is less than thirty percent, And that's
Speaker 2: really unfortunate.
Speaker 1: Yeah, that's bad. So the stuff that Mateo is talking about,
Speaker 1: then do you do you get those kinds of performance
Speaker 1: increases kind of for free just by upgrading your note
Speaker 1: or make.
Speaker 4: It better by using what on top of next which
Speaker 4: 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
Speaker 5: fundamental point is next JS is designed to run well
Speaker 5: on versall and to run it well on your own infrastructure.
Speaker 5: You're missing a few components, and we added those few.
Speaker 2: So with verse cell out of the box, I'd be
Speaker 2: getting comparable performance to what I have.
Speaker 5: Absolutely no idea. I've not measured. I've not benchmarked their cloud.
Speaker 5: To be honest, I don't even it's a good product.
Speaker 5: I am a customer like Performati is a customer overrsell. Okay,
Speaker 5: we are as most startup. Is the greatest thing ever
Speaker 5: to be using perself. Okay, yeah, it's easy, it's easy.
Speaker 5: There are a lot of companies out there that cannot
Speaker 5: use yourself for all sorts of reasons, okay, from and
Speaker 5: that is critical.
Speaker 2: I know that the companies are running next gs on
Speaker 2: 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
Speaker 5: a thing called open next run it on top of
Speaker 5: cloud Flare and other stuff. Okay, what we've done make
Speaker 5: 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
Speaker 5: 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
Speaker 5: have with nest is its reliance on the old time
Speaker 5: skip decorators. So I don't know if you've been following
Speaker 5: the story of Java skip decorators with the year thirty nine.
Speaker 2: That standard that never ever materializes. It's been stuck in
Speaker 2: 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
Speaker 2: that all our listeners I kind of assume that listeners
Speaker 2: were familiar with Kubernetes, which might have been either correct
Speaker 2: or incorrect. An assumption to make, but let's not assume
Speaker 2: the same for decorators. Decorators are a language feature in
Speaker 2: JavaScript or typescript which allow you to decorate function method
Speaker 2: classes and methods and properties. You put the ad sign
Speaker 2: and then some words, and basically it wraps the declaration
Speaker 2: in a function call and that function call can modify
Speaker 2: the actual class definition or the method definition. So for example,
Speaker 2: let's say the canonical example is I want to print
Speaker 2: out a log whenever a method enters and exits. Instead
Speaker 2: of explicitly adding a log everywhere, I can decorate the
Speaker 2: class maybe and thenates automatically. It basically modifies the behavior
Speaker 2: of all the class methods. Whenever I instantiate the instance,
Speaker 2: I get this functionality automatically. So it's a it's a
Speaker 2: 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
Speaker 2: it's very very popular in in Angular. Uh, it's been
Speaker 2: part of typescript for a while, and there's a proposal
Speaker 2: to add it to the JavaScript language itself, which, like
Speaker 2: we said, is kind of stuck in purgative.
Speaker 4: Yes, okay, let me explain the situation there. Okay, So
Speaker 4: the current so this pack.
Speaker 5: As it was originally proposed and done in typescript okay,
Speaker 5: all types types four and something okay, and before was
Speaker 5: was very hard to poly fil Okay. If you look
Speaker 5: at the JavaScript code that is being those syntax transpiles to,
Speaker 5: you can get very scared.
Speaker 4: Okay, lets let's go eight. It's like regenerator style things.
Speaker 4: I don't know if you ever looked at the cover
Speaker 4: of what our generator does, but is pretty ugly, okay,
Speaker 4: because there is a lot of global state. There is
Speaker 4: a lot of things happening. It's not nice.
Speaker 5: Then the standard changed in a way that it's essentially
Speaker 5: Java is essentially function wrappers okay, which can be attached
Speaker 5: to classes because classes are functions okay, or functions okay,
Speaker 5: which makes it way easier to to reason about this thing, okay.
Speaker 5: And also it's just a function, so it literally is
Speaker 5: easier to you know, implement some extent.
Speaker 2: The function that gets cold with the function as its
Speaker 2: argument and in context, and then it returns a function
Speaker 2: 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
Speaker 1: 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
Speaker 2: 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,
Speaker 5: and that is transpiled to some really two things that
Speaker 5: I would not have running on my servers.
Speaker 2: I'll say it again. It's really popular with people that
Speaker 2: come to note from Java, so I know a lot
Speaker 2: of back end developers that literally swear by it. It's
Speaker 2: a back end that you use as a back end
Speaker 2: for API. Course. Yes, it's it's not about necessa or
Speaker 2: anything like that exactly.
Speaker 4: But I am, I am.
Speaker 5: I have a side on all of this, so you
Speaker 5: can take all of what I said with a gain
Speaker 5: of salt. I have built to Fastify to solve this problem.
Speaker 5: Been using it for the last decade and very happy
Speaker 5: with it.
Speaker 2: Yeah, it's really opinionated anyway. Moving But in terms of performance,
Speaker 2: 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
Speaker 5: can use Express or Fastify underneath, and I suspect is
Speaker 5: slower and it adds a little bit over it on top.
Speaker 2: Yeah, it has to kind of because it's literally built
Speaker 2: on top of it.
Speaker 5: So yes, I hope is as little as possible. But look,
Speaker 5: you're asking so you might get an article on it.
Speaker 5: So I'm my co found is telling me to do it,
Speaker 5: 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
Speaker 2: the extent that it's boring, you know, like the best
Speaker 2: 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
Speaker 2: with so you talked about the surprising results that you got. Now,
Speaker 2: so obviously, if I'm running the bottom line is that
Speaker 2: if I'm running currently node on Amazon, and especially if
Speaker 2: I'm using it for a s SR, not necessarily, but
Speaker 2: especially if I'm using it for as SR, then I
Speaker 2: should be looking at what because bun won't save me
Speaker 2: pretty much. And okay, cool, anything else to add on
Speaker 2: 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
Speaker 1: have been recording for about an hour, which I'm totally
Speaker 1: fine sticking around for however long, but I need.
Speaker 5: To probably go at when these meeting ends that I
Speaker 5: have on my calendar.
Speaker 2: So that doesn't it just means that you want to
Speaker 2: 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
Speaker 5: the topic of flame graphs. Now, in all of these
Speaker 5: benchmarking to do a lot of optimizations and look at things, okay,
Speaker 5: and we created a brand new frame graph tool to
Speaker 5: do performance analysis.
Speaker 1: I don't know what a flame graph is, So imagine
Speaker 1: that you are.
Speaker 5: You want to do a performance optimization. Okay, you have
Speaker 5: you know your application is low, and you want to
Speaker 5: know where it's low.
Speaker 4: Okay. A flame graph shows.
Speaker 5: You the hottest points in your code base that consume
Speaker 5: the most time.
Speaker 1: Okay, I've seen them, I just didn't know that's what
Speaker 1: 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.
Speaker 5: The key point is you the flame graph abstract time.
Speaker 5: So it takes an internet of time and says, let
Speaker 5: me represent this the function calls that happen in this
Speaker 5: interval of time. Okay, because in that way, I know
Speaker 5: 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
Speaker 5: 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
Speaker 5: that I create with these kind of things. Okay, a
Speaker 5: new version of note require differently tools to get it done.
Speaker 5: PingER Cross is the last, but probably there will be
Speaker 5: another one in a few years.
Speaker 4: Okay.
Speaker 2: Now, somebody who's listening to us and here's a flame
Speaker 2: graft to measure NOTE performance might be thinking, Hey, why
Speaker 2: do I need this from a platformatic where I have
Speaker 2: it built into dev tools for like forever for why
Speaker 2: do I need at another one? What's wrong with the
Speaker 2: one that's built in death tools.
Speaker 5: The tools gives you a flame shart, not a flame draft.
Speaker 5: It's not as readable, it doesn't give you the full picture. Also,
Speaker 5: it's the way. The part of the problem is the
Speaker 5: collection of that data is very expensive, so by running
Speaker 5: it in the tools, you are essentially altering, like the
Speaker 5: 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
Speaker 2: I totally agree with you. I'm just bringing it up
Speaker 2: so you can rebut it perfect.
Speaker 4: Okay.
Speaker 5: So it's quantum mechanics at work. You observe it, you
Speaker 5: change it.
Speaker 4: Okay.
Speaker 5: The way the what we have done instead of relying
Speaker 5: on the inspector to to get that data, okay, we
Speaker 5: are using a C plus plus module from our good
Speaker 5: friends at Data Dog that they're using their agent to
Speaker 5: collect those data from C plus plus straight out of
Speaker 5: the eight in the fastest possible way. So it does
Speaker 5: not interfere much with the application itself to the point
Speaker 5: that you can use it in production to collect those
Speaker 5: flame graphs. Now, if you try to enable the inspector,
Speaker 5: you are looking at a fifty percent performance job.
Speaker 2: It's beyond that. First of all, let's start with the
Speaker 2: fact that you probably don't want to attach the development
Speaker 2: tool to your production environment. Yes, somebody might click pause,
Speaker 2: Oh yeah, you're not going to be running in production
Speaker 2: Node servant production with as inspect you know, yeah, yeah,
Speaker 2: and you're not and you're not going to believe that
Speaker 2: that port open. Well, you know, you can do it
Speaker 2: as such tunneling and whatnot. But anyway, and like Matteo said,
Speaker 2: the overhead of actually doing a flame chart is really high.
Speaker 2: And by the way, also for that same reason, it's
Speaker 2: time constrained. You can't run it forever. You can run
Speaker 2: it for a very limited amount of time. Now, I
Speaker 2: have in the past implemented certain scenarios in certain applications
Speaker 2: where we sent a signal or an event into a
Speaker 2: process to kind of trigger it. But it's you can again,
Speaker 2: you can only run these sort of things for a
Speaker 2: really limited amount of time.
Speaker 4: Exactly.
Speaker 5: You can also still run this kind of tool for
Speaker 5: a limited amount of time, So it's a you know,
Speaker 5: you can even the way you do it, you run
Speaker 5: it for essentially one minute to collect what's happening. And
Speaker 5: in our platform, we can even start collecting it when
Speaker 5: usage goes over a certain threshold, so that you know,
Speaker 5: you don't you're not wasting money. But it's actually very good,
Speaker 5: so you can actually.
Speaker 4: Even running in production get good data out. Data Doctor
Speaker 4: is running this in production all the time. It's fantastic.
Speaker 2: By the way, I have to say, it was really funny.
Speaker 2: So when I found out about this tool and I
Speaker 2: started using it, and I started experimenting with it, and
Speaker 2: I reported like six issues or something like that back
Speaker 2: to Mateo and the guys and the gang, and like
Speaker 2: within one day it fixed all of them. It was
Speaker 2: it was really amusing.
Speaker 5: Yeah, very fast. It's so there is that. Okay, tool
Speaker 5: was great. Last week. I think we shaped something new.
Speaker 5: We shipped a way to get the representation of the
Speaker 5: flamegraph as marked down, so you can essentially feed it
Speaker 5: to an l LM and it will just fix things.
Speaker 2: So it will basically understand where your bottlenecks are in
Speaker 2: terms of performance and focus on them automatic exactly. Like
Speaker 2: this function is slow, but it's not just slow. It's impacting.
Speaker 2: It's being called a lot, so it has a significant impact.
Speaker 2: Or that function is hardly used, there's no point in
Speaker 2: optimizing exactly.
Speaker 1: Yeah, but like you said, Matteo, it seems also that
Speaker 1: some of the fixes are pretty commonly understood and easy
Speaker 1: for the LLM to implement, and so I can also
Speaker 1: you know, it's like add add a database index or hey,
Speaker 1: if you can't if you do it this way instead
Speaker 1: of that way. This structure is more performant than that one.
Speaker 1: And you know it's it's it's little changes, but they're
Speaker 1: low risk, low risk, and the LAM is great at it.
Speaker 5: Okay, I called the low hanging fruits. Okay, so the
Speaker 5: 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
Speaker 5: bad architectural patterns happening. And the bad architectural patterns are
Speaker 5: 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
Speaker 5: for every rendering its schedules a timer that's never cleared,
Speaker 5: so it runs to completion. It's it's like five second,
Speaker 5: but that cause it's becomes a hot spot for the
Speaker 5: garbage collection.
Speaker 1: Right. I was going to say, it's a memory leak,
Speaker 1: but it's nice. It does get it.
Speaker 5: Eventually, yes, but it's enough that it gets by. It'll
Speaker 5: keep memory located for more and it's enough for that
Speaker 5: memory to be moved to old space. So it's actually
Speaker 5: creating a some problems for the wrong time that's actually
Speaker 5: not needed. That could avoid could be avoided. Okay, I
Speaker 5: sent a patch. Another one that I found recently is
Speaker 5: 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
Speaker 5: 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
Speaker 5: times per week something like that.
Speaker 2: GT.
Speaker 4: Yeah, GT, this is a bug. I passed the bag
Speaker 4: in the chat J I T I yeah.
Speaker 5: It makes any any function that export in a function
Speaker 5: between sixteen seventy times lower.
Speaker 2: What is chitty.
Speaker 5: It's a module to load the typescript straight from node,
Speaker 5: similar to tes what tes no does, but that differently
Speaker 5: typed syme of things is used by yes, lint, nxt, netro,
Speaker 5: post CSS.
Speaker 4: I don't know.
Speaker 5: Tailwind is very popular in front and I have I
Speaker 5: had no idea this even existed until it showed up
Speaker 5: 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
Speaker 4: it's one of the most misused technologies that you can
Speaker 4: get in that Like, if you're using a proxy, you
Speaker 4: should ask am I doing it wrong?
Speaker 2: And the answer would probably be yes, yes, not always,
Speaker 2: not one hundred percent of the time, but you should
Speaker 2: definitely be able to justify yourself.
Speaker 1: Yeah. So I'm going to kind of push us to
Speaker 1: wrap up this particular topic because we only have like
Speaker 1: eight minutes left.
Speaker 2: So I just have to say that before we conclude
Speaker 2: on this, that the ability to gather performance information throughout
Speaker 2: the lifetime of a process in production is invaluable. You know,
Speaker 2: we've had similar technologies in other programming languages, like the
Speaker 2: what's it called in Java? Java has the Java black
Speaker 2: box sort of thing, I forget the name. That they
Speaker 2: have the ability to collect performance information without usually without
Speaker 2: significantly impacting runtime performance, that you can do it in production.
Speaker 2: The ability to do the same thing or similar thing
Speaker 2: in for node is really invaluable. And I'm really grateful
Speaker 2: for Mattel and everybody Platformatic for releasing this game.
Speaker 5: Is there free tried out if you want, if you need,
Speaker 5: you know, talk a little bit about my company enough.
Speaker 5: But if you using this tag and you it's core
Speaker 5: 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,
Speaker 1: this is where we do shout outs about stuff we
Speaker 1: like and uh yeah, I know that you're kind of
Speaker 1: under a time crunch Matereo, do you want to go first?
Speaker 1: 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.
Speaker 2: We've been playing this amusing game in our family these
Speaker 2: past couple of weeks. It's called Hitster. It's this kind
Speaker 2: of a game where you've got a certain like deck
Speaker 2: of cards and each card has this QR code that
Speaker 2: you scan, and it goes with your phone and it
Speaker 2: goes to the and it actually starts playing that song.
Speaker 2: I think it uses Spotify, but I'm not. I don't
Speaker 2: remember off the top of my head. And the idea
Speaker 2: is that you play every you divide into teams. You
Speaker 2: play the song for about twenty seconds, and then the
Speaker 2: team that turn it currently is needs to guess the artist,
Speaker 2: the title of the song, the artist, and the year
Speaker 2: in which it came out. If you need to guess
Speaker 2: at least two to get a point, If you guess
Speaker 2: all three, you get two points. Something along these lines.
Speaker 2: And we've been playing this in our family, and it's
Speaker 2: songs from all eras. In the case of Israel, it's
Speaker 2: both Israeli music and you know international or American music
Speaker 2: or British music, and it's really a lot of fun.
Speaker 2: We enjoy it very very much. You know, you listen
Speaker 2: to music, what's you know and and try to guess
Speaker 2: the songs. It's it's a lot of fun. So that
Speaker 2: would be my first pick, and the second pick is
Speaker 2: again is actually Matteo. I want to mention that on
Speaker 2: 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
Speaker 2: minutes each, usually about a variety of topics related to
Speaker 2: know the Jass development obviously, and they're uniformly excellent, and
Speaker 2: I highly recommend following Matteo and watching the videos that
Speaker 2: come out. So that would be my second pick, And
Speaker 2: 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,
Speaker 3: which are the dad jokes of the week. An interesting
Speaker 3: video that popped up on YouTube last night by Jeffrey Ray.
Speaker 3: Jeffrey Ray, who is the owner creator of Larra Cass, which,
Speaker 3: if not Larabelle Community is a pretty well known training
Speaker 3: platform for Larabell and on many many other topics as well.
Speaker 3: And he titled it I'm Done, and it's just sort
Speaker 3: of a a it's about thirteen fourteen minutes where he's
Speaker 3: just talking about the impact that AI has had on
Speaker 3: Larrakass and they just had to layoff a bunch of people,
Speaker 3: similar to what happened with Tailwind and the you know,
Speaker 3: sort of the use of AI and coding and you know,
Speaker 3: the pros and cons and sort of almost having to
Speaker 3: use it or get left behind. He's a I gotta
Speaker 3: 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,
Speaker 3: but it's I think it addresses the reality of AI
Speaker 3: encoding and how it's impact impacting things both I think,
Speaker 3: I think both for good and bad.
Speaker 2: I think we should probably bring a bunch of open
Speaker 2: source creators, people like Matteo, like maybe uh, we've had
Speaker 2: a of the Joel we we've had on the show
Speaker 2: talking about the slint and t slint uh and and
Speaker 2: basically talk about the impact that AI is having on
Speaker 2: on open source developers. It's really cutting the branch that
Speaker 2: a lot of them are sitting on financially.
Speaker 3: On that upper Ever note, I'll get to the dad
Speaker 3: jokes of the week. So, first of all, pretty straightforward
Speaker 3: question here, what do you call a pony with a
Speaker 3: 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
Speaker 3: touring complete Uh, you know in computer science Enigma and yeah,
Speaker 3: he cracked the Enigma codes in World War Two, but
Speaker 3: nobody knows his sister Kay, who provided drink, snacks and
Speaker 3: sandwiches for him and his colleagues. I was in catering, Yeah,
Speaker 3: right right.
Speaker 1: It took me a minute. Yeah.
Speaker 3: And then finally, uh, why does Spider Man hate driving
Speaker 3: with his evil twin because he's a bad parallel parker? Oh?
Speaker 3: Thank you. Those are the dad jokes of the week.
Speaker 1: I usually don't laugh at the dad jokes, but Mateo's
Speaker 1: reaction was priceless.
Speaker 3: That's half the fun sometimes.
Speaker 1: Oh all right, I'm gonna jump in with some picks.
Speaker 1: The first one I always do a board game pick,
Speaker 1: and this one we got for Christmas. Man, has it
Speaker 1: been that long since I've been able to get on
Speaker 1: and record. Yes, thanks Steve. He made me feel better. Anyway.
Speaker 1: The game that one of the games we got was
Speaker 1: Everdell came out twenty eighteen. My wife and I played it,
Speaker 1: so it was just two players with us. It probably
Speaker 1: took us an hour, maybe a little longer to play.
Speaker 1: We were learning it as we went though. I think
Speaker 1: I played it with my sister and my wife another
Speaker 1: time and it took us about the same amount of
Speaker 1: 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
Speaker 1: of cool because it's got this tree that you kind
Speaker 1: of slide together. It's made out of cardboard, but it
Speaker 1: looks really cool when it's set up and it's sitting
Speaker 1: on the board. Reminds me a little bit of the
Speaker 1: Tower in Fate of the Fellowship, which is a pandemic
Speaker 1: like game based on Lord of the Rings. But anyway,
Speaker 1: so Everdell plays up to four players and you're trying
Speaker 1: to collect resources in order to fill missions, and you're
Speaker 1: building a little town of animals in you know, basically
Speaker 1: in front of you, and that gives you special ability.
Speaker 1: So it's a pretty standard kind of game. It's just
Speaker 1: you know, a couple of little nuances and stuff. Anyway,
Speaker 1: 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
Speaker 1: and reach for it on my own on a regular basis.
Speaker 1: But I did enjoy it. It's definitely a game worth,
Speaker 1: you know, having him playing, and the artwork on it
Speaker 1: is incredible. So I'm going to pick Everdell board game
Speaker 1: has a board game weight of two point eighty three,
Speaker 1: and that means that it's it's it's a fairly involved game,
Speaker 1: but if you've played a lot of the other resource
Speaker 1: gathering deck building kind of games, it's nothing outside of
Speaker 1: 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
Speaker 1: watching land Man and I've been enjoying that. That's on
Speaker 1: Paramount Plus, and so I'm going to pick that. And
Speaker 1: then I watched My wife and I started watching the show,
Speaker 1: and she's a little bit sensitive to people dropping f
Speaker 1: bombs during shows, and so if there's too much of that,
Speaker 1: she won't watch it. And so we watched like the
Speaker 1: first episode way back when of eleven twenty two sixty three,
Speaker 1: which is, uh, there's this history teacher. His friend's been
Speaker 1: going back in time to try and save JFK from
Speaker 1: being assassinated. And so anyway, he takes all of his
Speaker 1: friends research and you know, all the preparation that he's done,
Speaker 1: and he goes back to save JFK and right then
Speaker 1: come back to the future where it's supposed to be
Speaker 1: better because you know, Linda Johnson wouldn't have gotten us
Speaker 1: into the Vietnam War and a whole bunch of other
Speaker 1: things that other people did that you know, this particular
Speaker 1: guy didn't like wouldn't have happened. And anyway, so I'm
Speaker 1: not going to spoil how it changes the future, even
Speaker 1: though the show's like ten years old, just in case
Speaker 1: 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
Speaker 1: watch him go through and you know, encounter people from
Speaker 1: 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
Speaker 2: you enjoying Star Trek Starfleet Academy.
Speaker 1: I have not watched it at all. I've seen ads
Speaker 1: 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
Speaker 2: and the critics. You know, the story that they released
Speaker 2: the first episode for free on YouTube and a nerdratic
Speaker 2: in competition with him basically just put a video of
Speaker 2: doll of Spock sitting on a chair and he got
Speaker 2: 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
Speaker 1: Paramount Plus, but yeah, that's not That's not one that
Speaker 1: I've been watching. We liked Star Trek Discovery and Star
Speaker 1: Trek Piccard, but anyway, I haven't watched that one yet.
Speaker 1: So yeah, so Landman and eleven sixty three, which I
Speaker 1: think was originally on Prime and is now on Netflix. Anyway, Tayo,
Speaker 1: what are your picks?
Speaker 4: So the first one is.
Speaker 5: I've been taking a lot with Ai thinks, Okay, as
Speaker 5: everybody and I have having a lot of fun these
Speaker 5: last few days on a project called PI. It's a
Speaker 5: little open source codeing agent that is highly customizable. The
Speaker 5: heart of malt Bot now cloud bot whatever is what
Speaker 5: that thing uses internally to do work. Okay, and it's
Speaker 5: super fun to use and very fun to modify and
Speaker 5: 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
Speaker 5: a local model running very easily, and I add some success,
Speaker 5: some success, so I can run the full AI think
Speaker 5: on my machine. Not that I want to, but it's possible.
Speaker 5: So I can literally use those things on a plane
Speaker 5: if I want to, which is something that I really
Speaker 5: wanted to achieve.
Speaker 4: So I have done had fun with that. Okay, yeah,
Speaker 4: it's very easy. The other thing it's we're talking with
Speaker 4: the eye is tile scale. If you're not using tilescale,
Speaker 4: tailscale is you're missing out. Okay. You can interconnect all
Speaker 4: your devices, servers and so and so force in a
Speaker 4: single network. It's phenomenal. Okay, I'm a fan. So try
Speaker 4: that and combination with those two together, I can more
Speaker 4: or ize call things on the phone if I want to,
Speaker 4: and whenever I go, I can just have you know,
Speaker 4: checking on my agents doing things. And yeah, I'm becoming
Speaker 4: one of those people apparently.
Speaker 2: So the problem that I have right now, I know
Speaker 2: that a lot of people are running multiple agents at
Speaker 2: the same time. I'm having problems with that multitasking between
Speaker 2: different tasks myself, so it's difficult for me to schedule
Speaker 2: enough agents to do things all the time in the background.
Speaker 2: I maybe it's a fault of my own as a
Speaker 2: manager or something, but the end result is that I
Speaker 2: 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
Speaker 2: 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
Speaker 1: follow along with the things you're working on, where do
Speaker 1: they find it.
Speaker 5: They find me on Twitter at mate Hoolina, or they
Speaker 5: 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
Speaker 5: 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
Speaker 1: until next time. That's out. Mm hmm.