Javascript Should Come With Batteries

Hey, folks. Thank you all for being here. I know it's very late. You're probably all very tired and want to go home. So I'll tell you something about not React, for once. You've probably had a lot of React talks today because we're at a React conference. But I don't know. I'm going to talk about more JavaScript because, hey, React is really just JavaScript, right? And why don't we talk a little bit about JavaScript?

So my talk is JavaScript Should Come With Batteries. And let me explain... Actually, let me first introduce who I am. That's probably useful. So I'm Luca. I'm a software engineer at the Deno company. Some of you may have heard of Deno. If not, I'll get to that in a second. I work on various things related to Deno. I built a frontend framework for Deno called Fresh, that some of you may have seen. And I do a bunch of standards work at T-SYS39, standardizing the JavaScript language. And at WhatWig and W3C, standardizing things like Fetch, HTML. And I'm a co-chair at Widger CG, which is a community group at the W3C where we try to make server-side JavaScript runtimes more interoperable. So making node.js work better with Deno, and Deno better with CloudFlow Workers, with RUN, with whatever, right?

So about my talk today. I have this premise that I'm going to try to argue, which is that JavaScript is too bare bones and this is bad. And what I mean by this is that JavaScript doesn't really have an extensive standard library or default tooling. But rather, everybody sort of has to pack everything they want in their project together themselves. And this means that if you're setting up a new project, you have to go stare at a table like this and fill in the right-hand side. I need a formatter, so let me choose a formatter. Do I use Dprint, do I use Prettier, do I just use auto-formatting in VS Code, or do I use none? Linting, testing, do I want to use TypeScript or not? If so, now I need to have all of my tools support TypeScript. Maybe I want to set up benchmarking, documentation generation, if I have a library. And then you need to pull in a bunch of packages for things that you're going to need to do. You need to pull in a package to do YAML parsing because you have a config file that's written in YAML that some other team gave you.

Or you have some service that you're calling and it fails very frequently, so you want to do that with retries, you need to pull in some library for that. And this ends up with every tool and API that you need, you need to have one more package that you install.

So you have this very large package.json folder. And this becomes even more complicated because there's so many different tools out there. When you want to use them together, things become even more complicated. You can install ESLint. I hope your beer's fine. So when you install ESLint and you want to use that with TypeScript, that doesn't work out of the box. You need to install another tool called TypeScript ESLint. You don't just install one, you install two packages, you add a bunch of stuff to your ESLint config file, you need to have a config file for ESLint also. Same thing with JSX, you need to add plugins for that. ESLint is pretty good about ESM.

One of the standout tools here regarding ESM support still couldn't use config files up until a couple weeks ago, months ago, I don't know. But there are some really bad ones, and I don't mean to hate on the folks building Jest. A lot of this boils down to other projects that they use not supporting tools well, but Jest and TypeScript, getting that set up, not fun. You want to throw JSX into the mix, you need to set up more config. Here, you're not even setting up config for Jest, you're setting up config for Babel? It's like, okay, I guess I'm using Babel now. And ESM, just don't use ESM if you use Jest. If you want to test in ESM, just don't use Jest. And then your node module folder looks like this. You have 100 dependencies in your package.json, and a 300 megabyte node module folder. And you just have a config file, and then you have a project like this, right? And imagine coming to a company and you download the repo, and you want to start working, and you're greeted by this. This is not fun. This is not something you want. You just want to get set up and everything just works. And you want to start a new project, you don't want to have to set this up. You just want to have it work out of the box. So how do we solve this? And as a JavaScript developer, you may be wondering, like, yeah, how do we solve this? But if you sort of float around other language ecosystems sometimes, you can see that some ecosystems solve this really well. Some do it very poorly, but some do it really well. For example, Rust and Go.

And I'm using these specifically because they're about the same age as JavaScript, so you can't say JavaScript is old or Node is old, and because of that, it doesn't have this. Like Go was released the same year that Node was released. And Rust was released just a couple years later. And these have very extensive standard libraries and tools built in. Like, formatting comes out of the box. Testing comes out of the box. Everybody uses the same test runner. And I mean everyone, right? This is not 80% of people use the same test runner. Everyone uses the same test runner. And this is really great, because you can get started on a new project without spending any time on configuration. You open up a folder, create a file, write some code in the file, run the file. And that file now has formatting, linting, testing, all of that set up out of the box. Because it comes with a tool that you use to run the file. If you're building in a team, this means you don't have to have discussions with your team about, like, do I like ESLint, or like Roam, or whatever, right? Whatever is being used that day. Everybody uses the same thing. No discussions. And switching between companies and even teams within a company becomes really easy. Because if you know the tools from one project, they translate exactly to any other project. Because all other projects use the same tooling.

