Is CommonJS Bad for JavaScript
A panel dissects CommonJS versus ES Modules, touching on Node, Deno, Bun, and how evolving standards, tools, and runtimes impact JavaScript's future
Episode Description
JavaScript Jam Live debates whether CommonJS is hurting JavaScript, exploring the ESM migration challenge, runtime wars between Node, Deno, and Bun, and tree shaking limitations.
Episode Summary
This JavaScript Jam Live episode centers on a Deno blog post arguing that CommonJS is holding JavaScript back, sparking a wide-ranging debate among developers with diverse perspectives. The conversation opens with the newsletter topic and quickly gains momentum as Dax argues forcefully for dropping CJS support, comparing the migration to a necessary product evolution where legacy users must sometimes be left behind. Okiki, creator of BundleJS and an Astro maintainer, brings deep technical insight, explaining why tree shaking is fundamentally impossible with CJS due to its lack of static analyzability, and noting that the few CJS-specific features like module caching serve extremely niche use cases. Anthony Shew from Vercel offers a pragmatic counterpoint, highlighting "dark matter developers" running untouched Node 10 apps in production who can't simply flip a switch. The discussion expands into runtime comparisons, with Okiki arguing that Bun locked itself into Node compatibility by implementing APIs like setTimeout the Node way, while Deno differentiated itself but struggles with marketing. The panel also explores emerging specs like Module Blocks, the Origin Private File System API, and how React Server Components fit into the offline-versus-online debate. The episode balances idealism about an ESM-only future with empathy for developers stuck maintaining legacy codebases, ultimately suggesting that the priority should shift so ESM is the default while CJS remains available for those who truly need it.
Chapters
00:00:00 - Welcome and Newsletter Roundup
Scott and Anthony open the weekly JavaScript Jam Live show with their usual invitation for audience participation, encouraging developers of all levels to join the conversation. After some casual banter with regulars like Bro Nifty and Fuzzy Bear, they introduce the week's newsletter topic: a Deno blog post arguing that CommonJS is bad for JavaScript.
Anthony explains the context behind Deno's evolving stance on CJS support — initially refusing to acknowledge it, then reluctantly adding compatibility, and now publishing a post urging the ecosystem to move away from it entirely. They also briefly mention the public release of Claude 2 as a ChatGPT competitor, noting its larger context window and Constitutional AI approach to transparency.
00:06:36 - Edgio's New Podcast and Community Updates
The conversation shifts as Lindsay Moran from Edgio joins to announce the company's new podcast, "Behind the Edge," with its first episode covering the rise of bot attacks. Lindsay relates the topic to the Taylor Swift Ticketmaster incident, where scalping bots overwhelmed the system and crashed ticket sales, making the security discussion feel personal and relatable.
Anthony connects the bot discussion to broader cyber warfare concepts like IoT botnets, and the group discusses how consumers rarely think about the technical causes behind frustrating experiences like failed ticket purchases. Lindsay teases upcoming episodes on web performance before the conversation transitions back to the main CJS debate as more panelists arrive, including Dax.
00:14:18 - Dax Makes the Case Against CommonJS
Dax delivers a passionate argument for dropping CJS support, pushing back against the assumption that backward compatibility is inherently good. He frames the issue as a product development challenge where clinging to early adopters and legacy patterns prevents the ecosystem from reaching its full potential, comparing it to being trapped at a local maximum.
The discussion gains energy as Dax argues that most ESM bugs developers encounter stem from bridging between the two module systems rather than from ESM itself. He contends that only a small number of critical packages need updating and that the JavaScript community's talented current generation of tooling developers is being held back by historical baggage. Fuzzy Bear joins in, recalling the role of Snowpack and Pika in pushing ESM adoption.
00:21:42 - Fuzzy Bear and Okiki on the Node Ecosystem Schism
Fuzzy Bear describes a growing schism in the Node ecosystem, explaining why he chose Deno as his primary backend runtime due to its native ESM and TypeScript support. He references a conversation with Node maintainer Matteo Collina, who acknowledged backward compatibility as a "necessary evil," a stance Fuzzy and Anthony view as defeatist.
Okiki, creator of BundleJS, then joins the call and immediately brings sharp technical analysis. He argues that most CJS-specific features like module caching serve extremely niche use cases, that legacy packages often have unaddressed security vulnerabilities anyway, and that Rollup — not Vite — deserves primary credit for ESM's rise because it introduced tree shaking, which is fundamentally impossible with CJS due to its dynamic, non-statically-analyzable nature.
00:29:33 - Module Blocks, Tree Shaking, and the TC39 Spec
Okiki introduces the TC39 Module Expressions proposal as a potential future solution to the caching functionality that CJS uniquely provides, explaining how it could let developers create custom virtual modules on the fly without the security concerns of CJS-style cache manipulation. Anthony finds the spec at stage three review on GitHub.
The conversation turns to tree shaking limitations, with Okiki emphasizing that any CJS package completely negates the benefits of modern bundling tools. Jess from Cypress joins and adds that libraries with chaining patterns like Redux and RxJS are inherently difficult to tree shake, and that Faker JS illustrates the challenge of packages that import massive locale datasets regardless of what's actually needed.
00:38:12 - Anthony Shew on Turborepo, Dark Matter Developers, and Pragmatism
Anthony Shew from Vercel joins to offer a pragmatic perspective from his work helping Turborepo users. He describes how developers constantly struggle with CJS and ESM interop in monorepo internal packages and how he often sidesteps the problem entirely by recommending patterns that skip compilation. He introduces the concept of "dark matter developers" — the invisible majority running legacy Node apps in production who can't simply drop CJS.
Okiki responds by distinguishing between hard-dropping CJS support and gradually deprecating it with warnings and a long migration timeline, suggesting a 10-year deprecation window. The panel debates whether new packages should still be written in CJS at all, with Okiki arguing the real problem is that new CJS packages continue to be created despite ESM being the clear standard.
00:45:01 - Library Authors, Bundler Complexity, and the Deno Blog Post's Impact
Jess steers the conversation toward library authors who write CJS and expect bundlers to magically handle compatibility, sharing experiences from Cypress where adding Vite support surfaced a flood of ESM-related plugin issues. Anthony Shew references Mark Erickson's well-known struggles packaging Redux for every possible module format, and Jess reveals that Erickson's detailed blog post on bundling history emerged from a three-hour kitchen conversation they had.
The panel evaluates whether the Deno blog post will actually move the needle. Okiki offers a nuanced critique, saying the post is technically correct but lacks empathy for developers stuck with legacy codebases. Bro Nifty adds that Deno is coming from a position of having built tools like dnt to bridge the gap, though Okiki points out that dnt itself still publishes CJS by default, somewhat undermining the message.
00:54:03 - Runtime Wars: Bun, Deno, and Node's Future
The discussion shifts to comparing JavaScript runtimes, with Okiki arguing that Bun locked itself into permanent Node compatibility by implementing APIs like setTimeout to return objects instead of numbers, matching Node's non-standard behavior. He contends this means Bun can never truly differentiate itself and will always be "Node but faster," limiting its long-term competitive advantage.
Anthony Shew frames Bun's choices as product decisions about adoption curves, while Jess highlights the positive feedback loop where Bun and Deno innovations push Node to improve features like native test runners. Okiki critiques Deno's marketing strategy of positioning itself as a Node competitor rather than an entirely different runtime, arguing this sets wrong expectations for developers coming from Node who encounter Deno's permission system and different configuration approach.
01:03:05 - Web Standards, OPFS, and the Server-Client Convergence
Jess and Okiki explore how NPM's dominance displaced CDN-based package distribution, creating the current tension where Node packages must work on the web. Okiki introduces the Origin Private File System API as an exciting emerging technology that enables persistent virtual file systems in the browser without memory limitations, noting its use in Adobe's web apps and SQLite's WASM library.
Fuzzy Bear raises a philosophical question about convergence between server and client code, predicting an isomorphic future where the distinction disappears. Jess pushes back, citing offline scenarios like using apps on the New York subway, leading to a nuanced discussion about React Server Components, progressive caching, and how different product verticals will likely converge on different architectural patterns rather than a single universal approach.
01:25:04 - Personal Stories, Security Hijinks, and Closing
The episode winds down with personal tangents that showcase the community's camaraderie. Jess shares that they have upcoming brain surgery for epilepsy treatment involving an implanted device with recording capabilities, joking about becoming a cyborg and needing to avoid DEFCON. The panel riffs on lock-picking, physical security exploits, and Fuzzy Bear's story about breaking through a plasterboard wall to reach alcohol in Scotland.
Scott wraps up the show by thanking everyone for the valuable discussion, and the panel offers a final consensus position: rather than killing CJS outright, the priority should shift so ESM is the default and CJS becomes a secondary option for legacy needs. Fuzzy Bear gives a shout-out to Bryce, a new Astro community maintainer, and the hosts remind listeners to subscribe to the JavaScript Jam newsletter and tune in next Wednesday at noon Pacific.
Transcript
00:00:00 - Scott Steinlage
Yo, yo, yo. Welcome to JavaScript Jam Live. Yep. Hey. Hey. We do this every Wednesday, 12:00pm Pacific Standard Time. Welcome to the show, folks. You know we love hanging out here talking about JavaScript and just other web-development-related things. And whether you're a first-time guest here or not, you know you love to hear this part of it. So here it is. Whether you're a beginner, whether you're an advanced web developer, engineer, JavaScript, or whatever it might be, it doesn't matter. We'd love to hear from everybody. So please feel free to come on up and click on request there to do so and we'll bring you up. You can ask questions, make comments, statements, facts, opinions, whatever. We love to hear it all. Why? So that we can have a great time together. And it just, you know, creates more value for everybody hanging out. So let's get to it. Let's create some value. Let's have some fun. Let's hang out. Let's do this. My name is Scott Steinlage. I'm a technical community manager here at Edgio and co-host of JavaScript Jam. Anthony, who are you?
00:01:50 - Anthony Campolo
My name is Anthony Campolo and I am a developer advocate at Edgio and also member of the RedwoodJS core team and host of the FSJAM podcast.
00:02:01 - Scott Steinlage
Yeah, that's a mouthful.
00:02:06 - Anthony Campolo
All the things, and AJC and the Web Devs.
00:02:10 - Scott Steinlage
Yes, yes. And Scott and Anthony's web dev adventure. Jeez Louise.
00:02:16 - Anthony Campolo
That's right.
00:02:17 - Scott Steinlage
Golly. All right. Awesome, Bro Nifty. What's up, dude? I've seen your late nights on in some other Twitter Spaces.
00:02:30 - Fuzzy Bear
That's cool. What up?
00:02:31 - Anthony Campolo
You're just hanging out in the Ryan and Misho space. I don't know if you saw that one.
00:02:36 - Scott Steinlage
No, I didn't see that one. I wasn't on Twitter.
00:02:41 - Anthony Campolo
Yep, Twitter has been a thing today.
00:02:45 - Scott Steinlage
Yeah, there's lots of drama going on today on Twitter.
00:02:48 - Bro Nifty
Are you putting me on blast, Scott?
00:02:51 - Scott Steinlage
Oh, no, absolutely not, brother. I think I'm just saying I've seen you in your late-night stuff, just hanging out. I don't think I ever recall seeing you on that late. That's all.
00:03:03 - Bro Nifty
I try to go to bed by 9pm, but sometimes I drank too much coffee. I have too much, what's that, adrenaline. I gotta take this call.
00:03:12 - Scott Steinlage
Okay, no worries. No problemo, bro. No, wasn't calling you out. Feel free to stay up as late as you want. No, go to bed. Go to bed now. Awesome. Anywho, yeah. What was the newsletter this week, Anthony? We had lots of wonderful things.
00:03:34 - Anthony Campolo
The newsletter for this week was about Common JS being bad.
00:03:41 - Scott Steinlage
Bad to the bone.
00:03:44 - Anthony Campolo
Yeah, it's very bad. They're making it explicit because in the past, they just didn't support it at all, which is like, nothing's more. Nothing expresses how bad you think something is more than just saying, I'm not even gonna acknowledge you. And then they kind of had to acknowledge it after a while because everyone was like, yeah, this is nice. But, like, could you make it work with the old stuff? Because I kind of need the old stuff to work. I'm going to keep using it and you can't make me stop. And if you try to, I'm just not going to use your thing.
00:04:15 - Scott Steinlage
I'm going to rebel.
00:04:15 - Anthony Campolo
So they're like, fine. So they eventually started supporting it and now they're like writing a post basically saying, yeah, we support this, but wouldn't it be nice if none of us supported this?
00:04:28 - Scott Steinlage
Right. Spread the love. All you need is love. All you need is love. Love is all you need. Come on now.
00:04:45 - Anthony Campolo
All right, it's now on the Jumbotron.
00:04:48 - Scott Steinlage
There it is.
00:04:49 - Anthony Campolo
Newsletter. And then here's the actual link to the Deno post. Yeah, I like the Deno blog. They're always well written and they have good images, too. This one is like a rock with CommonJS written on it and then a JS hot air balloon trying to take off with this giant rock attached to it.
00:05:10 - Scott Steinlage
I don't even know how it's tilting it. It's kind of amazing. That's good. Yeah, yeah. Very comedic. Comedic, yeah, for sure. Even a word. Jeez. Yeah, Say it properly. That's cool, man.
00:05:29 - Anthony Campolo
Okay. On the Jumbotron. Yeah, I mean, and I definitely understand this is one of those things. I can very clearly see both sides because I've felt the pain of trying to constantly work with libraries and frameworks that are transitioning through this CommonJS-to-ESM thing. So you'll have CommonJS stuff in the docs, but then you really want to use it with ESM, and you end up trying to rewrite everything. And then if no one had really tried to do that yet, then all this weird stuff happens, and it really affects stuff if you're using Vite, because Vite just assumes out of the box you're going to use ESM. But at the same time, it's like there's probably more code written in the old style than almost any programming language or ecosystem ever. So it's going to be a hard change. Now, actually, something that I don't hear people talk about much, but I think this is a good use case for, is ChatGPT to refactor these kinds of migrations.
00:06:36 - Scott Steinlage
Yeah, that's interesting. Just plug it in and then you get a bunch of problems.
00:06:44 - Anthony Campolo
Yeah, it would write it for you and then you can at least then run it and see, like, okay, what breaks and then immediately see which ones break and then try and get to fix those. That would be an interesting experiment.
00:06:56 - Scott Steinlage
Yeah. Debugging. You'd be doing lots of debugging, if that's your thing.
00:07:05 - Anthony Campolo
Well, you're going to debug anyway. If you're going to try and move from one to the other, you can't get away from that.
00:07:10 - Scott Steinlage
That's true. All right, all right. Yo, Edgio is in the audience. What's up?
00:07:19 - Anthony Campolo
Oh, yeah, hello, disembodied brand account.
00:07:26 - Scott Steinlage
It's probably Lindsay behind there. What's up?
00:07:30 - Anthony Campolo
Pay no attention to the woman behind us.
00:07:36 - Scott Steinlage
Cool.
00:07:38 - Anthony Campolo
So.
00:07:38 - Scott Steinlage
Oh, she requested. Let's bring her up. Yo, add a speaker, say hello.
00:07:46 - Anthony Campolo
The giant E can talk.
00:07:47 - Lindsay Moran
The E. Hey, guys, it is Lindsay. What's up?
00:07:51 - Fuzzy Bear
Whoa.
00:07:52 - Bro Nifty
What's up?
00:07:54 - Scott Steinlage
How are you?
00:07:55 - Lindsay Moran
Happy Wednesday. Halfway through. We've made it.
00:07:58 - Scott Steinlage
Yes. Oh, yeah, absolutely. What's up?
00:08:02 - Anthony Campolo
You want to introduce yourself to the audience?
00:08:04 - Jess
Oh, sure.
00:08:04 - Lindsay Moran
Hey, everyone, this is Lindsay Moran. I am the content and brand strategy manager here at Edgio and the face
00:08:13 - Scott Steinlage
behind the E. Yes. Nice.
00:08:18 - Lindsay Moran
Thanks for having me on.
00:08:19 - Scott Steinlage
Yeah, thanks for joining us and listening in, hanging out.
00:08:22 - Anthony Campolo
I hear you have a new podcast.
00:08:24 - Anthony Campolo
Oh, that's true.
00:08:26 - Lindsay Moran
Yeah.
00:08:26 - Okiki
Actually, great call.
00:08:28 - Lindsay Moran
Thanks for the intro to that. Edgio just launched a new podcast called Behind the Edge. First episode dropped earlier this morning, and we talk about the rise in bot attacks and, you know, solutions for detecting and mitigating those.
00:08:45 - Scott Steinlage
Nice. Yeah, we should put that on the Jumbotron.
00:08:49 - Anthony Campolo
Yeah, I'm pulling it up now.
00:08:53 - Scott Steinlage
Cool. Check out the podcast, folks. It's a good one. There's three awesome, very intelligent people on there talking about some very interesting things when it comes to bots. So check it out. Security. That's the solution.
00:09:11 - Anthony Campolo
The edg.io. Is that the right link?
00:09:15 - Lindsay Moran
Yeah, that's the right one.
00:09:16 - Scott Steinlage
Yeah. I like the artwork for the thumbnail. It looked pretty good.
00:09:20 - Lindsay Moran
Yeah, the animations are fire. So is the conversation. It's really worth a listen.
00:09:25 - Scott Steinlage
Awesome.
00:09:25 - Anthony Campolo
What were some of your big takeaways from the conversation?
00:09:32 - Lindsay Moran
You know, it's interesting being in marketing and feeling like I could really relate to this one. They talked about some recent examples of bot attacks, including the Taylor Swift fiasco, and I was one of those that did not get in to see her. So I did feel personally victimized by Ticketmaster in this case, and so I could relate to the conversation in that way.
00:09:53 - Anthony Campolo
Can you explain what happened there for people who haven't heard the story?
00:09:56 - Lindsay Moran
Yeah, sure. I mean, basically, Ticketmaster just got overwhelmed with bots purchasing, you know, ticket scalping, and it crashed their site. People couldn't get in for days. They actually had to stop the sale. So, yeah, it was a big mess. They just weren't ready for it. They thought they were. They just could not anticipate that kind of demand.
00:10:21 - Anthony Campolo
Yeah, bots'll get you like that. This is a concept I always hear about every now and then. Either it happens every now and then, or it's like a TV show or something where people just hack a whole bunch of Internet of Things devices, like toasters and refrigerators and stuff with internet connections that have no business having internet connections, and then direct 100,000 bots at something. Very interesting type of cyber warfare.
00:10:50 - Lindsay Moran
Yeah. Yeah. And it's not something you really. I don't know, being in the industry now, like, I can. I can see it, but as a consumer, you're just frustrated that you didn't get tickets, so you're not really thinking about what's going on. Except for the fact that, hey, I didn't get. I didn't get in to get tickets.
00:11:03 - Anthony Campolo
Yeah. Yeah. It's especially difficult when it's not just, like, bots posting messages, but they're actually, like, buying up, like, inventory.
00:11:13 - Lindsay Moran
Yep.
00:11:14 - Anthony Campolo
Awesome. Are there plans for future episodes? Yeah, I have an idea of some of the topics that'll be discussed.
00:11:21 - Lindsay Moran
Yeah, they're working on. Let's see, what is the next one that they're working on now? I think diving more into web performance, I believe, is the next topic. I think that'll be out sometime later this month.
00:11:35 - Scott Steinlage
Awesome. Well, we'll go ahead and chat about it when that comes up as well. For sure.
00:11:41 - Lindsay Moran
Yeah, for sure. Thanks for the plug, guys.
00:11:44 - Scott Steinlage
Totally.
00:11:45 - Anthony Campolo
Yeah, no problem. Looking forward to listening to it.
00:11:47 - Scott Steinlage
Yeah. If you haven't listened to it yet, Edgio has a new podcast. Yeah, go check it out. We linked it at the top there in the Jumbotron, and it's talking about bots, so good stuff if you're into security. That's the thing. Dax joined us. What up, Dax, and Saban, Sabin, and Jason, of course. What's happening, folks? How's y'all's day?
00:12:18 - Anthony Campolo
Ooh, have you seen that Claude had a public release?
00:12:23 - Scott Steinlage
I don't think so.
00:12:24 - Anthony Campolo
Do you know what Claude is?
00:12:25 - Scott Steinlage
I don't think so.
00:12:29 - Anthony Campolo
So it's one of the main GPT competitors right now, and it's been behind a waitlist and, you know, you kind of had to go to a hackathon or something to get access to it in the past. And they just released their second iteration of it. So, like how there's GPT-3, 3.5, 4, this is like Claude 2. And the first thing that had interested me about it is that it has a much, much larger context window than ChatGPT.
00:13:00 - Scott Steinlage
But is it just as good on the conversation?
00:13:03 - Anthony Campolo
We'll see. It just came out today, so it requires kind of messing around with it, but I mean, it seems like they are going to be similar for the most part, but have different reinforcement learning done to it. I think also the company has this thing called Constitution AI that is like this very long initial prompt that basically gives it all the parameters of what it should and shouldn't do and how it should approach things. And yeah, I like that. That's at least, you know, to a certain extent transparent. You know, there's still stuff in the model I'm sure that's not fully open source, but having kind of the moderation aspect of it a little more transparent, I think is good.
00:13:50 - Scott Steinlage
And.
00:13:51 - Anthony Campolo
Yeah, we'll see. You know, it's kind of like I played around with both Bing and Bard, and the Bing was fine, but Bard
00:14:02 - Anthony Campolo
was like,
00:14:06 - Scott Steinlage
for sure. Yep.
00:14:08 - Anthony Campolo
But, yeah.
00:14:08 - Anthony Campolo
Anyway, I don't know, Dax, if you wanted to. If the title piqued your interest. You want to talk about whether Common JS is bad for JavaScript, I'm sure you'd have lots of thoughts.
00:14:18 - Scott Steinlage
Yes, Dax always has thoughts. Come on. Whether he wants to put them out there or not, that's up to him.
00:14:25 - Anthony Campolo
And then, funny enough, we also had, right after Demetrius got a new job, we posted. I know, it was like, weird about. About Zeta.
00:14:34 - Scott Steinlage
Such weird timing. Like, literally, you put it out midnight the night before he made the public announcement that he was gonna be working at Clerk. So, yeah.
00:14:46 - Anthony Campolo
What up, Dax?
00:14:49 - Dax
Hey, was that a new blog post that you guys linked?
00:14:52 - Anthony Campolo
Was what a new blog post? The Deno one? Yeah, that's a couple days old.
00:14:58 - Anthony Campolo
It's not.
00:14:58 - Anthony Campolo
It's a premiere. I did see that, June 30th.
00:15:02 - Scott Steinlage
Yep.
00:15:03 - Dax
Okay. Yeah, yeah. So you guys are right. I do have a lot of thoughts on this. I think that we need to stop shipping CJS. I think we're in this mindset of backward compatibility being infinitely good, and if you break backwards compatibility, that's bad. I think that's a weird bias that we have. And I think it's almost like a reaction to stuff in the JavaScript world typically moving too quickly and breaking stuff and not considering backwards compatibility. But when it comes to CJS, I do not understand why we're still in a world where we're bridging between these two worlds. ESM isn't perfect and there are a lot of bugs, but the majority of people that run into ESM bugs are because they're living in this weird world of bridging the two.
00:15:56 - Anthony Campolo
Yes, they run into migration bugs. It's not ESM, it's buggy. It's having to support both or go from one to the other.
00:16:02 - Dax
And the complexities of packaging that people are always complaining about, it's because we have. Now they're trying to figure out how to package for both. And what happens when you're in an ESM project and that has dependency on a CJS project, which has dependency on ESM project. Like, there's all kinds of weirdness with it and we just need to move towards a future where we are ESM only. I don't think we need to bring a million packages along. I think there's like sub 50 packages that cover like 99% of everyone's needs and those need to be ESM only. I'm sorry, they're old applications that are not going to be able to make that jump. But that just is the reality. Things need to get torn down and rebuilt at some point. This, this kind of like, urge to just have constant incremental progress while maintaining backwards compatibility is. Is not something that works well. Especially when CJS was great and it was like a good setup and we had no reason to move from it. Like, yeah, then maybe it makes sense. But a lot of Node's history is not great. I think there's. The people that are working in this space now are a lot more, I would say, talented, to be honest.
00:17:11 - Dax
I think it's attracted like a much better crop of people that are building things and, well, kind of. And they're kind of hampered by just like this history and legacy of it.
00:17:23 - Anthony Campolo
Yeah, I agree.
00:17:24 - Okiki
Super hard.
00:17:25 - Anthony Campolo
It's very validating to hear you say that because I've been saying for a while, I feel like once Vite really took off, we had the enabling tool to be like, okay, this is what's going to set us up for an ESM-only world. We should just leave it behind. It's like this whole Python 2 to 3 thing. Like, if they just made everyone have to support both forever, that would be ridiculous. As long as it took, they eventually recognized they had to drop support for Python 2. I feel like it's the same thing here.
00:17:55 - Dax
Yeah, it's the same thing. And I liken this to just another thing that happens in product development. And this is a painful thing, so I understand why it's difficult. Oftentimes you'll start building a product and very early on you'll have these very passionate early adopters, and you're really excited because somebody's using your thing and you are really appreciative of them. But over time you realize that you kind of see where your product is today and you see the best it could be within the current parameters, and you realize, okay, that's not big enough. We need to go to the next level. Our product needs to be massively different or care about different things or optimize for different things. And it's painful because in that process, you actually need to burn some of your oldest, most familiar users. So there just is this friction with doing that. But if you don't do that, you get stuck in a local maximum for way too long, potentially forever, and never actually become the great thing you could become because you're burdened by this. So it's painful and we should try to make it easy.
00:18:57 - Dax
But not to like a pathological degree word.
00:19:01 - Anthony Campolo
What's up, Fuzzy?
00:19:02 - Fuzzy Bear
Waka waka waka, folks. How are we all?
00:19:05 - Scott Steinlage
What's up?
00:19:06 - Anthony Campolo
Very good. Thank you for joining.
00:19:08 - Fuzzy Bear
Thanks.
00:19:08 - Anthony Campolo
Yeah.
00:19:08 - Fuzzy Bear
Thoughts, thoughts. CJS could go die in a bloody pit for all I care. But to be honest, right, I just joined so I could ask you to invite my colleague Okiki on. He's a creator of BundleJS.
00:19:22 - Fuzzy Bear
He has literally gone down this rabbit
00:19:25 - Fuzzy Bear
hole for the past, God, he'll tell you himself, right? But he's spent a long time swimming in this particular hole. If you don't mind, Anthony, if you can invite him up.
00:19:36 - Anthony Campolo
Any friend of Fuzzy is a fuzzy friend of mine. Yeah, I just sent him an invite.
00:19:44 - Scott Steinlage
Yep.
00:19:46 - Fuzzy Bear
Thank you, guys. No, that's great. I just want to say to you guys in the U.S., I'm finally in the U.S. What a country.
00:19:56 - Anthony Campolo
You're in the U.S. right now?
00:19:57 - Fuzzy Bear
Yeah, California. We. Awesome. Right.
00:20:00 - Anthony Campolo
So what's your CommonJS take?
00:20:04 - Fuzzy Bear
My CommonJS thought is that it's an antiquated open specification that took hold at a point in a vacuum, to AMD, all these kinds of open specifications bundling and packaging your JavaScript files together. They all grew in a vacuum, and when you have things growing in a vacuum, you're going to have problems.
00:20:32 - Scott Steinlage
All right.
00:20:33 - Fuzzy Bear
ESM is one of those solutions that is late to the table, but the quicker you adopt it, the less pain I have experienced. I mean, like you were saying, it was like when Vite came into the marketplace, right? Snowpack before that. I mean, Fred himself, he did a big push to get ESM, to push the ESM modularity kind of stuff, when it came to Skypack, Snowpack, those two particular projects, with Pika as well. And then having seen that grow in the ecosystem in terms of Vite, the kind of work that they do, the similarities that were there to begin with, now there's a divergence. But with Vite and Snowpack at that small point in history, there was definitely a world where the past was definitely present, if you get what I'm trying to say. They were moving from that mindset of, you know what, ESM is here, is now the standard, post-2015. Let's try and get tooling and try and get services and facilities made for this kind of new standard that we could share code on a modular basis.
00:21:41 - Fuzzy Bear
But yeah, personally speaking, CJS and the previous specifications that came before it, they were, you know, drop them, drop them. Like, you know, drop us. Like just get ready. In my opinion, when I see. Yes, when I don't, it infuriates me now when I'm having to work with code bases that are not ESM based because of those like pain points that Dax just beautifully, you know, succinctly described. So yeah, that's my take word.
00:22:11 - Anthony Campolo
Yeah, I totally remember when Fred was kind of doing that like media tour and that's kind of how I first learned really What ESM was the time because I was still kind of learning the whole ecosystem, like what is really the difference between these two things. And I. It seemed like, like you were saying everyone just kind of had to decide like collectively it just like this is the thing and then it would become so. So it's like chicken, the egg problem. Someone has to collectively agree to do it, but they all have to kind of jump at the same time. And like Vite was the closest thing to kind of like a shelling point term for that.
00:22:50 - Fuzzy Bear
The thing is, what we've not spoken about, and again this is something for the entire group to discuss, is the schism that is happening within the Node ecosystem. Because it's not just JavaScript now. ESM is internally within the JavaScript standard now. But what's happening within the Node ecosystem? Because Node, for the argument of backward compatibility, can't drop CJS or their previous standards, their previous module bundlers, whatever it's called, for ESM and go all in on ESM. That is why I've chosen Deno as my primary backend tooling system, because with ESM and TypeScript it's a lot easier for me to get going, whereas working with Node now is becoming a pain point because of the entire ecosystem. I remember speaking to Matteo about this, and Matteo's point when it came to the Node ecosystem on why they can't go all in on ESM was backward compatibility. But even his argument to that was that it's a necessary evil. It's one of those necessary evils that we just need to accept and try and work around.
00:24:06 - Fuzzy Bear
And for me that is not good enough.
00:24:10 - Anthony Campolo
Yeah, that's. I think it's like a defeatist attitude.
00:24:14 - Fuzzy Bear
It really was, it really was. But the thing was, from your point of view, this was a conversation going from Node 14 onwards and they've still not, you know, they're still pretty much, their position is we are on the fence now. We can't go either way. And because they're sitting on the fence, you're going to be having packages that are literally playing with fire. Some will just work like a dream, but having that together in your project, in a codebase, you're just asking for problems, and problems cost money.
00:24:53 - Anthony Campolo
I said an invite to your friend. I'm not sure if they're maybe having trouble joining. So if they need to, like sometimes it helps just like leave, come back. I'm not sure if they're trying.
00:25:05 - Scott Steinlage
Maybe they're. Maybe they're not on mobile and they're on Death.
00:25:09 - Anthony Campolo
Yeah. Is this someone who's done spaces before?
00:25:13 - Fuzzy Bear
I think so, yeah. Okiki has been around. Yeah. And he's from the Astro Community.
00:25:18 - Speaker 11
If you.
00:25:19 - Fuzzy Bear
He's one of the maintainers in the Astro community as well. He's actually some talent, that wee boy. But yeah, let's just say, okay, bro, get on your mobile.
00:25:30 - Anthony Campolo
Well, we'll see what happens when they come back. Do other people on the panel have
00:25:34 - Anthony Campolo
thoughts, things they want to say?
00:25:36 - Anthony Campolo
What about you, bro? Nifty.
00:25:37 - Bro Nifty
I. He was breaking up a little bit for me. Were you asking people on the.
00:25:41 - Anthony Campolo
Just like curious like you know, do you think CJS should be dropped or should we support it forever?
00:25:48 - Bro Nifty
Oh yeah, yeah. So Mateo is kind of the holdout for CJS, and I understand what he's saying there. In my view, CJS replaced the iffy for namespacing. And to me, I mean this is maybe a little bit of a brain-dead take here, smooth-brain take, but I feel like you can almost just use classes for the namespace. But anyways, ESM is the voice and it's much easier to work with.
00:26:19 - Anthony Campolo
What are you doing these days, Fuzzy? You work for Linux Foundation. I'm curious like what your day to day is like.
00:26:27 - Fuzzy Bear
Same here. I'm still trying to figure that out. No, it's actually me and Okiki, we were. Oh, he's there now. Perfect. We were working together to help.
00:26:37 - Okiki
I did not.
00:26:38 - Fuzzy Bear
Yeah,
00:26:41 - Anthony Campolo
sorry.
00:26:41 - Okiki
I did not know you couldn't use the mic on the website. I've done it on the phone before.
00:26:46 - Okiki
I didn't know you could become a speaker on the website, though, which
00:26:50 - Okiki
is a really dumb approach.
00:26:52 - Anthony Campolo
It gets everybody. It has like the ultimate foot gun.
00:26:57 - Okiki
Yeah, that is.
00:26:59 - Anthony Campolo
You want to introduce yourself?
00:27:00 - Okiki
Yeah, I'm Okiki. I'm a creator of BundleJS. I'm one of the maintainers in Astro.
00:27:06 - Okiki
Been around, played around with ESM and CJS
00:27:09 - Okiki
for quite a while now.
00:27:11 - Okiki
So there are two things with backward compatibility. One, a lot of those backwards-compatible packages haven't been looked at in years. So from a security perspective it may be better to drop them and look for different alternatives that are using ESM and have been maintained and are monitored for security issues, that's number one. Number two, the packages that use the features from CJS are few and far between, and the projects where they're used
00:27:42 - Okiki
are few and far between.
00:27:44 - Scott Steinlage
Right?
00:27:45 - Okiki
So, for example, CJS caching, right? The number of projects that actually need that are very few, right? We're talking like you could count them on your hands. The number of projects that actually need this capability. So no one's saying that you have to get rid of CJS, but to claim that CJS needs to be as prominent or treated as importantly as it is right now, it's just false. You can't quantify it because the feature set of CJS is so limited compared to ESM. And lastly, Vite isn't actually the reason why ESM is taking over. It's definitely one of the reasons. Rollup is actually the main reason why ESM took off. The entire idea of tree shaking could not exist in CJS because it is not statically analyzable. It is impossible to figure out where something is going to be used in CJS because of just the number of
00:28:43 - Fuzzy Bear
ways it could be used.
00:28:44 - Okiki
With ESM, you get that ability. So those are the three takes I have on it. So the first one being when it comes to caching and all that stuff. Yes, there are some key use cases that, yes, ESM currently doesn't cover. We don't say need to destroy that, but do note those are very few in between. Most people don't even know about this ability that CJS does where you can cache and you can delete caches for projects.
00:29:10 - Okiki
Most people don't touch that.
00:29:12 - Okiki
So it's a very minor use case that most people don't ever use. So it can be kept as a supported feature for those packages that need it, but not one that's pushed. So you only use it when you absolutely need it, type of thing in the Node ecosystem. And you know you need it because you know you need it.
00:29:31 - Okiki
You get what I mean?
00:29:32 - Okiki
Does that sort of make sense?
00:29:33 - Anthony Campolo
Yeah, no, it does. By the way, your mic's a little rough right now. Are you able to just go like straight through your phone? Yeah, like just kind of change.
00:29:41 - Okiki
Yeah, Give me a second.
00:29:42 - Okiki
Let me switch to.
00:29:45 - Okiki
Let me see.
00:29:46 - Scott Steinlage
Actually, can I.
00:29:48 - Okiki
Let me use my directly then.
00:29:51 - Fuzzy Bear
I just gotta say, he doesn't normally sound like this.
00:29:55 - Okiki
Yeah, usually at least on the computer
00:29:57 - Okiki
with a better mic. Okay. Is that better now?
00:30:01 - Scott Steinlage
Yeah, much better.
00:30:02 - Anthony Campolo
Yeah.
00:30:04 - Okiki
Okay.
00:30:05 - Anthony Campolo
Okay.
00:30:05 - Okiki
Maybe I should try repeating what I said earlier.
00:30:09 - Anthony Campolo
I mean it was understandable. I'll kind of interject, and it sounds like, you know, you're saying that really the biggest thing is that you get things like tree shaking and, I don't know if you mentioned, but just the asynchronous nature of it in general. And I think it's a good point about Rollup because Rollup underlies Vite. It's kind of like what pushed the standards to get developed in the first place versus what kind of brought it more to the mainstream. So do you think without Vite there still would have been as many people into it right now who would be just using Rollup, or do you think people are stuck more so with webpack?
00:30:49 - Okiki
No, even without it, Rollup would have taken quite a bit of this really far. For the key reason, Rollup is very flexible. The plugin system is very nice. In fact, Vite is built on that very plugin system, right? So the cores were already there. Snowpack was already doing stuff with this same idea around this time as well. So this stuff would have taken off even if Vite was never created.
00:31:13 - Fuzzy Bear
It's just.
00:31:16 - Okiki
It had reached terminal velocity by the time Vite arrived and we just took that all the way. You know what I mean?
00:31:23 - Anthony Campolo
Gotcha. Yeah, yeah, no, definitely, for sure. So do you think that we should drop support for CJS entirely?
00:31:31 - Okiki
No, for that the key reason is if you know you need that caching functionality of CJS, you know you need it. It's like if you know you need quantum mechanics, you know you need it, type of thing. Even though most people will never use it, you know you need it. So we shouldn't drop it. But the idea that most people should start creating packages with CJS, or that CJS is the better module system, is false and we need to change that. So we can still have CJS, we can have our cake and eat it too. Just need to flip it. It should be that the majority is ESM because most projects do not need the features of CJS. In fact, actually this weekend I was working on the BundleJS tree shaking. Right now, to get tree shaking to work of any kind in CJS, you have to give said package a name. So think React. You have to give whatever you're trying to export from CJS a name. You get literally no benefit to bundling, Rollup, all that. You get no benefit using any of those tools with CJS.
00:32:38 - Okiki
All those tools using CJS basically take any benefit you get from them and make them nil, zilch. You're wasting a lot of effort and time to use a CJS package. It needs to be made aware to people, like yes, you can do that, but the benefits are all gone when you do.
00:32:53 - Anthony Campolo
Is it possible or do you think it will be possible to recreate that kind of caching behavior in ESM?
00:32:58 - Okiki
It is definitely possible. The real question is should we? Right, Because ESM is a JavaScript standard, which means it can be used not just on Node.js but also on the web. The real question is do we want people to be able to dynamically change the caches of modules as they wish on the web? That is the big question no one's currently asking. It is a useful functionality for a local system where you have know what you can expect. But for a web based system where you can fetch from external resources from some URL you know may not own, do we want that functionality? Second, if we. If what There's a current spec being discussed where you can actually create custom modules using the module keyword and then use colons to basically create a virtual module within a singular module, if that is supported. Would we need caching for use cases people use right now? I don't know if you all are aware of the spec I'm talking about where you can. I think it's called Module Blocks.
00:34:07 - Anthony Campolo
Module Blocks?
00:34:08 - Okiki
Yeah, it's a TC39 spec.
00:34:12 - Okiki
Cool.
00:34:13 - Anthony Campolo
No, I've not heard of this actually.
00:34:14 - Okiki
Yeah, the module expressions, Module Blocks, whatever it's called, basically lets you isolate your modules into custom blocks that can reach outside the block, but basically lets you import those modules custom, as you wish. If we had this, could we allow people to dynamically create the modules they want on the fly and import whenever they wish and then have that act as a sort of caching system? So basically, instead of giving the user the ability to clear cache, give the user the ability to create custom modules and just use it directly, sort of way. Would that solve the caching issue? I don't know. I've not really looked into it all that deeply as to the goal of the spec itself. What I do know is that there's potential that in the future we can find solutions to this problem without introducing a bunch of security or whatever issues that even CJS currently has. So I'm bullish on it. That's how I term it, I guess.
00:35:20 - Anthony Campolo
Yeah, this looks really interesting. Does it say stage three?
00:35:28 - Okiki
Is this stage three already? I'll have to check stage two.
00:35:31 - Anthony Campolo
I mean I just googled or I just did a Control-F on the GitHub repo. It says TC39, stage three, being reviewed for stage three.
00:35:41 - Okiki
Okay.
00:35:42 - Anthony Campolo
Yeah, yeah, yeah.
00:35:44 - Fuzzy Bear
That's. That's the new update for us.
00:35:47 - Okiki
Yeah, but it seems like people are really interested in it. So if this does get merged, let's pray that it gets merged within the next year, because sometimes this spec has been available for the past, what, three years now. So if it gets merged within the next year or two, would we still need CJS, is the question. And if CJS still exists, why does this still exist? That's the question I would ask, because backward compatibility really isn't a good enough excuse. What's the latest LTS, it's Node 18, so it's not even like CommonJS needs to be supported anymore. It's that CommonJS is still supported because some people don't want to move away from it.
00:36:29 - Anthony Campolo
Right.
00:36:29 - Okiki
I think that's a big, big story with the Node.js ecosystem. It's not that people want to stick because there's some use case for CJS, it's that people don't want to move away from CJS in the first place. I think that's going to be the bigger issue to adoption.
00:36:46 - Fuzzy Bear
Yeah.
00:36:47 - Speaker 11
Yeah, I shared it. I shared a blog post on Bun. Bun also implemented CJS there, but Deno and Node.js also support CJS there. I think the same, like CJS is still first class there. We want to give some time to that support. That's from my side.
00:37:13 - Scott Steinlage
Cool.
00:37:14 - Anthony Campolo
Did you want to introduce yourself at all?
00:37:17 - Speaker 11
Yeah, from India.
00:37:19 - Anthony Campolo
Awesome.
00:37:19 - Okiki
Well, thank you for joining us.
00:37:21 - Speaker 11
Yeah, I added some comments there referring to Bun.js. It's a newer thing for the JS.
00:37:28 - Anthony Campolo
Yeah I've used Bun just a couple times. It's pretty interesting. Are you just using it in like personal projects? Are you running it in production anywhere?
00:37:38 - Speaker 11
Yeah, of course. And Bun also implements CommonJS support there, and they said CommonJS can be treated like a first-class citizen today. That's why, I'm sorry for my fluency. I'm not fine.
00:38:03 - Anthony Campolo
Yeah, no, we appreciate you joining us. Thank you for hopping up. Always welcome to contribute. Looks like we got the other Anthony here. What's up?
00:38:12 - Anthony Shew
Hello from other Anthony Land. What's up, y'?
00:38:17 - Fuzzy Bear
All?
00:38:17 - Anthony Shew
I'm.
00:38:18 - Scott Steinlage
I'm Anthony.
00:38:18 - Anthony Shew
I work at Vercel, and I help folks out a lot with Turborepo stuff and Turbopack stuff. And I think just listening to conversations and we think about bundlers and we think about CommonJS, we think about ESM, and it's something that's conscious on our minds when we have this conversation. I kind of always go back to when I'm helping folks with Turborepo. It's always top of mind for me. They don't want to think about these implementation details, and I personally don't. I mean, I do care, but, like, when you're building your project, you shouldn't have to care, I guess is how I should say it, right? And when I'm helping someone create an internal package, or I guess a little bit of description around how Turborepo works, right, you have packages that are in your monorepo, and you use them as if they were an NPM package, but they're just right there next to your application code. And a lot of folks end up asking me, like, oh, but I'm compiling this as ESM and I want to, but there's a downstream dependency on a CJS thing and it blows up.
00:39:34 - Anthony Shew
And when I try to import it here, it doesn't work. And sometimes it works over here. And I don't really understand all this. I'm like, okay. A lot of the time what I do is I just punt the entire problem and I say, hey, here's a pattern where you don't even have to compile that package. Just use it in your app code. And they're like, oh, wow, this is awesome. I don't even care anymore. Because you can have that consuming application bundle and compile and do whatever it needs to do as it drags in the code that it needs. Essentially, that's something I really key in on when I think about this. Is CJS bad? Does everything. Do we need to drop it, whatever, all that. It's like, okay, if we do that, like, what are the, you know, what are the ramifications on people? You know, there's ramifications on the folks that are making the bundlers for sure. Like, obviously, right? But, like, we need to go run our apps and, like, we need to make things that, you know, not even that.
00:40:38 - Anthony Shew
Those developers that are building these products, like, we're shipping, right? There's actual end users out there. And so there's actually kind of a chain of how does CJS impact our actual end users that exist? If you really want to dive deep on the conversation, that's how I always think about it. Okay, CJS matters in the context of building bundlers. Okay, now take that up a level. Take it to the developers that have to use these packages. Okay, now take that up a level. They're serving end users. To that end, when I think about, do we drop CJS, do we blow up, you know, no more CJS, ESM is the future. We all know we want that future and we know that future, but at the same time, flipping that switch is nearly impossible, right? I'm thinking of conversations that I have with Vercel customers all the time where they're like, oh, we're coming from this system that hasn't been touched in four years and it just still runs. It's on like Node 10 or whatever, right?
00:41:45 - Anthony Shew
And like, nobody's touched it because nobody cared. But, like, today we care. And, like, now we're trying to fix it. There's a lot of those out there. And, like, it's nice for us on Twitter that are really keyed into this stuff to like, want to just be like, yeah, CJS, bang it. Like, nobody needs it. But, like, there's a whole, you know, what I sometimes call "dark matter developers." Like, there's a whole bunch of people that we don't see. They're using these things that, like, we can't just, like, you know, kick into the curb. So I don't know. That's just what I always think about. Maybe that's probably going way too far with it, but I always think about it from that context.
00:42:23 - Anthony Campolo
The thing they always say is, don't break the web. I feel like dropping CommonJS support would break the web more than almost any browser API.
00:42:31 - Anthony Shew
Yeah, 100%. And that's kind of where, sorry, that's kind of where I come in with, like, oh, I love what Bun does. We're just like, I don't have to think about this anymore. And the way that I try to describe that internal package pattern for Turborepo users is like, just don't think about it. Somebody else is going to do it, hopefully.
00:42:53 - Okiki
You know, I mean, yes, of course. I think when we say dropping CJS, we have to determine what we mean by that, is the question I would ask. Let me say drop as in permanently stop Node.js from supporting CJS, or dropping it as in heavily discouraging it. I put a warning whenever someone uses a CJS package that says that CJS is no longer the preferred way of doing module resolution. Because if it's the latter, that would be much easier, especially for older packages and older projects to slowly migrate over. Given, let's say, we're going to drop it in the next 10 years, we'll fully drop it in 10 years' time. That gives people more than enough time to migrate the packages over. Assuming this isn't an IE situation where people are still using IE to this day, it gives people the time to drop it. But the key thing is new packages are still written in CJS. So that's going to be a problem if you ever want an ESM future. So I guess you have to determine, are we talking the first one where it's stop CJS from being supported in Node.js at all, or the second one, which is say we're going to deprecate in 10 years' time, but slowly wean people off CJS in the first place and avoid new packages being written in CJS.
00:44:11 - Bro Nifty
We got some heavyweight Vercel muscle in here. I just wanted to agree and amplify and also add to Anthony's point about the long-tail effect of the dark matter developers and whatever. I think in tech Twitter we have a kind of bias, maybe survivorship bias. People are so keyed in, like you mentioned. And I think the things that we talk about, what we're doing, are really on the more advanced end of the spectrum. So sometimes maybe we overlook that. I think what we see around us, what we see people talking about, is always the most advanced, cutting-edge stuff. So maybe we have a little bit of a bias and sometimes we may forget about it. So I just wanted to add that. Thanks.
00:45:00 - Anthony Campolo
What's up Jess?
00:45:01 - Jess
Yo, what's up? I think I know quite a few of you. I know at least three of us on speaking are library authors. Who else is a library author on this call?
00:45:15 - Anthony Campolo
Am I vaguely a framework devrel?
00:45:22 - Jess
So my beef, I have beef, is when library authors write CJS and they don't support ESM and they expect some magical bundler to just handle it. And this is, you know, Turbopack and webpack. Actually, Anthony, question. Does Turbopack treat CJS the same way that webpack does? Like, it just figures it out?
00:45:51 - Anthony Shew
Turbopack is, right now at this moment, it kind of just automagics everything. So yes and no. I don't want to speak to the, I guess, is what I'll say.
00:46:04 - Jess
Okay. Okay. So as, as of right now, it's like, compatible with the way that webpack handles module exports, right?
00:46:11 - Anthony Shew
Yep, yep, yep.
00:46:13 - Jess
So near-compatible. Very good. A lot of library authors just write CJS and expect downstream that the user is going to be using webpack, and it's really bad. So we had this problem at Cypress where Cypress would just have a default compiler of webpack. And all of a sudden we were like, okay, but this project uses Vite, and Vite is the entry point for all of ESM issues. It really brought them to the forefront. I'm probably late to this discussion anyway. You already talked about all this, but yeah, once we started supporting Vite as the bundler, all the issues started coming in from other plugin authors. Anthony, go for it.
00:46:59 - Anthony Shew
Oh, no. Did you have more continue.
00:47:02 - Jess
No, go for it.
00:47:04 - Anthony Shew
Oh, so, yeah, I was actually going to make almost the same point. I've actually seen authors that thought they were publishing ESM and thought they were handling everything correctly. And it was like, oh, uh, sorry. Actually. And something I think about all the time is, oh, my gosh, why is his name escaping me? Mark. Mark Erickson on the Redux team. He has been very open about mentioning that. He's like, yeah, like Redux, you know, contextually, is not necessarily a legacy state work state manager, but like, people still use it in new projects and stuff like that. He has a large surface area to cover and he talks all the time about if I want to cover everyone that wants to use Redux, like, he has to just do magic. He's got. I think he has a blog post maybe, or. But he's got a pretty sticky tweet that still pops up.
00:48:08 - Jess
So, Mark Erickson and I, that blog post comes from a rant that he and I had in January or February where we talked for three hours about the history of bundling in my kitchen. We were just on a call, just talking about life, and life eventually led to CJS.
00:48:30 - Anthony Shew
As is tradition.
00:48:32 - Jess
As is tradition, we were talking about concatenating files to get all your code into one script. Like all these. All these fun things we used to do back in the day. And he came out with that blog post at the end, Anthony, and it's really good and in his style it's like a 20 minute blog post. And you will learn so much. There's a tweet, actually, Anthony, what I thought you might mention is Dax's. I think it's Dax's tweet on if your library works on ESM. So I'm going to try to dig that up and we can pin it. Let me hunt on the Twitterverse. It's going to take a while for me to find it and give me a bit.
00:49:14 - Speaker 13
Oh good.
00:49:15 - Anthony Shew
But yeah, where I was going was we have all these various bundlers that want to do all of these things, and now we have this weird split where folks want to get to ESM most of the time, right? And sometimes a library author is like, oh my gosh, I'm kind of new to the game and we're starting to get all these users and I'm finding out now that I didn't do it right. And that's something that I feel like compilers and bundlers can get better at. And that's something specifically that with Turbopack we're trying to get to that world where it's like, oh, it just is, and solving the Mark Erickson pains of the world.
00:50:03 - Jess
I'm curious if people have thoughts on tree shaking and CJS and ESM.
00:50:08 - Okiki
I've got a lot of thoughts. Tree shaking doesn't exist with CJS, straight up. That is not a thing, because it's not statically analyzable. You can't figure out how to separate out packages. So it basically all ends up CJS. And even esBuild, which esBuild stuff is very clean, it's just webpack code. Basically the webpack spaghetti is what I call it. That's how you have to support CJS, any CJS package of any kind.
00:50:39 - Jess
There are a lot of packages that are not easily tree-shakeable, like Redux or RxJS, because they're chain based. So if you have that chaining pattern, that's a really good way to tell if a library is going to be easily convertible from a CJS bundled output to an ESM bundled output. Faker has this problem because it imports all of English, all of the fixtures. So Faker.js is, for people who don't know, a cute little library that generates random strings. So everything from lorem ipsum to company slogans that sound like hacker bullshit to GitHub SHAs. It's a really useful little thing, but it needs locales and imports the entire world. It's like two megs, but you only ever use it in dev, so nobody cares.
00:51:41 - Okiki
Actually, I think that's specifically a class thing. Classes are not tree-shakeable generally, but even more so if your entire package ends up being just a single class, then tree shaking isn't going to work in any package system you use. Yeah, in order for it to tree shake properly, you just need to understand how your stuff will be used, and classes are just not isolated enough generally to be tree-shaken out properly. So yeah, but for CJS, your entire package will just never be tree-shaken ever.
00:52:20 - Speaker 11
Cool.
00:52:21 - Anthony Campolo
Scott, you want to hop in with a station break?
00:52:24 - Scott Steinlage
Yep. I was actually just thinking about that. Thank you so much everybody for joining us today. This has been awesome. Lots of great conversation. I love it when everybody really comes up and participates. In fact, that's what we always say. Whether you're a beginner, whether you're, you know, been developing for a long time, it doesn't matter. We want to hear from everybody, so please feel free to request, come up, state of fact, opinion, statement, whatever. We love to hear it. Why? Well, it creates more value for everybody in here in the room and we just have a great time. So thank you to everybody who has. By the way, if you've gotten value from anybody up here now or earlier, please feel free to click on their icon there and follow them. Because I promise you, if you got value from them here, I'm sure you're probably gonna get value from them in other places. So make sure you do that. All right, thank you so much. And oh, one more thing. If you're not subscribed to our newsletter, go to javascriptjam.com subscribe to our newsletter and follow the other hundreds of people that have already done it.
00:53:28 - Scott Steinlage
Don't miss out on the latest in JavaScript and web development. Anthony puts a lot of time into putting those together and making it happen. All right, y'all, thanks.
00:53:40 - Fuzzy Bear
Word.
00:53:41 - Anthony Campolo
So we had an awesome panel. Do people want to kind of take this another direction? Add more thoughts about the current topic? Kind of open to whatever.
00:53:50 - Jess
I found that tweet. We can change topics. I just wanted to send it at least to Anthony. Let me figure out how to find this on my phone. Phone again, but, but I'll pin it up, I guess.
00:54:03 - Anthony Campolo
I'm curious, does anyone think this Deno blog post is going to actually matter in any sense of like the conversation or the trend?
00:54:11 - Okiki
Yeah. So the Deno blog post isn't wrong, but I guess it's lacking empathy, is the way I would best phrase it, because it doesn't really understand some people are stuck with CJS. It's just like if you're stuck using PHP, you're stuck using PHP. There's nothing you can do about that.
00:54:27 - Fuzzy Bear
Right.
00:54:28 - Okiki
If your codebase is legacy, it could be legacy, and we can't start throwing people under the bus like that. But at the same time, you also have to understand that new projects being created shouldn't be using legacy software or legacy ways of developing. They're legacy for a reason. Just like how most people don't use IE nowadays because IE is legacy for a reason, you know? So it lacks a bit of that empathy, a little bit of understanding for Deno. It works, but it doesn't really help a lot of people in the broader ecosystem by being nuanced in the discussion, which is, I guess, the problem with it.
00:55:08 - Bro Nifty
I agree with. Okay, hard, hard to say name.
00:55:11 - Okiki
Ok. Yeah.
00:55:13 - Bro Nifty
Yes, hi, I agree with you on the new project thing and I think Deno is coming from it from a perspective of they have this utility they built, dnt. It's like this command-line CLI that, according to the description here, transforms your ESM into an npm package that supports CJS and ESM compatibility. So I think they're coming at it from a position of you could just use Deno as the runtime and then whether you're CJS or ESM, it doesn't matter. And then just write all your modules for libraries in ESM. So that's my take on it.
00:55:52 - Okiki
Yeah, that's about right. Yes, that sounds right. Yeah, but you're still publishing new packages with CJS stuff, even with dnt, right? So it doesn't really solve the problem because other package managers and webpack still publish CJS. So you still get CJS in your codebase.
00:56:15 - Bro Nifty
Yeah, that's valid for Node though, right? We're talking about Deno. Deno doesn't need that.
00:56:21 - Okiki
No, but DNT still publishes CJS.
00:56:26 - Scott Steinlage
Okay.
00:56:26 - Bro Nifty
Yeah, you, you get, you got me there. I don't know all the, all the details.
00:56:30 - Okiki
Well, I mean, I think you can disable it, but the vast majority do not disable it. And dnt is meant to get your Deno projects to work in Node, and if it publishes CJS, then it doesn't really solve the problem as much as make the problem more convenient to deal with. So, you know, it requires a larger Node.js-specific conversation because Deno is doing good stuff on the Deno side of things. In fact, I would even go as far as to claim that Deno's package management system is better than NPM, but has some flaws. That's how I'll best term it. Hot take. What are your takes on that?
00:57:15 - Bro Nifty
Yeah, I agree. I agree. And I think, I think it does come back to what you're saying is true.
00:57:20 - Dax
And also.
00:57:21 - Bro Nifty
And Mateo, it's kind of my shelling point on the Node question. What Ryan's doing with Deno is kind of like a sort of
00:57:32 - Okiki
like, I don't know if you want
00:57:32 - Bro Nifty
to call it a hard fork of Node and just bring it into a totally different direction. But anyways, it's a new system. It's kind of like the old system, but different. Anyways, but yeah, if I could characterize Matteo, most respectfully, he's kind of strong-arming the JavaScript ecosystem a bit, which is fine. I mean, I believe in strong leadership. So if you want to do what you want to do, you got the vision, go for it.
00:58:05 - Okiki
But.
00:58:06 - Bro Nifty
But yeah, it is a bit of a strong arm attack tactic there.
00:58:09 - Okiki
But.
00:58:09 - Bro Nifty
And he is doing everything. Ryan is doing everything Deno centric. So it's, it's not. I don't think he's really. But yeah. But anyways, otherwise, all the other stuff, I agree.
00:58:19 - Scott Steinlage
Well, I can say it definitely got people's attention. And I think that's also part of the point of it too, a marketing perspective.
00:58:30 - Okiki
I think Deno sort of cuts itself off at the knees by the way they market themselves. By calling themselves the Node.js competitor, they sort of frame the game in the wrong sense of the word because Deno is very different from Node.js in the way it works. It is way more web-like than Node.js can really ever be. It's just way, way more web-like. And in that way, by calling themselves a Node.js competitor, they set expectations wrong. So if you're coming from Node.js, you're used to all the Node.js APIs, used to all the way Node.js works, and you come there and you find out you have to use -A or whatever, or you have to do permissions for all your commands, and now you have to use deno.lock or deno.json to do all this stuff, it will throw people off. And I think they're marketing themselves as a Node.js competitor instead of just a different runtime entirely.
00:59:29 - Anthony Campolo
What should they market themselves? Do you think they should just market themselves as like a JavaScript runtime?
00:59:35 - Okiki
Yes, like separate, completely separate from Node,
00:59:38 - Anthony Campolo
but like Bun has done.
00:59:41 - Okiki
Actually, I think also Bun cuts itself out, and they have the potential to do some really great stuff, but they're supporting some of the things that Node does that cause issues in the JavaScript ecosystem, one of which is setTimeout. They're doing it the Node way and then supporting some of the Deno ways, some of the web ways. The problem is the Node way is completely incompatible with any other runtime. So by supporting the Node way, the entire reason why it supported the Node way is to keep backward compatibility again. But all it's done is cement that API, because once you've created the setTimeout API, you can't change it anymore. It's one of those set-in-stone ones. And by supporting the Node way, it's just becoming Node, but faster.
01:00:30 - Jess
Can you dive into the differences between the Node way and the Deno way for people who are not familiar?
01:00:38 - Okiki
So the Node way, oh, sorry, the Node way is very focused on legacy. So back in the day, a bunch of stuff that wasn't supposed to exist, from my understanding of the history of it, is V8 only comes with certain features, like the runtime alone. If you separate the runtime away from DOM and everything like that, it only comes with certain features. And to implement those features at the time when Node.js was created, you had to implement those from scratch. So Node.js took its own route. Instead of doing the browser way, it implemented setTimeout and all these other APIs in different ways for Node.js. And because of that they've set some of these APIs in place, guaranteed, where they can't change it anymore because they can't ever be compliant with the way the browsers work.
01:01:25 - Jess
So I get that. What is the actual difference between the spec, between how they implemented it?
01:01:36 - Okiki
So from my understanding, setTimeout, when you use it, in Node.js it returns an object. But on the web and on Deno, it returns a number.
01:01:49 - Jess
Got it. So literally the return type is different and how you would cancel the setTimeout is different because of the implementation reasons they're looking for in different runtime environments. So if you're looking for a lighter weight implementation on V8 engine versus browser, you're going for one optimization, one design decision versus another. Is that about right?
01:02:10 - Okiki
Yeah, basically.
01:02:12 - Jess
Cool.
01:02:13 - Okiki
Yeah. So that's how Bun going the Node way guarantees that whatever Bun does now has to be Node-compliant. It now has to be, otherwise why go the Node way? So they've locked themselves into this so they can have some level of browser compatibility, but they're still locked into that Node-like system. Any mistakes Node makes get locked in now, which means that Bun can never really distinguish itself, separate itself away from Node.js. It's always going to be just like Node.js but faster. People can use Bun because they enjoy using Bun. It's just that it's Node.js but faster. And if you're a company looking into using a runtime, a JavaScript runtime, why would you use Bun for development or anything like that if Node.js is more compatible and it's the stable version?
01:03:05 - Fuzzy Bear
Right.
01:03:07 - Jess
I mean, a lot of the optimizations that are happening over at Bun are really made for the edge. Right. That's a lot of what Jared's working on. And also fixing the testing story, both Deno and Bun are pushing Node. I love that story. Right. Where Deno and Bun make innovations and then that comes back to the node group and they're like, oh yeah, shit, we should actually have official testing support. I like that feedback loop.
01:03:36 - Okiki
I like that as well. But unlike Deno, which is distinctly different, it can isolate itself from all of those decisions, right? They can very much isolate themselves from all of Node.js's decisions and make their own path. Bun cannot anymore. They've locked themselves in, otherwise they would have a completely different compatibility table. So, like, if they don't do the Node.js way, when you develop an application in JavaScript, you now have to think of it, hey, Node.js and Bun work differently. If they don't stick to the Node.js way because of that, they're guaranteed to stick to the Node.js way to avoid people having to think about that. Does that make sense?
01:04:19 - Jess
Oh, 100%. For setTimeout, that's the only one. You have defaults, right?
01:04:24 - Okiki
Yeah, there are a couple more APIs that they've implemented in Node.js. SetTimeout was just the one where those other ones were iffy, but you can work around those. The setTimeout one was when I was like, yeah, they've locked that one in place. That's when I knew they'd locked it in place, that wasn't changing anymore.
01:04:42 - Jess
I wonder why. I wonder why Jared decided to do that. I mean, like, that.
01:04:48 - Anthony Shew
That was exactly the question I was about to ask.
01:04:51 - Okiki
I should ask the. The reason, if I remember correctly, was backwards compatibility. But, you know, I don't know.
01:04:59 - Jess
I don't know. And why did. Oh, I'm sorry, Anthony, just go for it?
01:05:04 - Anthony Shew
No, I was. I was just thinking to myself as you guys were going back and forth, I was thinking to myself that, you know, we're thinking of this at a technical level, I think, a lot. And Jared has a. Has product decisions to make. Right? Like, that compatibility table really is a product decision. You know, does he want to do setTimeout the Node way?
01:05:28 - Fuzzy Bear
Right.
01:05:28 - Anthony Shew
Like, that's a question that, fundamentally, 10 years from now, when somebody's thinking about Bun, does he want them thinking of that in the Node.js way? To Okiki's point. And there's an adoption curve that Jared's probably looking for. Is it the hockey stick or is it just that slow upward trend, not a straight line, but you know what I mean?
01:05:58 - Jess
Right.
01:05:58 - Anthony Shew
And, you know, so I think the other thing, too, is that, to Jared's point, I feel like I've seen him specifically here on Twitter. I don't really get to follow Bun around too much, but I've seen him a lot, like literally just ask people for their projects. And I've seen him be very, very thoughtful about going through gigantic projects and then small ones and understanding different ways that Zig can handle these different things. And so it's been interesting to watch him make all of those product decisions, particularly against the way that Deno has been going about it. And the other thing that I was thinking about was Jess mentioned that feedback loop of, like, Jared proves that Bun can do something that Node can't, or it does it just a trillion times faster or whatever, and then Node has to hop on their horse and try to chase that. That, to me, is the real story when you're thinking about enterprise systems. They're probably never going to leave Node because they literally can't at this point. So that, for me, is the real story, like someone came along and pushed everyone to be better, which I personally think is the part that I love about all of it.
01:07:18 - Okiki
The issue there is, like, it's cool that you're pushing Node.js to get better, but that's not going to help Bun's adoption.
01:07:26 - Scott Steinlage
Right.
01:07:27 - Okiki
If Node.js has all the features Bun has, it's got the enterprise usage, and lots of people know it already, why would people switch to Bun? Kneecapping it kneecaps Bun's growth early on in that sort of way. You know what I mean? Like, if you created some new feature and then everyone, the bigger competitor, copies that. Think what Facebook did with Stories to Snapchat. They copied that. Why would you go over to Snapchat now if one of the key features is now on the big competitor?
01:08:05 - Anthony Shew
Totally. Yeah.
01:08:06 - Scott Steinlage
And.
01:08:06 - Anthony Shew
And that goes back to, for me, like I was mentioning, what's the adoption curve that you're looking for as a team? A lot of the time we have this kind of ugly habit of more people right now all the time, right? And maybe for Bun, what Jared is chasing is, like, oh, let's make that slow march upward instead of like, I'm going to go capture every single person that I possibly can. Maybe the approach really is, like, I'm trying to think of just some random company, Disney has all these Node apps. I'm not trying to capture all of their Node apps. Instead, I would like for them to, when they make a new Node app, it's not a Node app anymore, it's a Bun app. There's that idea, right, that do you want to just grab everything you can and be really aggressive about existing things, or do you want to capture all those net-new things? I'm silently staring here at this, actually kind of ties into this. I'm silently staring here at this CommonJS is hurting JavaScript on my monitor and just staring here at the title.
01:09:20 - Anthony Shew
And I'm thinking to myself, what if somebody came along and was like, file system extensions are killing Linux performance or something? And it's like, y' all should change. It's like, okay, well, like, that sounds great. Like, yeah, it might be a trillion times faster or whatever, but I got stuff to do.
01:09:42 - Scott Steinlage
Write it up. Just write it up.
01:09:47 - Jess
Yeah. I mean, at the end of the day, we're all just trying to ship applications and maybe setTimeout isn't going to be compatible in one runtime version versus another. But I'm gonna, you know, maybe take that 200 milliseconds in a very bad case, right? 200 milliseconds additional startup time from a cold start or warm start, whatever the fuck we got now. And, and I'm gonna bill my employer and tell him if he wants, you know, three months of dev time, he can have those 200 milliseconds and a few n thousand dollars back. Those are the trade offs that I'm making as an application developer when I'm thinking about A versus B always. So in the end none of this actually matters and our opinions are kind of moot. Right? That's the nihilistic approach.
01:10:50 - Okiki
Sorry, sorry, Fuzzy, you can go first.
01:10:52 - Fuzzy Bear
Oh no, I was just agreeing with Jess. The conversation is very circular. The question I'm thinking is, how much parity do you need on the server between the web and the server? How close is that line going to have to be? Back in the day the idea with Node was that it's going to be distinctly different to the code that we write for the web. Now we're kind of moving into a paradigm where that line is getting dropped. It's like the web standards are now moving into the server side. And that barrier is something that I'm looking at as a differentiator between the different runtimes in the marketplace.
01:11:41 - Okiki
So I think what actually happened there was back in the day when you installed any type of library to the web, jQuery, Lodash, any of those, you would use a CDN to do it. You'd do some sort of CDN, put it into a script tag, load it, that's how that would work. But NPM started to gobble up that service area there. It started to gobble it up, Rollup came in so you can actually tree shake your packages, so only what you need is being used. So all these things started coming in and started removing all the areas where CDNs and stuff would have actually previously been it. And because of that, Node.js now has to be compatible with the web if you want all these third-party packages that people rely on on the web to work. That's the reason why this is occurring. If prior to now Node.js was separate, and all these packages were being released as CDN packages still, I don't think this would be as big an issue as it is now.
01:12:48 - Jess
Can I ask a quick question, just to make sure I understood what you just said. Are you saying, like, if jsdom was shipped natively in Node, we wouldn't be where we are today?
01:13:00 - Okiki
No, rather the opposite. So if jsdom released a compatible package on CDNJS and other compatible CDNs, then we wouldn't have as much of this problem, basically. So if packages and package maintainers created packages explicitly for the web and then created ones explicitly for Node.js, like they're distinctly separate, then you would have less and less of this, hey, I want Node.js packages working on web.
01:13:39 - Jess
Yeah, okay. By the way, people do this, and webpack polyfills. I have a whole rant about how webpack has enabled this problem to proliferate. But yeah, I've debunked packages that are like import fs and I'm like, bro, you're in the browser. The fuck you mean import?
01:14:05 - Fuzzy Bear
Yeah, I've seen that though.
01:14:07 - Okiki
Yeah, I do like that there are a couple new APIs coming out that would make polyfilling much easier. I'm really excited for OPFS, Origin Private File System. I don't know if many people on the call are aware of what it is. Origin Private File System and anyone aware of what that is.
01:14:31 - Bro Nifty
Chrome links to your desktop file system.
01:14:35 - Okiki
No, that's. That's what makes it so distinctly different. It lets you create a virtual file system where the files are actually saved on the hard drive and not in memory.
01:14:45 - Jess
Bro said, I think. Is that what you said, bro?
01:14:50 - Okiki
Yeah. That allows you to have your file system APIs. You can actually polyfill node and Deno's file system APIs using OPFS and guarantee that it's not being stored in memory and you can access it whenever you want to.
01:15:09 - Jess
That's pretty cool. That would make a lot of things easier for a lot of libraries that currently talk over the wire to some specific server that they've set up just so that they can get around the privileged access requirements, especially in dev tools.
01:15:24 - Okiki
Yeah, yeah. It is incredibly useful, but the people who know about it and actually use it are very few and far between. I know that the Adobe web app is using it right now. It's one of the apps using it. SQLite, the SQLite WASM library, uses it as well. There's a bunch of libraries that use it that people don't realize just how useful this little API is for emulating Node.js environments.
01:15:51 - Jess
I saw Nick just joined. Nick, this is a pretty interesting API that you might be curious about for, I don't know, doing weird shit with testing and file systems and reporters and stuff. It's kind of a curious little application that you could, I don't know, I wonder where it fits in. For those that, that don't know him, Nick McCurdy is a testing library maintainer and nerd and we, we talk about weird shit and how it applies, how you can leverage weird APIs to make the testing ecosystem better in general.
01:16:28 - Scott Steinlage
Yeah, I invited him up.
01:16:31 - Jess
It's okay, I can just speak about him. Oh, welcome back, Fuzzy. By the way, I feel like we diverged from your original question. I felt a little bad.
01:16:45 - Scott Steinlage
Can't take the silence. Thanks for joining us.
01:17:00 - Fuzzy Bear
I missed that last bit. Sorry, what were you catching up on? If you could just bring me up.
01:17:06 - Jess
Oh, I said that I feel like we diverged from your original question about pushing, I don't know, all the, all the code we write towards the server.
01:17:16 - Fuzzy Bear
Yeah, no, that's what it feels like. There was a fork when it was like the greatest thing that happened to JavaScript was it could move outside the browser, but then it allowed JavaScript to become something more ubiquitous. But within that ubiquity, we're kind of seeing a pattern — a simplicity arising — where we are now pushing towards web standards, the standards coming out from the more proactive TC39 group and the web standards group. And I enjoy the fact that we're now adopting a more standards-based approach to our own development instead of, you know, "this is my own magic compared to what everyone else can produce." And I like it in that respect. However, what I'm seeing is that within the simplicity, we are now coming to a point where everything's going to start looking the exact same, if you get me.
01:18:27 - Jess
Hmm. I don't know. I don't know. I don't think we're ever satisfied. If I've learned one thing about web development and development right, nobody's ever satisfied the status quo.
01:18:43 - Fuzzy Bear
I'm kidding.
01:18:48 - Jess
I'm proud of the standards bodies learning how to ingest ideas from the communities. Like, you for sure know that Solid is working closer and closer with the Chrome dev team. And so we're kind of wondering, like, they just got, what was it, like, I think Ryan is public about this. They just got, I think, enough runway to hire two full-time developers, international developers, non-US devs, to work on Solid. And that's awesome because that means Google's paying attention to what's bleeding edge and deciding explicitly if they're going to adopt or not adopt different things. But I still don't think, Fuzzy, that we're gonna converge on like a one, two way. Like, we can't even figure out if we like utility classes or not. Still a joke for everybody.
01:19:42 - Fuzzy Bear
I don't appreciate that. It's like the trifle for those physicists trying to get the unified field theory together. And you know, it's one of those lost causes. But the thing is, it's more of a feeling than anything else when I look at this and it's like looking into my magic eight ball. But I do get a sense that there is going to be a day in the future where the web as we know it doesn't live on the browser. The applications that we develop don't exist in two spaces — on the server and on the client. That is going to be an isomorphic space, a single space where you could code from the back end and still see on the front end, but it's going to be a single.
01:20:41 - Jess
That's fundamentally impossible. Like I agree for many applications that might be the case. Many verticals can do that, right? But you have to have an always, you have to have an always online connection. Like what are you going to do when you go offline?
01:20:56 - Okiki
Okay, so I've got a hot take on that. So the idea of needing always-on connection, I think over time that's been proved less and less true with the APIs being made available. Even BundleJS currently does not need to touch, well, it does to a certainty, but once you've run whatever bundle you want to run, once it caches that and you can run that bundle again and again and again and get all funky with it and stuff like that, it will still give you new bundles once it's fetched the packages at least once before. I think more and more, especially with these new APIs coming out like the OPFS, WASM, SQLite, all this stuff coming online, you're going to actually need less and less network connections to accomplish complex tasks. Right. Even right now you run FFMPEG on the web, right.
01:21:51 - Jess
So like, I mean, it's slow as.
01:21:56 - Okiki
That is true. That is true. But like every technology, it improves.
01:21:59 - Anthony Campolo
Right.
01:21:59 - Okiki
So if you give it time and there is definitely an intention to make these APIs better and create better and better projects from it, you're gonna get less and less stuff being done from a server.
01:22:13 - Jess
Yeah. The movement for clients caching. For clients caching so they don't have to reconnect. I get that. All I can think about, okay, is all I can think about is getting on the New York subway with my Ionic app. That's all I can think about, right. Is just being like, you know, Spotify built their app in Ionic. They, they didn't. They don't. But you know, let's pretend Spotify builds their app in Ionic and I'm just like, I can't load my loading spinner because it's an RSC or whatever the fuck we've done. That's, that's all I can think of. And I don't know if I just don't understand RSC after five months, which is possible, but what am I missing?
01:23:00 - Okiki
So you're not wrong. Technically, RSCs are more efficient in the way they deliver the JavaScript required or HTML required to actually accomplish your site and application. They're more efficient — almost just-in-time rendering your site as required, even more so than previously because it has full understanding of all the components being used, complete understanding of it. It understands those dynamic network connections being needed, understands the connection to your database. It understands it and it can be very dynamic with it. That is both a good and a bad thing based on the example you just gave, for that exact reason.
01:23:45 - Jess
So, different applications. So we're still, I'm so excited for this, guys. Are you ready? It depends.
01:24:06 - Okiki
I would say it's nuanced, right? If your application is already heavily web based anyway, then have like no matter what, if the connection goes down, the connection goes down, right? There's some applications just already. If you're doing like think already. If you're like remote viewing into your computer, that's a very, very narrow connection required application. So no matter what. Even if using React server components, if you're writing pure HTML, you're going to need a network connection, and so it doesn't really change much. If you're writing like a blog post, then using RSC and not compiling to pure HTML is overkill is how I term it, I guess.
01:24:48 - Jess
Yeah. So, Fuzzy, I think we're at it depends on your product vertical. Maybe we'll converge for different problem spaces. Like e-commerce might converge on something specific, but it depends.
01:25:04 - Fuzzy Bear
I appreciate that, Jess. You're kind of spot on there. Yeah, you're spot on. How are you keeping, by the way?
01:25:15 - Jess
How am I doing? Yeah, I'm doing good. When we were so I met Fuzzy and modern front ends, the conference that shall not be named and that I just named. And he very kindly gave me a very tacky looking white lighter which is. Has emojis on it. And I see it every once in a while among my. My clutter. I stole it from him. But no, it was. I'm doing. I'm doing great. My brain surgeries are scheduled for later this season, so I wish you all
01:25:54 - Fuzzy Bear
the best of luck.
01:25:54 - Scott Steinlage
Would I just.
01:25:56 - Jess
Yeah, I'll post on Twitter. I'm very excited. I'm going to be a cyborg, probably.
01:26:02 - Speaker 13
Are you getting ChatGPT 4?
01:26:05 - Jess
I'm.
01:26:05 - Scott Steinlage
What?
01:26:06 - Speaker 13
Are you getting ChatGPT 4?
01:26:09 - Jess
I don't know. It has. It does have a CPU and data store, so.
01:26:19 - Okiki
That's gonna suck if you're only limited to 25 questions an hour, though.
01:26:26 - Anthony Campolo
Put a bitcoin miner on it.
01:26:29 - Jess
Bitcoin miner jacked straight into the brain. No, but it's really interesting. It has a record mode that records different electrical signals on three probes. There's a deep sensor and a shallow sensor. In total, there's like 16 little notches, and I'm pretty excited. Apparently some of the testimonials are like, using this data, my neurologist was able to determine that drinking orange juice in the morning triggered my seizures. So for everybody.
01:27:03 - Dax
Whoa.
01:27:04 - Jess
Yeah, people. Yeah, I have epilepsy. I have really bad seizures. Yeah. So I'm really stoked to. To see what happens. I've already been told I can never go to defcon once I get this thing in. Yeah.
01:27:21 - Okiki
Yeah.
01:27:25 - Fuzzy Bear
The moment people realize, right, there's a walking Seven of Nine about, they're going to try and hack the Borg.
01:27:30 - Anthony Campolo
Yeah.
01:27:30 - Jess
No, thank you. I won't. I will not be in 50 miles, 100 miles of DEFCON.
01:27:35 - Okiki
If you.
01:27:35 - Speaker 13
If it makes you feel any better, there's that one guy that, like, went to DEFCON because he knew FBI agents would be there. So he went dumpster diving and managed to figure out that FBI and CIA agents were discarding confidential documents
01:27:55 - Jess
and
01:27:55 - Speaker 13
he just ran them. So, yeah, I'm not exactly confident everyone at DEFCON is perfectly secure.
01:28:06 - Jess
I would be one of those people that is not people. Okay? So my habit is breaking into things — mostly legal. I don't do it now that I moved to Texas because I know better. Fuzzy. If you're wondering, Texas is the most America America that there is.
01:28:27 - Fuzzy Bear
California is very gentrified and very, like, you know, blah.
01:28:32 - Jess
It's. Yeah, I would say, yeah, it depends. But Texas is generally a monoculture. And legally, like, when you trespass, it's bad. Like, people can shoot you at any distance. So I don't trespass here. But in general, I like being where I'm not supposed to be. And my favorite hobby is breaking into WeWorks and tailgating in. Yeah, that's my black hat attribute.
01:29:01 - Fuzzy Bear
Hats off to you for that. Like, seriously, breaking into WeWorks is. Should be done. Those guys have ripped off enough people.
01:29:09 - Anthony Campolo
Did you.
01:29:10 - Speaker 13
You know, this reminds me of, did you see the LockPickingLawyer's Ben and Jerry's ice cream video?
01:29:16 - Anthony Shew
Oh, my gosh, I love that guy.
01:29:23 - Speaker 13
So he wanted his wife to. So if anyone not familiar, this guy is like an absolutely very talented lock picker. And he does professional grade lock reviews with lock picking attempts on YouTube. And it's all legal, it's all property that he owns.
01:29:40 - Anthony Shew
And he's a lawyer, so he knows.
01:29:42 - Speaker 13
Anyway, he's also hilarious. And he wanted to teach his wife how to lock pick, so he put a Ben and Jerry's pack, apparently it sells a combination lock that closes the top of the lid. So he put it in the freezer and the next day he found it flipped upside down and his wife cut off the bottom of it, just completely ignoring the lock.
01:30:14 - Fuzzy Bear
That's what I'm like, honestly. Yeah, it was like. That actually brings me up to like an actual story. We were like, don't ask why. We were trying to get into a house. Right. And it was. It was a new build as well. So it was like. It's kind of like these American houses where everything's made of wood. But over in the u. In the. In Scotland, you know, it's like we have masonry and we have plasterboards. Right? So, you know, it's like they had this side panel next to the door that was just plasterboard. It wasn't like masonry. So the moment I, like, I was just chopping around the door frame, I was like, oh, that's plaster. Put my foot through it. We were in the door. We were through the side of the door.
01:30:52 - Jess
Kool-Aid manned that door.
01:30:59 - Fuzzy Bear
We did. That was funny when you said that.
01:31:02 - Anthony Shew
Yeah.
01:31:02 - Fuzzy Bear
All right. No, I mean, it was like there was alcohol on the other side of the door. So I was the only reason.
01:31:08 - Jess
And you're. Yeah. Okay. That's. Culturally, it's a requirement.
01:31:17 - Scott Steinlage
I just want to say thank you, everybody, so, so much for hanging out. Thank you so much for contributing all the amazingness that you all have. We crushed it today. It was fun. Like, seriously, there were some really good, valuable conversations that we had today and insights, and hopefully CommonJS, I don't know, maybe we can just figure this all out and get along, but yeah.
01:31:45 - Fuzzy Bear
No, it deserves to die in a fiery pit in hell.
01:31:49 - Okiki
Well, you don't want to throw some of the legacy applications people have into issues. I would say maybe the goal should be, instead of getting rid of CJS, change its priority. So ESM comes first, CJS comes second for projects.
01:32:04 - Okiki
You know what I mean?
01:32:05 - Anthony Campolo
So Fuzzy wants us to not just kill CJS. He wants us to kill the people using it, too.
01:32:20 - Scott Steinlage
Little hostile.
01:32:22 - Jess
He doesn't need to say it. We all just know he'll bust through the door like Kool-Aid Man at our American houses. Just not in Texas. Please.
01:32:34 - Anthony Shew
The last thing you'll hear is waka waka waka.
01:32:43 - Scott Steinlage
That's funny. That's awesome.
01:32:46 - Jess
Thanks, guys. Bye, everybody.
01:32:48 - Scott Steinlage
Thank you so much.
01:32:51 - Okiki
Bye.
01:32:52 - Scott Steinlage
Appreciate y'all. All right, see you in the next one, y'all. Every Wednesday, 12:00pm Pacific Standard Time. We will be here.
01:33:01 - Fuzzy Bear
Guys, can I just quickly give a shout out to Bryce, right? He's been recently made a maintainer in the Astro community.
01:33:07 - Scott Steinlage
Right? Yeah. Yeah.
01:33:11 - Anthony Campolo
So nice.
01:33:12 - Scott Steinlage
Awesome.
01:33:12 - Fuzzy Bear
Much love, Bryce. Well deserved, well earned.
01:33:15 - Scott Steinlage
Bryce. What's up, man? Good shout-out.
01:33:21 - Fuzzy Bear
Actual legend.
01:33:22 - Scott Steinlage
Follow for more info on that.
01:33:27 - Fuzzy Bear
Yeah. Peace and love, guys. People. Stay safe, you two.
01:33:32 - Scott Steinlage
Thanks, man. Appreciate it.
01:33:35 - Fuzzy Bear
Love you all.
01:33:37 - Scott Steinlage
Same. All right. All right, y'all, that's it. That's a wrap.
01:33:44 - Anthony Campolo
Don't forget to click those faces and follow.
01:33:47 - Scott Steinlage
Click the faces that you got value from and follow them. If you don't remember who they were, you can listen to the recording and check it out. All right. Yeah. We will see you live on the next one. In the next one. All right. Thank you all. Love you. See you in the next one. Peace.