Jared Hanson is a software engineer at Okta. In this episode, they delve into the world of authentication strategies, troubleshooting touchscreen frustrations, and exploring the evolution of web application technology. They touch on the challenges of secure authentication, the complexity of JavaScript type checking, and the intersection of security and usability in technologies like WebAuthn. Join us as they discuss their experiences with Passport JS, the potential of WebAuthn, the frustration with ongoing changes in browser technology, and much more. Tune in for an insightful discussion on cutting-edge trends in the JavaScript and Node.js ecosystems!

 
CHARLES MAX_WOOD: Hey, welcome back to another episode of JavaScript Jabber. This week on our panel, we have Steve Edwards. 

STEVE_EDWARDS: Hello from very cold and windy Portland. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Yo, yo, yo. Coming at you live from the year without the Santa Claus. 

CHARLES MAX_WOOD: I'm Charles Maxwood from Topnet Devs. Go check out java That's where I've got my latest stuff going on. We have a special guest this week and that is Jared Hansen. Now Jared, I kind of got you down as the person behind or who created Passport.js. But what else do you want people to know about you? 

Hey folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? So if you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume will get you that. And you can just kind of use the formatting. It comes in Word and Pages formats, and you can just fill it in from there.

JARED_HANSON: Yeah, so I'm an engineer by background, been doing professional development, product development for about 20 years now. Most of your listeners would know me from PassportJS, which is a very popular authentication framework in the Node.js ecosystem. I currently work at Okta by way of zero and have been, you know, in addition to being part of the Node.js ecosystem. Really involved in the identity industry and identity world. So things like OpenID Connect, OAuth, et cetera, um, and who's spent the past 15 or so years kind of focused, focused in that area, which I really enjoy. We can get into. 

CHARLES MAX_WOOD: Yeah. Very cool. And, uh, yeah, as we kind of get rolling, I don't know if I want to assume that people know what Passport JS is. Um, I've talked to quite a number of people who use it. But you want to give us the background as far as what it is, what it does, what problems it solves, and who may want to use it. 

JARED_HANSON: Yeah, absolutely. So Passport.js is an authentication framework for Node.js. So what that means is it basically handles all areas of logging into your application, be it a web application with a typical HTML user interface, or if you're building API applications, you need to do token-based authentication. So it's primarily focused on Express, although it doesn't get used with some of the other frameworks out there, Next.js occasionally, which is very popular these days, and a few other frameworks. It's been around the ecosystem for a long time now. I think my first commits on it were back in 2011 just to give some context for people. I think Node was on like 0.2 at the time, and now it's 20 something, kind of forget coming on with maybe not the most, you know most recent topic, but still always very relevant to security. Um, and yeah, like I said, primarily it's a middleware for express JS. So, uh, people know your, you know, some of this stuff kind of like, uh, maybe gets forgotten to history a little bit, but anyone who's writing express JS apps is, is very familiar with middleware pattern. Um, so authentication is just middleware that you stick in your application, uh, in order to authenticate a user. If they aren't authenticated, then stops and the request is denied. Otherwise you're provided with the user and then you can write your business object to return you know user specific responses. 

CHARLES MAX_WOOD: Cool. So just to get a little more clarity on this and I'll admit I haven't done a whole lot with Passport.js because I don't write Express every day or you know JavaScript really every day. But you said it's middleware so if I want a login screen or myself you just manage the the stuff coming back and forward. How much how much many other pieces do I get? 

JARED_HANSON: Yeah, so passport JS is really focused on just authenticating the request. It's meant to be like quite Minimalistic so it doesn't get involved in really any other areas of your of your application so if you're writing your login screens and your front-end code that is all entirely up to the application developer pick your template and language or React, things like that, whatever your preference is on the front end. In Passport.js, it's just handling the backend components of those things. So if you're just form posting your thing up in a login form, it'll handle that. If you're doing APIs, then your client side is responsible for putting the tokens in the request and it'll parse those things out of that and authenticate it that way. It's really, like I said, designed to be minimal and unobtrusive, which is important to me in things. I don't like frames that kind of really start to take over your application. So it's meant to just provide just that authentication bit and leave the rest of the choices that aren't and shouldn't be authentication related up to the developer. 

CHARLES MAX_WOOD: So let's say that I want to authenticate against Google, right, because you have all these authentication strategies. So I write my login page, I put the Google icon on there, I click it and then what else do I have to do to make it work?

JARED_HANSON: Yeah, so with Google, so if you go to passportjs.org, there's kind of tutorials that walk you through these various things. So one of the challenges I'll get to your question in a minute, but just for some context here is like one of the challenges with authentication is really there's like so many ways to authenticate. And that's one of the things that passport really tried to address, which is like, we got all these disperse to authenticate. How do we give sort of like a single consistent way to, you know, drive that from with encode. That being said, there are slight differences across these things. So for instance, you know, one common way is just, you know, username and password submitted, you know, a login form. The developer has to do that. What you brought up is, you know, logging in with Google, for instance, via OpenID Connect or OAuth 2, which has kind of different semantics than just running a login form. In particular, there's, you know, you got to redirect to Google and then handle a couple interactions there. So you do probably need to have a bit of background on what the prerequisites are to set, particularly with respect to your user interaction, because like I said, Passport is just a backend framework. So there's tutorials on the website that will walk through these common scenarios. So in the case of Google, essentially what you would do is, like you said, drop the Google button on your page, a user clicks it, and that will send a request back to your application, and you put the Passport middleware there. The passport then will start to take over the OAuth flow because that's really the thing you don't want to do as a developer that's super complicated. So passport will basically abstract all that way from you. So you just say pass Google. And then passport will take care of redirecting the user to Google, at which point Google steps in and does the authentication. And then Google sends the user back to your application. In this case, what's known as a redirect URI or callback URI. And then here again, you just put the passport middleware on that particular route in your express application and that passport will finalize the OAuth or OpenID Connect interaction and then just supply user that log in. So it's really just basically kind of a in a way you sort of sense like two lines of code that you add as middleware at these two endpoints to handle the processing. And then a few more lines of code of just configuration to set up things like your client ID and secrets credentials that Google issues you in order to use this. 

CHARLES MAX_WOOD: That makes sense. I mean, I mostly do Ruby on Rails and, you know, Warden is kind of the, yeah, there, right? And so, and then there's devices built on top of it, the net provides you with the views and things like that. But yeah, that makes a lot of sense. So just to kind of restate some of this effectively then. I write the UI, I get the request, when I get the request into my application, I call in the passport, passport does all of the juggling of wherever the authentication is happening, whether it's on my app or whether it's somewhere else, and then I get the authentication token or whatever other credentials come back, and then from there I marry that up to a user in my system, and then I can go and do whatever I need to with an authenticated user at that point. 

JARED_HANSON: 100%. Absolutely. 

CHARLES MAX_WOOD: Cool. So what does it take to write something like this? 

JARED_HANSON: Or for me personally, or people dropping it in their application? 

CHARLES MAX_WOOD: For you. 

