You can check the slides for James' talk here.
This talk has been presented at Node Congress 2022, check out the latest edition of this JavaScript Conference.
You can check the slides for James' talk here.
This talk has been presented at Node Congress 2022, check out the latest edition of this JavaScript Conference.
James Snell, also known as JA Snell on GitHub and Twitter, has been contributing to Node.js for almost seven years and is a member of the Node technical steering committee. He has been involved in significant developments within Node.js, including the merger of NodeJS and IOJS.
Recently, Node.js has added several new features including HTTP2 support, new URL parsing, and support for web streams, which includes the readable stream and writable stream API. Two years ago, the Web Crypto API was also implemented.
James Snell emphasizes the need for a standard library of APIs for JavaScript runtimes to reduce developer friction and ensure consistency across different platforms like Node.js, Deno, and Cloudflare Workers. This standardization would help in harmonizing the way common functionalities like base64 encoding are implemented across different environments.
The debate on the standardization of Node's APIs centers on the balance between adhering to web platform standards and maintaining the unique aspects of Node.js. This ongoing conversation reflects the challenges in ensuring Node.js remains compatible and efficient across various user applications and other JavaScript runtimes.
The lack of a standard library in JavaScript runtimes leads to multiple implementations of the same functionality, such as base64 encoding, creating confusion and increasing the maintenance burden. Developers must choose among various APIs and ensure compatibility with different runtimes, which can be time-consuming and error-prone.
James Snell proposes that JavaScript runtimes should adopt a standard library of APIs that are consistent across different platforms. This approach would address issues of redundancy and inefficiency in the current ecosystem, where different runtimes have their own sets of APIs, making it difficult for developers to maintain code compatibility and efficiency.
Hello, Node Congress. I am James Snell, or JA Snell on GitHub or Twitter. I've been contributing to Node for almost seven years. We've had ongoing debates about Node's API standardization and its alignment with web platform standards. Other runtimes like Deno and Cloudflare Workers have their own APIs. We need a standard library of APIs for JavaScript runtimes. Let's kick it off with a discussion on base64 encoding in Node.
Hello, Node Congress. I am James Snell, or JA Snell on GitHub or Twitter. And I am with CloudFlare. I'm also on the node technical steering committee. I've been contributing to Node for almost seven years now. Started back in 2015, right when NodeJS and IOJS were having their issues and got them back together. So they've been around for a while.
And in that time, there's been some themes that have developed over time. You know, we have all the node APIs that are out there. You know, we've added a bunch of new features to node. We added HTTP2 support and new URL parsing. Recently, we just added support for web streams, so the readable stream and writable stream API. I think two years ago, we implemented the Web Crypto API. So, you know, there's a lot that's happened. And over that time, you know, we've had this kind of ongoing debate and ongoing conversation about just how standardized Node's API's should be or how much of the, you know, web platform standards Node should be paying attention to.
Well, you know, since that time, you know, we've had other runtimes that have come up. We've had Deno, you know, which is a fabulous, fantastic platform. But it has, you know, its own set of APIs. We have Cloudflare Workers, one of the runtimes I'm working on right now. You know, and it has its set of APIs and things that it does. And, you know, there are other environments you can, you know, look at Fastly or look at, you know, some of the IoT devices, you know, there's a bunch of places where JavaScript is being used now. So, yeah, you have to stop and think, you know, at some point, it's good to always kind of step back and think, what kind of APIs should we be implementing? Well, I'm here, you know, after, you know, seven years of doing this, you know, here with a bit of a modest proposal. We need a standard library of APIs for JavaScript runtimes. I'm going to talk a little bit about, you know, why I'm thinking that and, you know, kind of what I'd like to see. So, let's kick it off.
Here's a puzzle. You know, base64 encoding is something that is very common to many applications. We see it everywhere. In Node, you know, we've always had this, you know, buffer from hello to string base64. We can, you know, take a base64 encoded string and get our buffer back out from it.
What is the right way to base64 encode data from JavaScript? The answer is all of them. Node's API buffer from, Deno's API, or something from NPM. However, having so many different ways to do something fundamental adds friction and difficulty to developers. Base64.js module is widely used, even though Node has a built-in option. None of these are the right way because there's always a different way of doing it.
But, you know, what is the right way to base64 encode data from JavaScript, right? There's this, you know, people that have been developing the browser for the longest time, you know, are probably familiar with this B2A function. Is it the right way? I mean, it's the only standard we have for base64 encoding, but honestly, it kind of sucks. It doesn't handle everything you need and it just kind of works okay. But we really can't change it because of backwards compatibility and all that kind of stuff.
So, what is the right way to do base64 encoding in JavaScript? Is it Node's API buffer from? Is it Deno's API, you know, where you import this encode function from their standard library? Or is it, you know, is the answer something out on NPM, right? Where, you know, you have to go out and, you know, NPM install some module once you find it, once you find the right one. And hopefully, you find one that is, you know, well maintained, has an active, you know, at least, you know, an active contributor that will keep it up to date and keep it moving and ensure that it keeps working with Node and different Node versions or different Deno versions or, you know, other runtimes.
You know, and what is, you know, once you have the basic mechanism, you know, which API here is the correct one? Unfortunately, the answer is all of them. All of them are the correct way, you know, but having so many different ways to do something that is so fundamental it just adds friction, adds difficulty to developers who are writing code that runs on the web. Amazingly, this fourth option, this Base64.js module, you know, has over 30 million downloads per week from NPM and has over 1,300 dependents. And a lot of those are Node applications, despite the fact that Node has this built in, right? But also a large number of those dependencies are, you know, browsers, browser applications that, you know, that all they have to rely on built in is B2A. And, you know, B2A itself is lacking in quite a bit of functionality. So, you know, the answer is, you know, all of these are the right way, but none of them are the right way because there's always a different way of doing it.
We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career
Comments