Shopifys WASM Enabled JavaScript Functions and Lambda Cold Starts

Episode Description

JavaScript Jam explores Shopify's WebAssembly-powered functions, AWS Lambda cold start benchmarks, blockchain payments, and the React.js documentary.

Episode Summary

This episode of JavaScript Jam opens with a discussion of Shopify's new functions platform, which uses WebAssembly to let merchants run custom backend logic securely within Shopify's infrastructure. The hosts explain the technical challenge of running JavaScript inside WebAssembly—since WebAssembly doesn't natively understand JavaScript, Shopify embeds a lightweight JS engine called QuickJS compiled to WebAssembly, creating nested layers of abstraction. This leads into a broader conversation about when to use edge functions versus cloud functions, with practical examples like personalization and authorization being ideal edge use cases, while server-side rendering of universal content may be better handled centrally. The discussion shifts to an AWS Lambda cold start benchmark showing Rust and Go with the fastest startup times and Java the slowest, with an interesting finding that newer Node.js versions appear slower than older ones. A community member introduces Thirdweb's Shopify commerce kit for blockchain payments, prompting a conversation about cryptocurrency adoption in e-commerce, with the hosts estimating mainstream adoption is likely five to ten years away. The episode wraps with a review of Honeypot's React.js documentary, highlighting how React's dominance was far from inevitable and how engineering management decisions—like Facebook's four-month rewrite gamble—shaped the framework's trajectory.

Chapters

00:00:00 - Introduction and Technical Difficulties

The episode kicks off with the hosts dealing with Twitter Spaces outages that delayed the show by nearly ten minutes. Anthony and Ishan joke about the platform's reliability issues before welcoming listeners to JavaScript Jam, their weekly open mic for web development and JavaScript topics.

Ishan introduces the show's format, explaining that it welcomes developers of all experience levels to raise their hands and join the conversation. He promotes the JavaScript Jam newsletter at javascriptjam.com, highlighting Anthony's recent improvements to the weekly publication that curates the best content from across the JavaScript ecosystem.

00:04:21 - Shopify Functions and WebAssembly

The hosts discuss Shopify's new functions platform built on WebAssembly, explaining how Shopify needs to let merchants run custom backend logic while maintaining security and performance isolation across its multi-tenant platform. Ishan provides context on why WebAssembly is attractive for this purpose, citing its sandboxed execution model and fast cold start times compared to traditional virtual machines.

The conversation covers the ironic technical challenge at the heart of the project: WebAssembly doesn't natively run JavaScript, so Shopify had to embed the QuickJS JavaScript engine compiled to WebAssembly, creating multiple layers of indirection. They discuss how Surma, an ex-Googler now at Shopify, detailed solutions to bundle size problems through dynamic linking approaches, and how Edgio is pursuing a similar WebAssembly-based strategy for their own edge functions platform.

00:14:08 - Edge Functions vs. Cloud Functions

Anthony asks about the performance implications of WebAssembly compared to traditional serverless, and Ishan reframes the question as being less about WebAssembly specifically and more about when to run computation at the edge versus in centralized cloud infrastructure. He argues the ecosystem needs better intuition for this distinction.

Ishan walks through concrete examples, explaining that server-side rendering identical content across 100 edge nodes is wasteful when a single cloud function could render it once for caching. He contrasts this with ideal edge use cases like user personalization and JWT authorization, where computation is user-specific and benefits from proximity. The hosts also speculate about whether Shopify might eventually generalize its platform beyond e-commerce, drawing a parallel to how Amazon spun out AWS.

00:25:10 - AWS Lambda Cold Start Benchmarks

The discussion moves to a Lambda cold start analysis featured in the newsletter, which benchmarks startup times across different runtimes. The data shows Rust and Go achieving the fastest cold starts at around 16 and 54 milliseconds respectively, while Java reaches roughly 500 milliseconds—an order of magnitude slower.

An interesting finding emerges around Node.js versions: Node 18 shows nearly double the cold start time of Node 16, suggesting newer versions may be getting slower. Anthony theorizes this could be due to AWS not yet optimizing for the newer runtime or Node 18's expanded feature set including Fetch and a built-in test runner increasing its footprint. The hosts also praise the benchmark's animated visualization that shows progress bars filling proportionally to each runtime's cold start duration.

00:32:34 - Blockchain Payments and E-Commerce

Community member Bro Nifty joins the stage to discuss Thirdweb's commerce kit integrating blockchain payments with Shopify through a React-based platform. This sparks a broader conversation about cryptocurrency's viability as a payment method for e-commerce, with Anthony explaining that stablecoins offer a path toward consistent value for transactions.

Ishan presses for a timeline on mainstream adoption, defining it as more than 15% of e-commerce transactions using cryptocurrency. Anthony estimates this threshold is at least five to ten years away and notes that blockchain payment adoption may plateau at a niche segment of enthusiasts and those motivated by financial sovereignty rather than becoming universal. Bro Nifty adds context about traditional payment rails versus blockchain settlement, noting that companies like Visa are exploring blockchain infrastructure for faster cross-border transactions.

00:41:25 - The React.js Documentary

The hosts review Honeypot's newly released hour-long React.js documentary, with Ishan sharing observations from having watched most of it. He emphasizes the documentary's key point that React's rise to dominance was far from inevitable and that the framework faced significant resistance early on, challenging the assumption that its success was a foregone conclusion.

Ishan highlights how the documentary contextualizes Facebook's unique engineering challenges—building a long-lived, immersive web application at billions-of-users scale—as the driving force behind React's creation. He contrasts React's developer-happiness philosophy with AMP's restrictive approach, and discusses how critical engineering management decisions were, such as Facebook's CTO greenlighting a four-month product freeze to rewrite their ads platform in React. The hosts recommend the documentary as accessible even to non-technical viewers and note its value for newer developers who didn't live through this history.