JARED_HANSON: Yeah. So, so like I alluded to at the beginning, I'm, I'm a big kind of like identity nerd. I love the topic. So I'll just give some context here. So like I said, like passport was started back in 2011. Um, and I had been doing, you know, this was kind of like the early era of like, Web 2.0. So I got super fascinated by OpenID and OAuth and, you know, mashups and all that sort of stuff. And I, at that time, I guess I was just sort of like, I had been, I had moved to the Bay Area and been here for about like six years doing, doing a startup that was more kind of enterprise-focused. And I was kind of looking for something new. And I wanted to get like more involved in open source development, maybe, you know, get something out there that had a bit of recognition behind it. Um, and so that is kind of what I was looking to do. And so like node was real early at the time, like I said, zero.two. Um, and, and my background is more as a systems programmer. So C and C plus plus, um, and when I took a look at node, I was like, oh, this is super interesting. You know, it's basically you're writing IO-heavy applications, server applications got all this event-proof stuff in it with, with E-Poll and whatnot. And it was like, I, I first took a look at Node like the internals of Node, right? The C and C++ stuff that's, that's going on internals. I was like, oh, that's super interesting. And this is like a lot of the code I'm writing. But then they put this JavaScript layer on top, which just made it a lot easier to do, you know, just your business logic, you know, it's faster development and reasonably fast performance. Um, and so that's kind of what drew me to Node. Um, and then. As I was looking at a node and looking for maybe an open source project to take on, and also very interested in security and identity, I was like, well, what's out there for authentication in the node world? And I was familiar with things like, like, more mid-wise from Rails. And there wasn't really anything that existed at the time for node. There was another project called Evryoth, which I took a look at, but wasn't necessarily super happy with. Um, so I was like, Oh, okay. Like I'm going to, I'm going to try my hand to make a authentication framework for node and see what happens. And so really it was just, yeah. How hard could it be? Um, and you know, it was like, you know, like any, any developer, you know, like it was looking for a challenge and something, you know, it was hard, but also fun, I guess, 

AJ_O’NEAL: three promises. It was so much harder than it needed to be because I mean, that triangle callback of doom thing. I mean that, that, that made it. I mean, I back to the day I looked through the passport code. It was difficult to read because it's like callback, callback, callback. I mean, everything was back then. Not anybody's peeing on it, but you know, especially because the OAuth flow. Um, yeah, I was, I was trying to fix a, an issue with cookies way back in the early days, cause the, um, back then. Most Oauth implementations require third-party cookies, but of course, you know, in the modern age, that wouldn't work. And I imagine that it's, you know, that's, that's been reworked since then. But yeah, I was like trying to, trying to follow from this callback to that callback and then like an event system. Those were tough days before promises. Those were really, really tough days. 

JARED_HANSON: Yeah, yeah, absolutely. I mean, I think, you know, that was one of my experiences at the time I was also just learning JavaScript. I wrote some of this stuff. I had done a little bit, but nothing significant. Honestly, I found JavaScript a little bit confusing, honestly, at that point. I was learning that at the same time, and as I said, all the callbacks. Any sort of asynchronous IOS where it's in Benthrin can be hard to read because it's, as you know, not linear but more driven over time, I guess. So yeah, it was kind of one of the challenges of Passport is like design an API that can take those challenges and make it somewhat tractable, you know, and I think it's done a decent job of it. Obviously, there can always be improvements. But so yeah, that's what I set out to do. And like kind of my premise was like that middle pattern where it's just like Passport that from a developer standpoint, like those are the kind of things that you just repeat over and over. It's just configure your strategies and then like wrote the authentication and aware there. And reasonably then I think that, that means authentication, you know, attractable and easy. And I think most people used it to good effect. So that's kind of like the background there. And then, you know, at the time, like I said, obviously Node was new. So I published Passport, you know, the first initial versions of it spent a lot of time just like Twitter was also kind of new at the time. So at times when I tweeted about Node or Auth, you know, I'd reply to them and get Stack Overflow and just like a lot of community development, reaching out to people and telling them that project exists and did that for a while. And then it sort of just kind of threw its legs and took off from there. And now it gets a couple of million plus downloads in the month of NPM or something like that. Yeah, just it's interesting to watch a open source project kind of play out over a decade plus and see how it's evolved. So yeah, it's been a great experience. 

CHARLES MAX_WOOD: So one thing I want to call out that you mentioned, and this isn't specifically to Passport, but I've talked to a number of open source developers and they're like, well, I just package the people who use love it and I just can't seem to get people to find it. And it sounds, you know, your strategy where you're talking about, Hey, I just went on Twitter and just replied to people who were talking about JavaScript. Um, that's a strategy that I've seen, you know, in the podcasting space. Well, right. Wherever somebody's talking about whatever topic you cover on your show, or if you have an episode that's relevant to it, right, you talk about it on, on Twitter or Facebook or wherever. Um, so you have a specific method for doing that or.

JARED_HANSON: No, no specific method other than just reaching out and talking to people about it. I think that's one of the great things about how easy it is to just communicate with people these days and everyone's connected online. And also when you have a project like that, you're just super passionate about it, want to talk about it with people anyway. So yeah, I'd just reach out to anyone who seemed interested or like..Especially when you're saying, hey, let's check out this project. It's free. Maybe it'll solve your problem. You know, it's like, you're really not asking them to do all of that. So it's pretty, pretty easy to, to, you know, sell the product. I guess. Yeah. So, no, I was going to say like the one other thing that I think I would encourage like for people that are looking to kind of raise awareness of the things that they're doing is, um, the one is the documentation. You know, I think the other thing is like, you know, I do for any project I wanted to promote. It just gives it a sort of like polished and professional, you know, appearance. If you can have a website and read the documentation, because that's one of the things that I think people struggle with in adoption. You know, it's like a GitHub readme will only go so far, especially if it's a somewhat bigger or more substantial. 

CHARLES MAX_WOOD: Yeah, I think we've all run into that, right? Where it's, hey, this package or this library or this product says it's going to solve my problem. And you get in and you're trying to follow along in the documentation and you just can't figure out how to make all the pieces connect. Right. And yeah, it's down to their documentation. It's like, look, this isn't comprehensive enough for me to figure out how to get the gears to mesh. So I'm out of luck and, uh, yeah. 

AJ_O’NEAL: A lot of times on that. I mean, I would love to hear everybody's perspective on this, but I think the, the biggest issue with that is either a not recognizing that the developer is not at where you're at. So there's a lot of tools out there that people are asked to use that they're not necessarily a node developer, a Python developer, whatever, and just having the, you need to have installed node and you need to have, uh, you know, done some other thing, you know, create, run NPM and that, or, or something like that. Like there's these, there's like two or three steps that you have to do with every single project that people often omit from their readme's because it's like, well, duh, if you're one of these developers, you're going to know how to do that. But if you're coming to something where you're building a new project, I would imagine that particularly with Passport, you observe this is because people are not necessarily note experts. They're like, Oh, what's the easiest way to get an app together with this type of OAuth and they, you know, they, they end up on passport. Or number two would be that the examples are, are either too concrete or too abstract. And by that, I mean, it's difficult to tell which values are variables and which values are part of the framework's options. So like if everything's just foo foo foo foo foo, it can be difficult to tell, okay, which of these foos was supposed to be a URL? And if everything is like exact the literal then it's hard to tell. Okay. Do I am I roping into for example I know that passport doesn't do this but am I roping into passport dot com in order to run this thing or is passport dot com just an example you're up. 

STEVE_EDWARDS: Well let me let me play devil's advocate on you for once AJ. 

AJ_O’NEAL: Oh great. Great. 

STEVE_EDWARDS: So you were talking about you know making assumptions about this developer able to do this or that. One of the frustrating things for me that I read when I'm, and I'm looking for a lot of, uh, Laravel, you know, help on different things. And I'll come across blog posts all the time and I swear nine times out of 10, half of the blog post or three quarters of the blog post is just getting a Laravel project up and running. Okay. Install this, do this, create this. And I'm like, Good Lord, just get to what the blog post is about as if there's not a bazillion references elsewhere about, excuse me, including the Laravel website about how to get a basic Laravel project up and running. Don't pollute three quarters of a blog post unless you're just trying to make it look longer than it really is, you know, so you look better. But at some point- 

AJ_O’NEAL: You gotta get the keywords. 

STEVE_EDWARDS: You got, but you gotta make some assumptions about some basic knowledge at some point if you're a developer, you can't, every blog post, every read me is not gonna have-you know, a hundred steps on how to just get to the point where you're ready to use this. And there's, I mean, the internet's a big place. There's lots of tutorials on getting basic stuff up and running. And so as a user, if I'm, you know, searching, oh, here's a blog post that the title says, I'm going to talk about this. And it takes you three-quarters of the way through just to get to what they're talking about. And that's a tiny part of the blog post. And that'll tick me off and I'll go away faster than anything else. 

