[00:00:00] Introduction
Matteo: Fastify is, uh, a web dash API framework for node. You typically use it to build your APIs. You can also enter templates on Android html. So files do web sockets. It has a good, thriving community. And I would refer to other servers. It's fast. Okay. It's as fast as node is. Essentially like our goal is, our unattainable goal is to be zero over it compared to node js. We are trying to be there at the top. We are actually very close. What you lose for the fast, for fast five features, it's not much. Okay. It takes a few different approaches compared to express, which is what everybody else is using.
Andrew: Hello, welcome the Dev Tools FM podcast. This is a podcast about developer tools and the people who make ' em. I'm Andrew, and this is my co-host. Justin.
Justin: hey everyone. Uh, we're really excited to have Matteo on.
[00:00:55] Matteo's Background and Contributions
Justin: Mateo is the founder and CTO of platformatic, uh, co-founder and CTO of platformatic. Uh, so, and I mean, Matteo, you do so many other things, it's as we're doing the, the bio for you, it is just like kind of crazy.
Uh, so you're, um, sort of the creator and primary maintainer of Fastify, which is sort of what I think of is like the modern express replacement. Um. You have worked on Pinot, which is a really cool logger. Uh, you've got a lot of other really interesting open source projects. Uh, you're on the technical steering committee for node, uh, the list goes on.
Uh, so we're incredibly excited to have you on. Uh, before we dive in and start talking about, uh, specific topics, would you like to tell our listeners anything else about yourself?
Matteo: a few things, uh, that you might everybody by the way, start to start with that. And, uh, first of all, let's start with saying, well, I'm also, uh, um, on the board of directors of the Open Js Foundation, they more, no, JS Fastify Webpac, yes. Electron Express. Um, 30 other project, not red, like, I dunno, 20 other projects or something like that.
It's so jQuery too. jQuery. You know, you don't, you don't imagine how much time we spend in board meetings talking about Jay. It's, it powers the web, it is the most popular framework of the web. So, uh, you might, you know, we can talk about J query. This is good to be a phenomenal talk. Uh, modern jQuery.
You know, I recommend you another, a new show about modern jQuery on, uh, in, in here. So, and our approach in this late maturity would is, is due. Okay. It says it's interesting. It's interesting just for, for people to know probably. Um, so apart from that, uh, what I'll say do I have a daughter, almost three years old daughter.
So, I dunno. I'm also a father. I dunno, I don't, um, I, and uh, yeah, that's more or less it. I have a YouTube channel and a Twitch channel now, so trying to, um, do a little bit more marketing side of things and developer marketing, um, conferences. You can watch me at conferences most of the time, few times per year.
So yeah, pretty much. Yeah.
Andrew: What, decisions are you making about jQuery? Like, I feel Ha, has any lines of code in jQuery changed in a while?
Matteo: It does releases like the, it does releases. Okay. Uh, recently the biggest one was changing the provider of the CDN, like the, all the internet is maintain is, is up because the j, the Open J Foundation maintains the uh, uh, jre, DCDN, which is gently offered by a provider, and we needed to switch providers. So, and, uh, this is actually very hard because it consumes, you know, petabytes of data.
So, um, it's fun.
[00:03:54] Ad
Andrew: we'd like to think Ray CAS for sponsoring our podcast Raycast is an app for Mac that's like spotlight, but with superpowers. Besides just quickly opening files, URLs, or apps. It provides clipboard history. We know management, a schedule overview and much, much more. And if you're interested in writing extensions for Ray cast, it has a really cool clean API. It's based on react. So, if you know how to write react, you'll fit right in.
You should also check out Ray cast pro with pro you can take advantage of Raycast AI to summarize text in any app and translate text on the fly. It doesn't just stop there. It can do so many different cool things throughout your computer.
One cool new extension they offer for this is AI commands. AI commands, let you encapsulate a prompt. Into a command that you can run directly through. Raycast it's kind of like scripting for AI, but. Without really writing any code. One cool thing. They also added to enable that is the use of dynamic snippets.
That's just a fancy word for variables that recast keeps track of that you can use in your prompts. So you can use things like the date. The selected text or a few other different things to make writing your AI commands more powerful.
It also gives access to their cloud sync feature that helps you keep your settings in sync across all of your devices. To learn more about Raycast you can head over to Ray cast.com or. Or you can go listen to episode 38, where we interviewed the CEO Thomas about the product. Why they started and where they're going with it.
Would you like to advertise with the dev tools, FM head over to dev tools.fm/subscribe.
Do you want to not listen to these ads? Become a subscriber on one of the various platforms where we offer a subscription. So that would be Patrion, apple, Spotify, you name it.
And with that, let's get back to the episode
[00:05:31] Managing All the Source
Justin: wild. Before we dig into, uh, some of these other questions we have, uh. I just, I'm, I'm so curious, how, how do you do all the things that you do and not go absolutely insane? I mean, alright, let's go down the list because I, I think just maintaining one like popular open source project can be really taxing and really time consuming. Uh, maintaining a bunch, being on a board or several boards, having a family,
which, you know, takes
time. Yeah. At a startup. Yeah. Let's not forget that little fact. Like how do you do it?
Matteo: okay. So first of all, I burned out badly from open source, uh, around the 20 13, 20 14 time, so I know what burnout is and I know what I need to avoid doing. To not get into that situation, in that position. Okay. So that's the, uh, that's probably the starting point for the, for this convo. Okay. Uh, um, if we want to have it, it's, that's the kind of the, I think that, yeah, that's the starting point.
So let's go through that. Uh, um, I'm going to take a little bit long form to get to the point. Okay. Um, back in, uh, two, those a, those years I was very active in, uh, the, um, I did my p PhD in the internet of things. Okay. So part of how you do a lot of things is not a lot of time is that you do a PhD and you build a lot of, uh, uh, uh, uh, a lot of you hard yourself a lot to, to work.
Okay. And so you, this is as formative as they say. Okay. Um, anyway, uh, so it's, um. I had done my, when am I doing my pt DI do a lot of research on that, and I started, ended up, um, creating, uh, MQT broker called Mosca and maintaining the primary, uh, MQTT driver for node JS, uh, M-Q-T-T-J-S. And with those two things I ended up, uh, being in, um, uh, uh, what happened was that a company took, uh, my broker paired it up with another opensource project and another opensource project.
Okay. So I have two brother, I have two brother in arms. Essentially, they wrapped all those three projects, put a nice b and a lot of developer marketing on top of it. Um, raised money and sold it to, uh, another and, and sold the company. So I said, raise a serious seed and then solve the company.
This person does it as a job. Okay. And, uh, it's, uh, uh, at some point it was file filling up a lot of box and issues and questions on my repos. And, uh, I asked him, look, can you know, can you just start paying me because I'm fixing all these bug for you? You have raised money. Whatever, man. I am. Look, I, I am in Italy and I'm just out of my PhD, whatever.
I would love to make a living here. Okay? You may, you are making money. So, you know, I'm not saying, I said no.
And, and I burned out badly. Uh, mostly because I took on those projects. I took the point of if there was a bug or an issue, I would fix it myself. Okay. And. Part of the reason why I can maintain so many modules and so many things, it's because I don't do that anymore. Like, I don't fix bugs for others. Okay?
This is my start. My starting point on any conversation is either you fix your bug or, or you pay me. There is no in-between, between those two things. Okay. You know, it's, I'm, I don't, to be honest, it's the only, the only way, the only part where I'm fixing bugs for others are, is for matic my startup. So I, if somebody reports a bug, I fix it, but I'm paid to do it.
Right? And, um, and very happy too, by the way. Um, and if, uh, it's a security vulnerability. So if it's a security vulnerability, I typically step in and do the work that's needed to ship the, the fix. Um. Because I think, I believe it's important. And that's, uh, kind of it in all the other cases I'm typically replying.
Hey, um, thank you for, uh, reporting this. Would you like to work on this issue? I am no shame in, in asking and doing all of that. And it's essentially, I, to be honest, I don't, it's the only sane way for a individual to do that. Um, and it also provide the best long-term maintenance strategy. Like, you need to consider that if you're building a, a, an open source project, you want, you have a large number of people, which is the, uh, you know, you can call them the, the workers, the people that do not contribute, that do not show up, that, you know, they just use it.
Okay? There are pure consumers, okay? Then there are people that report box. And then there are people that fix bugs, okay? Then there are collaborators that, you know, help with the triaging, reviewing the bug fixes and, and shipping releases, and evolving the, projecting new things, and so on and so forth. And, and then you have, you know, the extra called project leadership or, or anything.
And if you need to consider this as a pyramid, when you're building a, a community driven open source, okay? If you're doing a, a startup or some other stuff, you know, you, you have, if you have capital available, you can do things differently if you want to. Okay? So it's, uh, but if you're building a, a community-based open source, this is the way to go.
And because you can share you want. So ultimately you want to share the governance, okay? With others. And if you have a company in place, you don't, you, you, you're already sharing the governance with your, with the, the shareholders or whatever, right? Um, but if you are building a community-based open source.
Then you want it to be, um, you want a large base and you want, you want a lot of people, you know more. The more people, the more collaborators you have. The merrier, the more triages you have, the merrier, the more you know, everybody should come in please it. You want to help. So essentially, um, share the load with a lot of other people and that's when and where things work.
That's the TLDR?
Andrew: Yeah, I, I really resonate, uh, with what you said about like, people asking for things of you, like, I'm not nearly as prolific of a maintainer as you, uh, but like on my projects, when someone's complaining about something, the words I've typed more than anything are prs welcome. Like, if you have enough time to complain, you, you probably have enough time to go look in the code and fix it.
'cause it's, it's just off script. You can fix it.
Matteo: Yeah, pretty much. Yeah. Well, yeah. That, that's A-T-L-D-R. Um, I, uh, yeah, that's the, that's the gist. So I have no, um, there is also a kind that only presents and ask, and then they say, oh, I will not use your library. I'm doing whatever. I'm forking, blah, blah, blah. And I am, you know, okay, fine. Do it. Or, you know, it's, I'm not fixing it.
Like this is now a tactic that does not work.
Andrew: Yeah, it's, it's a common one you wanna go for. I even in my young career, I was like, oh, I'll threaten to leave, but it's like, please leave. Like, I, I didn't ask you to use my thing. You're just, you're just causing me more work. Feel free to go fork it and have your own work.
Matteo: Pretty much, yeah. Well, I, you know, there is, um, the, uh, people that take, take, take from the open source community without giving back. I, I tend to call them the, all the, uh, the vampires. Okay. And, uh, you don't want to be left to the vampires. I, you, you, you, there is a good place. There's only one thing to do with vampires, so, you know, so just get rid of them and you can call, you can call Buffy and you're, you're good.
Okay? So if you're old enough, you can laugh at this, but this joke, but whatever. Um, so it's basically that's the, that's the solution with Vampire.
Justin: I think, you know, this is a basic sort of empathy thing, but people just don't realize how much time and energy it takes, um, to maintain, you know, a project. And when we think about the work context, you know, if you're a software engineering and you're paid to do something. Um, you know, you're working on a team.
You have like a feature in mind. You have a bug fix in mind or whatever, and you sort of have this continuous thing that's on a roadmap or whatever, and there's like a plan and you got, you got support system and hopefully, you know, you get the resources you need to, to make progress. But in open source it's like you're doing this on the side, you're probably not getting paid for it.
Uh, this is one of many, many responsibilities. Uh, you know, this is something that you started ideally because you wanted to, that you're interested in the problem or whatever. And every time you come back to it, you have to build up all this extra context just to figure out like, okay, what was going on?
Why did I do this? You know, why is it the way that it is? And they want it some way different. And then, you know, then balancing the decisions is like. This person wants this. Do I want to add this? Does it even make sense? You know? Yeah. It's just like all that context, it's just like a lot of energy. It's a lot of energy, a lot of time, and people get overly privileged and
just like want.
Matteo: Well, yes, it's, it's, uh, look, it's so bad. Okay. It's, it's, uh, uh, and there's a highs and there are lows. Okay? So, Mm-Hmm, uh, I, my career will not be there if I, I, uh, I had and do all the open source that I've done, and I didn't get massive results from the committee. So on that, I am very grateful. Okay. Um, on the other end, it's also a lot of responsibilities in here.
So it's, uh, uh, as a, and you know, most of the time is no, don't, don't, it's a gatekeeper, like most of the time is acting as a gatekeeper and say no, and say no. Like the, the, the biggest answer is no. Um, and uh, from time to time even say, no, I don't have the man capacity now to review this code or review this change.
Like literally very soon somebody sending me a pr, sending a PR that literally revert a library that was working fine from using, uh, pure functions to use classes.
And I don't, the test will pass still, but I am so worried of landing that change of what could break. So, uh, yeah, essentially this is the, it's very hard on that, on that front.
Also, tools change all the time. So to some extent, the lower your tool base is, and the lower your tool chain footprint is, the better.
So, and this is, you know, you see a few, a few maintainers, a lot of, uh, quite a few actually don't, um, still publish their stuff, publish their modules at, uh, with, uh, in JavaScript, write all of them modules in JavaScript, or use very old school test framework or use as, as little, because all of, like having a big tech stack, uh, increases dramatically the cost of updates.
Okay. And having a small one, uh, it, it's actually super, it's, it's a breeze, okay? While in an app, we need all those things, and that's fine. And there are a lot of good trade offs in, in maintenance. Having less work is the better. So if, you know, if my test framework changes and the new version does not run my old, my old test, this is a massive problem.
Okay. Just to clarify the, the, the, the situation. Okay. Sorry to be, to, to diverge a little bit. But this is, uh, also the way my certain of my projects are structured.
[00:17:58] Matteo's Involvement with Node.js
Matteo: What are they doing? It's, it's done in a certain good way.
Andrew: So speaking of large communities with few contributors, you're also involved with node js a lot. Uh, what is your role at Node jss and like what, what features have you helped
Shepherd?
let me try to correct you. So how many people do you think are involved in developing? Uh, if I had to guess, active, like fully active, like, or just like occasionals, like monthly.
Matteo: How many people do you think have the commit bet on? Node js.
Justin: There's probably been a lot of commits.
a hundred's
Matteo: Yeah. Okay. Okay. Hundreds. Okay. It's 120, something like that.
and, uh, active, I think, um, 30. Between 30 and 50, I would say it's, uh, no, it's a lot of traffic. There's also a huge amount of work to do, so I'm not, you know, it's, it's a massive no. JSS is a project with that runs on different combinations of, um, operating system and CPUs architecture, something like 50 something different combinations, which it's a lot all things considered.
Like you can run Node on AI X, you can run Node on Power pc. You can run node on arm, but not just arm the max you can. That's one build you can run on the arm of your Raspberry PIs, which is a different build because you know it's different arm and uh, you, there is arm windows, you know that now there is arm windows.
So if you have a Windows binary, you can have the arm windows binary or the, um, traditional intel Windows binary. I think we also have, uh, the X eight six, uh, 32 bet and the 64 bet available in those platforms. Um, you know, all in all Mac Intels, you know, there is a lot of, uh, builds to do and lot of operating system that we support.
So on top of that, there are new features coming and back fixes and updates in the platform and JavaScript and so on and so forth. So there is a lot to a lot of work on, and to be honest, we need more work, we need more volunteers. It's node js needs. It's, as you probably said correctly, it's a, it is understaffed.
We have a, a queue of 1,400 issue right now with, uh, uh, 562 PRSs.
So I, um hmm. You know, a few of them are, uh, are pretty old. Okay. Like the oldest one of Open PR is 2018 and, um, but there is a lot here. Okay. There are a lot of, um, uh, a lot of open PRS that, you know, might be, we could probably close it. Okay.
Right now. But, uh, I have just, uh, there's a lot. That's what I'm trying to say. Okay. It's, it's a lot of work and it takes some time to land a change because of all those. Um, question marks.
Justin: What do you, uh, what do you find your capacity of contribution to be? I mean, is it mostly guidance?
Matteo: mostly guidance. Yeah. I, IT So I typically do three things. Okay. I, my main, so I look quite, a lot of my contributions are on the security front. Um, this, this is a time sink. Okay? But this is actually time sink. That is good. I do, uh, guidance code reviews for other people most of the time, and if I have a bug, I implement the bugs or I implement new features.
Okay. Like, I, uh, I think maybe, um, in around 2018 or something like that, I more or less draw some kind of a plan to make fetch happen in Node and we just add. We'll actually be able to make not, uh, fetch stable now. So I'm very, you know, it's, uh,
it's a
milestone. Okay.
Justin: It is a huge milestone. Yeah, that work is very much appreciated.
Matteo: well, you know, well, to be honest, you should probably not use the fetch on node js to begin with, but if you want, if you really want to, it's there.
Okay. People apparently really want it badly, so it's now there. Okay. I am, there are better, there are way better alternatives than fetch, but people apparently loves that thing. So, um, we obliged and implemented it according as, as, as close to the spec as possible, which is, um, you know, the, uh, uh, which I didn't, a lot of people didn't like.
So this is the fun part. If, oh, I want fetch, but this is a spec. Yeah. But it doesn't work. Like, not fetch. Yeah, not fetch doesn't follow the spec. Oh. But I thought not fetch was the spec back. Ah-Huh? Okay.
Justin: Yeah,
Matteo: So, you know, it's, these conversations are fun. Okay. So it's, uh, yeah, but I, I, I personally knew, but if we wanted to ship fetch, we'll ship the true thing, not, not fetch, which is a great module by the way. It's fantastic. It's probably a better API than fetch. So. Yeah. No, this is, you know, this is super, super,
fun stuff. So, um,
[00:23:12] Discussion on ESM and CJS in Node.js
Andrew: so another fun topic in node js land is, uh, CJS and ESM. It's been a long road, uh, lots of arguments about it online. Uh, what's your take on the current situation and how we might get out of it?
Matteo: Okay. I am going to say something very probably not controversial, but for a person that used node js. Okay. Only on the server or on, uh, or for scripting.
Okay. For build tools
it's a complete nuisance. Okay. Ance, I dunno, what's the right way? It's literally something that is only causing problems and only a source of frustration. Okay? You, the, all those people don't care. Uh, they, uh, they want stable tools. End users want stable tools, stable libraries. All of this is just useless work for the sake of work.
Okay? This is the starting point of where does it matter where ESM start matter, the moment where you want to have libraries that are isomorphic and work both on the server and the, and the frontend, or both on the server and with bundlers. This is actually very important. So it's a important use case for now.
So this is where the ESM contention comes from. Also it comes from the fact that a lot of, uh, full stack engineers want to use ESM both inside their bundlers and inside, uh, in node js itself, and want to use the same library in the same way. All of that is well much understood. Okay. So, um, the part of the biggest problem in ESM was that, and when it was standardized, it was standardized without our reference implementation.
And it's, it did not deliver most of what the intents of that spec was, but now we are stuck with it. Okay. So, um, essentially it's, you know, in theory, oh, uh, the proponents of the assemble as well. You don't need bundling anymore. Okay. I, you know, it's, have fun. Okay. Oh, but you know, and then, and then there is, oh, but you can just run it straight on your browser, but you're not running GSX to transform your react components.
So what, you know, at that point in time, you could be rating. Uh, uh, Achman script and, uh, not ECMAScript, but Achman script. And you, whatever you write would be identical. Okay? You could be writing TypeScript and it doesn't matter, or TSX, uh, and it doesn't matter at all, uh, because you're transpiring anyways.
So what the, what's the problem here? Okay. Just to, to start to frame the problem. It's, it's a little bit, that's part of the situation, however, that is the standard of JavaScript. Okay? So at this point, that shape of saying, well, you don't really need this because you don't, I'm sorry. Nobody will change my mind on you don't need it.
You don't need it. Okay. But on the other end, the trend is pretty clear. Node JS needs to support ESM as a first class citizen, and it should become the default way of which people write node js in the future. So it's, um, it's also a big ask from the community maintainers and everybody, and it's something that the project is going, uh, full steam on.
There are a few things that are happening on that front. So first of all, the, um, loaders are almost ready, are very stable now, the one that we have on 20, once they, they, it's stable, probably is the way at the moment where you really want to start writing backend applications with ESN. Um, and I'm saying that, I'm not saying that lightly.
That is actually very critical. Okay? Loaders are, is the only way in which, um, an application can be ob become observable, okay? The, all those, um, APMs and observability toolkit relies on a lot, relies on monkey patching. A lot relies on injecting probes somewhere. And in order to do so, they need to attach to the load process.
Now, load the fact that the road were not stable means that you, that will not be reliable. Now, would you drive a car without a seatbelt on or, you know. Without the, you know, the, the warnings without the lights. We, you, you need, you need to know what you're doing. Okay. So, uh, it's so much better to drive a car that has the automatic braking system versus a car that does not have that.
Okay. So please, you know, it's, um, people want those tools, okay? Backend engineers, backend system want those tools. So that's critical. That's the first critical thing. So once that's getting stable, it opens up, oh, now ESM is probably a good citizen and you can, you can not be on the forefront. You can be, this mass is mass adoption time.
Okay. Uh, on the other front, we are on no jss, we are exploring a few things. Okay. We are exploring the, uh, uh, I ways in which we can, um, simplify a few things. So, um, we have introduced no 21. We have introduced a new flag. That you can test what an ESM word would be. So it flips the default, and now you en enjoy, enjoy the word.
Okay. Essentially provide us the feedback of how these word look like for you. Okay? And how, how are you getting on in the, in the e smm free, in AE smm first word. Okay. This is, uh, a question for people, you know, try it out. Let us know how, what you think about that, that work. Um, the second one, which is even more interesting is, um, we are currently exploring a few ways in which we could support both, um, uh, both syntaxes on the same extension.
Like the, the part of the problem is that TC 39 in the, in their massive, uh, source of wisdom, decided to write a language specification that could not be, um. Uh, that overlapped. So, and not have a, um, a you strict or, or, or, or a way to differentiate them very quickly. So, in order, the only way in which you can differentiate between the two is by read, by doing a full par and executing the thing.
But there is, this is, was a massive mistake from my point of view. Okay. You, you, you want to be able to, to do it with one pass. But there are ways in which we could do that now that we couldn't in the, at the beginning, um, do a very quick static analysis, pass on the file and cover the majority of cases.
And, uh, that could actually be enough. Like, for example, if you're using import at the beginning of a file, you're probably writing an ESM module. Okay. If you are calling module dot export equals something, it's probably ACJS. It's very likely to be ACJS margin. Okay. I, it's, it, it, it's. You know, it's technically possible to still cheat the system a little bit, but it's, uh, you know, a lot can be done in on that front.
And, um, people are currently exploring ways in which we can implement those things in a good way, in, in a way that does still performance. But it solves, you know, it removes the ambiguity in, in in your code. And
that would be great.
Andrew: Yeah. Uh, I was reading through some of the, the issues and pull requests around like the automatic mode is what I think you're talking about. And if, if that lands, like, I think that just kind of like solves all the issues. It's, uh, it was in, it's inspiring to see like, BUN came out and like just was like, oh, we're gonna do this.
And it kind of like made, don't think so?
Matteo: Yeah. That, that's, so it is not, it is not the problem of bun. So, okay. The problem of bun is bun do, did what a few people said that no should have done. Which, um, take the propo, the, the spec, wrap it in a nice piece, dip it a, take the spec, wrap it in a nice ball of paper and throw it in the bin. And that was bun is done.
And look, I'm, I'm very much, you know, it's, uh, basically said, no, I don't give, give a damn about the, the spec. I just do what developer wants and that's it. So that's, that's what Bond did. Okay. You know, it's, it's a respectful opinion. Okay. And not a, an approach that node js, they not the, the team on node js will be willing to do.
Okay. Um, also people involved in the spec and staff said, no, please don't do this. Okay. You know, it's, you don't, you. If the approach of ESM module is to be compatible with the web, you don't want to be an hybrid that are, that is a server hybrid. Okay. Sorry. Don't do this. Okay. This is. Um, that it's, it's against the goal.
Okay. Again, I'm, I'm, I just want to clarify that it's against the goal of having the ESM in the first place. So if you are creating an hybrid, then you probably, it's not a good thing for the ecosystem. So I'm really, that's one of the worst thing that BUN shipped, by the way, from my point of view. Um, because it's, it has some bugs also, and it's, uh, basically the way ESM works in sem, you need to do a big de linking step, which you connect all the information about all your modules, and then you run all the tree essentially, and you resolve the tree.
You link the tree completely at the beginning, and then you run the tree. And cj, common Js instead works, oh, I'm executing this file and then I'm using the next one. So the two models are fundamentally incompatible with each other. They cannot be mixed. And if you start mixing them, you are causing, you know.
Then you have a certain edge cases on loops of modules that don't work anymore, and quite a few modules out there do that. So, um, yeah. So this is my take. No, the reason it happened, it was, um, the reason why that, that, that discussion went through, uh, was, uh, it's part of the road to ESM and the discussion, the group that have been pushing and developing ESM for the past few years.
Um, I want to cite Joffrey Boots and, and a few others, but Joffrey and others, they're great. Okay. And, um, they've been championing ESM and it came from them like at some point we want to, uh, we might want to make the switch. Okay. And then while we were explored, and this is why the new flag came in. And while we were exploring that flag and that switch, okay.
Uh, it, um, we have, we found a lot of problems with it, okay. To be honest. And that spurred well, this does not seem viable, like it does not look to be viable. So if, what do we need to do to reinvent, uh, a world where we can do both parts in both things, okay. And turns out that there were progress in other areas, okay?
That unblocked this path. Okay? So this is, it might look like it's ban related, but to be honest, it's not ban related. This specific thing is not ban related. Okay? So this is, um, essentially the results of lot of years of work from quite a small team. So I could, you know, share support to them. And I'm not taking any merit apart from finding out all the problems in that flag.
So basically my take my, my, my take here, that red flag is there's a lot of problems with an ESM word. So, um, a lot of tools are not compatible with it. That's the, that, that's 2 cents. So probably don't want to do that. Uh, but we'll see. Okay. So hopefully we can get one of the two version that does, uh, automatic decisions on with, without looking there at the, uh, at the code, at the code without running the code.
And they can automatically pick, we can do them if we can pick one. That's amazing. And then there are two competing prs open. So I think one of them will probably land. So I think, I don't see why not. Okay. So the biggest obstacle I think is, was kind of resolved. And I think, uh, uh, once that ship, well this.
No blockers minus finding an implementation that's fast enough. So this is the question. Okay. So the true blocker would be if you probably are doing that, you will be probably seeing some lag and performance lowdown startup because of, you know that. But at this point in time, if we can guarantee that that happens only when you are eating the ambiguity path.
Okay. And you don't put your type module or your type common JS thing in, in your, in your, your packages. I might be, but I might be good into, into, uh, into
doing that.
Justin: I wanna shift gears a little bit.
[00:36:18] Introduction to Fastify
Justin: Uh, I would really like to talk about Matic, but before we do that, it's probably good to talk a little bit about Fastify. Um, given that that's an integral part of your, your, your company. So, uh, would you like to just explain briefly, sort of like what Fify is and sort of why you created it?
Matteo: Uh, Fastify is, uh, a web dash API framework for node. You typically use it to build your APIs. You can also enter templates on Android html. So files do web sockets. Do, you know, do a lot of very interesting things. Support both HGDP and HDP two compare against some, uh, other frameworks, support both. Uh, it's, um, it's maintained by, I think, 17 to 18 people now, something like that.
So it has a good, thriving community. Um, it's at version four, and I would refer to other servers. It's fast. Okay. It's as fast as node is. Essentially like our goal is, our unattainable goal is to be zero over it compared to node js. It's not technically possible because it had some work on top. But yeah, we are doing that.
Okay. We are trying to be there at the top. We are actually very close. Okay. So the, the the what you lose for the fast, for fast five features, it's not much. Okay. It takes a few different approaches compared to express, which is what everybody else is using. Um, uh, first of all, well, it's maintained. Sorry, it's, I'm, I said it. Okay. It's, uh, it's, it's, uh, it has ship releases, uh, ship releases regularly. Okay. It fixes bug regularly. It accept PRS regularly. It's, uh, um, it's, it's a thriving project. Okay. It's not in, in, uh, it's not in this limbo that expresses and, uh, especially super popular. It's a great project. It's, uh, um, but it does not have a thriving community of maintainers behind it.
So I am, uh, which Fastify I ask. So this is the first point. Um, it also come with the fact, oh, if you have a bug, you come and fix it. So you know, it's, um, might be interesting for you. And, uh, um, it does, it has a few other things. It has a different approach to routing, which makes it, uh, way faster. Especially if you have a large project.
It's, uh, it's significantly better because it use, uh, a little bit of data structures and algorithm to, to do fast routing, thinking that, oh, look, routes are actually a tree. Oh, okay. Instead of like, express does a list of, um, regular, uh, uh, expressions looped. Okay. So that's what our routing in express does, is that looping over regular expressions.
So if you are the one that matches is the last one, good luck. Which, you know, it's the most naive thing to do, but it's, it's, it's far from good. Um. Uh, uh, then it does not monkey patches core. Okay. So I am pretty much, um, not core, which is probably something pretty bad. And it's, uh, it, it means that, um, it can be faster, but also it's, uh, um, it allows core to evolve.
Okay. And it'll, you can just, you just using public APIs is significantly better in this front. Um, uh, it has, it has a logger embedded. It's, uh, we talk a little bit about pinot. It's, uh, if you're doing logging in OJS, you're not losing pinot, you're probably leaving money on the table in the front of server costs.
So you might want really want to use Pinot. It's really flexible. It can be adapted to your logging needs. You need to know your logging needs to adapt it, of course. Okay. So it's, uh, um, always, I have a good video on, on YouTube that. Talks a little bit about logging, but essentially logging, it's a side effect of your routes.
Okay? If you're reading a server, which is the worst thing you want to have, you know, they, they, in school, they tell you functions should not have a side effect. Okay? They don't, don't, don't, they try to grill this to everybody. Function logging is by, by, what it is, is the side effect of you executing a function.
So it's, uh, and one that is unbounded, okay? Nobody wants to slow down their application. If the disc cannot keep up in logging the disc you're logging to cannot keep up with amount of logs. But this is a problem that people at scale have been seeing. So penal facilities to deal with those things. Okay?
And, uh, um,
and they're, it's amazing because it's used by, um, quite a lot of companies out there that have massive logging needs and tools that all of you're using every day. Essentially are, um, right now, you know, right now or this evening, you're probably using any, some of those tools that are logging with pinot at massive scale.
So it's, uh, it's, it's a very good logging library, so it's built in. Okay. And those two things, this is actually very important and we, it also have a plugin system because you want to have an ecosystem, but middleware are not good because of the overhead cost. So, and so we have plugins that are, uh, uh, more complex API surface, but allows, uh, the same level of extensibility without monkey patching.
So it's, it's great. So, um, with, uh, so yeah, essentially that's, you know, a little bit of overview. Of Fastify from all intended purposes. It looks a lot like express in term of APIs. It's been heavily inspired by it, to be honest. So I'm not, uh, I, I'm not going to say anything different here, but it's a different beast underneath.
It's uh, um, faster support, a sinker weight out of the box. You can do a lot of nice things with it.
Justin: Yeah. That's awesome. Um, so what kind of things can you do with ?
Matteo: So something very interesting is, um, Fastify, this, one of the technical principle is if it can, if something could be a plugin, it should. So we have added hooks everywhere to let people do everything, all sort of possible things. Um, let me make a few examples. So one of the things that's very hard. Is, um, shut, starting up and shutting down a, a program.
Now why? It's important because a lot of people tended to use, uh, implement their server and using globals and, uh, having your, oh, the app is a global, the logger is a global, the database connection is a global, okay. And then when they started to write tests, everything fall apart because, oh, how do I accept the global? really, are we doing singletons again? Okay. Um, didn't we learn anything from the languages that came before? So, uh, singletons are just one of the source of all evil. You don't want to have any live data or any live objects attached to those. So, um, you so avoid them. Like, how so, because of that, because the fact that we have, uh, so Fastify, I have a startup and shut down phase with the startup and the plugin system is, is managed by this library called vo.
And then we have a hook to shut everything down. What does it mean? Well, it means that whenever you start something up, then we can, you can unwind it. So if you start, you can say that you start a database connection where your server start and you shut it down when the server closes. What does this mean?
Well, it means that, you know, you can use Fastify to implement some sort of, uh, auto loading or regular loading system somewhat easily, or it's possible at least because you, you know, you don't need to swap modules or do any credit stuff. You just say, oh, I can just start the server. Stop the server, restart.
It's done. Okay. It's not a lot of work. Okay. Well it is a lot, it is a lot of behind the scene to set it up correctly, but it's not impossible. Um, the, um, some of the stuff, you know, that we added is web sockets. Okay. So with web sockets you can, the web socket plugin, um, a I. Uh, uh, piggyback on the, the router of Fastify to implement routes for web socket.
Do you know that web socket are routes? Okay. If you knew you, there's web Socket of routes, so you can have, uh, uh, multiple web socket connection with different handlers and sify support that too. So it's great.
So these are a few examples. Then we go from there to, um, uh, um, file system based routing. It's possible with a plugin, uh, to CSRF protection, you know, uh, if you, if you need that, uh, you prob and you, you probably need CSF protection even though you think you don't, but you probably need it, you know, just saying, um, and that kind of stuff.
Okay. So down to, you know, implementing event loop protection, I. Which is a phenomenal thing that you, everybody should be doing and should be the default in all your apps, but most people don't even know that that exists or that's a problem. So I received on a talk at as in Europe to talk about this, probably post a video sooner rather
than later
on social.
Andrew: So Fastify seems like it's a very like. Uh, like unopinionated, you can make it do whatever you want.
[00:46:02] Introduction to Platformatic
Andrew: Uh, but your service that you built on top of it, platfomatic, uh, is what I've heard. You describe it as very opinionated. So what is platfomatic and what are those opinions that it
brings
along?
Matteo: Okay. So, um, you can build a lot of things with ified. Okay. It, it's similar to express. It comes with more opinion than express, but not too many. So, for example, it, it builds a, it bundles in a logger. Okay. You know, that's, that's a major one. Okay. It bundles in a logger. It's, this is a logger. Okay. Logging.
Everybody does logging. It's a first class concern of a framework. So yeah, this is the logger. Okay. Um, and it does plugins, it does hooks, but it's very unopinionated in the way you structure your projects. Okay? This is the first problem. And, but it's also because we wanted to have a very large contributor base.
Okay? So we want to be able to attract people that are, that care for the most disparate users usage of Fastify. So, yay. Okay. Um, please come. So that's Fastify. Okay. Uh, however, there is quite a lot of other problems that Fastify does not have a strong opinion on. How do you manage config in your application? Okay, this is bad.
Okay. Most people do configs so much bad. So bad that, uh, they, their application becomes unmaintainable. As a result of their confi choices. I dunno why, like I am very, uh, keen on, on, uh, on knowing. Okay. Uh, uh, but yeah, again, it, we took that choice, that thing as a good starting point for something. Then we have, uh, it has embedded the ability, it embeds quite a lot of the Fify ecosystem.
So Fify, there's the main Fify project and maybe 50 plus, uh, public, uh, modules, public plugins that we maintain. And, uh, uh, uh, matic builds on top of those public modules plus something in the ecosystem too. So it throws all, it collates all of them together. So you don't need to think of, oh, I need the event loop protection, uh, plugin.
Oh, I don't need, uh, the open API plugin. I don't need the GraphQL plugin. I don't need the, uh, the route level, the file system based routing, uh, to set, set up. Okay. I don't know. I don't need to, I don't need to think on how I structure my unit test, how I structure my folders. Okay. How I configure everything up.
Okay. platformatic does all of these out of the box. Okay. It does just, it comes with, it comes with batteries included. Okay. This is what we call platformatic service. Okay? Then on top of it, we have a, a tool called platformatic db. Matic DB is, uh, it used matic service, but on top of that, it also add an automatic, uh, uh, SQL to REST and SQL to GraphQL, uh, uh, crowd system so that you can just run your migration, point it to a database.
It explores the database, runs the queries. And then it creates the routes and resources and GraphQL for you automatically, which is fantastic because it can shed a lot of time in, in, in that. Um, we also have, uh, an automatic client for calling microservices. So these are typical usage of fast fire and building microservices.
But then if you build microservices, you have one server that calls Andrew's Microservice that calls Justin Microservice, and each one of us needs to write a client. Okay, mine's Justin because he's lucky and, uh, he does not call anybody. And, but I need to write a client and Andrew needs to call a client, write a client, which, what does this mean in practice?
It means that a lot of times it's being burned in writing those clients. And, uh, and in fact what we have done is we have an embedded client system. So you can just say, oh, these are URL and you, we can generate some types for you, but or also more importantly, you can get. uh, a client already built in, in the system that also support all the Open Telemetry editor out of the box.
So another thing that we do in, in Platformatic there is open telemetry support built in and, which is great. Okay. Um, uh, we have a composer system, uh, that is built on top that allows you to compose multiple services into one. Uh, using rest now open API and rest and in the future GraphQL. Uh, and uh, we also invented away, and this is phenomenal, but another lot of people is, is bothering us and it's to run multiple fast five servers on site inside the same process, and have them have them autoload and live load separately, and having them composed as a single, as a single endpoint.
It's actually phenomenal to see because you can have 3, 4, 5, 10 microservices running in the same process. Greatly simplifying, building that, the modular monolith thing, uh, greatly simplifying the way things are, uh, um, deployed and set up, especially for, for for small teams. So it's, um, yeah, this is, I think it's amazing from my point of view.
Okay. I have not, uh, seen anything. I, we have been dog footing it for the development of our, uh, uh, closed source tools. So it's, uh, which is great. Okay. And it's fantastic. Like the developer Boost is fantastic. Okay. Like it's, um, we have this, um, uh, we, we can implement things in no time almost now with, with this tool, because everything is already, we already figured it out.
So it comes, it comes with batteries included. So a lot less to think about, you
know, than
it's, it's already there, so we could use for better
docks, but this is, uh,
you know, we are working on
it.
Justin: that that reminds me of, uh, like Module Federation. There's some exploration of like being able to break down larger frontend apps into different modules that all get like spliced together into, you know, one frontend app and this, this, uh, modular approach to sort of, you're building microservices, you're thinking about it microservices, and you're authoring it, but you're deploying it like a monolith, which is kind of a, a a cool approach.
Matteo: Yeah, it's pretty nice. it's
pretty
interesting.
[00:52:28] Monetization Model of Platformatic
Justin: So what is the, what is the sort of monetization model of platform Inc. Uh, you, you're based around a lot of open source tooling. You have like some configuration and some good defaults sort of out of the box. So how do you Yeah. How do you monetize the product?
Matteo: Oh, okay. So the open source part stays open source. Okay. It's, we are not planning to make any changes or even can make any changes there. Like they don't want to talk about too much about legal, uh, open source stuff, but, you know, things we put in place to avoid relicensing, better licensing issues. So the open source pass, the open source, they're Apache show, so we'll stay open source.
Um, the, uh, uh, what, how are we monetizing it in a few ways? So, first of all, we have, uh, uh, we have a closed source. So we have, we have developed platformatic cloud that you can use to deploy any Fastify platformatic application or even express application on to, uh, uh, to the web. Okay? It has, uh, uh, it has tires and so on and so forth.
So that, that's one of the ways. Then the other way we have, um, we sell, uh, uh, support contracts for, uh, platformatic. So, which is, uh, you know, it's traditional open source business model to some extent. Um, we have also one component that's part of our cloud, though, our cloud. You can also take our cloud and run it on-prem.
So we have, uh, enterprise version that can run fully run on-prem. I dunno how many of you have worked on, on-prem software and how hard it is to find good automation there? Um, we can, you can take that and, you know, um, uh, run it on-prem and it's very nice, uh, because you can get a lot of things for free.
Well, not for free, it's a big product, but you, you get it, uh, you get at a fraction of the cost that will take to develop it yourself. Okay. This is the, the gist. Um, the, uh, last, not but not least, we created a new algorithm to be able to automatically detect the risk that a poor request is going to break your, um, production system.
And, uh, we have even published, uh, a white paper on it, on on IV, a few, uh, a month, a month ago or something. So we've written this algorithm. I have a PhD for. And it's, it's, we have written this algorithm with a lot of simulations and science and, and, you know, analysis around it. And it's, uh, uh, we give you a risk analysis and a number.
Okay. Which typically is, well, we think this is going to break your production by, in the 20% of the cases, it's probably too high, or you probably want to cut to, to, to verify it by hand. Okay. Oh, no, this is not going to break production. Okay. Yeah. And maybe I can ship it Okay. With, uh, on, in a relaxed, in a more relaxed way.
Okay. But the one that breaks, you know, 20% of the cases maybe, probably do it better, man. Okay. So, you know, probably want to, you know, verify it all. The nice part is that system works with live data from open telemetry. So, and it's not, so, it does not work on a closed world model, but it works from live production data.
So it can even know, identify, and know that a service is using this API that you do not know about, which is the typical case of
production breakages
in
microservice system.
Justin: Yeah, that's, that's really awesome. I saw that in your, uh, in your 1.0. Announcement video. Uh, and, and I think that's a, that's an incredible value add, uh, because this is, you know, this is something we all face. So there's a few things that you talked to, you talked about that are like really cool. I mean, I think we do end up making interfaces between services a lot, like spending a lot of time writing on those and then also making a breaking change without realizing it's a breaking change and bringing something down accidentally.
Uh, that's unfortunately common.
Matteo: It's, look, it's, it's that the typical is not even like typically you know that somebody is using your API. So you send a message to them. And say, look, I'm going to deploy this to production. Please change your, your client or something. Okay. So you coordinate with them, you do the release with the two things at the same time, and then somebody else is using the same API and don't have a clue.
So that's the, the, the most nightmare-ish scenario that you can, and that is typically building. And now you have your CEO at your door of your house with pitch with a pitchfork to, to try to, you know, I don't know. This
is
the, situation. It's pretty bad.
Justin: Yeah. Revenue impacting is is never good.
Matteo: Revenue impacting bugs. Yes. Because typically that's typically the case for the small, tiny service that keeps everything alive
okay.
[00:57:28] Future of JavaScript Runtimes
Andrew: So, uh, now that we're wrapping up here, we like to ask like a, a future facing question, uh, looking out into the future. Uh, so for you, I think a good question to ask is what do you think the future of JavaScript runtimes is? I feel like now we're in like, kind of this, like, there's a lot, a lot of activity going on.
There's bun, there's Dino, uh, nodes doing stuff. So what do you think the future of it all is?
Matteo: Okay. We have nice w Matic, so if, if we have a nice bottles, can, can I, can I put it there? Let me see if I can, yeah, it did. Platform. We have Nice wa so I'm sorry, I'm just, I'm joking. I'm, I'm, I'm drinking some water, so I that
that's a tough question.
Andrew: Stalling. I see.
Matteo: so the solution, so the future of runtime. Okay. So. My main, the main concern is and should be the openness of the platform. Okay. It's, I learned HTML and CSS and JavaScript by looking at the source code of pages. Um, you know, that is critical. Okay. Keeping the platform applicable and keep the platform very easy to get started and, and so on and so forth with, and you, we need,
I'm very, I'm somewhat like scared. What a future of. Uh, you know, if you, if you heard about the original Dean announcement where they did a lot of jokes on, uh, we are, um, not his dad type of thing. Okay. Luckily they were not right. But, you know, there, there was a lot of jokes running, not too much from them, but from the, the community.
And right now, even when Eno, Dino, a Bond came out, it, they, it, it's a drop-in replacement for node. And there was a recent meme that went around from somebody says, well, this, it's a drop-in replacement as much as a chair is a replacement for a sofa. So it, it's, it's a copy in replacement, right? You can sit on it.
Um, not the same thing. Okay. So, um, it's, uh, uh, the problem with those is, um, ultimately. Uh, they are, um, company products. Okay. And
I, I, I think it's, it's totally okay for, um, a meta level, meta frameworks, frameworks, high level components to be, um, product based products. Okay. Mostly because they require, um, they are user facing and you, they are easy to monetize. Okay? Um, languages, run, times fund, um, um, fundamental things usually tend to be very hard to extract, harder to extract value from because they're not user facing.
Okay? And, uh, um, because of that. There is a risk of those things going, um, private or we not being open source anymore. Okay. Um, so if, this is probably the, a word where, uh, uh, node, the stop existing is a word of, uh, um, commercial software. Okay. It's, um, it's not a word of, uh, uh, open governance and collaboration.
Okay. And, uh, on the other end, Brightside, um, comp all the frameworks have pro, have given phenomenal stimuli on node to improve and ship faster, and, uh, show pain points. And be able to explore new directions, which Node cannot off, cannot afford to explore. Okay. And especially on certain performance trade off, that Bun is doing okay to, you know, it's, it's actually, you know, some of those are really phenomenal.
So it came out with install, uh, being super fast and turns out that it's super fast because you're doing a lot less. Okay. You know, it's, which, you know, oh look, is this available, uh, viable, um, trade off. Okay. If you are willing to not have the latest version of your dependencies, uh, you might, uh, uh, get away with what you have on disk and therefore you, we can not call the internet before saving a lot of time.
Easter time. Wow. Okay. Sorry to leave. Um, uh. And this is, this is really fundamental. It's a good jar. It is a really good performance engineer. Okay? And he, he did a good work here identifying those things. And he shaped something that is incredibly fast with different trade-offs. Now is, are those trade off something that the community likes?
If they are, then, you know, those things can be spread, maybe as just options, okay. That you can turn on and turn off if you want them in other tools. Okay? Now, there was some, some benchmarks showed that showed, oh, this is like 20 times faster, 30 times faster, something like that. Which in reality it's not because it's doing two different things.
And if you are removing, putting them the pm PM as some flags that more or less do the same thing. And if you s squeeze them, it's still a few, couple of times faster. But one may be completes in 200 milliseconds and the other one 800 milliseconds, which it's. You know, a lot less appealing of than switching from a tool that takes from 22nd to, to 200 millisecond.
Okay. Like something like that. Okay. Which is, um, uh, you know, there was a hundred times faster. Something like that. Yeah. Because it's doing nothing. Okay. So you, you cannot, like the numbers was telling that there was some major comp major difference there. Okay. And the major difference is in, is in the caching.
Like again, and it's a great experimentation. Okay. The other thing that Dino experimented on that is great is the fact that dependencies can be served from, uh, without a registry. Okay. Turns out that probably that was not a great idea. Okay. Um, because in the end they had to support, ended up to support MPM.
So it's, um, they're still using their imports and stuff. They have their proxy, they, it is done with them, but. They still have to, they ended up supporting all of MPM. Okay. Which it's a single point of failure owned by GitHub, Microsoft, and so on and so forth. Probably not great from a community perspective.
So the word that they described would be much better if we just use URLs. It has some problems. Okay? So it's, uh, um, but again, that is great. Okay. So, uh, and then there is CloudFare workers with a completely different execution model, which is fantastic. I love workers. Okay? And they're very specific for something, and it's a great tool.
So all of those combined creates us, uh, uh, some interesting ways in which, uh, you know, they're pushing node and in different direction all the time. Uh, renewing an effort on performance, for example, and, and or renewing an effort on, uh, um. Go on, on, on security on the other end. Well, you know, there's all those things that are very important.
So Node is doing them and I'm pretty glad that those other runtime exist to, um, uh, to push node and create competition because for a few years, node was a little bit stagnant to some extent. And, uh, uh, it was hard to ship a lot of stuff. Uh, to be honest, there was a lot of, um, technical adapt to be, to be cleaned up in some cases.
So, uh, there still is, it's a node project. Okay. Um, but I think things are significantly better now. So, and, uh, things are progressing very smoothly
I
think.
Justin: This is something I appreciate about the, the flourishing ecosystem 'cause that it is like a, you know, a rising tide lifts all. All ships. Uh, I, I think that like, you know, so when BUN came out, I think it helped push Dino in a direction of thinking more about compatibility. Uh, and then I think that they both had a positive influence on Node.
And like you were saying, there is this value of having some external project do something that you can't do. So like Node, you know, being really close to standards and that being important is tremendously valuable for stability in the ecosystem and for compatibility. But there are some times where you think is like, oh, well if we could like not do some of this, what would that look like?
And then having another framework, like another tool out there to, to do it and you're like, oh, well it works in this case, and it really doesn't work in that case. And like, you know, if nothing else that's educational right? It like, lets you see. It's like, oh, so, so these are the sort of trade-offs that, that emerge in that world.
And I, and I think that that is just valuable for the ecosystem. 'cause it, like, otherwise it's hard to even imagine what the possibilities are without someone like taking the, the chance to sort of not only build it, but like, you know, actually deploy it to production. So, um, it is kind of interesting to see that, that world evolve.
Matteo: Cool. Yep. I'm very, look, it's a fun, brave, new word to
some
extent.
Justin: We just need, uh, the, the stewards of V eight to, to continue investing.
Matteo: pretty much, yes, we have the Google overlords and the apple overlords to keep, uh, uh, releasing versions of that, of, of those libraries. Okay. Um, they are open source. So they're open source. And I think at the, let me check if the V eight license, uh, so V eight is, seems a form of BSD or something like that. I don't know. Um, it's, it's, it's not, it's, it's a very simple license. Okay. So unless we change, things change. Okay. Um, it's, uh, very hard for us to. Uh, it, you know, if if V eight we can close source? Yeah. Well, probably there will be a fork. Okay. Um, it's, uh, uh, um, very, it's very likely that it'll stall the development of new features, of the language essential and, and so on.
So it's, um, I don't think they would, to be honest. They, they, I think they benefit too much from V eight being open source
than anything
else.
Justin: Yeah. I just, you know, I'm to the point now where, no offense to any people working at Google who might be listening to this, but I, I don't have a lot of faith in Google not killing things. They, uh,
Matteo: it takes cash cow. Okay. So the only key question here is they decided to make it close source, but, um, I think there are so many people. In Google that like chromium and that they want their system to be run on max on, uh, sorry, on Linux, on Linux systems, and they like the chromium tree, the chromium line, and so on and so forth.
That I don't expect Google, ch Chrome to stop being, like to chromium stopping being a, a, a, an open source project. Okay. Even though it's corporate open source in that sense of there is, um, there's not open governance to be honest. Throw with the, with Microsoft stepping in and doing, you know, they doing co maintenance and so on and so forth with the, with Edge, maybe that this is a good sign.
Okay. You have two big techs working on the same stuff. It's very, you know, I don't see it going down and becoming and
disappearing anytime soon.
Andrew: Okay with that, I think, uh, we'll wrap up the episode today. We'll, we'll skip tool tips. Uh, thanks for coming on Matteo. Uh, this was a fun talk about all things node and all the great work that you do
for the
ecosystem, so thanks.
Matteo: Thank you folks. Thanks for
having me.
Bye-Bye.
Justin: Yeah, it was, it was really great having you on Mateo. Uh, and I'm excited to see how, uh, platformic evolves. Uh, it's, it seems like a cool product. Uh, good luck on with the startup and I I hope it continues to do well
Let's
Matteo: finger crossed. Finger crossed.