00:51:17 - Community Stories and Wrap-Up

Matt joins the stage with an entertaining anecdote about a former colleague—a Russian VP of software development—who began teaching his three-year-old son Python, quipping that "a monkey can do Python." Anthony relates this to the broader principle that starting to code young, like learning any language or instrument, is advantageous.

The episode wraps up with Anthony thanking listeners and previewing the following week's guest, Ben Myers, who will discuss accessibility and Eleventy. The show closes on a casual note, reflecting the community-driven spirit that defines JavaScript Jam's weekly format.

Transcript

00:00:00 - Anthony Campolo

All right, looks like people are starting to roll in.

00:00:07 - Ishan Anand

Yeah, all right.

00:00:11 - Anthony Campolo

Sweet. Never a dull moment.

00:00:14 - Ishan Anand

Yeah, never. Apologies to those of you who tried to join earlier. It looks like Twitter Spaces is having some issues. Hat tip to Anthony: Downdetector shows that reports started rolling in about an hour ago, more than an hour ago. At 11:05 it indicated reports and it was clearly above baseline. At 11:35, more than a half hour ago. So when we were basically nearly 10 minutes late and tried to get on, we just couldn't get the Space up, and it looked like the Spaces tab was completely borked. But it looks like it's working now, so apologies if folks had issues getting in. Thank you for joining us on JavaScript Jam today.

00:01:05 - Anthony Campolo

Yeah, it must be, you know, there's Twitter. So many people using it. It's just so successful they don't know what to do with it.

00:01:12 - Ishan Anand

It's the so-called good problem to have. You know, the Fail Whale was born at Twitter also long ago.

00:01:22 - Anthony Campolo

That's true.

00:01:23 - Ishan Anand

Yeah.

00:01:23 - Anthony Campolo

Fail whales coming back.

00:01:25 - Ishan Anand

Yeah, well, it looks like they've got it resolved, so I'm glad we're back up. Thank you, everybody, for joining. This is JavaScript Jam. If it's your first time here, JavaScript Jam is an open mic for anything web development- or JavaScript-related. Anything in those two areas is on topic. We welcome everyone, whether you're a beginner just getting started in web development, going from CSS and HTML to JavaScript and trying to figure out how to make heads or tails of stuff, to seasoned experts. We want everyone to participate. Feel free to raise your hand. It's at the bottom of Twitter Spaces. You can raise your hand, and we're happy to bring you up to the stage to comment on whatever we're talking about or to ask a question and change the topic. I should introduce myself. My name is Ishan Anand. I'm VP of Product for the application side over here at Edgio, and my co-host is Anthony. I'll let him introduce himself.

00:02:33 - Anthony Campolo

Hello, hello. I am a developer advocate at Edgio and, yeah, super excited to be here. Thank you, everyone, for joining.

00:02:41 - Ishan Anand

Yeah, and one other note here. If you want to know what we'll probably be talking about, although we never know because it's an open mic night, we have a newsletter to keep you informed about the latest happenings in the web development and JavaScript ecosystem. Usually that's a source for a lot of our discussions. That goes out once a week and has kind of the best from around the web as it relates to JavaScript. If you want to sign up for it, I highly encourage you to go to javascriptjam.com, and you can sign up right there on the front page. You can also see our previous archive of past newsletters. You will note there's been a step-function improvement starting in January when Anthony took over and started writing them. I'm really proud of them. I'm really excited he's here and what he's done with the newsletter, so I highly encourage you to take a look at that.

00:03:31 - Anthony Campolo

There's the link pinned to the Space right now.

00:03:35 - Ishan Anand

Oh, great. Thank you. So definitely check out the newsletter, and Anthony's going to pin it up here so you can take a look at it. Feel free to look at that right now and comment on stuff. Otherwise, we'll take it away from there. Oh, and then last but not least, there it is. I see it now. If you get value from anybody that comes up on stage, feel free to click on their face and follow them, because you'll probably get value from them in the future. Okay, with that, Anthony, was there anything that jumped out at you when you were putting together the newsletter that you wanted to highlight especially? I'm happy to go through and tell you the things that jumped out at me from this week's newsletter.

00:04:21 - Anthony Campolo

Yeah, I think we'll probably have a similar one because it both aligns with our own personal interests and our kind of work relations as well: the Shopify functions, which are going to be using WebAssembly and some things called Javy and QuickJS, which I don't know a whole lot about, but I'll be willing to bet you know at least a little something.

00:04:42 - Ishan Anand

Yeah, so I saw that. I was really excited. Shopify has actually had kind of a long history in WebAssembly, and they were using it and adding it to their system even before they started building the Hydrogen and Oxygen system, just as a way to make the system more extensible. So for the audience here, just to set some context and some stage: Shopify, of course, is an e-commerce platform, and their key differentiation is that brands can come, or stores can come, and they can build their experience on Shopify. Most of the heavy lifting is taken care of for them, and they just get to customize the experience for their customers, the people they sell to. Unlike, say, something like Amazon, where every single product page looks the same and every single category page looks the same, as a brand you cannot stand out and differentiate. And the big need their customers are facing is, how do you take that to the next level? They need to customize the experience even more, yet they're still on a very unified, everything-built-for-you platform. So how do you handle that tension between bundling as much as possible for the merchant so they don't have to do any heavy lifting, but then where they want to break out of that sandbox, you want to give them the ability to customize? How do you manage those trade-offs and that tension?

00:06:07 - Ishan Anand

Obviously, you need to build some ability to have some level of customization. They have a way to do that through Liquid templates in Shopify. That's their markup language. But you ran into this problem where people wanted to customize the backend logic inside the platform. And then, as has started happening over the last few years, they want to run what are called headless experiences, where they're using Shopify just as an e-commerce backend platform, but the entire front end is on one of these modern frameworks like Next or Nuxt. And so that's where they started building out the Oxygen platform as well as their own framework, Hydrogen. Although maybe I've got those backwards. No, Oxygen is the platform, Hydrogen is the framework, I believe. Correct me if I'm wrong, Anthony.