AJ_O’NEAL: I 100% agree on that. But I'm saying, no, I'm just saying that like a couple of either a couple of bullet points or like here's the two lines you copy and paste. Yes. If it's, if it's like a hundred steps to create a Laravel project, then yeah, the link to it. 

CHARLES MAX_WOOD: Yeah. One thing I want to add to that is just, um, in Steve's example, the thing that always trips me up is it's. Here's the three-quarters of the thing that's boilerplate, but halfway through that three-quarters is a critical step. Oh yeah. Right, because I'll skim it and I'll go, oh, okay, I know all this stuff. And then it's, why isn't this working, right? And so yeah, having the, it's, hey, look, you need to take this step if you have an existing project because you probably have an existing project. Jared, I do wanna come back to the idea though. So it was documentation. I mean, obviously it was the right problem people needed to solve, but it was the documentation and the interaction that grew the project, right? Or are there other things? 

JARED_HANSON: Yeah, well, yeah, I would say like, certainly over the course of time, so I think one of my learnings here is just like, you know, kind of maintaining an open source project for over 10 years, you start to see like more more cycles come through. So like, I want to talk about this documentation a little bit, it's relevant to what you guys are all saying. So like in the early days, I set up the passport website and some documentation. And the documentation was really, probably a little bit more conceptual in nature, which was fine at those days. So think about, again, like Node back in 0.2, 0.4, the 3.1.0 days. Node itself was attracting sort of a different audience of developers. You had very leading edge developers who are willing to get in the bleeding edge. Reading a lot of code, like when I was writing Passport, I was reading a lot of code of other libraries at the time, just to understand development. And I think that was common. Like a lot of the people that started using Passport, even though it made it relatively easy, I think they were the type of developer that was willing to get and read the code and the internals, like you were saying, AJ, whether they understood it all or not, you had people digging into it. And so the documentation was a little bit more geared towards that. But like as you think about this, the scales just in like number of adopters and like over time, you start like node has attracted different developers over time. Now it's much more of an established thing, you know, like it's not bleeding edge anymore. People adopt it because they know that they can write stable applications in it. And you have developers that just kind of, you know, maybe aren't going to read the code of the libraries that they pull in as dependencies and just want the documentation to be there. So I've evolved the website over time a lot as well to like add documentation, which is really helped a lot. So one of the frameworks that I used was, have you guys come across Diataxis? I'm not quite sure how you say it. It's like a documentation framework that's interesting. I'll send you guys a link and we can put it in the notes or whatever. But it's really talking about like, think about the challenges that you face as a developer. There's different challenges that you face in terms of like, you might be coming into something very new where you want just that step-by-step tutorial. So like on the Passport website, I have step-by-step tutorials for people who might not have ever used Node or Passport. So it assumes some knowledge like you have Node up and running, but you can follow just step-by-step. This is what you do to get off in your thing. This is what you do like on an HTML page to add a login form. This is the type of route that you will add to your Express app, and it's just you follow it step-by-step. You don't have to have any knowledge, and then at the end of it, you have a working sample application. There's also just more reference style documentation where it's like, hey, I just want to know APIs and that sort of stuff, options. I just want to know what's there. I don't want to follow tutorial. Then there's conceptual documentation, which is like, okay, I might have this thing running in my app, but now I need to know what's actually doing. What is this OAuth thing behind the scenes, which I didn't have to know from the tutorial, but maybe I want to know it now that I'm more experienced with my application and taking it to production. I want to know what problems I might face. So different developers at different stages have different needs. So writing documentation to those needs is really important. And I saw that one of the motivating factors for me to add some of that documentation to the website was just the sheer number of GitHub issues being filed of things like you said. It's like, OK, I just pulled in this library and tried to put it in my app. It's just not working. I don't know how to fit all the pieces together, right? Which is maybe not something I obviously would have liked scene being the developer of it. I'm of course too familiar with the details, so I don't necessarily think about those problems all the time. But then you start to see the influx of issues of people having them. So taking a step back and writing documentation that just assumes very little knowledge about the system has greatly reduced my own support load. It just cut those issues down because now there's just a tutorial to point to if someone has a question or the questions ought to go away because they find a tutorial on their own. So it's just a way to scale. I guess my time or maintainers. 

CHARLES MAX_WOOD: Yep. Makes sense. I kind of want to take this back. Um, working on passport JS and onto, uh, authentication. So let's talk a little bit about authentication here for a minute. So you get this basic functionality up where, you know, maybe it does OAuth or, uh, open ID or something. And, you know, you can, uh, you can maybe bring some other strategies. Um, when, when did the new strategies come in? Was that something that was there from the get go or was that something that. 

JARED_HANSON: Yep. Yeah. The strategies were there from, from the get go. So, uh, I think. Like if I, if I remember the evolution of this, uh, basically like, uh, the first strategies where your typical like username and password, um, and then. Oh, often open ID. And I think it was like, oh, often want an open ID, like 2.0 at the time. Cause they're like, you know, technology sort of faded over time. But yeah, the strategies were always central to the framework because like, authors are disparate and I wanted a way to unify those things. I think the OAuth ones came like, most of the initial passport was done, like development was done within like a month or so. So like, I think it was like, I took two weeks to write like the framework and the first nnnnn, like the username and password strategy. And then, and then I think I- added some basic auth and the API style authentication. And then I added OAuth stuff, all within the span of about a month, I think. But the OAuth piece, once that was working, I knew the framework sort of had what it needed to handle all the use cases. Because that's a broad range of different functionality that you need to accomplish auth, and it all sort of fit within this nice strategy pattern and the middleware pattern, and I was pretty satisfied with it.

I think the larger question I'm trying to ask, because that kind of sets up, you know, okay, this is where this is where we started. And this is kind of how things evolved as far as strategies went. 

CHARLES MAX_WOOD: But like, how has the problem set for authentication changed over the last 10 years that you've been working on this? Right? 

JARED_HANSON: Yeah, so good question. I think authentication is one of those topics is like constantly changing. And it seems like, you know, always something new, new to learn. Like, I would say like one of the biggest changes has been like just the like single page applications and more front-end focused stuff. And so like, and I'm not even sure like how to explain this stuff succinctly necessarily because it's still still quite complicated. But you've just got so many different styles of application development, even within the scope of like web applications, right? So you've got your typical like traditional back-end web applications where it's all HTML user interfaces and login forms and session management. You've got newer API style stuff where you just might be writing just JSON APIs and you don't care about any front-end stuff. Then you've got single page applications and mobile applications accessing those APIs where the login is done completely on the front-end, somewhat disconnected from the backend and you get token-based authentication a lot of similarities between those things, but also a lot of key differences just in terms of architectural stuff that you have to understand. And I would say that to me has been the biggest change is that these single page applications and mobile applications are far more popular and predominant today than your traditional web application. And understanding those differences has been the biggest challenge. Looking forward a little bit more, and this is this is stuff I'm excited about, but you have things like weblfn happening now. And there's some kind of newer work that's out there to do to make sessions a little bit more secure, so we can talk about that if you want. But more things like token binding so that things are actually tied to the device and not just bear tokens. These are the areas that authentication is pushing into that are hot topics and challenges today.

Hey, have you heard about our book club? I keep hearing from people who have heard about the book club. I'd love to see you there. This month that we are talking about Docker deep dive. That's the book we're reading. It's by Nigel Poulsen. And, uh, we're going to be talking about all things Docker, just how it works, how to set it up on your machine, how to go about taking advantage of all the things that offers and, uh, using it as a dev tool to make sure that what you're running in production mirrors what you're running on your machine. And it's just one of those tools a lot of people use. They're really looking forward to diving into it. That's February, March, April, and May. We're going to be doing the Pragmatic Programmer. And we're going to be talking about all of the kinds of things that you should be doing in order to further your career, according to that book. Now, of course I have my own methodology for these kinds of things, but we're going to be able to dovetail a lot of them because a lot of the ideas really mesh really nicely. So if you're looking for ways to advance your career, you're looking to learn some skills that are going to get you ahead in your career. Then definitely come join the book club. You can sign up at topendevs.com slash book club.