So let's do something about this. Why don't we get to this state with JavaScript? This is something that my boss, Ryan Dahl, thought like five years ago at this point. Ryan Dahl, if you don't know him, is the original creator of Node. In 2010 he released the first version of Node actually in Berlin on a stage not too far from here. Ryan went on to use Go for a couple of years, where he saw all of these nice built-in tooling things. And then came back to JavaScript in 2018 and realized, like, there was a problem here that needed solving.

So in May 2020, ten years after the original release of Node, we released Deno to fix some of these problems. And I want to talk to you a little bit about that, show you what it looks like, and what kind of experience you can have when tooling just comes out of the box.

So a little bit about Deno. Deno is a next-generation JavaScript runtime that's incredibly simple to get started. And you don't have to take my word for this. I will give you some code demos in a second. It really is. Secure by default, native support for TypeScript and JSX out of the box has built-in testing, linting, formatting, a language server for VS Code, documentation generation, you name it, single file executables, a bundler, go on and on, right?

It has web standard APIs built out of the box, so, like, if you want to use... If you're coming from the front end, which most of you probably are, you're front-end There's a lot of APIs in there that you just know. If you want to make an HTTP call, use fetch. If you want to stream some data around, you use web streams. If you want to, like, I don't know, store some strings in a key-value database somewhere, very little, you use local storage. It's backwards compatible with Node.js and NPM, since pretty recently. And it's used by a lot of large companies. We have, like, I think the website says 250,000 monthly active users, but I don't know. It's a couple months old at this point.

To install Deno, you just run a single command. And this is really all it does. It really installs a single binary. There's no lib files, openSSL, anything you need to install. Just a single binary. And then you can get started. And then this is what your setup Deno project looks like. There's nothing in the folder, right? To get started, I create a file. And I'm gonna create a TypeScript file. I told you I can run TypeScript out of the box. So create a TypeScript file. And I write some code in here. And let me turn off Copilot, so it doesn't annoy me. Did that work? It did.

Fantastic. And then I just run TypeScript. And this works. And this is actually TypeScript, right? Like, I can put this in here, and it still works. So actually running TypeScript. Yeah.

So that's very basic things. Now you're wondering, like, okay, I can console log. This is not very helpful. I can do nothing by just console logging. So let's do some I.O. Let me read a file from disk. There's a nice file that's stored on all UNIX systems called EDC password. Which unlike the name suggests, doesn't actually store my password. But it's fun to log out. So let's log that file out.

Did Copilot not disable? I thought I disabled this. Hmm. Okay. So if you do this, you're actually gonna see something else. Look down here at the terminal. So I ran... Let me zoom out one. I ran Deno. And it asked me to give permission to read this file. And this is what I mean with secure by default. So in the browser, if you create a website and you want to send user notifications, you can't just do this always. Right? It pops up a prompt to the user that asks the user, hey, do you actually want shady website 36 to send you notifications? Because probably you don't. This is really helpful. If you're running some random script off GitHub, and you don't really trust the author, just run it.

If it tries to do something bad, you'll see. I'm gonna allow this. I'll allow this. And there we go. It logs out my EDC password file. So that's IO permissions. You explicitly opt into them. You can either do this via the prompts like I just showed you. You can also pass flags. So I can do deno run, dash dash, allow read, minots, and this bypasses the permission prompt. And this is very granular, so you can also say read only from EDC or only from this specific file. However you like.

Web standards. I told you we have a bunch of web standards built in. So let's just fetch something off the network. Like, I don't know, example.com. And you're gonna look at me here, like, writing a fetch statement. I'll do this every day. But what's kind of cool is, like, Deno uses web standards not just for things that are obvious, like fetching HTTP, but even for things like writing to standard out. So Deno's standard out is actually a web stream. Like this writable. It's a writable stream from the web. Which means that I can do response.body.pipe to all web APIs, right? This is all web APIs. I wait that. If I run this... It pipes streaming the text to my console. So really you use web APIs all over the place. And we take this pretty far. So we, like, very much try to work with other people in the space. Like with node and with Cloudflow workers and with Bun to sort of get them to all adopt these same APIs.

So that code that you write for the frontend can work on your server. This is really useful if you're doing server side rendering and hydration. You want to be able to share the same code between the two. But also if you write code that needs to be portable across different server side run times. And we have a community group at the W3C, a standards group that's set up to do this, where we sort of talk about these things and figure out what APIs everyone should support.