00:06:53 - Anthony Campolo

Yeah, that's right. Yeah, that's right.

00:06:55 - Ishan Anand

And so one of the ways they looked to add the ability to give their merchants a way to run arbitrary customization code inside this platform was through WebAssembly. So what is the challenge here? You say you want to give somebody the ability to customize, and when it's not just look and feel, like templates and HTML/CSS, but actual logic like JavaScript running in the backend, now there's this whole security aspect to it. You need to make sure that when you're running the function for merchant one in the large Shopify platform, it doesn't go and steal data from all the other merchants, and it doesn't starve the resources of all the other merchants. You don't have one function that's running an infinite loop and suddenly nobody else can serve customers on that instance, because it's a universal platform that anybody can be on. And so you can't just give them access to raw V8 or something they run the rest of their backend logic on. They need to protect it in some way, in a container of some form. Historically, the way you do this is in something called a virtual machine.

00:08:03 - Ishan Anand

But there's this new standard, WebAssembly, which lets you run untrusted code in a sandbox that you have security guarantees about, that you know is not going to be able to break out of this jail. It's got some other benefits, like really fast, or very small, what they call cold start times. It doesn't take a lot of time to essentially start up before it actually starts executing the function, which is an issue.

00:08:29 - Anthony Campolo

And that's actually relevant to one of the other links we had in the newsletter, which is a comparison of different runtimes on Lambda and how their cold starts relate to each other, which is really useful, I think, for people who don't work a lot with serverless functions and may not have a good intuition for what is fast or slow and what's a reasonable cold start time.

00:08:48 - Ishan Anand

Yeah, that was actually the first thing I was going to jump to. That was the one that jumped out to me first on there, but we'll get to that in a second. So what Shopify released, which is actually from an ex-Googler, Surma, who has some really great developer-focused content, and I highly recommend his stuff, including, I think, a podcast called HTTP 203, or at least he may still host that. They talked about how they've brought JavaScript to WebAssembly. WebAssembly is a format for code that can run in this universal container. It's the write-once, run-anywhere, as they used to say. If I write some code and I compile it down to WebAssembly, it becomes this module that any place that says it runs WebAssembly can run. Notably, WebAssembly can run in browsers, but it can also run on servers as well. And so what Shopify is doing is they're basically opening up their platform so you can run their functions in WebAssembly. The challenge historically is that WebAssembly doesn't actually natively understand JavaScript. And so what they detailed is all the work they had to do to be able to run JavaScript from within WebAssembly to enable Shopify functions.

00:10:06 - Ishan Anand

This is, as Anthony mentioned, near and dear to us because at Edgio we've actually had various forms of edge functions. There's a couple companies we've acquired. Layer0, where I worked, had a form of serverless. Edgecast was another company that was acquired by Edgio. They had their own Deno-based edge functions, and Limelight Networks, which was also acquired as part of Edgio, also had edge functions. But what we're doing moving forward is harmonizing the next version of edge functions on WebAssembly ourselves because of all its really great properties regarding cold starts and security guarantees. But one challenge is, unlike, say, V8, which is the JavaScript engine in Google Chrome, which some people use for their edge functions and which natively understands and runs JavaScript, WebAssembly doesn't know how to run JavaScript. It only knows how to run WebAssembly. And so the way that people are getting around this is they basically pull a JavaScript engine off the shelf, which is written in WebAssembly, which then runs JavaScript within it. So it's kind of like that turtles-all-the-way-down apocryphal story.

00:11:20 - Anthony Campolo

It seems so silly. It's like the killer use case for WebAssembly is just to let us write more JavaScript.

00:11:27 - Ishan Anand

I know. It's really, in some ways, frustrating. I was like, wait. And it's really bizarre because the original version for WebAssembly started off as a variant of JavaScript. It was a subset of, what did they call it? I forgot what it was called before it was WebAssembly.

00:11:43 - Anthony Campolo

Emscripten.

00:11:44 - Ishan Anand

That's what I'm thinking of. Yes, exactly. It basically took regular C code and compiled it into this subset of JavaScript to execute a virtual machine really fast. That was the thing that kickstarted, hey, let's build this bytecode. Then the ironic thing they lost was the ability to run JavaScript. What you have is a JavaScript function running inside a JavaScript runtime, which is called QuickJS, which is itself running within a WebAssembly container. It's multiple layers of indirection. And so they detailed a bunch of things in there that were really fascinating about how they worked through those issues. Most notably, when you try to do it in, say, a naive approach, the size of the bundle gets really, really big because every single function now has to have a little bit of QuickJS in it, which itself is not big, and then you compile it to WebAssembly. And so they came up with some solutions for what people might be familiar with as essentially something very similar to dynamic linking, which is like, if every program on your computer is using the same library, well then why don't I just store that library once on my computer and all the other ones don't have to pull that all in, kind of like what we used to do with libraries like React or jQuery, which were commonly used and would all point to one repository, the same way monorepos now

00:13:12 - Anthony Campolo

do a similar thing.

00:13:13 - Ishan Anand

Yes, yeah, very similar. So that was the number one thing I thought was interesting there. But they're also building and open-sourcing part of their toolchain around it. It was a really impressive and in-depth walkthrough. Surma, if you go to his blog, by the way, has, I think he calls it, like, "my brain dump on everything I know about WebAssembly," that he just posted within the last week or so, that I also recommend checking out. If you really loved this post, it's really in-depth. But the big takeaway here is the progress they're making, and the whole ecosystem is making, toward making JavaScript run better in WebAssembly, which I think would be great for everyone and is something near and dear to the hearts of folks like myself who are close to the runtimes of the ecosystem. So that's my...

00:14:08 - Anthony Campolo