AJ_O’NEAL: So I'm, I'm very interested in where web often is going. My understanding is that is the rebrand of Fido. So like, and this stuff is changing like super fast now for a long time. The, these things were kind of stagnant, but now, uh, Windows hello is integrating it, Mac OS is integrating it. And then the browsers are also integrating it with sometimes starts to get confusing because there's like multiple layers of web often. Yes. Yeah. So like what, what, what have you seen in web often and where is it headed? Is it actually, I mean, it's, it seems like it's gotten to the point where all I have to do is, is just hit okay. Because of the operating system integration and at that point I'm thinking, okay, is this actually more secure? Did we just get rid of the whole thing? The security. 

JARED_HANSON: Yeah. Yeah, no, no, no, it's fascinating. I mean, it does feel like magic at times, especially with the stuff that you're talking about, like with Windows Hello, and you know, like touch ID and face ID on math now. So yeah, 

CHARLES MAX_WOOD: it's nice that it feels like magic because if I don't want to fight it, I can just reach for something like passport and not have to worry about it until I have to worry about it.

JARED_HANSON: Yeah, for sure. And I think the other thing like, yeah, when I say magic, I don't mean that in any sort of like derogatory sense. I think like it, what about that? And in technologies like that are both more secure and easier to use, which is like a very rare thing to happen in a security environment. Usually likes making something more secure makes it harder to use. 

AJ_O’NEAL: Which makes it less secure because there's more loopholes where people go around. 

CHARLES MAX_WOOD: Now the hoop I have to jump through is on fire. 

JARED_HANSON: Yeah. For sure, for sure. So yeah, so I think like some context here, you said like WebAuthn is carrying the rebrand of Fido, which is more or less true. Fido is actually like the organization that started doing the protocols for like how you talk to the hardware. So that Ubiqui that you've held up like the USB protocols, how all that hardware to hardware stuff happens at a low level. And they did some initial like JavaScript work, but they took their JavaScript work to the W3C and that's where WebAuthn happens. So it's kind of like WebAuthn and Fido are married together in some sense. But some of the early work there on Fido is like all based on like hardware security tokens for the most part, right? So it's like you got your Fido device that you plug in or it might be built into your computer. And it makes it super secure and phishing-resistant. But one of the sort of things that happens as an implication of that when you have hardware-based devices for login is like, what happens if you lose that device? So I've got my Fido key and my laptop, and I've got both of those registered, but the Fido key is plugged in the laptop, and my laptop gets stolen or lost or whatever. I have no hardware devices left. So how do I get into my accounts? That's not necessarily in the strictest sense, like an authentication problem. But because authentication is such a cross-cutting concern, you get into these other issues pretty quickly, maybe without you even realizing. You know, so think about a developer. They might just say, oh, like Fido is the latest thing. It's a secure implement that now you've got a customer that calls you off on the phone being like, I can't log in anymore because I only had Fido credentials. Like what do I do? Right. And so 

AJ_O’NEAL: never seen that in the wild though. That's like, that's like the crypto nerds dream, but it's like, yeah, yeah. So I know is never well, except, except now that the iCloud I. was it iCloud keychain iCloud keychain is now integrated. Actually, I take it back since iCloud keychain has been integrated. I think that a few providers have actually been adding it as the first method, but then you're away from the hardware. It's virtualizing the hardware through the software in the cloud. 

JARED_HANSON: Yeah, a hundred percent. So that's, that's kind of where I was going with that. Right. So it's like, you have this recovery problem statement. So like, how do you solve that recovery problem statement? And like Apple kind of really led the charge here as you as you noted with iCloud, where they basically said, okay, look, we'll basically make these Fido style keys, these WebAuthn keys, but we will sync them on iCloud so they sync across the devices. So if you register it on your phone, it'll sync to your laptop. And as long as you can log into your iCloud account, you can get a new device and it'll sync there. So there's obviously some wrinkles here and we can poke at it, of course. But it does nicely solve the recovery problem if you're willing to accept it, like iCloud is a sufficient recovery for you, right? And like that begs its own questions, but like, you know, more than likely someone's going to remember their iCloud password so that they can set up a new device, whereas they might not remember like the random recovery password for, you know, a site that they don't use too frequently. So yeah, like I said, trade-offs there, but like that was sort of the turning point with WebAuthn is once they introduce these what they call passkeys now, which are the these sinkable credentials that go across device. Now it kind of opens up the room for adoption and to make that magical experience where not only is the authentication easy, but like the recovery and the sort of, your disaster scenarios are also trapped. 

AJ_O’NEAL:  feels like we've come full circle back to OAuth though, because now it's like iCloud is the new OAuth if you're using iCloud or Windows Hello is the new OAuth. So now rather than registering through Facebook, which I think Facebook, I could be wrong. I think they're in massive decline. So I think most sites are either Apple login or Google login right now. And then if you're on a business tool, like an Outlook or whatever, it's got the Microsoft login. But it seems like the social login is being replaced with an operating system log in that, you know, once you, you know, squint right and erase some of the magic, it's just off again.

JARED_HANSON: Yeah, yeah, I definitely see where you're coming from there. Like that's a topic we could go in for a long time. I think it'll be interesting to see how this trend plays out. Like it's from a user's sort of experience, it's very much the same. It's like, okay, like I either see like a connect with Google button and I click it and do the OAuth dance, or I see like a login with Paskey button, then I click that and then do the Paskey prompt thing. So it's very much just kind of a one-click login from a user's experience. There's a couple of technical differences underneath the hood that I think are super important to point out. One, like with OLOTH, there's a lot of privacy concerns in the sense that the provider you use for OLOTH sees a lot of your activity, all the sites that you log into, et cetera, which, you know, I'm not going to say good, bad, or indifferent there, but it's something that you have to be aware of. With WebAuthn, even though your credentials might all be synced through iCloud. So you're sort of a reliance on, on Apple. That's your provider of choice. Apple doesn't see all that activity. Like if I use login with web off end and use, use my iPhone to do it on every site, um, I can log into every site on the internet with that. Apple doesn't know, know that I have done that. So there's a lot of big privacy wins there. 

AJ_O’NEAL: Is that true? 

JARED_HANSON: Yeah. Yeah, that's definitely, definitely true. 

CHARLES MAX_WOOD: How Apple also wrote the OS. So if, if they are spying on it, there are other ways they could do it already. 

AJ_O’NEAL: Yeah, that's, that's my question is because if you control the whole chain of software, saying that it's end-to-end encrypted, we don't look pinky promise. Like, yeah, I don't know if I trust that. 

JARED_HANSON: Sure. Like, obviously, if we're looking full stacked, you know, Apple writes the browser, etc, etc. Like Google does that too. So there's there's lots of insertion points by which they can like, like monitor things. I'm strictly speaking from the authentication sense.

CHARLES MAX_WOOD: Yeah, you wouldn't have people on Facebook in the middle. 

JARED_HANSON: Yeah, in the OAuth world, you have them in the middle, and they can see your activity by virtue of just that single protocol, OAuth here. That layer alone gives them that activity. Now, WebAuthn eliminates that. And we can talk about how, if you're interested. Of course, there's other layers in the whole stack to make it work, which things could be happening. But at least at the authentication layer, there's more privacy guarantees. The other trend, I think, that's like interesting to watch here is just like how that interaction model evolves. Like as, as these things change is like there's a lot more development, like wallet style interactions and things like verifiable credentials, where a lot of the patterns that you see with OAuth in terms of like, um, granting access to something or proving that, you know, like you're a certain person or have certain characteristics, you can start to shift to more of these like wallet style interactions where like my transactions with another third party are just kind of point to point. And there's a lot of like privacy benefits to that, uh, that shifted out of like, you know, your typical identity provider model where there's a third person. So like these things are all happening and I think it's like quite interesting. Um, they ultimately lead to like very similar user experiences, but very different sort of like technical and architectural. 