One more little demo I want to give you. Let's do some NPM imports. So I told you it's backwards compatible. What's more backwards compatible or more interesting for backwards compatibility than Express? Everybody knows Express. So Deno can import Express, obviously. Let's build a little HTTP server. So to import NPM packages in Deno, you just write an import statement and you prefix them with NPM colon. And if you want to import a specific version, you can do that using an at. And you don't see, I don't have a package JSON here, I don't have a node module folder here, nothing. Just my one line of code here. And I can create an app. And you can actually see I have no typings here, because this is one of these other fun things with the existing ecosystem is a lot of old packages don't have types out of the box. So if I want to include a type, I have to tell Deno that I want those types. And this is the same thing you do in a package JSON, where you specify your types with, like pulling them from at types. So I'm going to pull the types here from types slash Express. And now you can see I have types and documentation.

Okay, so let's write a little server that takes a request and a response. And I forget what the API is, send? Yes, send. That just sends out hello world. And you could send anything here, right like you could render some JSX. If I have time, I can show you that later. We listen on a port. And let's log out that the server has started. Running on HTTP localhost 8000. Okay.

So let's run this. I trust Express, so I'm just going to run with all flags to not get permission prompts. I've shown you those already. And you can see, started up a server. It pulled an Express. Again, still no node modules folder, still no package JSON. And I open this, and it runs. Hello world.

Okay. Let's talk a little bit about the tools that are built into Deno. So I told you there's tools built in, and actually you're seeing one of them working right now. This little orange squiggly line, under request here, is actually Deno lint that says request is never used. If this is intentional, prefix it with an underscore. There's a linter that just comes out of the box, no configuration necessary. And I can run this. Deno lint reports the same error. I can fix it. And actually you've seen the other tool that I'm going to demo already also, the formatter. If I go and mess up my formatting here and format with Deno, formatted. No config necessary. And I can do the same using the command line. And if I want to run this in CI, I can have a Deno format check that checks that you're formatted to failed CI if you're not formatted. All just comes out of the box. I don't have time to show test and invention, all that kind of stuff right now. But yeah, you can look at those on the website. They're very easy to understand too.

There's one more really cool thing that I think we have built in, which is a database. And you may be wondering, like, why do you have a database built in? And this is really part of that same philosophy that we should have everything that you need to develop an application just built into the runtime. So most people do not want to have to go through and choose what database they want. They just want something that works, that is easy to set up, that doesn't require configuration.

And Deno.KV is just that. It's a key value store, ACID compliant, so it sort of has the same consistency as Postgres and other SQL databases. It's really built for serverless applications, built for running on the edge, has built in support for task queues and scheduling, cron jobs if anybody's familiar with that, has support for key watching. It actually says coming soon, slightly older iteration of this slide. We just released that last Thursday? Oh, that was yesterday. Yeah. We released that yesterday. No setup, no install, no import. You can just use it.

So let's integrate a little KV database in here. So I can Deno.OpenKV. This opens my database. This is all I have to do, right? I have a database now. And now I can... Let's add a visitor counter. You know those sites from, like, the early 2000s that had a little visitor counter at the bottom? I'm gonna add one of those, because I think they're cool. So let's have a key that we call visitors. And we're gonna increment it by one every time you load the page. And this is an async operation, so we need to await it. And then this needs to be an async function. Let's grab the new value after we've set it. So await kv.get. We're gonna get that same visitors key that we just set, and just print that out. That's the response. So if I could type... It's getting kind of late already. Okay. So, Deno.Run. Main.Yes. Oh! And actually, this is an unstable feature, so I need to do this.

And where's my... There we go. Okay. Visitors, one. I'm the only visitor to this page. Weird, right? And every time I reload, increments by one. And if I shut down the server and start it up again, it resumes where it left off. So this is an actually persistent database. This is not some in-memory stuff.

And what makes this really cool is the next thing I want to show you, which is how we make money. And you're gonna think, like, why is this relevant? But Deno is an open source project, and I think it's really important to be very transparent about how open source projects make money, because otherwise you're gonna think we just are giving you all this free, cool stuff, and at some point we're gonna say, hey, hey, actually starting next Monday, you're all gonna pay us 10 bucks a month, and otherwise you can't use it anymore. That's not how we want to do things. So everything you've seen so far is totally free, totally open source. MIT license on GitHub. You can contribute to it. It's written in Rust.