Yeah, I'd be curious. Do you think that developers will need to know anything about these internals or is the idea to be able to just write JavaScript and have it work? Is there anything that's going to be specific to these webassembly things that we're using?

00:14:26 - Ishan Anand

Yes and no. I think the goal is that they don't have to. That's the holy grail, and you kind of already have that on the V8 versions of these platforms. There are issues they have, which WebAssembly, I think, solves. So ideally the answer is no, you don't have to worry about it. That's what we want to get to. I think there's going to be growing pains, though. There will be areas that will be, I don't want to say uncanny valleys, but there may be things that people have to be aware of: I'm in this runtime versus not. And it's going to be, I think, a little bit analogous to the early days of the web, where you might have had, if you remember, some browsers support some features and some browsers don't. We still have that, actually, but not as bad. Now everyone is really aligned to overall standards and it's just a feature or two off. But way back when, they were following completely separate standards. I feel like, thanks to things like the WinterCG group, it's going to be more like what it is today, which is, if you're running in this browser, this feature might be available and this feature might not be in another.

00:15:44 - Ishan Anand

But the broad outlines are roughly the same. I think it's going to be more like that than what we had before. But that is kind of the danger we have to worry about. So hopefully the answer is no, but don't be surprised if there's one or two details you have to worry about.

00:16:00 - Anthony Campolo

Yeah, I'm looking at some of the code in the blog post now, and it looks like if you want to import fs, like the file system module that most people would use from Node, it's going to be from Javy FS, and then they're going to try and implement that as close to the standard as possible. I would assume, I guess it's not really a standard system in Node, but as close to the Node API as possible.

00:16:24 - Ishan Anand

Well, I mean, that's where this other standard, WASI, comes in. WebAssembly, or WASM, only describes how to execute computations. It does not describe how you talk to the file system, what the actual function call you make is, how you send messages, and all that. It could be that all of that is very different from platform to platform. WASI is an attempt to standardize it, and so is, to a certain extent, WinterCG. And hopefully, again, this is why I think we've learned as an ecosystem. The collective memory of what happened when we had browsers that had different senses of standards, even though there was standardization to a certain extent from W3C, I think means we're going to try and prevent people from having to go through those pains. But there's that risk right now as companies are pushing forward and are ahead of where standards may be.

00:17:30 - Anthony Campolo

Yup, yup. And then what's your intuition for just how big of a performance gain you would get from this in comparison to both Lambdas and other edge functions?

00:17:48 - Ishan Anand

For the latter one, it remains to be seen. I think there are a lot of factors that go into it. It depends on how the function is written, and there are always things like memory-versus-time trade-offs and things like that. And then how much resources are allocated to functions, and those policies in terms of how you make sure that one function doesn't starve another and you make sure you give equitable resources, that may depend on your go-to-market model and whether you've got a large free tier or not, and things like that, and how you isolate those customers. How it compares to serverless, I think, remains a little bit to be seen. What people generally are using WASM and edge functions for are things like middleware, and they're generally used in environments where the... Let me back up, because I'm glossing over a really important detail. I don't think it's really a question of WASM versus serverless. I think it's a difference of edge functions versus serverless, or edge functions versus cloud functions. It's about when do you run computation on the edge versus when do you run it in a more centralized data center in the cloud.

00:19:11 - Ishan Anand

Whether it's WASM or not, I think, is a little bit orthogonal to a certain extent, although not completely. And so I think there needs to be a kind of collective understanding in the ecosystem about when you run code where, just like we're starting to have this appreciation of things like the performance impacts of hydration, and it took our ecosystem a couple years to really start to appreciate that. I think it's going to take us the same amount of time to realize not everything should be an edge function. The canonical example I like to use is server-side rendering. It doesn't always make sense that you should do your server-side rendering in an edge function. There are people who are like, I'm looking forward to running server-side rendering there. The reason you might want not to do that is, imagine you've got a page that's the same for everyone and you've got maybe 100 PoPs around the world running edge functions. And let's say you're able to do it fast enough that you can do it inside an edge function, because edge functions typically don't let you run as long as cloud versions of functions.

00:20:19 - Ishan Anand

Even if you do that, you're going to do that server-side processing, that compute cost, in 100 different nodes if you get hits from all across the globe. Now, if you did it in one cloud function and then all the edge nodes had to do was just cache that result, you'd only pay for it once. So there are times where you've got to pick judiciously, and not everything needs to be an edge function. Things that make sense to do in an edge function are things that are closer to the user and get personalized to them. So an example of this is personalization of the content. You might take a cached version from that cloud function that runs centrally and then add on details about the user, personalized, like it might say, you know, "Hi Bob, welcome back," at the top in the login, right? You can add that at the top of the header of the screen in maybe a personalized edge function because that's just for that user. It doesn't make sense to do it in the cloud, and it can pull from the cache immediately. And that makes a ton of sense.

00:21:18 - Ishan Anand

Another great example, or form, of personalization is authorization. So you might get a JWT token or an authorization token from maybe a centralized security server, but then your edge functions can decrypt that token and check whether that person is authorized to access some other resource right there at the edge. That's personalized to them, and that'll have lower latency. I think the ecosystem needs to get an intuitive feel, I should say, for when to use edge versus cloud. And there are some people who are already out there, but I don't think, as a whole, the ecosystem is really appreciating that. That's how I break that down. That's a really long answer, I think.

00:22:00 - Anthony Campolo

Yeah, no, that was useful. The main thing is going to be: don't do computation on the edge if it's not really going to give you much of a gain, but will have a cost of having to duplicate lots and lots of compute.

00:22:16 - Ishan Anand

Yes, you know, use it where appropriate. We have a slide deck that's like, use the right tool where it's appropriate, and it walks through some of those use cases that we talk folks through there. But I think it's something the ecosystem will learn. Maybe we should jump to the cloud cold start analysis.

00:22:39 - Anthony Campolo