CHARLES MAX_WOOD: So just, you know, kind of coming back to authentication with JavaScript, maybe using Passport. Are these things that Passport currently has strategies for? Are these things you're looking at? Yeah, yeah, to some level, it's a job too, is the other question. 

JARED_HANSON: Yeah, yeah, so, so yeah, Passport's been like a good framework to evolve here. So like the strategies have been there from the beginning. So like, you know, WebFN didn't obviously exist at the time Passport was written. But because the strategy mechanism is flexible, you can implement strategies to do this. So Passport does have a WebAuthn strategy that's workable today. There's some... That WebAuthn is in development, lots of new features happening constantly as the W3C and the browser vendors sort that stuff out. So there's some features that probably aren't yet implemented in the Passport strategy, but I've got my eye on them and I know other people have some pull requests out there for them. So that's a work in progress. But you can get started on it today. For things that are further out in the horizon, the things I mentioned like verify viable credentials, those are much more experimental today. So there's not a strategy out there for them that I know of anyway, but it's certainly doable and something that I kind of play around with in the background. So if and when those things become adoptable, there'll be a strategy for those as well. 

CHARLES MAX_WOOD: So it's more a question of like maturity of the technology and things like that.

JARED_HANSON: Yeah, yeah, exactly. And that's one of the benefits of like that strategy pattern, like, you know, kind of one of the things I tried to do with with passport is make it like an open ecosystem. So like, there's now I don't know, well over 500 strategies, it might be approaching close to 1000. I kind of quit counting at a certain point. But like lots of developers publish strategies for tons of different authentic ways of doing authentication. And it's permissionless in the sense of like, anyone can do it, the API is there for you to do it. I myself at the beginning kind of wrote like 50 or so of the initial strategy. So you can see how it took off from there. But like, as these technologies, I know people who like pursue some of these more experimental technologies, who will write a passport strategy as a way of like proving that it's implementable or show that it's real. And then as, you know. You know, those technologies can succeed or fail on their own merits, but support. 

AJ_O’NEAL: So another question that I have passport is it's old, right? I mean, like you said, it started in the point two days. I, uh, I imagine it's probably gone through a major refactor or two as JavaScript has evolved to have native crypto primitives and promises and stuff like that, but us old dogs and anybody sensible is using Express because it's just simpler, right? And it's dead. And dead things don't change. They don't break on you. But it's not cool. It's not hip. It's not making any headlines. If Express 5 finally releases after what's it been, seven years in beta now, no one will probably care. So with..With the future of passport, are you making it available for or adaptations of it or a different version of it for things like fastify or what's that? What's that? I'm forgetting the name of the one that we had on just a few weeks ago. Can somebody help me? What was it called? It's it's one that's written for bun, but it works and notice. Well, the Elise is it Elise?

CHARLES MAX_WOOD: Elysia,

AJ_O’NEAL: okay, Elysia. You know, you got Bun, you got Dino. Are you just staring like this is tried, it's true, it's stable, you know, people that want that are gonna have this or are you doing anything to play towards the younger crowd? 

JARED_HANSON: I'm probably more on the former, like it's kind of tried, it's true, it's stable. I think like, you know, Express might be old and not cool anymore, but like I've also gotten old and not cool anymore too, so I'm maybe okay with that. Um, yeah, I guess I'm one of those people who like, I like stable technology. I like boring technology and like something that works works. 

AJ_O’NEAL: Who has didn't know 0.2. Well, fair enough. Fair enough. 

JARED_HANSON: Um, yeah, you know, there's always going to be something new. I think that's like part of what makes technology development exciting, but like also I'm not one to want to break things that, that are working well either. So I'll talk to that a little bit, like specifically. So with the passport, there's a notion, although it doesn't really get talked about too much, you probably leveraged all that often of having different frameworks that you can plug in underneath it. So this is more of an internal thing, but passport and the way it dispatches its authentication handling out to the containing web framework, if you will, is somewhat pluggable. So it defers to express and calls express specific stuff. But you can swap in other frameworks if you want to. And like back in the day, again, this is going to be like old stuff, but like that was leveraged by happy if people remember that. And so, and I think, you know, that probably doesn't get used as much anymore. Uh, but I know people have used that similar technique. Like there's, there's ways to use it in, in next JS. Um, I've played around with it in fastify too, as like an experiment. I'm not sure if it gets widely used in that ecosystem. Um, but this is something that's always on the back of my mind is like, okay, like how far it can be made to play with these frameworks in a better way. It's never quite reached the level of priority where I'm like, okay, like I'm gonna really like stabilize this pattern and vote it. It just doesn't seem to have that people asking for it, keep demanding it that much. But as I like play with things and refactor on my own time, that's something that's always there. And like, maybe at some point I'll get interested enough in one of these alternative frameworks to prove out and show people how it can be done. But otherwise I'm pretty satisfied with where it is. Yeah, I think, yeah, just to reiterate, it's stable and I feel no need to break it. If I wanted to jump to a completely different framework and probably look at doing it completely new JavaScript style and that sort of stuff, a JavaScript world has evolved and things like WinterCG and stuff like that I think are worth paying attention to and changing what it means to write like portable portable packages. But there's just a long tail of historical packages that'll probably never make that move. And I don't know what that does over time, but that's just kind of like, you gotta know your history, I guess, for some of these things. 

CHARLES MAX_WOOD: So I was also thinking, and this is a question I like to ask just in general, is, okay, well, what's the other, I guess, major alternative to this? And the thing that I'm coming up with, and you said you work for them, is Okta or Auth0, which is owned by Okta now. And so when would you pick one and when would you pick the other? Because I've used both, or at least both strategies, right? I've used the Warden strategy for my Rails apps and I've used Okta and sometimes it made sense and sometimes one of them caused way too much pain and I moved to the other. So in your estimation, yeah, when do I start thinking, okay, Am I going to get it done for you or am I going to do it myself? 

JARED_HANSON: Yeah, so so good question. So I'll give some background here. So like I would say, so password started in like, you know, like I said, 20, 2011, 2012. And I joined Auth0 and I think like early 2015, like shortly, shortly, maybe like a year after it got started. I was I was pretty early there. And, you know, Auth0 was like a big proponent of passport and promoted passport, and also like passport works well with Auth0. So I view these things as like really symbiotic in a way. I'll talk about what that means. But basically, if you look at passport, it's trying to solve the authentication problem generally. So there's always this notion of, okay, you can build everything yourself. So if you want to build your own login forms and all that stuff, go for it and a lot of people do and consider that something that's important to them. And I don't think I'd ever at this point, like try to talk you out of it if that's something that you wanted to do. That being said, I think one of the things that's important to understand as you like build authentication is you end up tackling a lot of problems that aren't just authentication, right? Like you might start saying, okay, I'm going to build my own login form, but now you've got to, you know, pass your passwords and like, you know, keep your cache is up to date, you've got recovery problem statements, like how do you email people like password reset links, you've got rate limiting problem statements if you get to any scale and people start to attack you. And there's just all these sort of problems that you might not know at the outset, but that eventually you run into, right? And it's not just about authentication, but it's about all stuff around. And so that's really like the premise of using a service like Auth0 or Okta, which is, okay, You know, you want to build an application and you need authentication that entails a whole bunch of stuff that you really probably don't want to do if you're going to have any like significant traction in the market. So just kind of like outsource that, right? And so like that's, that's the value of using a system that way. And I think it's, it's probably recommended for those people who are, you know, intending to launch like a widely deployed. That being said, even when you choose to use Auth0, for example, you still have to do authentication problem statements in your own application, right? So one of the ways of using Auth0 is just like talk to Auth0 via OpenID Connect. So Auth0 becomes like your identity server, but your application needs to speak OpenID Connect to it in order to authenticate. So it's like, yes, Auth0 is doing the authentication, but you might drop Passport in via the OpenID Connect strategy to have your application authenticate against Auth0. Similarly, you might be building APIs and Auth0 is issuing the tokens for those APIs, but you need to authenticate them in your own application. Authentication exists on both sides of the wire. You might build it all yourself and you can use Passport as one piece in your toolkit to do it. But really, you shouldn't have to build it all yourself but you still have to do handle authentication beds in your own application, even though you've outsourced most of it. So you can use them together as well. 