But we provide a hosting solution for Deno called Deno Deploy, which is a hosting platform not just for Deno, but for all serverless JavaScript. You can run Node projects on there, too. And it works really great for Deno, because it runs on the edge, sort of similar to Cloud Flare Workers, but it has built-in support for Node modules, it has this built-in global database I'll show you that in just a second running all over the world. Deploys directly from GitHub, so you have a very similar experience to when you're deploying from Vercel or Netlify or any of these services where you're pulling right from GitHub. Now we have an offering for enterprise customers that want to just run some JavaScript as part of their product. If any of you are building SaaS products that use webhooks, why don't you just let users just write some code directly in your product rather than having to webhook out to them? So yeah, this is part of our sort of philosophy that we want to make it really easy for you to build and test your projects locally, and then very seamlessly be able to deploy them to either our platform, or to like Google Cloud Run, or Vercel, or Netlify, or really any place, but then have them backed by sort of much more globally distributed APIs. In the same runtime, same APIs, but just backed by systems that are built for scale rather than systems built for you to run your tests. And an example of this is that DenoKV database that I showed you earlier, locally, it's backed by SQLite. And when it's deployed, it's actually backed by FoundationDB, which is the same thing that all of you use when you use your iPhones every day, right? Like, iCloud is backed by FoundationDB. It's a very, very scalable, globally distributed, or globally distributable database, very robust. And I have like zero seconds left, so I just wanted to quickly demo how to deploy this. We have this tool called DeployCTL that lets you deploy a project. Let's count here. 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13.

Okay, there's a URL. If you all visit this URL on your phone right now, you're going to see a visitor counter. So how high can we go? I'm visitor number one. Anybody daring to be visitor number two? Still number two. Nobody's gone there yet. Oh, somebody else has gone there already. Come on, people. We need to accelerate this. This needs to be one of those skyrocket moments. 44. There we go. This is what I'm talking about. Okay, so, visitor counters. Globally distributed, scalable, right? This just works. And 13 seconds. I didn't configure anything here before. I created a project, created a database, and deployed my service all in those 13 seconds.

So quick recap of what we've done here. In a matter of 20 minutes, I've started a new project from scratch with a formatter, a linter, a database, NPM dependencies. So I wanted to test some tests, benchmarking, documentation generation, compiling a single executable. We deployed it to the cloud and we used no tooling other than the tooling that comes out of the box with Deno. I didn't have to write a single configuration file. And we've so far used 16% of the tools built into Deno, right? There's a lot of stuff that we give you. And that's batteries included. And I think this is where we should really go with JavaScript. Not just in Deno, also in Node, also in other tools. Tools should come out of the box with all the stuff you need to sort of build a successful product. Yeah, significantly increased productivity, but I think much more importantly, significantly increases fun while you're programming, right? Nobody likes building config files. And if you never have to build config files, you can have much more fun building things you actually like. One more plug.

I didn't talk about JSX at all or React or anything. So I needed to plug a front end framework to sort of make this relevant to this conference. Fresh! Fresh is a front end framework built for Deno using Preact rather than React, but it's all the same anyway. Sorry. No, it's not. I know. Again, no configuration, TypeScript support out of the box, zero runtime overhead. Can do service side rendering on the edge. Yeah, Fresh.

And yeah, that's it. One last thing. Check out Deno if you want to try deno.deploy. Deno.com.deploy. And if you want to join our Discord, discord.gg.deno. And that's all I have. I have a bunch of stickers, though, and I need to get rid of these. Otherwise, my DevRel person's gonna get mad at me. So please pick up stickers on your way out. Thank you.

Okay, so there is a bunch of questions, which I'm holding in my hand. First thing that I have for you is why do you think is the reason that Deno hasn't been adopted so widely? Yeah, that's a great question. So I think part of it is that when we started out with Deno, we really started focusing on all of the things that we wanted to get where we wanted to be different than Node. And we didn't really care about compatibility very much because we just wanted to make sure that the end goal, the state where you're getting to is really good. Like we need to have a good formatter, good linter, good testing library, good runtime. And then over the last couple, like the last year or so, we spent a lot of time working on Node compatibility. So as you saw, I could just run express out of the box. And it's not just express. I can run a lot of npm packages just out of the box. And sort of this backwards compatibility is really required for people to adopt something at scale. So in the last year, we've seen a tremendous amount of growth.

And I think, yeah, that'll accelerate. I'm sure you're gonna hear more about Deno next year and the year after, and hopefully the year after that.