Yeah, yeah. The last thing I would say is I dropped another link to the Shopify docs for this, and it looks like you can spin it up locally and kind of test it out, but you can't deploy them yet. So if you want to be one of the first people to try this out, this would be a good time. But you're not going to be migrating your company's production site anytime soon with it.

00:23:01 - Ishan Anand

Well, unless you're... Yeah. Here's my hot take, by the way, on Shopify. I think it's really interesting, the platform they're building out. I do wonder if they're planning at some point to generalize it beyond e-commerce. So here's my rough analogy: Amazon was an e-commerce company, and at some point they said, we built this great infrastructure, we should spin it out, and that became AWS. You can kind of imagine history rhyming if Shopify plans to do the same thing. Right now it's very focused on e-commerce use cases, but it'll be interesting to see if, in, I don't know, half a decade or so's time, they start broadening out once they've nailed the e-commerce use case, or if they just continue to go deep. So I'm really curious to see whether they go deep or broad, but it remains to be seen.

00:24:02 - Anthony Campolo

Yeah, I've been appreciative of the amount they've been investing in open source in general, and I think they've done a good job of sourcing people who are already fairly established in the open source community. So yeah, I'll be curious to kind of see, as you say, how this all shakes out and whether it becomes something more generic and more applicable to non-e-commerce things. Usually when I would start talking about some of these projects, like Hydrogen and stuff like that, people would be like, oh yeah, it doesn't really interest me because I don't do Shopify stuff or e-commerce stuff or whatever. And I was like, well, yeah, that may be true, but they're actually creating cutting-edge tech that could be used for lots of things. So definitely agree with you there.

00:24:42 - Ishan Anand

Yeah. And they keep pulling in people that I have to imagine have ambitions beyond just e-commerce. To put it like, I don't think Remix is only thinking they're going to be the framework for e-commerce, right? I don't think some of the other folks they've pulled over from Google are thinking just beyond that. They're used to thinking about the developer ecosystem as a whole. My hot take on it.

00:25:07 - Anthony Campolo

Yeah, that's absolutely right.

00:25:10 - Ishan Anand

Let's talk about the Lambda Cold Start analysis though. How did you come across that one? And I thought that was really interesting. I'll tell you my thoughts, but I'll let you go first on that one.

00:25:20 - Anthony Campolo

It's a good question. I kind of have a whole set of newsletters and things that get filtered in through my feed. This is just one that I pulled out. I actually don't really remember where it originally came from. But yeah, I've seen things like this before. Back when I was working at QuickNode, there's one of these for blockchain, like if you're using Ethereum, you could connect to it through QuickNode or Alchemy or Infura. They all have slightly different latencies and response times. And I think it's really useful to just have a quick visual image to look at things and compare against each other. Because when you're kind of just using these things by themselves, you may be getting, like, a half-second cold start and you'll be thinking, well, is that good or bad? Can you compare it to something to know? And so this kind of lets you see, okay, if you're using, say, Rust, you could get potentially a 16 millisecond cold start, but if you're using Java 8, you could get a 500 millisecond latency start. So yeah, this kind of tracks with my general intuition of why I would expect things to be faster or slower.

00:26:32 - Anthony Campolo

Rust and Go are the fastest, Java and .NET are the slowest. So yeah, the leaner, more systems-level languages do very well, and the larger "we have a whole virtual machine inside of this language" ones will perform slower.

00:26:50 - Ishan Anand

Yeah, I thought it was interesting on multiple levels. It was interesting to see the different Node versions. So there's obviously what you called out, Rust versus Java, the fastest versus the slowest. It's an order of magnitude, more than an order of magnitude. Go is like 54 and Java is like 10 times that, and that goes into the fastest Rust was, at least on the current benchmark. The other interesting thing was Node, the difference that Node is getting slower. So Node 16 was faster than Node 12, but Node 14 is slower than both of them, and Node 18 is nearly twice what the fastest version, Node 16, was. So it's interesting to watch the newer versions. Are they getting slower? Are they getting faster?

00:27:45 - Anthony Campolo

Yeah, I would have a couple theories about that. I would say it might be either one, just because support for that is pretty new, I think, at most just a couple months. So it may just be that AWS hasn't tuned their infrastructure yet to give good performance on this, because as more people use it they'll have more data to optimize more hot code paths. Or it could be that Node 18 has a lot more stuff to support. We're adding things like Fetch, we're adding things like a test runner. So I'm not sure if you can use the test runner in a Lambda, but I know you can definitely use Fetch, and that's kind of the idea. So I think as Node has now had to support Node-y Node stuff and now new JavaScript stuff, it's probably getting to be a larger footprint.

00:28:29 - Ishan Anand

Yeah, I had similar thoughts as well. More, I guess, I don't know, I'd call what we're describing tactically, but more strategically, just some things that struck me about the project were, like you said, lots of people do these, but what they've built is an evergreen source. It'll constantly be updating, and he has a GitHub page where he walks through that. So I think that's a really valuable resource to the community. It'd be really great to see how these change and evolve over time. Maybe he'll add that. The other really fascinating thing to me was, because it's the thing I wouldn't have thought of, it's an element of delight, which is, if it was me, I would just put this in a table. And I thought it was really creative that they have that progress bar for each one to reflect proportionally how long each one takes. So you get a visceral feel for how relatively slower or faster they are, as a human, in relation. So you can count off the four seconds it takes the Java line to come through, but the Rust line comes by so fast you can barely see it.

00:29:42 - Ishan Anand

In fact, it's probably not literally 16 milliseconds. I thought that was a really nice touch. There's a little bit about the way it renders that I feel like doesn't quite convey that message. I had to think about it too much to appreciate it, which they can probably fix. But overall, I thought that was a really brilliant touch, and that added a really valuable element of delight.

00:30:06 - Anthony Campolo