CHARLES MAX_WOOD: I want to be mindful of time, but I think we've got a few more minutes if somebody else has something they want to go into, or if there's something we didn't cover Jared. 

JARED_HANSON: No, this has been great. Your questions are awesome. 

STEVE_EDWARDS: Yeah. Sorry. I'm not much of a Node.js user. Heretic I know, but uh, so I like the smarter people ask the questions. I mean, I will say this that I mean, In my experience dealing with authentication, listening to other people talk with it, it's not some road I want to go down. You know, I like to be able to, some of the distributions that I use have a lot of that built-in for me, you know, whether it's simple stuff or something more complex. And it's just nice when I can start up an app and not have to deal with that. I just know that my users can be authenticated and I'm not having to reinvent the wheel, so to speak. So amen to people like you that do that for me.

JARED_HANSON: What about you, and what problems do you see like on authentication? I'm always curious to like, you know, people who are in the weeds on this stuff, like what are the challenges you're facing these days? 

AJ_O’NEAL: As far as I know, well, I haven't really looked. I've been building something incrementally for a few different clients, but having the ability for people to have their own single sign on and having the authentic having more like a library for authentication than a, than something that's frameworky. That the reason for that being that if you're, if you're building it rather than using Okta, there's something special that you care about that you need to tweak and the, the more that's abstracted away the more difficult it is to find the area to do the, whatever it is that the tweak needs to be. Um, but yeah, I, that, that's something I I've got, I've got a little, a little project that I've used in a few places over a few iterations and, and I, I tentatively called it lib off. Cause the idea is that it's at some point I'll have like a lib off in this. And libAuth init will write out the routes and it'll have a lot of boilerplate in it. So if you need to go tweak something, you'll go tweak the boilerplate rather than having it abstracted into a single function where you have to re-implement the strategy to move those few things around to track it in a different way or whatever. So I'm not building a lot of uh, new applications. So I'm not dealing with off often, but those, those are kind of the two things is as a company gets larger, they want other companies to be able to integrate with their API and so then they need a single sign on for themselves to export out. Uh, and then like I said, just is there, where is the middle ground to export the primitives and in some ways it starts to feel like. Well, these functions are so small and so tiny, you could just implement them. But then it's all those little bits over and over again. Your function would end up being a hundred lines long. But if you, you know, so it's like, where's that nice middle ground where it's not just abstracting away trivial things that granted end up being a hundred lines long, if you don't abstract them away, but you're also not abstracting away the meat and potatoes to the point where you have to copy, paste and publish a new strategy. 

JARED_HANSON: Yeah, no, I track exactly what you're saying there. I think that points to like why authentication is so interesting, kind of challenging is it's such a cross-cutting concern in an application. And a lot of people have very like specific requirements they have when they want it. And you touched on like something there, which is like, okay, you've got your, your clients and what they really want to do is like provide system own API. So it's kind of like at that point, they want to be their own OAuth circle effectively, right? Which is a common thing that companies do as they grow. But it's in my view, even though these things are related, you're moving from authentication into more like authorization problem statements, and you get like a lot more things around like, oh, how do I prompt my user for consent and like, you know, scopes I need to prove present them dialogues to say what they're granting access to in a way that's understandable. And that gets to be like, you know, now you're deep into like kind of the domain model of the application itself at that point at some, at some layer. Right. 

AJ_O’NEAL: And also, you know, you talked earlier about the SPA stuff. So this, this auth library that the result of it today, it's, I've started it over a few times. But Almost every single time I've hunkered down and been like, okay, I'm really going to flesh this thing out and I'm going to, I'm going to make it into a real thing the next day is, you know, major update to browsers, uh, you know, iframes no longer supporting. Yes. Right. It's like, okay, so now we can't have seamless authentication anymore because of click jacking, whatever. All right. So, okay. Scrap this, come back to it a couple of years later. All right. I'm going to, I'm going to write this thing again. Then, you know, Like literally I'm almost done and, uh, you know, Firefox, Safari, and all other browsers, except for Google, no longer allow third party cookies starting next month and it's like, Oh, well, that's not going to work, you know? So that's kind of one of the frustrating things is the, the primitives that allowed us to make authentication seamless, keep on getting removed. The buggy things don't get better. I mean, I think that we still have that problem. If you're on an iPhone web view, uh, if you call window to close, it doesn't close, you can't redirect and so then like the user, so, so like the things that were easier getting removed and the things that are blocking us from having a seamless experience, those bugs aren't actually getting fixed. Yeah. And it's like every couple of years, there's some major change to the way that browsers work between third parties. 

JARED_HANSON: Yeah, I think that speaks to the sort of like interplay between effectively like an end or client side authentication concerns and like back end server sided concerns. And like, you know, I guess fortunately in the case of PassportJS, I like really focused on the back end concerns itself. Right. And like kept all the client side stuff out of it. You know, that's been scalable and evolveable in a relatively sustainable way. Uh, but to your point, like maybe makes the developer do more of the front end stuff that themselves, right? It's less abstract. 

AJ_O’NEAL: I've got that front end stuff. It's all broken. Like any strategy that you ever would have tried to do this stuff on the front end. It's all broken over the last 10 years. 

JARED_HANSON: Like, yeah, for sure. For sure. 

AJ_O’NEAL: Yeah. So it turns out that the only thing that has reliably worked over the last decade has been put the whole thing on the back. 

JARED_HANSON: Yeah. Yeah. Yeah. And I think, I think that is probably like, so the trend, like in my own kind of like ideal world, I've often toyed with like kind of marrying like passport or any really backend off framework with like a seamless, like front end framework. I think that'd be interesting, like from my identity nerd type of standpoint, like that's a challenge that would be fun to solve. Um, but to your point, like it's, I've took stabs at it like here and there over the years, but I've never really felt satisfied with like the levels of abstraction that could be achieved and making it like DevEx friendly. So I still think there's like room, room out there to like improve the front end side of things and then integrate it. 

AJ_O’NEAL: Are you aware of the portal spec? 

JARED_HANSON: Portal spec? No, I have not come come across this. 

AJ_O’NEAL: We will see whether or not a this is ever implemented and by implemented, like my thought is basically on the front end, if you're a responsible developer, you shouldn't be using anything that hasn't been around for two years. Unless unless I mean, that's not entirely true. Because a lot of times you can bet on the future and by the time your product rolls out, that thing has been available for two years. But a lot of times it's already been deprecated deprecated or taken off of the standards track within two years. So that's where it's like, and then you end up with the Babel story where for the rest of time and eternity, you have to either use Babel or you have to use something like, um, like back in the web socket days, what, what was that one called the super, super popular web socket framework 

STEVE_EDWARDS: socket I O 

AJ_O’NEAL: socket I O right. Like socket I O still implements like an I frame strategy or they may have removed it. Yeah. You know, like you end up with that, with that, that kind of thing. So portals If it actually comes to fruition, my understanding is that will be a secure iframe where the iframe changes the URL and the URL bar. So a portal pops up like a modal. When you click into the portal, the URL changes in the URL bar. And then you have the ability to expand the portal, to take up the whole screen and potentially some sort of CSS transition so that you could do, for example, an OAuth flow without a redirect, you open up a portal like opening up an iframe, but the portal takes over the URL bar. And then when the portal goes away, the URL bar goes back. So it almost looks like in all respects, a redirect, except that the redirect never happens, the state of the application and the background, like the form that you were halfway through filling out or whatever stays while the flow in the foreground happens. 

