mini ep 9/8/23
===

[00:00:00] Happy Friday, developers. Today is September 8th, 2023. And welcome back to our roundup episode where you can catch up on episodes you missed and get a quick rundown of the past two weeks from PodRocket. So let's get started. First up, we have Kevin Winery, head of Deno's Developer Relations. And yes, that's Deno, not Deno.

And he joined us to talk about some of the upcoming features of the next release, Deno 2. 0.

So the DDo 1.

0 release was in May 2020. So it's been a few years since 1. 0 came out. And since then there's been some iterative improvement, but nothing actually breaking some of the major Improvements have been like compatibility with the vast majority of the NPM ecosystem. So building a compatibility layer for both like Node.

js built in APIs, which then, NPM packages are built on top of. The big thing [00:01:00] that's driving the 2. 0 switch is how we're going to do module resolution in Dino, or how we're going to recommend that folks do that going forward. And while it's not like exactly a breaking change because actually like HTTP imports which are the primary way that you include like Dino native code in your programs today those are going to continue to be around and still be used.

But What we've discovered from like people using, in production and actually trying to get work done is that the HTTP URLs have some kind of important drawbacks, like from a developer experience and like technical usability standpoint,

Where I know when you have lots of different servers that are hosting different versions of packages, it becomes very difficult to, do any kind of Optimization around like semantic versions.

So you get like multiple versions that are very similar of the same package all being included in a program where we can't really do any kind of optimization around that. It's also just the case where like server [00:02:00] infrastructure that we Don't control or that actually dynamically creates content that gets included in programs can be a little bit unreliable, like we've had bugs that users have encountered where, a dependency that they're using changes in a very subtle way, like even though the the end point is the same.

So there are like guarantees that we can't really make around like the content of the packages. So, Yeah. So like duplicate and disappearing dependencies are definitely part of it. There are also just some like DX issues around like it's, if you've seen a Dino program that imports a module from a URL it's a little bit verbose and it can be a little tricky to configure those inside your programs.

And there's minor things like I Maintain a number of NPM packages, and one thing that's really nice for testing is you can do NPM link and like within another node project, you can use a development version of your module, and that's not really a thing we can easily support in the current world.

So, so, yes, one of the big changes is going to be where [00:03:00] we're going to actually be creating a registry that will work a little bit more like a traditional package manager, like a node or cargo or packages during any other package management tool you've used in the past, where they'll be like a central namespace.

And, in that registry will be able to do things like have some have a degree of like editorial control over the namespace. So if there is a my sequel module say that's published, but it points to like an unmaintained or an older or God forbid, like malicious piece of code.

Like we will be able to intervene in those cases and make decisions based on what the best developer experience will be. So we can have the ability to do that. At the end of the day, like it'll still be built on a lot of the same, like HTTP import functionality that exists in Dino today, but by having kind of a central registry, we can make sure that the DX of that improves a little bit where like we can type check modules as they're registered and and make sure like the Dino first certain nature of the registry ends [00:04:00] up being a good experience.

Next, we celebrated the release of Astro 3. 0 with co creator Matthew Phillips and Astro team member Ben Holmes as they discussed all the new features with Astro 3.

Here, they talk about the biggest part of the release, view transitions. 

Yeah, for me, it's easily the View transitions feature I'm not gonna claim it because Matthew's actually the one who got to build it but I've been demoing it every chance that I have because it answers some pretty fundamental questions with Astro Up until now, it's been focused on generating each page separately.

So if you've heard multi page app or just how the web was, that's pretty much what Astro does. It outputs a bunch of separate HTML pages or separate endpoints with SSR. But if you wanted to share state between pages, maybe have a media component that stays on the screen while you route around, or you want to, have a snappy transition without a page refresh, That wasn't possible.

And now both those things I described are baked into Astro 3. 0 should [00:05:00] be stable from 1. 0. And it's all possible. Thanks to a cool API from Chrome called view transitions as well. We have some polyfill, so it works in any browser, but that was the inspiration for it. And it's the one, a lot of people are really excited about.

So like, in my opinion like, or like my perspective was the major. Like backlash against MPA versus like SPA was like the refresh between like page navigations is, does it like, so I haven't personally used the view transitions API. Is it now that it gives you that seamless, like client side navigation.

So you persist that state across routes.

Yeah. We might want to start, I don't know if your audience is probably very technical. They probably know about these things, but. It might be good just to define what a view transition actually is at like its core. So a way I would, I've been thinking about it. I didn't actually know this at first when I first started working on all this stuff.

I was like, Oh yeah, view transitions. It's a way to animate between pages. That's the primary use case, but really what a view transition is that kind of at the core of it is it's a [00:06:00] way it's a browser API. To say to tell the browser, Hey, I'm going to make some changes to the Dom. I want you to take a screenshot of the current state.

