Eric Meyer: This episode of Igalia Chats is brought to you by Igalia, an open source consultancy with a proven track record of landing features and devices from XR to handheld, deep expertise with embedded devices, advancements in flagship web browsers, kernel contributions, and much more. To get in touch, or to learn more, visit Igalia.com.
Brian Kardell: Okay. Hi, I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And my name's Eric Meyer. I'm also a developer advocate at Igalia, and today we have another person from Igalia.
Nicolò Ribaudo: Hello, I'm Nicolò. I'm at Igalia on the compiler's team, and I am maintainer of Babel, which is why I'm here today. For those who don't know, it's like a JavaScript tool that takes some JavaScript code in, and transforms it to code that works in all the browsers. So you can... Maybe there is some new JavaScript code feature that you want to try, and you cannot because your customers, the people using website, might be on a browser that's not being released yesterday. So this new, cool JavaScript feature is not going to work in their browser. So you can still write it in your source code, then you give it to Babel, and Babel gives you something that your customers can actually run.
Eric Meyer: So is it that there's a whole bunch of stuff in it that will basically backport or polyfill older browsers, and so as new stuff gets written, people are adding backward polyfills for those things?
Nicolò Ribaudo: Yeah, that's kind of like it works. There are two parts to it. There is like JavaScript has new syntax and new built-in functions, Babel mostly takes care of the syntax so it actually rewrites it to other code. For example, when 10 years ago we got let and const for variables, Babel would rewrite it to VAR so it would also work in browsers without let and const support. But then it also has some integrations for automatically injecting polyfills that are JavaScript implementations of new built-ins, so that if you have an array that includes function that maybe doesn't work as a browser, it's going to inject some code to load an external polyfill that makes that work.
Eric Meyer: Okay. So if someone's using temporal JavaScript, for example, it might inject Moment.js or some other thing that will...
Nicolò Ribaudo: Something like that. Not Moment.js, but some exact implementation of the temporal proposal that works exactly how it would work if it was implemented built-in in the browser.
Eric Meyer: And who would write that polyfill?
Nicolò Ribaudo: Very few people, actually. Babel has maybe two or three integrations, but there are basically two popular polyfills and that's it, for at least for the JavaScript standard library. And just everybody relies on them that are core-js and the es-shims. And it's literally two people in the whole world that do that because I guess they like it.
Brian Kardell: I think Babel is... There's a history here, which I would like to talk about because I find it very interesting. I always liked the history and to think about where you're coming from, where you're going. But I think Babel was in the news and getting a lot of hype a lot more, maybe five years ago or so, and I think it's less now. But there is an interesting thing that we were talking about before the show, which I think is part of the reason why we're talking about this today, which is I have this stat on Wikipedia that says it was downloaded 16 million times a week in 2019. But you also just looked, and what was the stat that you came up with?
Nicolò Ribaudo: It's now 61 million times per week.
Eric Meyer: That seems like a lot of growth in six years.
Brian Kardell: So it's basically also I think something like one in a thousand downloads is Babel-core.
Nicolò Ribaudo: So a lot of this growth, I don't think it's real growth as in Babel getting more popular, it's just that JavaScript keeps getting more popular and NPM just keeps growing and growing. And Babel, I think it's close to have saturated the possible market share, and so at this point it's just growing with the ecosystem. So it's likely that if total downloads NPM double, downloads for Babel will also roughly double. Then I don't know how much it was actual growth, possibly Babel had some growth in the past five years, but I don't think it's just that it got six times more popular.
Brian Kardell: Probably. And there probably are projects, built-on projects, and projects that are forks of projects, and there's lots of ways for things to get lots more usage numbers like that. But anyway, the point is it is a really mature, stable project at this point that a lot of stuff depends on. And I think you were saying to me that it's one of the most stable projects.
Nicolò Ribaudo: Yeah, compared to most other tools in the area, we tend to disappear, as in Babel is configured by something and then you don't have to worry about that. You don't have to worry about migrating the next major version or this update broke everything. It's possible introduced bugs, but the intention is that it just stays there, silent, and does its job. It was not like that in the past. We caused a bunch of migrations that caused pain to every single user, like Babel five to Babel six forced everybody to learn about Babel plugins, and then Babel six to Babel seven, and we just renamed every single package, but that was maybe seven or eight years ago. And we now try to make it so people don't have to worry about it anymore.
Eric Meyer: So when you say, 'we', you said you're a maintainer of Babel. One of many, or where are you fitting in the Babel infrastructure?
Nicolò Ribaudo: We are three main maintainers. The maintainer group has been the three of us for maybe five years at this point. There have been various generations of a core group of maintainers, then there is a bunch of people that just stick around. For example, we often get some reviews from maintainer of related projects. So just keep an eye on how Babel works, or there are some specific areas of the code base that are mostly maintained by somebody that's not the three of us. Or sometimes the old maintainers show up and say, 'look, you could do this thing' or give ideas. But yes, there is this little core with the three of us and then there is a bunch of community friends around the project.
Eric Meyer: That is not many people to maintain a project like that. It sounds like it would be really time intensive. Where are you finding the time?
Nicolò Ribaudo: The two other maintainers are actually paid to work part-time on Babel. I'm also, at Igalia, have some work time to spend on it. So in total there is actually more than one full-time person maintaining it. It's still not a lot, but it's enough to keep the project not only afloat, but actually evolve the rest of the ecosystem.
Eric Meyer: Nice.
Brian Kardell: And maybe that's one of the benefits of it being super stable, is that it doesn't need to be doing a lot of super rethinking. And that can happen with new projects, like I think especially when you make breaking changes. There's a lot of, 'Hey, we can do whatever we want.' And then you end up touching a lot of code and making a lot of work to effectively keep the same functionality in a lot of ways. So I think it's interesting and good that it's in this really stable state, and it has some financial support enough to keep it relevant and keep it going. You also mentioned to me when we're talking about stability, what's the earliest version, the node?
Nicolò Ribaudo: Babel still supports node six. Actually I didn't look it up, but curious to know how old node six is. I think it's Node 24 now, so that's been 18 releases. Node six might be nine years old at this point, which is actually a very annoying maintainer to have to worry about compatibility with something that old.
Brian Kardell: Node six was officially released on April 26, 2016.
Eric Meyer: Almost nine years. It'll be nine years this coming month.
Brian Kardell: Amazing.
Nicolò Ribaudo: Eventually, in a couple of months, we'll drop software for node six. We'll have a new major release that keeps most of the public API the same, but it removes a bunch of internal workaround needed for compatibility with old stuff. We're going to drop all node versions up to, I think, 18 or something like that, because they're not officially maintained anymore.
Brian Kardell: Can we talk about the history of this a little bit? Because I find this very interesting, because there's some things that intersect with my own personal development, and personal thoughts and views, that also lead into some questions that I would like to ask. So I remember back in 2009, we had Jeremy Ashkenas made CoffeeScript, and it was a transpiler, it would transpile CoffeeScript into JavaScript. And it was like maybe the first thing that I saw that got popular that was like... You could change, you could create a new language that had a slightly different syntax, but was familiar enough you could do cool things with it. And I think at that same time, you can correct me if I'm wrong, but I think at that same time we were still in the pre-Harmony era of JavaScript. And if people don't know what that is, there was a long, long period in JavaScript where nothing happened. There was this attempt to do what was called JavaScript 2, was brand that they were going for there. And you'll note that there is no JavaScript 2. There was, but it never happened. So it was a little bit like when you track the HTML versions, you get these...
Eric Meyer: HTML 3.0 and...
Brian Kardell: Exactly.
Eric Meyer: Which never was released.
Brian Kardell: Never really was a thing. So that was very big, and it was, not totally different than what we wound up with, but it was really heavily inspired by Java and stuff like that, and it was, I think, not even remotely backward compatible, and all this stuff. It seemed like very dominated by a few committees. And then we did start to get these proposals together, and things started to change somewhere around that same time. And I remember the Traceur compiler came out in 2011, and that was done by some people at Google, including Alex Russell. And right around that time I was beginning to talk myself to a bunch of people - Yehuda Katz, Alex Russell, Marcos Caceres, Francois Remy, a small group of people. And we were talking about all these things and coming up with this thing that eventually wrote down as the Extensive Web Manifesto. And the idea was, what if we could build tools like this so that it wasn't just in a committee? Because one of the problems with that is that it could take seven or 10 years, and it might not go anywhere. And even if it does go somewhere, sometimes you get through that committee, and it's so much group thought that when we get it, and real developers try to use it, it's underwhelming or even bad. So the idea was can we somehow incorporate this into standards so that we get proposals to people, it gets transpiled, and because of that, it's not like we can change the proposal along the way, because you transpile it, it's a compile time thing. It can mean something different in between compiles. It's not going to break at runtime, which would be a big deal. It's just like a library that you're using. And then, importantly, can we find a way to take that feedback and do useful things with it to know if we're doing a good job, if there should be changes to that, if people are adopting it. And I think that along the way, there was several generations, that you can speak to a lot, of originally, I think this started out as a project called 6to5 by Sebastian McKenzie, and then there was also ESNext, right?
Nicolò Ribaudo: That's correct. It was like these two projects just merged together to create Babel, but it was after Traceur. Babel was from 2015, I think, so it's been a few years in between.
Brian Kardell: And even the way that that's worked has, like you said, changed in some breaking ways. There was these polyfills, and then there was, 'the target is ES six,' and then it's like, 'well, maybe it's just these browsers,' and there's, 'well, the last three browsers.' And so you've come along how that's been done. And I'm wondering, can you maybe tell the story of some of those evolutions, but also answer the question: have we done any efforts to see how we incorporate that, and get into getting feedback and looking at data and knowing... Have we used that in some way to help shape the standards?
Nicolò Ribaudo: That's out of questions, out of points. So, just disclaimer, I only got involved with Babel in 2017, so my memories of what was before is actually indirect experience from other maintainers talking about it. But Babel started, as you said, as Sebastian's project was called 6to5. And then I did marriage with another project, and I think at the beginning two maintainers were Sebastian and Jamie, James Kyle. And from there it was like there was some competition with Traceur. Everybody wanted to be the project that people would use. And then over time, Babel stayed around. I believe Traceur now is much less used, don't even know if it's still maintained. So Babel started doing exactly what Treasurer did, then there have been some along the way. Like you mentioned, Brian, the support for specifying, 'oh, I want to support these browsers,' or, 'I want my code to be compatible with this and this thing.' I believe that came to Babel around 2017 maybe. There was a preset called Babel Preset EMV. It was an experiment from some other maintainer, I believe it might have been Brian Andrew, but I'm not sure, that basically took some external project called Browsers List that had this database of which browser versions were available and some usage stats that I believe it gets from CanIUse. And it took this data, it took this project, to transform human-readable queries, like last three browsers, into an actual list of browser support. And then Babel has mappings for each browser to list the features, and so then it knows what to transpile. And I believe that has probably been the largest innovation that Babel brought to transpiling JavaScript. It was not an entirely new idea. As I mentioned, browser's list already existed and that believe it's used for some CSS transpiling, but Babel was the first tool bringing that to JavaScript and probably that will be the largest impact at Babel. And then we kept experimenting with many things over the years. At some point there was a Babel minifier that was using Babel architecture to minify your code, because in the end a minifier is just another sort of transformer that takes some input code and gives some output code. That's not maintained anymore due to lack of maintainers. But we've done a bunch of things. We've implemented many proposals. Actually, the way I got involved in Babel and in TC39 was by implementing various versions of the decorator's proposal. It's been a proposal for more than 10 years probably, and it's one of the most popular ones, and everybody wanted it. And in this standardization process, we went through four or five different designs. And in Babel, we were implementing all of them one-by-one. I think at some point we skipped one just because the proposal kept changing so quickly, it was impossible for us to actually keep up with it. But we actually let people experiment with various versions of proposal and say, 'Oh, this is good. This is terrible. This is incredibly slow. This is not very usable.' And we did bring some of that feedback back to TC39, and the proposal is almost done now, hopefully.
Brian Kardell: Hopefully it would be really good, because we had a lot of touch along the way. It wasn't just theory, and performance concerns, and... It was a lot of testing on it. You get a sense that it's fit for survival more or less.
Eric Meyer: What do decorators do again?
Nicolò Ribaudo: Decorators are some syntax that you can use to call some function that can modify class methods, class fields, classes themselves. For example, you could say, 'Oh, I have this method. I have a decorator that's a logger, and I write @logger before the class method. And every time you call the class method, it logs something.
Brian Kardell: It's been interesting, and I was watching it develop early on, and I think maybe I used, probably, your stuff through Babel at some stage and then I didn't. I used to use it in Java and, I don't know, things like JSDoc aren't that, but they're similar in nature to how you do them. But I think there was a lot of that in things like spraying in Java that were pretty cool. Speaking of this comparison with Java that I'm making out of nowhere, there's an aspect of this that I think is really important that I mentioned earlier, which is that you can use a proposal, and it is compiled into something that you can guarantee remains the same. So, it's like if you use a version of jQuery, you know that you chose that version of jQuery and it's just going to keep working unless the browser itself breaks, or something. So you can think about it as, 'I'm trying out a proposal. I know that I can treat it as almost like a library in practice, even though I'm using it to... I hope this is what becomes the standard, and it allows me to really lower the cost of me somehow participating in that, and learning about it early, and being a part of the process.' But I think that that fact that you do it at compile time, that is really important. And it reminds me of a thing that contrasts those two in Java and JavaScript. So we have collections, like arrays, and maps, and sets, and things like that in Java, or in any programming language. And in Java you had... Eventually we got types for collections. So those are done through erasure and it's a lot like TypeScript is. And I think TypeScript you can do through Babel as well, right?
Nicolò Ribaudo: Yep.
Brian Kardell: But this thing with collections is in both of the specs, this is actually part of how I got involved in standards, which is why I know anything about this probably. So, at one point in time, both of the Java and the JavaScript specs said, 'Oh, well, if you have a hash map, or you have an object with properties in JavaScript, you can iterate over the keys basically, more or less, you can iterate over the properties, but the order is completely undeterministic.' It's just like whatever order. But in practice, in both of those, it was always, more or less, insertion order. It was more or less. There were some funky cases where you used numbers as the keys or something, but more or less, whatever order you inserted the keys, that's the order that would iterate. And so even though that was not what the spec said, people came to learn that you could do that, and they were like, 'I can do useful things with this.' And so they started to do a lot of useful things with it. And sometime around the same time, both of them changed. Now, in browsers, it only changed, I believe it was Opera that was trying to eke out more performance. And they came up with a way to do that. And they reasoned that it would be fine because the spec said you don't need to have an order. So they just found what they thought was a really efficient way to do this that didn't maintain the insertion order. And they said, 'because the spec says you don't have to.' And in Java, when that broke, it was like, it's not like anything broke overnight it broke when you rebuilt it and sent it to QA. You know what I mean? You try to do some QA, stuff just didn't work. And you had to figure out, 'Oh, I see. I have to update these things.' It's not a big deal, you just change to use a different collection. But in JavaScript, in the browser, all kinds of things broke, Gmail broke, and big major properties. And so I think that this idea that Babel and transpilers use is really powerful, but also then it does mean that things are frozen in time. And if you build your website, and then you don't touch it for two or three years, are you still polyfilling stuff that maybe you don't need to polyfill anymore?
Nicolò Ribaudo: I would argue that's good and not bad. Your website is guaranteed to keep working if you use something that was actually unstable, because the unstable parts is just shipped together with your website as if you're shipping your own virtual machine or something like that. And yes, you could improve your website probably. If you're using some proposal that then becomes standard, you don't need to transpile your script anymore. So you could improve your website, make your code smaller, or something, just removing Babel from the equation. But at least it's not breaking, which is probably more important than, 'oh, you could have had some optimization thanks to something was released last year,' but you're not benefiting from it.
Brian Kardell: It's a super interesting conundrum in a way, to balance those two things, because the Extensible Web Manifesto, when we wrote it came from this Extensible Web community group where we had a lot of these discussions and this exact topic was topic of a lot of things where people would say, 'Yeah, but I want it to be optimal, so when I write code that uses a polyfill, I put it conditionally so that it doesn't...' People use yepnope. Remember yepnope? Modernizer? Remember?
Eric Meyer: Yep.
Brian Kardell: And they say, 'I only load it conditionally.' And I was like, 'Yeah, but when you wrote this, you didn't know whether it would change or not, so how can you...' If you say, 'This is how array iteration works.' And then you're like, 'Okay, well array iteration is supported now, so just automatically assume that you don't load this.' But what if it doesn't work the way that it worked when you compiled it?
Nicolò Ribaudo: Yeah, that's actually a big problem in JavaScript. When it comes to Babel, the main thing that Babel does, which is transforming syntax, you cannot redo that conditionally because you cannot do... If the syntax is supported, then use the syntax otherwise not, because your whole file needs to be syntactically valid. So Babel just unconditionally transpiles everything to whatever you're asking it to do. But when it comes to runtime features, so to polyfills, like to custom implementations of built-in functions, some polyfills just do that unconditionally. So we might have a polyfill for the new set intersection union methods that just does set.projectapp.union= and then some implementation. And then there are other polyfills that do that conditionally. So they check if the set-dot intersection method exists and if it does not, it defines it. And the second types of polyfills actually causes problems in standards and involving the language, because maybe a browser shipped some proposal that then, after shipping the standard body realized, 'oh, actually we need to tweak the behavior in this or this way,' and then, 'we cannot actually tweak the behavior because something breaks because it has this conditional polyfill that just stops polyfilling with the old behavior, and so it automatically triggers the new behavior.' So, it's also a problem in JavaScript, just not when it comes to syntax. It happened very recently with scoped custom elements.
Brian Kardell: These were my positions very early, so I'm pleased, very pleased to be right about them. So originally this project, I know from the 6to5, because Sebastian wrote a piece in 2015, or something like that, where he talked about the early development of this. He was 17. This started out as a hobby project that he did in high school. And he ended up getting a job out, his first job, and then also his second job, and maybe even his third job. And that involved them paying for him, at least part of his time, to work on 6to5. But then I think at some point, maybe in 2015, '16, '17, I know that's a big range, but I don't know when exactly it, I think was Open Collective funded. It began to...
Nicolò Ribaudo: So when I joined the project in 2017, Sebastian already was not involved anymore. So I don't know exactly what happened before I joined, but at the time in 2017, we had an Open Collective page where we were receiving donations from a bunch of companies, and that was enough to pay a maintainer to spend some time on the project, paid, not as part of their main job, but through donations. We also had other maintainers with doing as part of the job. There was Henry Zhu working at Adobe, that had maybe 40% of his time dedicated to Babel, until when then he actually quit Adobe and started working full-time on Babel paid through Open Collective donations. And it's been great. Babel is one of the projects that received the most funding through Open Collective in the JavaScript build tools ecosystem. It's Babel and Webpack back at the top, especially maybe five, eight years ago. And then everybody has an order of magnitude behind which actually made it possible for us to improve a lot of the project. And it was not just luck, it's not just like, 'Oh, money's arriving. Great.' But some of the maintainers were spending significant amount of time going around and knocking at the door of company saying, 'Hey, use Babel. Please give us some money.' At some point, Henry was doing that almost full time, just asking for money to make it possible to pay other maintainers. And then it's been decreasing over time, especially since Covid. Companies started laying off employees, but before laying off employee, you look at your budget, and you cut all the unnecessary expenses such as donating to open-source projects, but we can still pay two maintainers to work part-time on the project now. And then there is me who, as part of my job at Igalia, I have some time to spend on Babel.
Eric Meyer: So Igalia is covering your time, and then the other maintainers are being paid out of the collective?
Nicolò Ribaudo: Yes, that's correct. And I don't think the other maintainers have a job that would let them work on Babel.
Brian Kardell: A really nice thing about working at Igalia, I think, is that if you have something that you believe should be done, for whatever reason, really, you can propose to the assembly that this is a thing that I would like us to do, and we can discuss it, and often do it. So I think it's great that we do that kind of thing.
Nicolò Ribaudo: That was one of the things that I learned before joining Igalia that made me decide to try applying, and it went well. Even though at the beginning I was still paid, when I first joined Igalia, I was maybe working some percentage of my time on Igalia things, and then the other percentage of paid by Igalia, and then the other percentage of my time was actually still paid through Open Collective my time spent on Babel, or at least part of it. But then, as donations went down, Igalia stepped up more to cover all of it for me.
Brian Kardell: Do you know how much money has been raised by...
Nicolò Ribaudo: It's probably more than a million in the history of Babel, a million dollars.
Eric Meyer: All over the entire history of collective funding of Babel?
Nicolò Ribaudo: Yeah. A large part of this nation is actually coming from very few companies or individuals. There was MPHTML was a big sponsor. Our largest sponsor, I think, is Airbnb that's responsible for a quarter of our total donations. At some point, we even published some article saying Babel is running out of money, because during Covid, donations dropped so much that we were receiving half of what we were spending, and two people from Japan together donated almost a hundred thousand dollars, like that.
Eric Meyer: Wow.
Brian Kardell: Wow.
Nicolò Ribaudo: Which was... I don't really know what was going on there, but was happy about that. But donations has still been decreasing. We have a couple big sponsors now. We have some sponsors that are a bit maybe sketchy and probably just do it to get their little logo on our website. We discussed it a lot internally. Do we want to have sponsors with questionable values? But in the end, what we decided was that, well, we cannot afford losing all of them, so either other companies step up, or we're just going to keep accepting money from whoever gives us money.
Brian Kardell: It's a little bit of an interesting thing. We just had breakout sessions at W3C, and we were talking about this collective, I don't know, evolution of how we think about open source, and all the different ways that we try to fund it. And so we have the model where it was originally you had the people paying him to work, and now Igalia's paying you to work part time. I think you said Henry was paid part-time by Adobe. Then we have funding through the Collective, which can be individuals or companies, and they can pay either a single lump sum or a recurring thing, either annually or monthly. Or people can hire Igalia. Like if you had a really specific bunch of work or bugs that you needed fixed in Babel or whatever, you could totally come talk to us, or you could do it yourself, or another company could fund the work, or... It's interesting to me all the variables in this, and which things feel, to you, more sustainable. Because I do think that the fact that, I looked it up, it was like $1.5 million is the total amount that it's raised, and it looks like it's pretty close to $118,000 annually right now. But like you say, it's been falling, and it's that plus that doesn't account for what Igalia sponsors you to do, right?
Nicolò Ribaudo: Yeah. It also does not account for fees that we pay to Open Collective to use the platform.
Brian Kardell: So there's benefits to all of these things. I think that it doesn't have to be all one or all the other, but certainly, to me, it does seem like monthly recurring contributions is a pretty good way.
Nicolò Ribaudo: Yeah. It's all about trade-offs. The two best things are either being employed by a company to work on the project or having a monthly recurring contribution from some company. When it comes to actual donations like company and money, the monthly is much better, because it makes it easier to plan, because monthly contributions are somewhat more stable than somebody doing one time every once in a while. So it actually makes it possible to say, 'Okay, we have this much amount of money now, and we're probably going to get about this amount of money in the next six months or next year.' So it makes it possible to actually decide to have some maintainer that spends some fixed amount of time, and actually has some regular income from that. And then there's the other model, the one that's working for me right now, where I'm employed by Igalia to work on the project. And this feels more stable to me, at least I don't have to constantly worry about money and about fundraising. But at the same time, it gives me less freedom. If other Igalia tasks are requiring more of my time I feel like, well, I should focus more on those than on the Babel part because Babel is not the thing that's making me have a job at Igalia. While, if I was entirely paid through donations, I would like... Well, that's just my job. I would spend as much time as I want on it.
Brian Kardell: Yeah, that's exactly the kind of tension that I was thinking, because you were saying the best thing is probably if you're employed by a company to do it, because it's less volatile. But I don't know that it is. I think you should feel like we allocate this money for you to do that and you should a hundred percent do that. But I get exactly what you're saying, and I would imagine not all companies are like Igalia. I have worked for other corporations, so I could see we're late on this other project, and maybe don't do the Babel work for the next six months.
Eric Meyer: And isn't the Sovereign Tech Fund...
Nicolò Ribaudo: That's very recent news. There is this part of the German government that goes around and funds like infrastructure projects...
Eric Meyer: Digital infrastructure projects.
Nicolò Ribaudo: And we've been talking with them for a while and it seems like for the next year they will, again, give us some funding and that will probably make them one of the largest contributors we have. But again, it's not just money that gets thrown at you. It took a lot of effort from our side to figure out this funding, but it'll at least make us not have to worry, anymore, about how to pay the two maintainers paid through the Collective for the next year. Mostly because our reserves are very low right now. We used to have a hundred thousand dollars in reserves, now it's more like maybe 30,000, which it's scary to see the number going towards zero. So, now this Sovereign Tech Fund project gives us some buffer for a while.
Eric Meyer: My experience of Sovereign Tech Fund actually is through other projects where generally, I don't know if this is true for what they're doing with Babel, but there are milestones. Basically they're deliverables. Is that the case here?
Nicolò Ribaudo: Yes, that is the case. However, they are quite flexible with what the project is. For example, when Igalia worked with the Sovereign Tech Fund for test262, it was easy to say, 'okay, there is this and this proposal, so the milestones are working tests for this, this, and this.' For projects like Babel is some of that. You can say, 'oh, there is this proposal to implement in Babel,' but also there is things like you just need to spend time triaging issues, and going through all stuff, and cleaning everything up. That's, for example, one milestone even if it's a trillion milestone.
Eric Meyer: It's great that there is an organization that's specifically tasked with funding digital infrastructure. You know the XKCD cartoon that everybody uses in their slides about one thankless maintainer in Nebraska, Sovereign Tech Fund is an example of an organization that's trying to give money to the thankless maintainer in Nebraska, or three people working part-time on a really core piece of JavaScript backwards-compatibility infrastructure.
Nicolò Ribaudo: I wish there was more of that.
Eric Meyer: Same.
Nicolò Ribaudo: I believe there is something from the US or at least there was, I'm not sure about what's the status now.
Brian Kardell: Pretty sure it's not the status now.
Eric Meyer: Probably not, but really who knows at this point?
Brian Kardell: But there were statements from the White House in the last few years that had a lot to do with maintaining the digital infrastructure, and also beginning to migrate to parallel memory safe things as a basis for our digital future. I agree with you, it's very scary to see the number of something that is maybe the top few most downloaded things with NPM get near a budget of zero because there is still stuff to do, and it's still widely used, and there's a reason that you supported till node six until this long. You would think that you could discontinue node six a long, long time ago, but when you discontinue it, probably somebody is going to get really upset and go, 'What?!' So speaking of replacing, and keeping up, and memory parallel languages and things like that, I think part of the reason I was saying I don't think that you hear as much about Babel these days is because there are some competitors, or, not competitors, but competitors...
Nicolò Ribaudo: We can call them competitors. There is the new generation of tools that's coming up that maybe eventually we'll replace Babel, and they are all written native languages, and 20 times faster than Babel. And there is SWC, which is written in Rust, and now it's like the one bundled in both in Deno and Node.js node to strip away TypeScript 'at runtime.' At runtime, here, is in quotes. Or there's Oxc that is the new transpiler from the Vite ecosystem that's also written in Rust, and it's also trying to replace a bunch of other tools other than the Babel. They want to do linting and a bunch of other things. And it's actually very cool to see them popping up like this in the past few years. Yes, they're competitors, but it's nice to see that what we've... Many of the things we have learned in the last 10 years have been incorporating from scratch the lessons of those tools. And they don't have all the technical depth we have, and they have a much larger performance budget than we have. Because if you're 20 times faster than the alternative, you can add things. And even if you become twice as slow, it's still going to be very fast and can...
Brian Kardell: 10 times faster, literally.
Nicolò Ribaudo: I'm hoping that these new projects will be able to experiment much more than what Babel can do. Babel will stick around for very long, because it's so much used deeply in so many parts of the ecosystem that you cannot just replace it overnight. But who knows? Maybe in 10 years I can retire as a Babel maintainer and there will be these other people and these other projects keeping the web alive, and doing so many new cool things that we cannot really do today.
Brian Kardell: Or maybe you just have to become a maintainer of one of those projects instead. I don't know that they're complete overlap in all of the use cases that Babel serves either.
Nicolò Ribaudo: There isn't a true replacement to Babel. For the core use case of Babel, which is I give you some code, you transform it to something that works in other browsers, they cannot do it. But then, for example, many people use Babel with custom plugins, maybe some code transformations that are tailored to some specific library, or to some specific code pattern that you use in your company. And you cannot really do these things with these Babel alternatives is why they're not just a drop-in replacement for it. Or even if you can, I am pretty sure you can write your custom transforms on whatever, SWC, for example, parses, and then it gives you some representation of the code, and you can transform that. But then you have to know Rust, rather than just hacking your plugin with JavaScript. And given that the target user of Babel is JavaScript developers, it's probably going to much easier for them to write things in JavaScript than in other languages. There are also experiments in this area to, for example, Dino shipped some Linter written in Rust, and it supports plugins written in JavaScript. So eventually, probably, these Babel alternatives will actually solve both the use cases that Babel is solving, but we're just not there yet.
Brian Kardell: I think it was a really good chat. I learned a lot. I would encourage people... I know on this podcast we end up somehow talking a lot about sponsorship and funding a lot. It's not because I like that, it's because it's a huge problem in the ecosystem. And so I know everybody has things that they think should be sponsored, and I just hope that this helps people realize that, at least for the near term, it is really worth supporting Babel. So you can go in and do that. You can do it on Open Collective, or sponsor somebody to do it, or on GitHub sponsors is also a way to do it that's actually more economically efficient.
Eric Meyer: So where would people go to learn more about Babel if they don't already know and are interested?
Nicolò Ribaudo: There is a babeljs.io/videos maybe, that has a bunch of talks, and things, and resources about Babel. They're not super recent, because as I said, Babel didn't change much in the past five to eight years, but there is a lot of resources about what Babel does, how it does it, what you can do with it, and how all the various parts of it work.
Eric Meyer: Okay.
Brian Kardell: Cool.
Eric Meyer: Very cool. Nic, thanks for so much for coming on.
Eric Meyer
Brian Kardell
Nicolò Ribaudo