Josh chats with James from e18e. This is a project that is working on improving Javascript packages by cleaning up, speeding up, and leveling up the dependencies. The way the e18e project handles this work is very human open source. It’s all about building up connections and trust with the package communities, which is no small effort. James fills us in on what they’re doing as well as how we can get involved. It’s a truly amazing effort
Episode Links
This episode is also available as a podcast, search for “Open Source Security” on your favorite podcast player.
Episode Transcript
Josh Bressers (00:00) Today, open source security is talking to James, who is the lead of e18e which is a project actually Andrew Nesbitt pointed me at, which made me very exciting. And I I looked up James and e18e and I was like, Holy crap, I’ve not heard of this before. But James, I’ll I’ll let you explain because you will do a much better job than I. But welcome to the show. I am very excited for this conversation.
James (00:21) Yeah, thanks for having me. But yeah, the e18e project is, I mean, you can summarize it as trying to clean up and improve performance of the JS ecosystem. But obviously that includes like a massive amount of work. So, you know, there’s the, there are basically a few categories that we’ve focused on. So one of them, for example, is speed up.
where we’re trying to speed up existing tools and applications. And one of them is cleanup, where we’re trying to reduce dependency trees, you know, to have a smaller supply chain footprint, basically. And we also have level up, is where we’re producing alternative libraries to old, unmaintained stuff and things that haven’t been modernized.
in a long time. But yeah, the combination of all those basically, the overall aim is that we’ve all seen how bad the node modules directory is. So the ultimate goal really is that that’s nice and small and it’s tidy. There’s like a small amount of polyfills if possible because we have modern engines now. And the security improves because you’ve
you’ve got fewer dependencies and the ones that you do have are actively maintained then. So it’s a focus on performance, security and just maintainability basically.
Josh Bressers (02:07) Yeah. Okay.
So I wanna set the stage a little bit, maybe for anyone I suspect everyone knows this, but I’m just gonna say say it all so to to make sure we understand is so like the node ecosystem is currently legendary for being gigantic, but I I I would maybe I don’t know if I’d call it bloated necessarily. I mean I’m not uncomfortable using that word, but it is well understood that when you install almost any node dependency these days, you get like a ton of stuff, often hundreds of packages underneath
anything you use. Like if you install any of the web frameworks, you’re gonna go from you think you installed one dependency to now having like 200 dependencies because it’s just it explodes. And you mentioned kind of two important aspects of this is a lot of this stuff is not fast because it was just, you know, slapped together often by by some random person scratching their itch, which there’s nothing wrong with that by any means. But obviously when you have infrastructure powering a huge amount of the internet, like
slow and fast can be a huge problem with some of these dependencies, which, you know, I mean, great. I I get that. And then you’re also talking about level up, which one thing that I think we’re starting to understand about the open source ecosystem that has kind of not been well known is that a lot of this stuff is not maintained or it’s not well maintained. Where like a developer wrote a thing and they threw it up on GitHub.
And they’re like, whatever, I’m done. And then people started using it. And all of a sudden you have someone who maybe doesn’t want to or isn’t ki you know, kind of keeping I d I don’t know, I shouldn’t say taking care of, keeping track of. It it I don’t blame them, right? I’m not saying like if you dump a thing on GitHub, you don’t necessarily have a responsibility for it. But I’m I’m very excited that you your crew is paying attention to this and trying to do something about it. So that’s that’s really cool. So I wanna start talking about cleanup because I kind of put a list together and and that’s
That’s what you get. But like
James (03:58) Yeah.
Josh Bressers (03:59) let’s talk about that. So what do you mean when you say cleanup? Because I know you mentioned kind of replacing some of the packages, but like you have is you have some really nice examples actually on your website. I’ll put a link in the show notes. But like explain what cleanup is, kind of like let’s go into some of the details here.
James (04:14) Yes, so the
The best example probably is Storybook. from a couple of years ago, well maybe one to two years ago now, we worked with the Storybook team because Storybook was known as being this massive thing. And for context by the way, if anyone hasn’t used Storybook, it’s basically a component catalog and testing tool for when you’re building UIs and things. But basically that was known as having like a crazy
dependency tree and a lot of that it obviously isn’t maintained by the storybook team it’s deep dependencies that they don’t have any control of so at some point people started trying to create alternatives to storybook as a way of solving that problem basically like let’s make a new one and that will have fewer dependencies that are actively maintained
So we worked with the storybook team instead to reduce all the dependencies basically, get rid of all the stuff that can be done natively now. And eventually I think it must have gone down from a few hundred dependencies deeply to like…
maybe 20 or 30 dependencies and most of those the storybook team can actively contribute to then it’s feasible you know they’re not dealing with having to contribute upstream to like hundreds of dependencies now so the dependency tree is a lot smaller and that you know that’s beneficial to them because it means the install size is a lot smaller for people to download it and it’s easy
to maintain at that point. But yeah the security side of it as well in that we now have a smaller footprint basically in terms of the supply chain but we want to do that to as many high impact JS libraries and tools as we can basically as a community. Like the storybook one is showing an example right and we now want to follow that example and do that to as many high
impact things, things with lot of downloads and usage and dependence as possible. Hopefully give the same improvements then to everybody basically because we all consume these tools. So the more we can affect as a community, the more that we all gain basically.
Josh Bressers (07:01) Okay, so I I have a question about this because I I I was reading about some of the things you’ve done this work with and and we’ll just pick on Storybook because you brought it up. Is so when you’re talking about decreasing dependencies, how often are you having to go, you know, past Storybook into some of their dependencies and trying to work with those projects? Because like I know on your website, one of the examples you have is like glob and fast glob, right, where they’re functionally the same. Why do we have them both?
And obviously you have them both because two different dependencies require well, hopefully two different dependencies require them. But I’m curious because obviously working like directly with storybook is probably very simple, but w like how deep do you need to go in this tree to really kind of create the kind of change you’re talking about?
James (07:42) Yeah, so…
It’s this is a thing basically that has to be learned. So in the e18e is a community, right? First of all. so the whole point is that we want to help people contribute to popular tools and things themselves. So the thing that needs to be learned for people that want to get involved deeply in this is how to look for
point in the dependency tree where you can have the largest effect basically. an example in what you’re asking about is in the globs actually for tiny globby we will have looked at the dependency tree and found which things were pulling in fast glob and globby and whatever else and those things so those packages will evolve
been deeply dependent on you know like they’re not direct dependencies quite a lot of the time but we will have contributed to those you know to switch them away from fast glob and globby and any other one so that that is a difficult job because you have to go around all these deep dependency repositories contribute an upstream but it’s not as simple as like going to the bottom of the tree and then
you know, contribute into the leafs basically, the leaf nodes. You have to kind of figure out in this tree, like, at what point does it become an isolated subtree?
So what I’m saying is like if you have a dependency up here that depends on this and then there’s a one here that depends on that and then there’s a subtree that nothing else depends on. That’s the point at where you would chop it off basically and that’s the bit that someone that’s getting properly involved in this cleanup work has to learn that you know like where is the boundary? Because if you try to contribute to every possible
granular package upstream you just never get anywhere. As you said earlier a lot of them are not maintained so you would just get stuck basically and just to note on that as well like sometimes you do get blocked and it’s not possible to migrate it so then you go one more level you go one more level in the dependency tree and try contribute to that one instead and if you can’t do that then you go one more level until
get to the point where you can make change basically. So yeah it’s a lot of work.
Josh Bressers (10:37) Turtles
all the way down, right?
James (10:39) Yeah.
Josh Bressers (10:41) I mean that’s so I’m going to ask you a question that I’m sure someone has asked you before and I I’m only asking it because I don’t I want it asked. Like, why can’t we just let an LLM go do this work for us, right?
James (11:00) Yeah, and it would like it would probably end up rolling its own of everything right?
Josh Bressers (11:06) Yes.
James (11:08) So You could say well I want you to reduce my dependency tree and its solution would just be let’s get rid of all the Dependencies and inline everything because you weren’t clear you asked me to reduce the dependency tree. You didn’t say do that by having smart a choice of dependencies
So yeah, you could throw an LLM at this, but it would probably just result in lot of duplication. Assuming this is a thing that you publish, like if this is a private app or something, then it doesn’t matter as much because no one’s depending on your thing. But still, obviously, you should aim to have the least code for you to maintain.
That’s the problem really, in that it would introduce a lot more code that you now have to maintain because you’re not pulling it from somewhere.
Josh Bressers (12:08) And you
have in, I don’t remember where I read this on your site. I was I clicked around a lot. But one of the things you mention is projects that do kind of inline the dependencies, right? Because in like in the Node.js world, you have the concept of packing where you’ll just like literally take a dependency and just take the, you know, HTML and JavaScript and whatever it has and and like literally include that inside of your project. And there was something you mentioned where the install size was like
I think thirty or sixty megabytes. And it was because they were including all that. And like this looking for this is one of the things you’re doing. And I know in the in like the security world we call these I ghost dependencies quite often where it’s just copied code. And and I think that’s kind of what you’re talking about, the LLM thing, right? Is is that.
James (12:51) Yeah, yeah, I’m not actually like the…
Probably the most popular example of this now in the JS world is next. You know, like the next JS package only has four or five dependencies, I think, but it’s a 500 meg or something package itself. And that’s because all of its dependencies are bundled really. So, you know, they probably have their reason for doing that. It’s some sort of DX choice or whatever.
but that does mean now that they have vendored copies of all of the deep dependencies and so then from the security point of view your problem is you know if if a hotfix goes out or something a security fix you’re not going to get it until they rebundle so whoever then pulls nextjs in is now relying on the next team to ship fixes for their deep dependencies rather than you just pulling it
naturally
Josh Bressers (13:56) Yeah. Well and even just knowing you
have it, right? Because when something is is pulled in like that, you might not even know it’s there. So if you’re trying to do some sort of, you know, audit of your infrastructure, you think, I have next, I don’t have this other thing, great, right? But you do.
James (14:11) Yeah, yeah, 100%. And it’d be really cool one day to do some sort of big analysis job, you know, of the most popular packages, let’s say, and you just scan them for bundled dependencies. Just out of curiosity to know how many are doing this, because it’s probably quite a lot.
Josh Bressers (14:32) For sure.
This this sounds like something we might might be able to Tom Sawyer or Andrew Nesbitt into doing. Just drop some hints.
James (14:37) Yeah.
Josh Bressers (14:40) Sounds like his his cup of tea. So okay. So I want to move on to your your second one on my list is is speed up. So I feel like this one is I I it feels obvious, right? Like let’s make it faster and better, right? Better code. But I I I don’t even know how I would start doing this, right? Because it’s like such a
What what do what do you do? Do you go to someone be like, Your code is crap? Here’s a better copy. Like I d I don’t even know what I do here.
James (15:08) Yeah, like quite often the way this one is so if you look at the the cleanup category we sort of go down the dependency tree and then work our way back up.
But from the speed up side of things, you basically want to benchmark something big and popular that people use at the top level and then figure out how to make that faster by speeding up the dependencies. If it is the dependencies that are slowing it down. So an example is like when we improved Astro rendering performance, you know, that was just done by
benchmarking astro rendering like which is a high level thing like directly in the astro repository so that one is just regular cpu profiling but you know who would think to try that because it’s a stable thing that you know it’s working you would just assume the team is gonna do it one day but that’s not how it works like you need a you need to be nudged
to dig into the performance basically. So part of what we’re trying to do is just help these teams benchmark it and things and find bottlenecks and help improve them. But it’s a much more involved process so there’s a lot fewer people in our community that do this stuff because it’s like a deep-diving performance stuff, know, profiling.
and
Josh Bressers (16:52) Yeah, which is hard
to do. And and I think one of the other challenges is I mean, if we if we think of it from like a very business perspective, no one’s going to buy your product because you made it ten percent faster, right? They want new features. Features I would sell products, not saying, this version’s ten percent faster. People are gonna be like, I don’t care, right?
James (17:09) Yeah.
And a good example actually of why we would do this is probably the prettier CLI. know, people prettier the format, people knew that it’s pretty slow. And at some point we did a deep dive into how to improve the performance because at the time everybody used it for formatting code in the JS world basically. There’s alternatives now, but it’s still the most popular
by far and so you know we did a deep dive of how to make that faster and Fabio that’s one of the members in e18e basically built a new CLI for it that was a lot faster and that’s now inside prettier and you know it was like a 10 times speed up or something but it’s like that kind of thing is affecting a tool that
everybody uses so you know how many how many projects around the world now run faster locally and have faster CI and whatever else because of this one package getting faster so so we’re trying to attack it that way you know like a lot of it is developer experience stuff in that it’s not runtime it’s not like what you ship to a web app or something but at the same time we do do improvement
like the Astro one to runtime stuff as well but that’s a lot harder because it’s like way more variable you know it depends heavily on how people ship websites basically
Josh Bressers (18:54) Yeah, yeah, for
sure. Now out of curiosity, I I I haven’t seen this anyway on your site, but has like memory usage been a topic? ‘Cause I know like the price of RAM is ridiculous right now, and I feel like anything I could do to reduce RAM usage on any of my apps would definitely be a welcome change.
James (19:10) Yeah, we, so we’ve done some work as a community like that with frameworks at least. I’m like, for example, we worked with the Svelte team to reduce memory of the Svelte parser, I think it was, and the ESLint plugin as well. And I’m pretty sure we did some stuff in TypeScript ESLint to reduce the memory usage. You know, mostly DevTools again in that case, but it just means like,
your local dev setup then is using a lot less memory which is what we all want.
Josh Bressers (19:48) And I mean, buying a laptop with what, sixty four gigs of RAM is just out of the question right now, I think, for most people. So yeah, less RAM. And
James (19:56) Yeah.
Josh Bressers (19:56) and CI runners as well, right? Like CI runners have a ton of memory pressure now.
James (20:01) Well you don’t usually realise things grow over time. something that used to use very little memory incrementally has sort of just gone up and up and up. And then before you know it, it’s using half your memory or something.
Josh Bressers (20:21) Yes.
James (20:22) So yes, some of that stuff works similar in terms of contributions to the CPU profile and stuff.
if we find someone that cares enough to dig into it, then they can do memory profiling and stuff. But it is a lot less common for us to do that than the other tasks just because it’s like a, it’s an in-depth thing, like a research job basically. But we do do it. So I’d love to see more of it actually as well.
Josh Bressers (20:58) Nice, nice. Yeah.
I mean heck I mean I remember a few years ago, man, like we’d be planning some feature or something and so it w someone would always say, RAM is cheap, like whatever. Like not anymore.
James (21:10) Yeah, and you know, stuff adds up as well. This is one of the difficult things to convey to maintainers is that memory and CPU, you can often turn up in like a small package that’s used by loads of projects and say, well, can you change this piece of code to this piece of code? Because it uses less memory. And to them in their world, it looks like it’s barely anything.
But you’ve got to remember that’s like a leaf at the bottom of this massive dependency tree that’s used by most of it. And so when you get
Josh Bressers (21:47) Yeah, yeah.
James (21:48) to the top, it’s actually the reason for most of the memory and most of the CPU time. yeah, getting that across to maintainers is a difficult one when doing these contributions. Because we’re looking at much bigger picture than your package.
But yeah, the ones that do understand it then have improved the entire ecosystem, you know, if they’re a popular enough package.
Josh Bressers (22:19) Which is amazing.
I I love that. All right. I w I wanna I wanna jump to level up before we run ourselves out of time here because this one I think is the most interesting, but I also have a lot of questions. So your idea behind level up is I’m just gonna read what you have on your website here. You say, you know, modern
James (22:35) Yeah.
Josh Bressers (22:35) runtimes provide features that enable packages to be leaner, blah, blah, blah, blah. And so the the intent, my understanding, is there there is a lot of old stuff.
There are new ways things might be done. Other new packages might have more features than they did in the past. The run times, like the things in Node proper are vastly different than they were, you know, a decade ago or or when a lot of these things were made. A lot of these packages are are maintained or poorly maintained. And so it sounds like you guys are trying to just like literally build new projects that do this stuff. Am I am I did I get that or did I miss something?
James (23:10) Yeah,
so the priority is always try contribute upstream, you know, to modernize popular libraries and things. But that’s not always possible because, you know, it might be unmaintained or it might just have a different direction it’s going. The maintainers might have a different goal, you know, or some other reason like that. And in those cases, it makes sense to create a new package.
where you can modernize it you can use like new engine features and new syntax and stuff like that. So TinyGlobby is probably a good example of this in that eventually it will probably switch to using the built-in glob function that’s inside node under the hood. So it’ll just be a thin layer on top of node’s own glob function.
the other globbing libraries that it replaced their direction is different they want to keep their own implementation because it has differences whereas we’re saying well most consumers don’t care about that most consumers just want you know like source slash star star dot ts or something they’re all basic globs basically so this is part of what I think I did a blog post
this at some point, but it’s basically that edge case first code is what we ended up with. And
Josh Bressers (24:48) Yes.
James (24:49) part of the level up stuff is to reverse that where you end up with the common case is implemented and the people that want the strange edge cases can use a different library.
If you switch that around, everything gets lot smaller and faster because you’re not accounting for all of these special cases, which I think more libraries should do that.
Josh Bressers (25:15) Yeah. yeah.
A hundred percent. So all right, so here here’s my question though. Here’s what I I wonder is how how many how do I I don’t want to sound like a jerk. have you have you angered any of the projects that you maybe have forked or or created a new version of in the in this particular effort?
James (25:37) probably not angered but i i can’t remember off the top of my head but there have been debates and things you know like
Josh Bressers (25:45) Okay.
James (25:47) for example
When we started promoting pico colors, which is just a library for doing terminal colors, there was a lot of debate about you shouldn’t move away from chalk, even though this pico colors library is faster and smaller. You shouldn’t switch to it for various reasons. And most of reasons were, well, chalk is older and the maintainer has been around a long time.
you might as well stick with it it’s safer and you know fair enough but
That’s the user’s choice, right? We shouldn’t be telling people to stick on a much older implementation when there’s something better available for their case. So yeah, we have had some debates like that, but usually everybody is open to modernization at least, and especially
Josh Bressers (26:52) Nice.
James (26:53) speeding things up. But that’s also why we ideally want to contribute.
to have to replace these. If we could just improve the existing ones, we always would want to do that. Because it also increases options since everybody uses it already.
Josh Bressers (27:12) Yeah, yeah. Okay, okay.
Here’s the big close, James. So when we think of a lot of these problems, I think we often think of the technology behind it, right? Where we think about the patches and the the the level up projects and the pat you know, however we’re gonna work with making things better. But I think everything you have described and everything I’ve read
This is fundamentally people, right? Like it’s all people. You’ve built a community of people that like the motivations behind them are all different. And and like I think this is amazing, right? Like this is how open source is supposed to work, where you’ve collected a bunch of random people doing a bunch of random stuff with a a somewhat common goal in mind. You’re going to projects where you have to interact with them. Cause like one of the things I’ve noticed, you know, in in this whole like LLM universe right now.
Is there’s nothing that angers open source developers more than getting like some drive-by LLM PR, right? Versus interaction and like human contact. And so like I’m I’m curious if this is something you have have in mind. And and I I suspect you do because just everything you’ve said so
James (28:25) you
Josh Bressers (28:25) far, but like this is people, right? Like it’s all people, all the up and down this whole project.
James (28:31) Yeah, and we so we are trying to build tools to help people do this themselves or some of it but ultimately, yeah, it’s always people on purpose because even the for example when we contribute upstream we we have like a process that’s followed where it’s Reach out to the maintainers first to find out if they’re even interested and only if they signal interest then you can
open an issue about the individual changes that we want to do and only if they get accepted then someone should open a PR. There’s a process to follow and that’s to avoid just flooding a bunch of repos with PRs because everybody’s got enough of that already.
Josh Bressers (29:20) Yeah, yeah.
James (29:22) yeah, a purposeful choice is that we’re not automating a bunch of this because it’s
that maintainers speak to each other basically and they understand that even if there’s some disagreement or like different directions we should discuss it rather than just conflict or whatever so yeah I think like that’s probably one of the most important things to build a community of people and get everybody working together
Josh Bressers (29:59) I a hundred percent. I mean that’s that I I know in this day and age I think often people think of open source as a license and and packages, but it’s always been the people and it it always will be the people, I I suspect. And this is that I I will say so lurking in your Discord for quite a while, that is the one thing that I think I find the most impressive is is you have a group of people that are very focused on like talking to each other in talking to other groups, which is
I mean it saying that it it should be obvious, right? Like it’s one of those things that’s like, well, duh. But I feel like we’ve gotten away from that in a lot of ways with with a lot of open source we do today.
James (30:42) Yeah, 100%. And you know, I’d love to see more of this because in the framework performance project we have going on, for example, Alex that’s mostly leading it, he basically talks to most of the framework teams themselves about the stats that we’re pulling and things like that and possible improvements upstream. All of that is communication between like big
framework teams and the e18e community and then
everything about suggestions to what packages we promote and things like that and what we should improve and what we should speed up. All of that really happens in the discord as a discussion between a bunch of people and people share things. Loads of people share things all the time where they’ve just said, I’ve been using this package for the last few years and it’s not maintained so I made a new one. Do you want to check it out?
all sudden it gets popular because people are looking into it because it’s a person behind it. So it’s really good to see that community building basically. And it just happens naturally now that people know it’s a space to collaborate and share basically. Not many of those exist these days. Well, they do, but there’s fewer of them over time, I think, which is a shame.
Josh Bressers (32:18) Yeah, yeah. agreed. All right. All right, James. Let’s land this plane. Tell us how to get involved if we’re listening to this and this sounds interesting because this is I’ll admit, like performance and things, it’s it’s definitely a very nerdy niche, but it’s also I love that you’ve created a place for people that love this kind of stuff.
James (32:37) Yeah, so if you want to get involved basically the main place to be is the Discord but you can find that on the e18e.dev website and you can basically check out we have a repo called Ecosystem Issues and this Ecosystem Issues repo is basically like GitHub issues for tracking upstream contributions.
So it might be, we should migrate this popular package to ES modules. So there’s loads of issues like that, ready to be picked up and they’re all labeled with things like, you know, needs first contact or something. And so if it’s labeled as that, then you could contribute by going to the repo and asking, being the first contact, you know, asking the maintainer if they’re interested. And then if they’re not, we label it as
not interested and then that’s when we can pick some other thing to use you know or or we can contribute to some other project so there’s loads of labeled issues like that that are really easy to pick up but i would definitely say just come along to the discord and say hi and there’s tons of people that are always willing to help out and chat about things
Josh Bressers (34:00) Yeah, and and I’ll tell anyone listening,
like, if you join this Discord, you’re gonna learn a lot of crazy stuff. Like there’s a lot of really cool conversations. It’s definitely worth a join. Just to lurk
James (34:10) Yeah, and there’s so many good people in there, like maintainers of really popular projects and frameworks and tools and you know, like all the influential people in the JS world are probably in that discord because they all want to make their own projects faster as well and you know, make them leaner and everything else. So yeah, everybody’s on the same page pretty much.
Josh Bressers (34:37) I love this. I just I love this project so much. I mean, I I th this is amazing, right? Like I I hope we see this for every ecosystem, every language, everything that could possibly exist. Because this is the kind of work I’d love to see. And the one other thing I will say, and this is just a giant thank you to you and the whole community, is this is like this is Morlock work, right? This is stuff that is not gonna get attention. This is stuff that’s not gonna be even seen or understood by the vast majority of people.
And so the fact that you’ve created a community of people that are basically like working in the mines and will never see the light of day is awesome and amazing. So just thank you so much for that.
James (35:15) Yeah, I’m very thankful of the people that are part of the community as well, including yourself. It wouldn’t be a thing if we weren’t all there. So the only reason it works is because we all join together.
Josh Bressers (35:32) For sure. I that’s perfect. I love that ending. All right, James. This has been a treat. I cannot wait to talk to you in the near future to find out all the crazy cool stuff you’ve been up to. But this has been a blast, man. Thank you so much.
James (35:44) Yeah, thanks for having me.