Okay, one question that has actually been asked a bunch and I had to delete all the other ones because this has been asked a bunch of times is can you... That is not the question. I'm very good at this. Okay, there we go. Can you customize the linter? Yes. If you met a JavaScript developer. Guys, why? No linter configuration. This is out of the box. Okay, no, no. I'm re-support configuration. There is a config file that you can set up if you want to have a configuration. But really, we try to make the default work well for everyone. And this is the same path that Go and Rust take, where there's a default set of rules that everybody should probably use because they're good baselines. You can add upon that, or if there's a rule that you really dislike, you can disable it. But don't personalize your linters, folks. Only add rules. Don't remove rules.

Okay. Why? Because... Oh no, you're talking about linting, but the formatting. Can you also... Oh, for formatting. I'm sorry. Yeah, I don't know. Does it work with Angular though? We've had too many fights about formatting. So that's why you can change it? No, you can't. You can't change it. There's like five options in Prettier.

You shouldn't. Just everybody use semicolons, please. Honestly, whatever you tell me to do, as long as... By you I mean Prettier tells me to do, I'll do it. Just don't make me do it manually. Yeah. That's my only concern right now. Exactly. That's sort of the idea. Like, we tell you what to do and just go with it. It's probably a good idea. It's probably fine. No one's going to die.

Does it work with Angular, though? But are you working on it? Are you working on compatibility with AngularJS? We're working on all the compatibility. And I'm sure Angular will work at some point. I don't know if it works right now. I've never tried. This was a joke question. I do legitimately think that Angular may work, but you have to try it yourself. No one wants to do that. I think this is very... That was a joke question. Well, I disagree. But it was on the top, so I had to... It's a democratic system and I had to go with it. Fine, fine, fine.

What are your thoughts on Bun? Thoughts on Bun. I think it's cool to see more runtimes in the space that are trying to do something. Node really needed competition. When Deno was announced, Node did not have Fetch, and Node has Fetch now, and I don't want to say it was all Deno's fault that Node has Fetch now, but it was Deno's fault that Node has Fetch now.

I think other runtimes pushing all the runtimes in the right direction is a good idea. So excited to see it. I lost the question, but someone was asking if it can run Doom. Can you run Doom? So this is actually a fun one. I'm pretty sure somebody ran a WASM build of Doom in like a web GPU frame that somebody had built with Deno. So you can run Doom in Deno. It legitimately might have happened. I don't remember if it was Doom or some other game, but I think it was Doom. It's always Doom. It's probably Doom. It's most likely Doom. I don't think you can run Skyrim, though. Nope. Nope. Unlikely.

There was a question also about TypeScript, and also about this in a little bit. It's like how are packages managed then? Like there's no need for package.lock or anything, so like... Yeah. So actually one thing I didn't show is there's a lock file that is generated when you... So the project that I showed didn't have a config file because it's a single file script, right? This is the kind of thing that you use when you want to write some migrations for your database, or you just want to rename some files. But in a real project, you would still have a Deno.json file that specifies an import map. And that map is actually web standard that some of you may know which allows you to remap your specifiers to specific URLs or specific versions. And that's how you manage dependencies in Deno using import maps. And if you have that file, it will actually also generate a lock file because lock files are important and you should use them.

Oh, okay. So if you do that, there was also a bunch of questions about like you don't have to write like every time the number of the dependency. You can just write it there once and then by default, you'll import that one that's in your... Yeah. Yeah. Yeah. So that's like a web standard thing, right? This is not something specific to Deno, but it's a web standard import map. So you can even use them in the browser.

Oh, okay. Cool. That also answers this question, which is how do you have an overview of all the dependencies using the project? Yeah. And actually there's also a sub command. Deno info gives you a nice graph of all of your dependencies.

Okay. Final question is, can you use Deno with something like Next.js? Yeah. Or Astro. So Astro, definitely. There's an Astro adapter for Deno and it works pretty good. For Next.js, there was like some problem that we were fixing last week. I think that's fixed now. Maybe in the next release, Next.js will work in the dev mode. I think the build output already works, but there was something with the dev mode that wasn't working. But probably soon. Yeah. Oh, but the idea is to support it and it's probably going to be in the very short term. Yeah. If anything doesn't work, it's always a bug. So feel free to open issues if things don't work.

Okay, perfect. Thank you so much. We're out of time, but Luca will be in the same spot with the other Q&A, where the other speakers were. So feel free to ask him any questions you have. And yeah, thank you so much. Please take your stickers. I already took three. Fantastic.