Yeah, no, that's cool. And data visualization itself, I think, is a very underappreciated kind of thing because it's easy to just put a bunch of numbers on a page, but that doesn't always necessarily resonate with people. So that's why you do bar charts and things like that. But with this, it's like an animation that's conveying something about the data, which is really cool.

00:30:30 - Ishan Anand

Yeah. You know, if you've done stuff in WebPageTest, right, you do the side-by-side comparisons of the video of it loading. You can see the webpage load faster on one versus the other. This, to me, was kind of the equivalent of that. It was really clever, and I thought that was really nice. Aside from the data and all the other work that went in, there's that one last Apple-like addition to it that just takes it to another level. So my hat was off on that part. I thought that was really cool.

00:31:02 - Anthony Campolo

Yeah. I wonder if the person who created this is a plan to ever do this with Edge functions. That would be also interesting comparison.

00:31:10 - Ishan Anand

Oh yeah. I mean, if they're not thinking it, I'm sure plenty of people who watched it or saw this post probably are. We're a little well past the halfway point, so I'll just do our typical station break. If you are just tuning in, this is JavaScript Jam. We are an open mic for everything web development- and JavaScript-related. We hold this every week at 12 p.m. Pacific time, so that's lunchtime in the San Francisco time zone. Anything JavaScript or web development related is on topic. We love it when we are audience-driven. People can raise their hand to come up to the stage. We're happy to bring you up and change the topic to whatever you want to ask about, whether that's a beginner question, like "I'm just getting started," or it's an expert question. Some of our favorites are when one person in the audience asks a question and somebody else from the audience comes up and answers it. If you're getting any value from anyone in this session, feel free to click on their face and follow them. And then lastly, do subscribe to the JavaScript Jam newsletter. That's actually the source of what we're talking about a lot today.

00:32:19 - Ishan Anand

All the links that we've discussed are in there. Anthony has pinned it to the top of the Space, and if you go to javascriptjam.com, you can subscribe there as well.

00:32:34 - Anthony Campolo

All right, looks like we got Bro Nifty up here to join us. What's up, man?

00:32:38 - Bro Nifty

Yes, sir. Yes sir. Thank you. Yeah, I continually struggle with this one. It's one that I don't want to miss. Yeah, yeah, I missed it a couple of times ago and I almost felt like I betrayed you guys, like you'd think I didn't want to be here or something. No, I just straight up forgot. I was doing something or whatever. But yeah, I kind of tend to be like an absent-minded professor a little bit. Sometimes I get off on a tangent and I forget what I was doing. I've had this alarm set five minutes before, just to give me a little window, but I also had to set it for the exact time so it can just kind of nudge me in case I was doing something in that little five-minute window and I got sidetracked. Whatever. So I'm just fine-tuning my alarm system here. Thirdweb, they have a shop. Speaking of Shopify, Shopify is on fire. Shopify is amazing. Shopify is the best. Shopify is the mothership.

00:33:35 - Bro Nifty

But for Remix, React, Shopify loves React. Thirdweb, there's a commerce kit with Thirdweb and Shopify to do some combination of blockchain plus regular payment systems with a React platform to customize themes built in and so on, whatever. So I thought that was pretty cool. Thirdweb's kind of main thing, their main squeeze, is React. Shopify obviously loves React. A lot of people like React, so it's kind of nice that it revolves around that so you don't have to relearn a whole new thing to be able to use that. So that's kind of the thing that popped up in my emails. I was looking at it, and I thought that was kind of neat too. But it goes along with your thread here. We're talking about Shopify stuff and their functions, which is obviously very cool too.

00:34:35 - Anthony Campolo

Yeah, actually, I didn't see this. This is interesting, though, because I know Thirdweb, and I interviewed a couple people there when I was working at QuickNode. Had them on our Twitter Spaces. And yeah, they're a great platform, very dev-focused. If you're used to modern dev tools, it'll be very familiar to you. And Shopify actually has a blockchain division team that's been working on that. So this makes a lot of sense for them to bring in something like this that has already kind of carved out that path of good DX building dapps and stuff like that. And yeah, that's pretty cool. I think that the appetite for this kind of stuff is at an all-time low right now, but that's actually when the most interesting things usually get built.

00:35:22 - Ishan Anand

What do you... So yeah, this is definitely in Anthony's wheelhouse more than mine. But I'm curious, Anthony, what do you think about the potential for blockchain as a common e-commerce transactional currency? It's been so volatile. It seems like it was supposed to be a currency, but it's become more of an investment vehicle. Do you think we'll ever get to that point? What are your thoughts there?

00:35:53 - Anthony Campolo

Yeah, so there are already a lot of different coins, a lot of different chains. There are ways to do it where you're using something that does have kind of a stable value, like stablecoins. Some stablecoins have kind of blown up, but some, yeah, have stayed consistently stable and have shown that you can do that. I think it's a question of what use cases can you unlock by adding that. And I think if you get into this subject, you end up finding a lot of potential use cases, most of which probably won't pan out, but a handful of which will. I think ideally, for the blockchain people, Web3 people, they would like it to be where anyone can pay any way they want for anything, and that's just the goal. So having something like Shopify kind of bake it in so that someone who was going to use their credit card could just send Ethereum instead would be really nice. And that's kind of what's going to help bridge that gap between Web3 people and people who've never really interacted with it yet.

00:36:59 - Ishan Anand

Let me rephrase my question. How far off are we from, do you think, a large number of consumers crossing the chasm on using blockchain to make payments for e-commerce?

00:37:13 - Anthony Campolo

Yeah, I mean, it depends, I guess, how you define large. I think that it will kind of continue to grow over the next five or ten years and then probably at a certain point start to plateau. So the question is, where is it going to plateau if it's going to continue to be a niche number of people who are enthusiasts and want to keep using it, or they'll be kind of like a critical mass of people who want to use it. Because I think to a certain extent some people like it and use it and want it to be part of society almost as like a political statement, because they want the ability to kind of have a currency that's out of the control of the government. So that may be a larger percentage of people than some might think, depending on kind of what their priors are there. But it's never going to just become like money that everyone uses. Like it's always going to be some subset of the population, I think that's going to use it. Unless literally governments themselves implement their own digital currencies, which then everything would change.