I'll make some changes. And then when I'm done, I want you to animate between those two states. So if you think about it like that, it's not actually about page navigations. Like you could use it for anything. And there's actually some people doing some really cool demos out there. I don't know if you've seen that they really have nothing to do with.

With page navigation, literally, like I've seen demos where, you know, you reorder a list, you sort a list, and then inside the view transition, you get this really cool animation just automatically, without you writing, having to write any CSS code yourself. So, yeah, that is actually what a view transition is.

Now, obviously the, the biggest use case, and the one that we're, Focused on right now is page navigations. 

And finally, we welcomed on Kyle Simpson, also known as Getify, to talk about the future of the web and how local firsts could change the web as we know it.

I'm curious to [00:07:00] hear your thoughts on education of the general populace and how this might move the needle. If I have somebody who has never touched a computer or command line before, and then I say, Hey, there's a way, like we can use SCP this weird thing, right? Let me show you how a terminal works.

And this is a true story. Like it's actually, we've gone from zero to SCP in the time span of two hours. And they were like, what? I can just do this right on the LAN. I was like, yeah, believe it or not. I feel like that might move the needle, right? As more and more people can just hop on YouTube, hop on like you had in your talk chat GPT and actually get to an operable point, maybe in web dev.

I might feel the same way that it's getting more and more difficult for newcomers. But there's this concept of like education. Do you think that plays into this?

I think it's incredibly important. I'm glad you brought it up. Probably one of the biggest points of skepticism when I start talking about idea, so [00:08:00] briefly socket supply creates a free runtime that lets you take a web app and make it into a peer to peer capable native app. So you use your favorite web app technology, but now you have the capability for this app to live on a device.

Talk to another app instance on another device without the cloud. That's the big thing that we're doing. And when I talk to people about that, immediately people started saying, well, wait a minute, you're telling me that all of my data would reside only on my device. What if I drop my phone in the toilet or if I lose it or somebody steals my phone or whatever.

Okay. So that's, Their first instinct when you talk about users, whether they're developers or not, their first instinct is, I know that I might not always permanently have this device. And if you're telling me that what I should value as a person is that my data resides locally on my device, even without being a technical person, I worry, what if that's the only place that data is?

Because it could be lost, just like a home can burn down and all my valuable paperwork can be lost, [00:09:00] that data could be lost and I might not be able to get it back. So even a non technical user has a question like what happens to my data if I lose my device?

That was a whole selling point back in Web 2 when it came out. It's back it up. Yeah.

exactly. Back it up. And I'm not suggesting that there's nothing wrong, that there's nothing virtuous about backup. But I am suggesting that centralized backup is not the only model for backup. It just happens to be the one that's most beneficial to Amazon execs, right? There are other ways that we could manage and create that kind of Safety.

So one of the things that I get is a lot of skepticism from people like that. They say, well, I would never do that because I wouldn't want an app that only keeps my data there because I'm worried that I might lose it. Another question that people get is I don't want to an app where my phone and my laptop or my two phones or my wife's phone and my phone.

They're out of sync. And I never know which data is real and live and correct. So even a non technical user has experienced out of sync problems and can express in even non technical terms that this is a concern. So these skeptic, these [00:10:00] skepticisms that we get from non technical users, when you talk to a technical person, they will tell you a non technical user, which is the primary user base of the internet, they're not ever going to.

Believe in or understand the importance of owning their data and being responsible for their data. So they'll tell me this will never happen, right? You're being completely naive. The general end user will never want this version of the world where they actually have control and therefore responsibility over data.

My response to them is if you get if you went back even seven or eight years and you said to anybody who was even remotely Technically under, literate at that point, that we would take from at that point. I best estimates that I can get is that were there was less than 1% of the world at that point was using what we now call two factor authentication, meaning that they were using some other form of proving their identity and their [00:11:00] authentication on the general open web and in software, they were using something else besides a password.

That number was way less than 1% 5, 10 years ago. And that number is now, by the estimates that I can see, well over 30 or 40% of the people that are connected to the internet are using some form of two factor authentication. They may be crappy ones like SMS, but they're using something. If you went back 10 years and you said, we will, in 10 years, train over a billion people in this world, That they have to own more responsibility over proving who they are and their identity.

And that will be more inconvenient and it will take a few extra steps. But we will convince a billion people on this planet to change their behaviors around passwords so that they own more responsibility. If you told a person that ten years ago, they'd laugh at you and say, that'll never happen. We'll never get a billion people to change their behavior.

And yet, it has happened. So my response is, just like we educated the world, little by little and [00:12:00] as painfully as possible, that it was an important responsibility that they own the way that they prove and control who they are, their identity. The same thing can happen and must happen for our data.

And that's it for today, Friday, September 8th. You can check out the full episodes linked in our show notes or on our feed. And if you like what you hear, follow PodRocket for more great web development content. See you at the next roundup. This episode was brought to you by LogRocket. Try it for free at logrocket.

com.