Paul: Hi there and welcome to Pod Rocket. I'm Paul. I'm your host today. And today we have Luca Casanado joining us. Welcome to the podcast, Luca. Luca Casanado: Hey, thanks for having me. Paul: So Luca, you're a software engineer and contributor, creator of the Fresh framework, which we're going to be talking about today. It's a new way to get your feet into web development, a new way to make really fast modern websites. And it runs on a really cool runtime, which is this Deno project, which I, myself, haven't really looked into much, or I'm really excited to pick your brain and learn about it. Luca Casanado: Yeah. Paul: So yeah, let's get right into it and talk about Deno, because we're going to get to Fresh and we're going to talk about how we can create websites and why it's so special, but at a core it's running on something different, which is Deno. So could you talk to us a little bit about what Deno is and why it's special? Luca Casanado: Yeah, so Deno, or Dee-noh, actually how [inaudible]. Paul: Dee-noh. Okay. Luca Casanado: Yeah. It's a long argument on if it's Dee-noh or Deh-noh, but I think we've settled on Deno now. Yeah. So Deno is a run time, which is meant as a replacement for other server side, JavaScript run times, Node.js. It's built by the same people that originally built Node. So Ryan Dhal, who originally wrote Node together with Bert Belder and Benward House, and some other folks, went like eight years after having built Node, reflected on everything that went wrong with Node and everything that could be improved with Node. And out of that, they envisioned a new run time with a bunch of different semantics that are different from Node that would provide a better user experience. And that is Deno. And the core selling points of Deno are that it feels much more modern to use. And that's a very wishy washy thing to say, right? I can say this feels more modern to use, but if you've used Deno, you'll realize pretty quickly that it feels a lot like you're writing for you're writing a modern website because it is very heavily based on web standards. It doesn't have a proprietary HTP module. But it uses fetch to do HTP fetching. It uses ecmascript modules to do module things that you would use required for Node. And it imports stuff from URLs. You do browse in the browser. It feels very webby. And in addition to that, it also includes a bunch of tooling, which you don't necessarily have in Node out of the box. Things like a test framework, a linter, a formatter, editor integrations, documentation generation... I'm probably missing half of the things. A bundler. There's a whole bunch of stuff in there. I can run Deno dash dash help to see it all. But essentially it's meant to be a fully integrated runtime, which allows you to do your entire web flow of building a website entirely with a single tool. Paul: If I was writing a script to do something, let's say I wanted to sort out a file, is this something I'd usually call upon Python to do? Like, because it's really good at that IO stuff. Would it be appropriate for me to just reach for Deno right away? Luca Casanado: Yeah, I think so because one of the selling points of Deno is that it's very simple to use. In Node, for example, if you want to have a project, you would import some dependency. You have to create a JavaScript file. You have to create a package json If you want to write in type script, you have to set up TSC and do all this crazy stuff. With Deno, you just create a .ts file and then denorun.ts file. And if you want to import some dependencies, you just import them by a URL in the file. So it's all very self-contained. It's really easy to get started with. Paul: Are there any things I should watch out for in terms of plug-ability or sustainability on other cloud platforms if I want to roll with Deno today? Luca Casanado: Yeah. So Deno, it chips as a single binary, which you can run on any Linux machine, which is relatively recent from the last eight years or so. So you can dockerize Deno and run it on any cloud provider that supports running docker containers. You can run on Fly.io. But you can also run Deno on our cloud hosting service, Deno Deploy. Which is an edge run time, which is pretty similar to CloudFlare Workers, which allows you to run code anywhere across the world, really close to users. Paul: Deno Deploy. I haven't heard of that one. It's fun to shop around for serverless offerings because they all have a different basket of eggs of what they're going to offer you. My experience with CloudFlare Workers, the thing that really makes me feel constricted, is the one megabyte package limit. But more importantly, it's a 32 second auto timeout on any sub requests that I had in my worker. Does Deploy have something different or is it the same? Luca Casanado: So Deno Deploy also has limit on the default size or on the bundle size, but it's 20 megs. Paul: Ooh. Luca Casanado: So very unlikely you're going to run into that, especially because the way that the file size is calculated is it only takes to account the ... whatever. I can get into exact details, but essentially you don't have to ship your entire Node modules folder like you would with like AWS Lambo, for example, because it doesn't have a Node modules folder. You import the specific files that you need. And only those count towards the files size limit. And on the sub requests, we actually don't have a hard limit on sub requests. And we don't have a hard limit on timeout either. There's a CPU time limit, which you can increase by operating through Pro account. But yeah, there's no hard limit on you have to be done after 30 seconds. Paul: Enjoying the podcast? Consider hitting that follow button for more great episodes. That's music to my ears. What a thing to have to engineer around. It's a great runtime environment, man. It's so fast, but that 32 second time out, it's good to hear these other options to look for. Because it's really nice to have a serverless environment where you don't even have to worry about the Node modules folder. Yeah. You just push it on up. Luca Casanado: And actually, part of that, that we don't have the Node modules folder, it allows our deployments to also be insanely fast, because we don't have to pull down a bunch of packages from NPM during a CI step or anything like that. And we don't have to do a TSE build because Deno's just able to run type script natively. So if you write your project in type script and import some packages, and push them to GitHub, you'll have a live deployed URL in three to five seconds. Paul: Oh, it sounds like this is a really great use case for Deno. Because of the fact I can run it all natively, your cold start time's going to be shorter. Luca Casanado: Yeah. Paul: That's awesome. Benefits right off the bat. Look at that. I'm sure there's a plethora of things that we could go into about little optimizations and reasons why we should look into Deno, but let's take a little bit of a shift and talk about Fresh, because I think that's one of the main things we wanted to get into today. What is Fresh? What's your elevator speech on Fresh? Luca Casanado: That's a great question. Fresh is a modern full-stack development framework which is built to be fast and built to be easy to use and build to be as simple as humanly possible. All the bells and whistles are web standard bells and whistles. There's no proprietary bells and whistles. And it's engineered to be the only way for you to do things is the right way to do things. The happy path is also the fast path, which I think is something which a lot of frameworks out there have not done a great job of making the easiest path also be the fastest path. And fast as in both developer experience, but also primarily as user experience. If I'm loading a website, built with Fresh, it's going to be fast. And it's pretty difficult to make it slow because It really pushes you in a way of making things fast. Paul: What's a way that a traditional framework makes it slow that Fresh changes? Luca Casanado: Yeah. So one of the big selling points of Fresh is that in many traditional frameworks that do server-side rendering and clients [inaudible] maybe I should actually explain slightly more what Fresh actually is. Fresh is the framework which does server side rendering on the edge for all pages by default. That means that instead of shipping an empty shell to the browser and then hydrating it on the browser with the client side code, you render the entire page on the server and then serve the entire rendered page to the user. And then you can still hydrate it on the client. I'll get into that in a moment. But one of the big ways it's faster is just because server-side rendering is much more reliable in terms of performance, especially on slow networks compared to pure client side rendering. There's other frameworks, which have tried to do something like this. Remix is a great example where they're doing server-side rendering by default. And it's very great that we're moving in this direction, but there's still downsides that Remix has. Namely, that you render your entire page on the server and then it ships all of the code that it used to render that page on the server. It chips that code also to the client and then renders the entire page on the client again. Which, if you imagine you have a blog post, a page which shows blog posts, you would render that blog post on the server. So you would read in your markdown, transform into HTML, I don't know, pull some comments from a database to show a comment list or something like that. You ship that to the client and then the client, you have to load the markdown parser or JavaScript library, the HTML like generator from that markdown parser, you have to load the markdown and then recompute all of the stuff that is already done on the server and renders it on the client again. Even though, the markdown is not changed in the time that your servers said rendered versus when you client side render. So that's just a bunch of lost CPU cycles, essentially. It's wasted battery on a mobile phone. It's not a great user experience. So what Fresh does instead is, it doesn't ship your entire rendering pipeline to the client by default. Instead, it only ships the pieces of the rendering pipeline to the client that are actually interactive. So for example, back to this blog post example, you have a static blog post, but you have a comment section underneath where people can type in comments and you want to have these comments be live updating. And maybe you have some fancy interactive editor that you can type your comment into. You want to have clients that interaction you want to have JavaScript to hydrate this and make this cool. So what you can do with Fresh is just ship the JavaScript for only that comment section to the client, but not have to ship all the JavaScript that was required to render the blog post itself. Because the blog post is static. It doesn't change. You don't need to render that on the client, but the things that are actually dynamic you do. So that is served to the client. Paul: So in general, I feel like what you're describing is you're shifting your mentality to be as server-side as possible. You want it to be as flattened and pre-rendered as possible, and then minimize those, I don't know, for lack of a better term, functional components, right? That you're going to ship over it. Okay. Luca Casanado: Yeah. So what we call them are islands, those components. Because they're essentially islands of dynamic content in a sea of static. Like, in a sea of static HTML. So we want to try to create as much static HTML as possible on the server, and then only shift the JavaScripts client that's absolutely necessary to make something interactive. And ideally also with fallback. So if you have a browser, if you're on a slow connection and the JavaScript is just taking a really long time to load, and there's a form, you can still submit the form and it'll still work using a regular form component, even if the JavaScript isn't loaded. And then it'll progressively enhance if the JavaScript is loaded. That's the kind of thing where we really try to lean on the platform as much as possible. Paul: So do you think that this is going to be a struggle for developers today who probably think in the more traditional MBC or whatever they're used to, to transition into this? Did you come from the typical traditional land of everything functional in JavaScript you're going over or did you start from a more server-side, pre-rendered background? Luca Casanado: Yeah, so actually I started pretty much from static generation, so where you'd have a build step and you generate static HTML. And essentially this is that except for you're doing the static generation dynamically rather than once at build time. Right? So it's actually very similar to something like PHP. And a lot of people have compared it to PHP. And actually, I don't mind that comparison because I think it's a good comparison. PHP is very server-side rendering heavy and if you want to have something dynamic, you have to explicitly write some JQueries to make some components interactive, except for Fresh makes this much easier. You would just write JSX components on both the client and the server. And it'll just figure out. It can use the same code for both the client and the server. Paul: What would you say to people who are interested in approaching this, but they have anxieties in their mind about this is a whole new paradigm and I'm not going to have a sea with islands. I'm going to have America with lakes. So what do you say to people who have that anxiety coming into this and how they can prime themselves to really using the best things you have to offer? Luca Casanado: It's obviously mentality shift. When you go into this, you have to really start thinking about writing websites differently. You have to think about, instead of you're shipping JavaScript to the client, instead of shipping, essentially a game engine or a renderer to the clients that renders out your entire page, you ship out the content itself. And that's quite the paradigm shift. A lot of people are not familiar with that anymore, even though this used to be really popular. But even if you have these huge islands where essentially your entire page is an island, you can start there. Right? You can start at having one big island and then scale it down over time, where you realize, actually this component is static. So I can move that out of the island. I can turn that into a static component. Fresh was not originally built for that, but it's going to work really well anyway. Paul: Folks coming from Remix, is this going to feel familiar to them if they're trying to explore Fresh? Luca Casanado: Yeah, I think so. The templating system, the way it works, is very much inspired by Remix or the data loading framework more specifically. It's very much inspired by Remix with the handlers and the way data is fetched. And the templating is very or not the templating, sorry. The routing is very similar to Next.js people who've used Next.js are going to be very familiar with that. It really tries to pull a lot of great ideas from a bunch of existing frameworks and combining them into something new. If you've used Next.js and Remix before, Fresh is going to feel pretty familiar. Paul: Awesome. Okay. If we can get into the weeds a little bit. So in Next, we have server-side props. That's like a thing I can use to get the server-side values and in any work I want to do. Can we talk about what the analog for Fresh is and how developers might actually start creating these actual separations of islands and what's an island and what's not? Luca Casanado: So the most basic way to create a page in Fresh is you scaffold a new project. And that's going to generate a routes folder in your project directory. And that routes folder is going to contain a bunch of TSX or JSX files that describe each of the routes that a user can visit in your page. And those routes, they can export a few different things. The first thing they can export is a default export, which is a JSX component. And that JSX component by default is just rendered with no data properties as arguments if you don't specify a data loader. But what you can also export is something called a handler function. And a handler function is essentially, if you've used express before and you do app.use ... Paul: A middleware type of thing? Luca Casanado: Yeah. It's sort of like a middleware type of thing, where essentially you get in a request and you return a response. So essentially, it's just an HTP handler. And what it provides is, it additionally provides a context.render function inside of this handler that you can use to render out your component. So what you can do, if you want to do data loading, is you create this handler function, you load your data, and then you call context.render with that data passed in as an argument. And that's going to generate a response object for you. And you can just return that response from the handler. That's like the simplest data fetching. And then there's more advanced ways to do the data fetching, like you can have middlewares, where you can have the same data fetching for multiple different pages that start with the same path segment or something like that. Paul: I feel like putting things in middleware oftentimes ends up being where I end up, because you have some functionality that you just keep re-implementing over and over again. And even if something was technically not a middleware, I just always find it efficient to put it there, because then you can reuse it everywhere. It doesn't really matter. It's globally available. Okay. So this handler is sort of paradigm and it really sorts it out under the hood, right? Going to sort out what life cycle and where to grab the data at what time. Luca Casanado: Yeah. So, because Fresh does not have a full page render on the client, all renders happen on the server, there's also no client side navigation in Fresh, which means that if you do data fetching, we never have to ship the data that you fetch to the clients to then render something there because you only have to do it on the server, right? Because you always do server-side rendering. If you're using islands, you can pass props to those islands and then that'll get sent to the client. But the data itself, or the page that you return from the handler never has to go to the client itself. Paul: That's awesome. I mean, you should typically, I guess, design it in that way, but if you have the data go on the server side, the big thing is I remember I was doing this analytical app one time and all this data came through and there was this engineering challenge about around how do we get the Chrome run time to make this palatable? But if we had a private product end server, you could throw as many Kubernetes pods as you want at that thing and just let it rip. So yeah, paradigm shift. It's just different to think of doing the website, your whole life cycle, in this way. What do you think is one of the coolest implementations of this new way to think about the new paradigm of server-side rendering heavily, heavily on the server? Is there some sort of application or website you've seen, particularly made with Fresh if you can think of one, that would be slow or not possible if you did it traditionally? Luca Casanado: Yeah. So there's like you can do anything with client side rendering, right? And the many downsides just going to be that it's slow often, but there's a bunch of sites which are written in Fresh. The Deno land homepage is written in with Fresh. The entire genome module registry, Denoland/x, where you can upload modules from GitHub and serve them. That's using Fresh. Our merch store, merch.deno.com also uses Fresh. Our blog, deno.com/blog, also use users Fresh. These are all things where we could have used Next.js or we could have used, I don't know, Remix or something like that. But specifically, for example, for this registry thing, there's a bunch of modules that could added every day. If we had to do a static generation step with something like Astro, every time a new module is added, that would be completely unpalatable. We'd just be spending the entire day regenerating all of our content, especially if we have millions of files. We want to have code views, rendered code view, for all of those files. We need to do that dynamically. We can't do that statically. And we could also do that on the clients, but then that would be really slow for mobile connections. Let's say you have a, I don't know, 20 kilobyte by JavaScript file. You send that to the client. That's already quite a bit. Then you have to send an entire JavaScript [inaudible 00:23:02] do syntax highlighting. You need to actually do the syntax highlighting, render it into the dom. If you're on a Moto G4 ... Paul: You're dead out of water. Yeah. Luca Casanado: Sitting there for 30 seconds waiting for that. Yeah. That's just not a good experience. And this, it just sends you the HDML with all the CSS tags, the right place. And there's nothing else for the browser to do other than to just render that page. Paul: I guess this is a funny question, because I'm asking, wow, what websites would be slow? What ones would benefit from this? It's every website would. We're stuck in a bubble of everybody has an iPhone and a MacBook, but you go to the other 90% of the users around the world and they're running Android and they're running Samsung 5 and they're running a Windows XP computer. Windows XP still shockingly is one of the most popular operating systems around the world. Yeah. It's surpassed by Windows 7 by far. But there's still plenty of XP people out there. Luca Casanado: And even on iPhone, let's say you just have bad cell coverage somewhere. You're walking down a block, you have bad cell coverage. You have suddenly a 50 kilobit connection rather than your regular 200 megabit. If you're trying to load some store and it just doesn't load, you're going to abandon that and you're not going to buy anything there. But if you have a fast store, which works even on slow connections, it's going to get [inaudible]. Paul: Let me tell you. I was on an airplane a few days ago, trying to load the GCP console. It was a bad time. I was not a happy flyer. Luca Casanado: Yeah. But the GCP console's especially bad. Even [inaudible]. Paul: [inaudible]. Luca Casanado: Even if you're on a gigabit network, it still takes seconds to load. It's kind of terrible. Paul: And that's an amazing feat of, I have the same reaction looking at the GCP console as I do looking at an ant tower. I'm like, wow. I don't know what this is, but they built it. And it's massive. Luca Casanado: Yeah. Yeah. Paul: Yeah, I guess so it could really, it's all these scenarios as you noted. We don't think about them. When we don't have connection and it's useful everywhere. It's really useful everywhere. It's going to improve all aspects of the business and the organization. So what are you looking forward to in the next year besides Deno and Fresh? Is there anything that's coming out in the web, anything that's coming out in the SaaS technologies that's piqued your interest? Luca Casanado: Yes, but I can't share all of them unfortunately yet. But there's some really awesome stuff that I know we're working on, especially related to the SaaS stuff. That's a great point. But yeah, we have 50 people working on do Deno now. We're going to grow the team, continue to grow the team. We have a bunch of funding. So Deno's just going to get better. Fresh is going to get better. And we are seeing a lot of other people trying to write JavaScript run times, which just proves that this is something that people are interested in and that Node was not the end of JavaScript run times on the server. Right? There's still a lot of things to be done. Paul: Anything else? Any other projects you're looking at that aren't related to Deno specifically? Luca Casanado: Yeah. So I'm also a member of TC39, which is the JavaScript standards body. And we do JavaScript standards there. Right? We figure out what's next for the language and what engines should implement. And there's a bunch of really cool stuff I'm super excited for there. For one, there's a bunch of improvements to the ES module system that we're currently working on related to WASM integration and lazy loading and deferred loading and module blocks. And these are all things you're going to hear more about once they're closer to being ready, but really cool stuff going on there. And I'm also working on a bunch of other web specs with folks, namely at the WG and winter CG groups, working on the Fetch spec and also working on making sure that server side run times Node and light Deno and CloudFlare Workers implement the same APIs and have those APIs inter-operate between those run times. I think that's something which is really, really necessary and we haven't spent enough time on. Paul: And when you say that APIs are similar, do you mean on the server side or for the client side when we're uploading our serverless functions? Luca Casanado: Well, all of it, even. All of it, actually. Ideally, what I want is, you write a JavaScript library and you don't have to say that library works. I know it works. In the browser, it works. In Deno, blah, blah, blah. It's a JavaScript library, okay? And it runs everywhere. Paul: Right. Right. Luca Casanado: That's what I want. And there's obviously still a long way to go there, but it's something we're working on. And I think it's really, really important that we do. Because JavaScript is the most used. It's the best dynamic language out there. It's the fastest dynamic language by far. It has millions of users every day that are writing it and billions of users that are executing JavaScript every day. So anything that we can do to make it better is going to have a profound impact. Right? Paul: It's like the English of programming. You know? Everybody learns a common language. It's weird how we've all gravitated towards this single point. But I mean, it feels refreshing when you step in a JavaScript and it feels like you have every Crayola color at your disposal. It's hard to match that feeling in other languages sometimes. Luca Casanado: And especially, even if folks are not super familiar with JavaScript, everyone knows that little bit of JavaScript. Right? Everyone knows console log and it's like a universal language, like you said with English. But it's the universal scripting language. Paul: Well, Luca, we're getting kind of close to the time. Maybe we could point people at resources they can look at. You've mentioned some links in our podcast so far, but if people want to go check out Deno, Deno docs is probably the first step to look at, right? Where are those located? Luca Casanado: So you just go to deno.land and you get everything there. There's the manual there. There's the API reference there, installation docs, standard library, everything at deno.land. Paul: Deno.land. Awesome. And what about Fresh? Luca Casanado: For Fresh, you go to fresh.deno.dev and same thing. There's installation guides, docs, everything's on that page. Paul: Fresh.deno.dev. Right on. Okay. And if people wanted to hear more from you, are you active anywhere in socials? And if so, where can people find you? Luca Casanado: Yeah. So me personally, you can find on Twitter. Twitter.com/lcasdev and for the company, you can find more about deno.com/blog for our blog, or our twitter.com/deno_land. Paul: Awesome. Well, thank you for your time, Luca. Hopefully some people can be encouraged and instilled to actually take the dive into more server-side things with Fresh and take a look at this new JavaScript run time. Because it sounds really great, one binary, does everything. It's all it's homogenous. It sounds great. So hopefully some new stars and some new users will come your way soon. Luca Casanado: Yeah. Thanks for having me. Emily: Hey, this is Emily, one of the producers for Pod Rocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on apple podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome Pod Rocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.