00:38:15 - Ishan Anand

Okay, yeah. To answer your question, the way I define large is crossing the chasm, so past the innovators, past the early adopters. So more than 15% of e-commerce transactions. So I'm actually Googling right now, what is the percentage of usage of cryptocurrency in a transaction?

00:38:42 - Anthony Campolo

Yeah, it's definitely going to be way below that and I would say it's probably going to be at least half a decade or a decade until we all get to that point, I think.

00:38:52 - Ishan Anand

Okay. Okay, that answers my question. Okay, thank you. Bro Nifty, anything else around that that you wanted to say before we move on?

00:39:06 - Bro Nifty

Not a whole lot. Yeah, as far as payments and integrating payments, it's one thing to add a button on your website that you can use to pay through a blockchain or whatever. But it's another thing at, like, a point... I don't know the exact retail terminology, but let's say you can point your phone at something and pay through various cards that are stored, virtual cards that are stored, and the various... I don't know if it's at the card level. This is my... I don't know all the details here, but I believe some cards, like Visa or something, are using, or thinking about using, the blockchain rails to send and receive payments and do various transactions rather than the traditional rails where they do clearing and then the actual money changing if it's cross-border or whatever. And all the traditional kind of, it takes like three days, like ACH and all. EU has different, India has different, and then ACH in America has a different...

00:40:24 - Bro Nifty

But either way, it's like the traditional payment rails versus using the blockchain rails.

00:40:33 - Anthony Campolo

And I'm thinking it kind of cut out there. Yeah, yeah, cutting in and out there. But yeah, I mean this is the most classic... This is what blockchain was created for, to allow two parties to transact without necessarily needing a third-party intermediary. And then you have a settlement layer that allows you to do that. So yeah, this makes a ton of sense. If they can do it and still be legally compliant, that would be the question.

00:41:08 - Ishan Anand

Okay, I know it was cutting in and out for me, but I'll move us on. If you guys can hear me, let me know.

00:41:20 - Anthony Campolo

Yeah, I'm not sure. That may have been from my phone since I'm hosting the space, but continue on.

00:41:25 - Ishan Anand

Okay, well, we're coming up close to 10 minutes from the top of the hour, when I have to drop. The other thing that was in the newsletter that was really, really interesting was the React.js documentary that was released. It's an hour-long documentary about the history of React. I'll let you, Anthony, go first, and I don't know if you have any thoughts on it, if you've got a chance to watch the full thing.

00:41:50 - Anthony Campolo

I have not watched it yet. I'm definitely going to, though, because I've seen other Honeypot stuff and I think they're really legit, and I know my friend Michael Chan is featured quite prominently in it. So yeah, it looked like it was super high production value, and people seem to enjoy it.

00:42:07 - Ishan Anand

Yeah. So this is one where I don't know if there are any spoilers, because you know how this story ends. But yeah, I've watched all but the last 10 minutes of it, so I still need to watch the last 10. So maybe there's a plot twist at the end. But one of the things that Michael makes a point of pointing out at the beginning is that people sometimes feel like it was inevitable React was going to become the dominant framework, and that's certainly not the case. People often forget how much React struggled to gain acceptance, and there were multiple points along the way where you wouldn't have predicted the outcome.

00:42:55 - Anthony Campolo

Yeah, history always looks inevitable in retrospect.

00:42:58 - Ishan Anand

Exactly. And especially for people who are coming to the ecosystem more recently, it just feels like it's part of the woodwork. What it really does a good job of, I think, is contextualizing what history looked like before React and what React was kind of railing against, which I think is really important to appreciate, especially if we are moving to a post-React world. So I thought that was really fascinating. And I like how they took what is a technical topic and really boiled it down to, I think, a narrative and a story that could be appreciated by somebody from any background, whether it was technical or not. And I think it's particularly challenging when you're writing a documentary about a framework. And I believe Honeypot did the one on Vue.js, so they've got some experience doing it. This might be their longest one. I think the Vue.js one was like 30 minutes. This one's over an hour. But I thought they did a really good job of communicating technical concepts in a non-technical way sometimes.

00:44:11 - Anthony Campolo

Yeah, I remember the GraphQL documentary they did a couple of years ago, and I thought that was the, at the time it was the Best documentary I'd ever seen about a developer subject.

00:44:20 - Ishan Anand

Oh, I remember when that one came out. I have not watched that one, but I'll give you an example. It's really important for people to understand that the thing React was coming against was, hey, it's really hard to keep track of all these different updates inside a browser with the current tooling that we have. What if we just, you know, this crazy idea they called it, that you don't even worry about keeping track of updates. Conceptually, as a developer, you get to blow everything away every time anything changes and you rebuild it. And then React just does some magic to fix that so that you can do it efficiently. There's this great statement, like somebody said, "It shouldn't work, but it does." And really the challenge that Facebook was feeling, which I think people don't appreciate now, is they were trying to build one of the first really 100% pure, digitally immersive experiences inside a webpage at such a scale of billions of users. Everything else was, you know, "I'm trying to buy a product," like there is an end goal. But Facebook needed to be a compelling experience just to keep you there for no other reason than to keep interacting through the webpage with your friends.

00:45:42 - Ishan Anand

Right, or stay in the background. And so this is this long-lived webpage that is trying to keep you there as long as possible. And so they have to figure out how to build a very complex application. When you think about it that way, you're like, oh yeah, I don't think anybody else really had to deal with those problems in the same way at that time, although there might have been people approximating it. That was the problem that necessitated the creation of React. I think there's two interesting things there. One is that there's a lesson there that you may not be facing the same business requirements and architectural constraints that Facebook is. So maybe React isn't the right thing for you because you're not trying to build something like that. Maybe you're trying to be like Google, where they get in and get out as quickly as possible. You're not trying to keep them there. In which case, maybe the startup time of React or startup performance is more important to you than it might be for the team that actually built it.