JARED_HANSON: Yep.

AJ_O’NEAL: And it sounds really, really promising if they figure out how to do CSS transitions so that it'll work the way that people want to, which it sounds like it probably will. Cause I think they're already doing CSS transitions for redirects. Now, if I, if I remember correctly, there's some sort of spec to basically say. You can have a CSS transition that if you load a new page, the new page will load. Yes. The transition, it'll feel like a single-page application or multi-page, but that's that's something I've got my fingers crossed for, because it essentially solves all the problems. It solves the security concerns. It solves the state management concern. If portals land, it will be the perfect tool for seamless authentication. We'll finally have what we had back in the 2000s without the click-jacking. Until somebody comes out and do the click-jacking and then we'll lose it again. I don't know. 

JARED_HANSON: Yeah. That sounds promising. I mean, that state management problem is like one of the things that has always like hung up like oof adoption and you know, like spots in particular is like you redirect and you lose all your state that's sitting there in the browser. And then you got to like reconstitute that on the redirect back and it's never worked right. 

AJ_O’NEAL: So which would totally be fine if we could use the pop-ups except we can't use the pop-ups because they don't work on mobile. 

JARED_HANSON: Yep. 

CHARLES MAX_WOOD: All right. I'm going to push us to picks just in the interest of time before we do that, though, Jared, if people have questions or if they want to follow anything else you're doing. Where do people find you online? 

JARED_HANSON: Yeah, so Jared Hansen is my handle pretty much everywhere. Twitter slash X, GitHub. You can go to PassportJS.org and everything will be linked from there. So yeah, check it out. Shoot me questions. 

CHARLES MAX_WOOD: Awesome. 

Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End Devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topbendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive, and we're gonna be going into Docker and how to use it and things like that. We also have workshops on the following topics, and I'm just gonna dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time. They also want to make more money. And so we're going to talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. That one's going to be on February 7th, February 9th. We're going to have a career freedom mastermind. Basically you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're going to actually brainstorm together, you and whoever else is there. And I, all of us are going to brainstorm on how you can get ahead. Um, the next week on the 14th, we're going to talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a visual studio, uh, or VS code, uh, tips and tricks. Um, on the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at topendevice.com slash sign up. 

CHARLES MAX_WOOD: All right, well, let's do some picks. Steve, you want to start some picks? 

STEVE_EDWARDS: Yes, I will start with picks. And I actually have a couple lower level picks before we get to the high point of the podcast. A news breaking today as of this recording that would be a rather large issue in the design community is that Figma and Adobe have bailed on their merger. The top of Hacker News, Dylan Fields, who's the CEO of Figma, put out a blog post and basically said there was just too many regulatory hurdles. And so they have bailed. And I think if I remember correctly, the number was something like $20 billion merger. Oh, wow. It was pretty huge. And a lot of, I remember hearing a lot of designers saying, all right, Adobe is going to screw up Figma now. I'm getting out of Figma. I'm going to something else. So it'll be interesting to see if this, I'd be curious to see number one, how many people actually did leave Figma and two, how many people come back after this. So that's some interesting news. And then in the burgeoning and very important world of interior design for automobiles. This sort of struck me because I've seen this happen elsewhere too. There's a story on the drive about how with the newest designs of Volkswagen has really got a lot of pushback because in their carriers, they've gotten rid of tactful physical buttons and everything's been on touch screens. And so when things don't work, a lot of the time people get really frustrated, which is pretty common. And so what they have said is they're going to go back to using actual buttons for a number of features within the car. And I saw the same thing recently from Hyundai as well. Their chief designer had said he's going to keep using buttons because people are used to them and actually work. You don't run into a lot of the issues that you do with touch screens on, on digital displays. Uh, you know, for me, myself, my vehicle has some stuff on, on, um, on the touch screens, but there's some stuff that you can actually do with physical buttons in my truck and it's really nice to have that. So sort of a- 

AJ_O’NEAL: So frustrating that try to adjust the temperature and have to like deal with a flipping touch screen when you're driving. It's like just give me the flipping knob, like come on. 

STEVE_EDWARDS: Well a knob or even mine has a couple of up and down buttons that you can push pretty easily as well. So yeah, it's one of those cases where you see the pendulum swinging one way and then it's coming back because people realize maybe this one way isn't all it's cracked up to be. So interesting. And then, um, 

CHARLES MAX_WOOD: we got a new, uh, oven and they have digital buttons for the, to set the temperature. So you turn it to bake and then you hit temp and then you, and yeah, it's most of the time it works. And every once in a while I'm practically breaking my finger on the UI, trying to get it to read that I hit the three 

STEVE_EDWARDS: and probably breaking the UI itself because you're pushing so hard, right? 

CHARLES MAX_WOOD: Yeah. 

STEVE_EDWARDS: Right. Um, okay. Time for the jokes of the day. And those of you, uh, dad joke, uh, aficionados won't be happy to hear that. I have my rim shot back. So, uh, that will enhance practicing for these. Oh, yes, Jared, you can either laugh or groan. All, all responses are welcome. Um, sort of a simple one today. What did the sushi say to the bee? 

JARED_HANSON: Wasabi. 

STEVE_EDWARDS: Right. So, uh, For those of you who may be a fan of the Budweiser, was up commercials from 20 years ago, there's a great one about Wasabi. Just Google Budweiser Wasabi and you'll see it. So recently for my son's birthday, I got him a sort of simple gift. I got him an alarm clock, but it squares out of instead of beeping. So he's in for a rude awakening. Right. And then finally, You know, I've talked about some of the jobs that I've had in the past that I get fired from and, you know, working at the calendar, the typewriter keyboard factory and taking off too many shifts and that kind of stuff. But one of my first jobs was, uh, posing like a mannequin in a clothing store window. I held that position for a long time. Thank you. Those are my picks. 

CHARLES MAX_WOOD: All right. AJ, 