00:46:50 - Ishan Anand

The other key thing is, it was interesting in my head to compare and contrast the evolution of React with the AMP framework. React was really built for developer happiness and the ability of developers to build and scale great experiences in a scalable way. AMP was almost developer-second.

00:47:16 - Anthony Campolo

It was really built for users optimized for developer sadness.

00:47:20 - Ishan Anand

It was, it was, yeah. You could almost say optimized for developer sadness. It said, you know, the way we're going to solve this, rather than giving developers a great playground, is we're going to restrict what they can do instead of enhancing their expressiveness. And it actually created magical, performance-wise experiences, but it was too constricting, and developers railed against it. So I thought that was one of the interesting things that was going through my head when I was watching it. But I can definitely tell you, I've got like 10 minutes left on it, but everything I've watched has been really great and a fascinating story, and I definitely learned a thing or two. So yeah, I highly recommend it.

00:48:03 - Anthony Campolo

Yeah, I definitely look forward to watching it. I would love for there to be like 10 times as many of these for all sorts of frameworks and projects, because there's always more to learn about the history of these things. We have so much data and so much content and things online, and these things are all being built in the open, but it's usually hard to get a good condensed explanation of just the history of some of these projects. I definitely found that getting into all this stuff. So these things can be really useful for developers who did not live through this. And it's also really cool because I am going to watch this with my partner, who is someone who doesn't know anything about code and doesn't really understand exactly how the different things that I work with relate to each other. So I talk about React and I talk about React frameworks and Redwood and stuff like that. She hears all these terms, and hopefully this will give her a better idea of what I mean when I say React.

00:49:01 - Ishan Anand

Oh man. You know, as you're talking, I'm wondering if I should watch it with my kids. That might be...

00:49:08 - Anthony Campolo

Yeah, that could be really cool.

00:49:10 - Ishan Anand

That could be... They're 8 and 10. Maybe I need to wait a little bit longer.

00:49:13 - Anthony Campolo

Yeah, yeah. Have you taught them any code yet?

00:49:19 - Ishan Anand

Not really, but they've done Scratch and they've done Minecraft Education Edition. And actually it turns out their middle school requires computer science, which I was impressed by.

00:49:36 - Anthony Campolo

That's awesome. My middle school required Microsoft Word, so I learned that that was kind of the equivalent of learning to code, I guess.

00:49:43 - Ishan Anand

Yeah, well, I think when I was in school they just called it typing, so I guess I'm dating myself. But yeah. The one other thing I'll say that's really valuable before I have to drop is how much, and I think this is a lesson for enterprise managers and people in non-Facebook companies, engineering management was really critical. There's a decision point, for example, where the Facebook stock price is really, really low. They've just built this, they just built this... Sorry, what'd you say?

00:50:22 - Anthony Campolo

So buy the dip.

00:50:24 - Ishan Anand

We have "buy the dip." The stock price has gone low. This is back when they first IPO'd. They're under a lot of pressure, and they're like, do we rewrite the whole ads software and do no additional product development for four months just to migrate to React? And it goes back and forth. And finally, I guess it's the Facebook CTO who says, okay, we'll bet on React. And they did a bake-off, and Netflix did the same thing a few years later. They're like, okay, let's do a 30-day contest, and we're going to build the next version of our platform for the next 10 years on either React or this other thing. I think it was Ember. And they did the bake-off. I think it's a very powerful example of how important these questions are outside of, say, the biggest tech companies, and what we can learn from how they make those decisions. So with that, I have to drop, but I'll leave you in Anthony's great hands.

00:51:17 - Anthony Campolo

Yep. See you later. Ishan. Matt, I saw you hopped up. Did you have something you want to say?

00:51:22 - Matt

Oh, yeah, I just had a funny story. Sorry, it was a motorcycle driving by my living room right now. When I first started really down the development path, like 12 years ago, the VP of software development at the agency I worked at was Russian, as in his dad lived in Siberia and carved a wooden keyboard for him, and that's how he learned how to use computers. And at the time I was doing a Python course, and he was like, "Matt, what's the name? What's the link to that Python course you're doing?" I sent it to him. He's like, "Okay, cool, I'm going to teach my kid how to start coding." And I was like, "Oh, how old is he?" And he goes, "He's three, but a monkey can do Python." And I was like, "Oh, thanks, man. That makes me feel really good." And that was him teaching his son Python at 3 years old.

00:52:11 - Anthony Campolo

I mean, the younger the better. It's like learning a language in general or learning to read and write. Like, the younger you start, the faster you'll get good and the more plastic your brain is or like learning an instrument, you know, so that's great. I wish I had a parent who would have taught me to code at 3 years old.

00:52:28 - Matt

Yeah, it's pretty crazy. I'm convinced that this guy's a robot. Daniel's met him. He's an absolute machine. He pretty much knows every language there is and literally does everything he's working on. He's actually helped build the upgraded version of Binance. That's what he's working on right now.

00:52:46 - Anthony Campolo

Seriously. Wow, that's legit.

00:52:48 - Matt

Yeah, it's pretty crazy. He's in another one now. It starts with a P. I forgot the name of it, but that was just a funny story I had.

00:52:56 - Anthony Campolo

Word. Well, thanks for hopping up. I think we'll go ahead and end the Space here since we just got a couple people left. But thanks, everyone, for joining. This is a bit of a more chill JavaScript Jam, but we talked about some interesting subjects. Catch us next week. We will be talking with Ben Myers, I believe, about accessibility, Eleventy, things like that. So yeah, would love to see you all there next time. Thanks for joining us.