AJ_O’NEAL: we did have some silent chuckles just for the listener only audience. Yes. Very even Jared was, you know, having to have an email on one of those. Yeah. Uh, okay. So I've got, I've got a technical pick for the first time in a long time. I think, I think it's been a while since I picked a JavaScript library, but. Uh, recently so there's this old application that I'm working on and it gives me so much anxiety. It's so, it's so fragile. It's been getting better and better over the years. We've refactored a lot out of it, you know, but, but there's just, there's just times when I'm scared to push the production and a tool that I found recently as I'm trying to gradually add types to it so that I can feel more and more confident. I found a couple of tools. One is MySQL Schema TS and Postgres Schema TS that will read, you connect to the database, it'll read the current state of the database, not what's in the migrations, which may not reflect what somebody did as a hotfix. Uh, so it'll read the actual state of the database and output typescript interfaces. And then there's another package TS to JS doc, which will translate from those whichever tables, or if you've selected the whole schema will go through and then read the typescript definitions and then translate them to JS doc. And so then you can mark your types. And I have not been able to get objection to work with the TypeScript checker in JavaScript. I hear rumor that the latest version might work if you use it with TypeScript, or maybe the latest version would work if you use it with JavaScript, but we're pinned to the version that we're pinned to. But anyway, so those two tools have helped me and helped me find a few bugs because I can basically manually overwrite a call to the database and say, ignore what you think type the type is that's being returned that you're reading from the ORM instead, you know, this is the type that's that's being returned. And so those, those two tools have been really helpful for me. And if you're interested in either starting new projects, uh, using JavaScript with types, or you are trying to migrate a project to incrementally add Uh, type checking, uh, I did a presentation on this. It's up at JS with types.com and there's a little NPM module that you can run NPM and knit, and it will do the magical incantations that will make it so that you can use the TypeScript checker in JavaScript, which there's a lot of blogs out there about this, but there's a lot of, I don't know, there's like a lot of little details and if you want to get the TypeScript checker working with It's, it's deceptively not easy. It's, it seems like it should be straightforward. It seems like, Oh, I'll just, you know, set JavaScript types to true in the config file and that, you know, this should work, but there's, there's like a number of things that you have to do that are not intuitive and they're difficult to explain. So if you run the NPX JSWT in it, it will just do the right thing. Um, Or, or if your project is set up in a particularly weird way, it'll, you know, you can at least open up the config file and hopefully see you need to change your lib directory name or whatever. So, uh, I, and I've, I've been a huge fan. I hope this has come across on the show. I'm a huge fan of JavaScript and types. Huge fan. I wish there were simpler ways to do it. I wish there were better tools for it, but I, I love JavaScript's native type system. I think it's amazing. Uh, I don't think it's perfect. I don't really think it's amazing. I think it's workable. I think it's very, very workable. Not amazing at all because it wasn't designed to be a type system. But we have, JavaScript has types and we can use those to our advantage. We don't have to pretend like double equals is the rule. Double equals is not even an exception. It's not an acceptable option. We can use strict, strong typing in JavaScript. And after all, I mean, even if you're using a language like C. I would say that C is very weakly typed. The types are in the tool. If you have bad tooling, you have bad types. If you have good tooling, you have good types. And, uh, the, the TSC, the TypeScript checker is certainly acceptable and will help you have a better experience with JavaScript. Um, other picks a little, a little quicker, hopefully, but I, I came across these speakers. So I had this issue where, I mean, you know, It's just the world is falling apart. I'm going to refer back to, to Jonathan Blow's talk, the collapse of preventing the collapse of civilization, right? Like things that seem like they should work because we're more advanced now. Don't. I had these Bluetooth speakers. They would literally cause my Mac to eventually the Bluetooth audio model would kernel panic and then audio would stop working without a reboot. This is. It could be that the Bluetooth speakers, they were, you know, fairly cheap speakers from a no name brand. Right. So it could be that the speakers were just bad, but shouldn't the kernel be more resilient against malicious hardware? I mean, isn't that like the colonel's job is like, Hey, you're malicious hardware or, or your hardware that doesn't follow the spec properly. Your reset. No, like instead the kernel resets. And so I bought a new pair of speakers and they're the creative T sixties. And they're larger than I thought they were going to be. And in my mind, they were probably about the quarter size, a quarter of the size of what they really are. They are about the size of a Nintendo Switch. Well, bigger than that on just the face of them. Yeah. About that size on the face of them. And then they're, I don't know. What are they about the size of, um, if you go back, cause they're not thin like that, but it anyway, but they, they ended up being bigger, but the sound quality is actually really, really good. And they connect via Bluetooth, which I have not tried. And I don't want to try, but they also connect via USB-C, which when I did the swap between these and the other speakers that were messing up, literally caused the computer to restart. I don't know what's happening with the Mac operating system, but it's not good. Anyway, but they sound really good. Like they have an amazing sound stage and there was 65 bucks. Like I, and I'm, I'm an audio snob. I, you know, but these, they actually sound good. My only complaint is that because I'm using them via USB-C because most people could probably just plug them in with the 3.5 millimeter cable and be fine. But because I'm plugging them in with USB-C, I lose a volume control. So I have to use the Loopback app to make a virtual audio device that outputs to the speakers set my system output to the virtual audio device, and now I have volume control on the keyboard again. Why that can't be just done in Mac OS? I don't know, but the speakers themselves, they have the Bluetooth option, the USB-C option, and the 3.5 millimeter option, and they just, they sound so much better than I would have expected at $65. So Creative has done it again. I just, huge shout-out to them for it. Again, it's the creative t 60s. And then, okay, I'll be fast on these ones. I promise I think I brought no I promise. I talked about the hammerhead metal showerhead a few weeks back. Our other shower head in our other bathroom broke. So I bought another one. So I brought it back to my remembrance. So easy to install and I have no doubt that it will last at least as long as I do. Or at least as long as the house does. So if you have

 

showerhead holders breaking because they're the silly plastic ones that ship with every single showerhead which no showerhead manufacturer provides as a replacement part To on their website because they really don't give a darn about their eco-friendly blah blah blah blah blah save the planet blah blah blah blah blah, they just want you to buy new shower heads the hammerhead metal showerhead will will save you and you'll never have to buy another showerhead holder again and then My wife has fallen in love with me all over again because I bought a degrees of comfort king dual heated blanket for the winter. Because I can't stand the house being hot. She wants the house to be like 100 degrees. And I'm like, it's winter. It's okay. The house can be cold. And I bought this blanket for us and it's dual-heated. So each side you can pick how warm you want it. So I can turn my side off. I could turn it on when I'm just getting into bed. And then turn it off when I'm about to go to sleep and she can leave her side on all night long. And this is working out great and she tells me every single day that she loves it. So yeah, and it's got good ratings and I looked through dozens of them before picking one and I feel pretty confident that it's probably the best one that I could have gotten. So I'll give a link to that. So those are my picks.

CHARLES MAX_WOOD: All right, I'm going to jump in. I'm going to be really, really brief. I always do a game pick. The one that I've been playing lately, I've picked it before is Risk Legacy or Game Geek Weight of 2.59, which means that it's a little bit more complicated than the average gamer wants to play. But if you're a fan of Risk, it's actually the games go faster and it's, it's, it's a lot of fun. So I do have to say my friends, after I won the first two games, they ganged up on me. So that happens, right? Anyway, a couple of other picks. We're gonna be doing things, a few things different. One of them is, is we're gonna tweet out before we go live every week. So keep an eye on that. You can follow us as JSJabber on Twitter. You can find a Facebook page. The YouTube channel is Top End Devs. You can go check all that out. And then in addition to that, we're putting up the premium version of the podcast, which just doesn't have the ads in it. But a bonus I decided I was going to add was that if you want to help us decide what to talk about, right? So it's like, Hey, so-and-so would be a good guest or Hey, I'm learning about this topic and I think you ought to talk about it on the show, right? So maybe you go try out WebAuthn and it's like, I want to learn more about WebAuthn. Is there a WebAuthn guy, you know? And it turns out, yeah, I probably do. So we'll, we'll get that lined up. And I'm gonna be doing those once a month. And all you have to have is that premium level. Now I'm also putting together videos, weekly videos on training, kinda like what Railscast used to do for Rails, except it's gonna be JavaScript focused. I'm also doing a React series. And then we're gonna have JavaScript geniuses, which is going to be three meetups per month. They'll all be at the same time of day, same day every week. And we're probably gonna have an expert one week. We'll do a Q&A one week. We'll kind of do a workshop or live coding or something else the other week. And then it also includes a meetup with the rest of them, the Ruby geniuses and the React geniuses where we talk about career stuff, right? So tools, careers, things that are not specific to a language or framework. So definitely go check all those out. And then I'm also finally working on the how to get a programmer job book. I released it a while back but there were some updates I wanted to make to it. So that'll come out next year and I'm self-publishing it. So you'll be able to just get it on Amazon or off of the website. Jared, what are your picks? 

JARED_HANSON: Picks, so I recently moved into a new house. So I've been kind of setting up new house stuff. The pick I will throw out is Ubiquities networking gear. If anyone's looking for like house wifi networking gear, it's a pretty nice equipment that I've enjoyed.

CHARLES MAX_WOOD: Nice. 

STEVE_EDWARDS: I've heard that recommended rather ubiquitously whenever I look for networking gear. 

JARED_HANSON: Yep, highly recommended. Slick, works well, easy to configure. 

CHARLES MAX_WOOD: All right, well, thanks for coming, Jared. This was fun. 

JARED_HANSON: Thanks for having me. Always interesting to dive into this stuff too. 

CHARLES MAX_WOOD: Well, we'll wrap it up here. Till next time, folks, Max out.