Hey, welcome back to another episode of JavaScript Jabber. This week, on our panel, we have Steve Edwards Well from Very Cold and Wendy Portland, A j O'Neal yo yo yo, coming at your live from the year without Santa Claus. I'm Charles Maxwood from top Endev's Go check out JavaScript geniuses dot com. That's where I've got my latest stuff going on. We have a special guest this week and that is Jared Hanson. 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? Yeah? So I'm an engineer by background, been doing professional development product development for about twenty years now. Most of your listeners would know me from passport JS, which is very popular authentication framework in the no Jazz ecosystem. I currently work at Octa by Way zero and have been, you know, in addition to being part of the no Jass ecosystem, really involved in the identity industry and identity
world. So I thinks like up an id connect a lot, et cetera, and who's spent the past fifteen or so years kind of focused focused in that area, which I really enjoyed we can get it. Yeah, very cool and yeah, as we kind of get rolling, I don't know if I want to assume that people know what passport JS is. I've talked to quite a number of people who use it, but you want to kind of give us the background as far as like what it is and what it does,
what problems it solves, and who may want to use it. Yeah, absolutely so. Passport JAS is an authentication framework for no Jazz. So what that means is basically handles all areas of logging into your application, being a web application with the typical HTML user inter or if you're building API applications and 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 for a long time now. I think my first commits on it were back in twenty eleven. Just to give some context for people, I think the node was on like zero dot two at the time, and now it's funny stuff then kind of forget so, you know, coming on with maybe not the most you know, most recent topic,
but still always very relevant to to security. And yeah, like I said, primarily, it's a middleware for Express JS. So people familiar, you know, some of this stuff kind of like maybe gets forgotten the history a little bit, but anyone who's writing Express JS apps is very familiar with the middleware pattern. So authentication is just middleware that you stick in your application in order to authenticate a user. If they aren't authenticated, then then the
middleware stops and the request is denied. Otherwise you're provided with the user and then you can write your business project to return you know, user specific cool. So just to get a little more clarity on this, and I'll admit I haven't done a whole lot with passport jass 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 uh myself, you just managed
the the stuff com back and forward? How much of how much? So many of the pieces do I get? 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 in your login screens and your front end code, that is all entirely up to the application developer port so you're free to pick you know, your templated language or you know, react things like that, whatever, whatever your preference is on the front end and passport JS is just handling the back end components of those things. So if you're you know, just form posting your thing up in a log in form and it'll handle that.
If you're doing APIs, then you know, your your client side is responsible for putting the tokens in the request and it'll those that and authenticate it that way. It's it's really, you know, 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 and leave the rest of the choices
that aren't it shouldn't be authentication related up to the development. So let's say that I want to authenticate against Google, right, because you have all these authentication strategies, So I write my log in page, I put the Google icon on there, I click it, and then what else do I have to do to make it work? Yeah, so with Google, so if you go to passport, jass dot org, there's kind oftorials that walk you
through these various things. So, okay, 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 disparateness to authenticate, how do we give sort of like a single consistent way to you know, drive that from from
within code. That being said, there are slight differences across these things. So for instance, you know, one common way is just you know, use your name and passwords, submitt it feel a log form the developer has to do that. What you brought up is you know, logging in with Google for instance, to be an open ID connector or two, which has some kind of different semantics than just runing a loging form. In particular, there's you know, you got to re direct to Google and then handle a
couple interactions there. So you do probably need to have like a bit of background on kind of like what the prerequisite parts up, particularly with respect to like your user interaction, because like I said, Passport is just a back end 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, up the Google button on your page, a user clicks it, and that will you know, send a request back to your application, and you put the passport middlewhere there. The Passport then will start to take over the O off flow because that's 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 passport dot authenticate Google, and then Passport will take care of redirecting the user to Google, at which point, like 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 your I or call back your I. And then here again you just put the passport middleware on that particular route in your express application, and then Passport
will finalize the O off their open idconnect interaction and then just supply the user. So it's really it's really just basically kind of in a in a end wave, you sort of sense like two lines of code that you add as middleware at these two endpoints UH to handle the processing, and then a few more lines of code of just configuration to set up things like your client idea
and secrets, credentials the Google issues you in order to use. That makes sense, I mean that I mostly do Ruby on rails, and you know Warden is kind of the yeah there, right, so yeah, and then there's devices built on top of it and that provides you with the views and things like that. But yeah, that makes a lot of sense. So h 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 into 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 you know, 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, Yes, one hundred percent, absolutely cool.
So what does it take to write something like this for me personally? Are people dropping it in their application for you? Yeah? So, So, like I alluded to at the beginning, 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 twenty eleven, and I had been doing you know, this was kind of like the early era of the like web web two point zero, So I got super fascinated by opening and oh and on 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 uh, doing a startup that was more kind of an enterprise focus, 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. 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, Zarah dot too, and in my background is more as a systems programmer, so C and C plus plus And when I took a look at NOE, I was like, oh, this is super interesting. You know. It's basically you're writing io heavy applications, server applications. It's got all this event group stuff in
it with with equal and whatnot. And it was like I first took a look at Node, like the internals of Note, the C and C plus plus stuff that's that's going on internals, I was like, Oh, that's super interesting. 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. It's faster development and reasonably past performance. And so that's kind of what drew me to Node.
And then as I was looking into Node and like looking for maybe like 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 note world, And I was familiar with things like like Mordan, a devise from Rails, and there wasn't really anything that existed at the time for Node. There was another project called every auth, which I took a look at,
but wasn't necessarily super happy with. So I was like, oh, okay, like I'm gonna I'm gonna try my hand to make authentication framework for node and see what happens. And so really it was, right, yeah, how hard could it be? And you know, it was like you know, like any any develop you know, and like I was looking for a challenge and and something you know, hard but also fun. I guess
pre promises. It was so much harder than it needed to be because I mean that triangle pyramid waterfall callback of doom thing, I mean that that that made I mean I back the days looked through the passport code. It was difficult to read because it's like callback call back back. I mean, everything was back then, not not anywaysing on it, but you know, especially
because the off flow. Yeah, I was I was trying to fix an issue with cookies way back in the early days because the then most OFF 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, it was like trying to trying to follow from this callback to that callback and then like an event system that was Those
were tough days before promises. Those were really really tough days. Yeah, absolutely, I mean I think, like you know, that was what one of my trying to like experiences. At the time. I was also just learning job script. I wrote some of the stuff I had done a little bit, but nothing significant and and honestly, like I found jobs a little bit confused, honestly to that point. And so like I was learning that
at the same time. And and that said, like all the callbacks, you know, any any sort of like a syncoprins io where it's an vent and can it can be hard to read because it's you know, as you know, like not linyar but more driven over time. I guess you haven't done d But so yeah, it was kind of one of the challenges Passport is like design and API that that can can take those challenges and make it somewhat tractable, you know, and I think I think it's done a decent
job of it. You know, obviously there can always be imp events, but so yeah, that's that's what I set out to do, and like kind of my my premise was like that middle Wattern where it's just like passport down authenticate and then you know, using some strategies and like 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 throw the authentication
and nowhere they're and reasonably. Then I think that that mess dedication, you know, tractable and easy, and I think most people used it to good
effects. 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 I published Passport, you know, the first the first initial versions of it, and spent a lot of time just like Twitter was also kind of new at the times, Like the times when tweeted about Node or off, you know, I'd replied to them against stack upper flow and just like a lot of community development and reaching out to people and telling them that the project
exists, and did that for a while and then it sort of just kind of threw the legs and took off from there and now it gets i don't know, a couple couple of million plus demos and a month and PM or something like that. Yeah, just it's been interesting to watch an 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. So one thing I want to call out that you mentioned, and this isn't specifically to passport, but I talked to a number of open source developers and they're like, like the package and the people who just 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 a joscript. That's strategy that I've seen, you know,
in the podcast in this space as 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 Twitter or Facebook or wherever. So you have a specific method for doing that or no specific method other than
just like reaching out and talk to people about it. You know, I think, like, you know, one of the great things about how easy it is to just like communiate with these days, and like everyone's connected online. So yeah, and also you know, like when you have a project like that, you're just super passionate. I don't want to talk about people anyway, right, So yeah, I just reach out to anyone who who seemed interested or you know, and like, especially when you're saying, hey,
check out this project's free. Maybe your problem, you know, it's like you're really not asking them to do a whole life. Yeah, pretty pretty easy to to you know self. I guess yeah, yeah, No, I was going to say, like, the one other thing that I think I would for it's like for for people that are relying too kind of raizareness of the things that they're doing is what the documentation. You know. I think the other thing is, like you know, I do for any
project that 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 and adoption. You know, it's like a GitHub red Megle and he
go so far, especially if it's a somewhat bigger or more substantial. 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 yep, 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 mash, so I'm out of luck. And yeah, a lot of times on that. 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 NO developer or Python developer whatever, and just having the you need to have installed node and you need to have you know, done some other thing, you know, create a run n
PM and NIT 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 read mes 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. And I would imagine that, particularly with Passport, you observe this is because people are not necessarily Node experts, are like, oh, what's the easiest way to get an app together with this type of oof? And they, you know, 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 foofoofoofoo foo, it can be difficult to tell, okay, which of these foods was supposed to be a r L And if everything is like exactly 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 out, Well, let me let me play Devil's Advocate on you for one. AJA. Oh right, 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 Larra
bell, you know, help on different things. And I'll come across the Bond posts all the time, and I swear nine times out of ten and half of the blog post or three quarters of the blog post is just getting a later Velt project up and running. Oay, 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 Lavo website about how to get a basic layer Velt
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 gets you got But you've got to make some assumptions about some basic knowledge at some point. If you're a developer, you can't every blog post, every reading's not going to have, you know, one 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. Now I'll
kick me off and I'll go away faster than anything else. I agree on that, But what 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 one hundred steps to create a Larabel project, then yeah, the link to it, right. Yeah. One one thing I want to add to that is just in Steve's example, the thing that always trips me up is it's here's the here's the
three quarters of the thing that's boiler plate. But halfway through that three quarters is a critical step. Oh yeah, right, because I'll skim it and I'll go, 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 kind of want to 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 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 ten 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, you know, I set up the Passport website and some documentation, and and the documentation was really fully a little bit more conceptual in nature,
which which was fine at those days. So think about like again, like Node back in zero dot two, zero dot four, you know, the three one zero days, like Node itself was attracting sort of a different audience and developer you had like very like leading edge developers who are willing to get in the bleeding edge and reading a lot of code. Like when I was writing Passport, I was reading a lot of code of other other libraries at the time just to understand the And I think that was that that was
common. Like a lot of the people that started using passport, even though it made it relatively easy, I think they were you know, the type of developer that was willing to get and read the code and the internals. Like like you were saying, ah, whether whether they understood it all or not, you know that you had people digging into it, and so like
the documentation was a little bit more geared towards them. But like as you think about this at the scales, just in like number of adopters and like over time, you start like note has attracted different different developers over time. Now it's much more of an established thing, you know, like it's not
leading edge anymore. People 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 involved the website over time a lot as well to like add documentation, which is which
has really helped a lot. So one of the frameworks that that I used was have you guys come across diete, I'm not quite sure how you say it's like a documentation framework. That's interesting. I'll send you guys a link and we can put 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 like it assumes some knowledge, like you have note 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 the log in 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 like the APIs and that sort of stuff options.
I just want to know what's there. I don't want to like follow it tutorial and then there's like conceptual documentation, which is like, Okay, I might have this thing running in my app, but now I need to know like what's actually doing, Like what is this o OP thing behind the scenes, which I, you know, didn't have to know from the touch oreial, but maybe I want to know it now that I'm you know, more experienced with my application and taking the production, I want to know what problems
I might face. So like, different developers at different stages have different needs, so like writing documentation to those needs is really important, and I saw that like one of the kind of motivating factors for me to add some of that documentation to the website was just like the sheer number of GitHub issues being filed of like you know things like you said, is like okay, like I just holded this library and like trying to put in my app, it's
just not working. I don't know how to fit all the pieces of right, which is maybe not something I obviously would have like seen being the developer of it. I'm of course, like 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, and so like taking a step back and writing documentation that just kind of assumes very little knowledge about
the system has like greatly reduced my own how of support load. It just like cut those issues down because now there's just a tutorial to point too if someone has a question or you know, the questions off to go away because they find the tutorial in their own So it's just kind of a way to scale I guess my time or a maintainer's yeah, yeah, makes sense. I kind of want to take us back working on passport JS and onto authentication.
So let's talk a little bit about authentication here for a minute too. You get this basic functionality up where you know, maybe it does oh off or open ID or something, and you know you can you can maybe bring some other strategies. When when did the new strategies come in? Was that something that was there from the get go or was that something that ye,
yeah, the strategies were there from from the get go. So I think like if I if I remember the evolution of this basically like the first stround where your typical like user name and password and then oh off and open ID, and I think it was like oh off one and open id like two point zero at the time, sort of like you know, technologies that have sort of baited over time. But yeah, the strategies were always central to the framework because like author is so disparate and I wanted a way to unify
those things. I think the O off 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 it took two weeks to write like the framework and the first log in, like the use name and password strategy, and then and then I think I added some like basic off and like you know, the API style authentication, and then I added oh stuff, you know, all all within the span of about a month, I think.
But like the OFF piece, like once that was working, I knew the framework sort of had what it needed to handle the all the use cases because that's like you know, that's a broad range of different functionality that you need and like accomplish hat and it all sort of fit within this nice like strategy
pattern in the middleware pattern and that was pretty satisfied. Yeah. Yeah, I think 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. But like, how has the problem set for authentication changed over the last ten years that you've been working on this, right? Yeah, so good,
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. H Like, I would say, like one of the biggest changes has been like just the like single page applications and MOREK front and 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 like login forms and session management. Right, You've got like newer API style stuff where you just might be writ and just chase on APIs
and you don't care about any front end stuff. And then you've got you know, single page applications and mobile applications accessing those APIs where like the logging is done completely on the front end, somewhat disconnected from the back end, and you get like token based authentication, And there's a lot of similarities between those things, but also a lot of like key differences just in terms of
like architectural stuff that you have to understand. And I would say, like that to me, has been the biggest change is that these sort of like single page applications and mobile applications are like you know, far more popular and predominant today than traditional web application and sort of like understanding those differences has been the biggest challenge, uh, looking forward a little bit more, and this
is this is stuff I'm excited about. But you have things like web then happening now and and there's some kind of newer work that's out there to do, uh 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 is pushing into. That are that are pot topics and
challenges today. 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 that these things were kind of stagnant. But now Windows Hello is in a it, mac Os is integrating it, and then the browsers are also integrating it, which sometimes starts to get confusing because there's like multiple layers of web off in. Yes, yeah, so like what what what have you seen in weboth in
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? 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 Window slo and you
know like touch I D and face id on on math now. So yeah, it's nice that it feels like magic because if I don't want to fight it, right, I can just reach for something like passport and not have to worry about it until I have to worry about it. 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 web then and technologies like that are both more secure and easier to use, which is like a very rare thing to happen in the security environment usually, like making something more secure makes it harder to use. It was less secure because there's more knows where people go around. The hoop I have to jump through is on fire, yeah for sure, for sure. So yeah, so I think like some context here, you said like web then is coming with 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 ubiky that you held up, like the USC protocols, how all that hardware to hardware stuff happens at a low level, and they did some initial like job script work, but they took their job script work to the W three C and that's where web oftn happens. So it's kind of like web of then 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 tope right. So it's like you got your Fio device that you plug in or you might be built into your computer, and it makes it super secure and fishion resistant. But one of the 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?
Right? So if I've got my Fido key and my laptop and I've got both of those registered, but like the final keys plugged in the laptop and my laptop gets stolen or lost or whatever I have, I have no hardware devices left, right, So how do I get into my account? And 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, you know, maybe without you even realizing, you know. So think about a developer. They might just say, oh, like Fino is the latest thing is a secure implement that. Now you've got a customer that calls you off on the phone, like I can't log in anymore because I've only had Fido credentials, Like what do I do? Right? And so never seen that in the wild though that's like, well, 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. Yeah, one 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 well we'll basically make these Fido style keys, these web than keys, but we will sink them on iCloud, so they sink across the
devices. So if you register it on your phone, it'll sink to your laptop, and as long as you can like log into your iCloud account,
you can get a new device and it'll it'll sink there. So there's there's obviously some wrinkles here, and we can like poke at it, of course, but it does sort of nicely solve the recovery problem if you're willing to accept that, like iCloud as 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, the site that they don't use to for you. So yeah, like I said, trade offs there, but like that was sort of the turning
point with with web off ends. Once they introduce these what they call pass keys now, which are these thinkable credentials to 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 you know, you're just scenarios are also trying to It feels like we've come full circle back to O off though, because now it's it's like iCloud is
the new O OFF. If you're using iCloud or Windows Hello is the new o off. 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 log in right now. And then if you're on a business tool like an Outlook or whatever, it's got the Microsoft log But it seems like the social login is being replaced with an operating system login that you know, once you you know, squint right and erase some of the magic, it's just oh off again. 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 for Google button and I click it and do the OT dance, or I see like a log in with passy button and I click that and then do the do the passy prompt thing. So it's very much just kind of a one click log in from a 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 o author's there's a lot of privacy concerns in the sense that like the provider you use for for oh off 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, good batter indifferent there, but like it's something that you have to be aware of with with webf in, even though your you know, your credentials might all be synced through iclouds or you're sort of a reliant on Apple that's your provider of choice. Apple
doesn't see all that activity. Like if I log in with webf in and use use my iPhone to do it on every site, I can log into every site on the Internet with that, and Apple doesn't know that I have done that. So there's a lot of big privacy wins there is that true? Yeah, Yeah, that's definitely definitely true. How Apple also wrote the OS, so if they are spying on it, there are other ways they
could do it already. Yeah, that's that's my question is because if you control the whole chain of software saying that it's into end encrypted, we don't look pinky promise, Like, yeah, I don't know if I trust that sure, Like obviously, if we're looking full stack, you know, Apple writes the browser et cetera, et cetera, like Yogile 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, yeah, right, like in the in the middle. Yeah, in the world, Like you have them in the middle, and they can see your activity by virtual of just that single like protocol O off here, Like that layer alone gives them that activity. Now Web often eliminates that, and we can talk about how if you're
interested. Of course, there's other layers in the whole stack to make work which like things could be happening, but at least at the authentication layer there's
more privacy guarantees. O. The other trend I think that's like interesting to watch here is just like how that interaction model evolves, Like 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 OA in terms of like 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 that shift it out of like you know, your typical identity provider model where there's a person. So like these things are all happening and I think it's like quite interesting. They ultimately lead to like very similar user experiences, but very different sort of like technical and architectural. 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 that you're looking at? Yeah, yeah, to some level of development effect your job too, is the other question. Yeah, So so yeah, Passport has been like a good framework to evolve here. So like the strategies have been there from the
beginning. So like you know, web then didn't obviously exists 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 web FND strategy that's that's workable today today. There's you know, there's some that web then is like in development and like lots of kind of new features happening constantly as the W
three C 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 poor requests out there for them. So that's that's a work in progress, but you can get started
on 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 it's certainly doable and something that I kind of play around with in the background. So if and when those things become become adoptable, there will be a strategy for those. There's more a question of like maturity of the technology
and things like that. 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 try to do with with Passport is make it like an open ecosystem. So like there's now I don't know, well over five hundred strategies, it might be approaching close to a thousand I kind of quick counting
at a certain point. But like lots of developers published strategies for tons of different authentic ways of doing authentication, and it's you know, permissionless in the sense of, like you know, anyone can do it and the API is there for you to do it imself. At the beginning, kind of wrote like fifty or so of the initial strategy, so you can see how it
took off off from there. But like you know, as these technologies, like 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 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. So another question that I have of passport is it's old, right. I mean,
like you said, it started in the point two days. I 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 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 five 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 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? Uh? It's it's one that's written for bon but it works and not as well at least is it at least Alisia Elisia? Okay, Elisia. You know you got Bud, you got you got Dino are are are you just staring like this is tried, it's true, it's stable. You know people that people that want that are going to have this or are you doing anything to play towards the younger crowd? Probably more on the former, like it's kind of tried as true, it's
stable. I think like you know, uh, you know, Express might be old and not cool anymore. But like I've also gotten old and not cool anymore too, so so I'm maybe okay with that. 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. The man who has in no zero point two well, fair enough, fair enough, fair enough. 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, Uh, there's a notion although it doesn't really get like talked about too much or probably leveraged all that often of like having different like frameworks that you can like plug in underneath it. So like this is more of an internal
thing, but like Passport in the way it's sort of like dispath dispatches, it's offen cation handling out to like the containing web framework if you will.
It's somewhat pluggable, so like it sort of 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 gonna be like old stuff, but like that was leveraged by Happy if people remember that, okay and so, and I think, you know, that probably doesn't get used as much anymore, but I know people have used that similar technique, like there's there's ways to use it in in next JS. I've played around with it
and Fastify too, as like an experiment. I'm not sure if it like gets widely used in that ecosystem, but this is something that's always on the back of my mind, is like, okay, like how park 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 going to really like stabilize this pattern and promote it. It just doesn't, you know,
uh, seem to have that people asking forward commanding it that much. But as I like play with things and refactor on my own, I'm 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 like it's stable and you know, I feel no need to break it if I wanted to jump to like a completely different framework and probably look at you know, doing it completely new, you know, JavaScript style and that sort of stuff like a job script world is involved in, like things like winter CG and stuff like that, I think are worth paying attention to and kind of like changing what it means to write like
portable portable packages. But I don't like, there's just a long tail and of historical packages that will probably like never make that move and I don't know what that does over time, but you know that's that's just kind of like you gotta got to know your history. I guess for some of these things.
You know. 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 Octa or zero which is owned by Octa now, And so when would you pick one and when would
you pick the other? Because I I've used both or at least both strategies, right, I've used the Warden strategy for my rails apps, and I've used Octa and sometimes it made sense and sometimes one of them caused a way too much pain and I moved to the other. And so in your estimation, yeah, when do I start thinking, Okay, am I going to get done for you? Or am I going to do it myself? Yeah?
So so good question. So I'll give some background here. So, like, so Passport started and like you know, like I said, twelve and I joined Osto, and I think like early twenty fifteen, like shortly maybe like a year after it got started. I was pretty early there. And you know, Ausara was like a big proponent of passport and promoted passport and also like passport works well with Austerero. So I view these things as like really symbiotic in a way, and I'll talk about that what that means.
But basically, like so if you look at passport, it's trying to solve the authentication problem generally, right, So there's always this notion of okay, like you can build everything yourself, right, So like if you want to build your own log informs and all that sort of stuff, like 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 gonna build my own log inform, but now you've got to you know, pass your passwords and like you know, keep your passes up to date. You've got
recovery problem statements like how do you email people? Like password reset links. You've got great limiting problem statements if you get to any scale and people just start to attack you, and there's just all these sort of problems that like 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 the stuff
around it. And so that's really like the premise of using a service like Assero or Octa, which is okay, like you know, you want to build an application, you need authentication that entails a whole bunch of stuff that
you really probably don't want to do. If you're you know, 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 assistant that way, and I think it's it's probably recommended first people who are you know, intending to launch like a widely deployed That being said, even when you choose to use a zero, for example, you still have to do
authentication problem statements in your own application, right, So one of the ways of using a zero is just like talk to a zero via open id connects. So a zero becomes like your identity server, but your application needs to speak open id connect to it in order to authenticate. So it's like, yes, Austerero is doing the authentication, but you might drop passport in via the open ID connect strategy to have your application kind of authenticate against austereo.
Similarly, like you might be building APIs and like all Stero is issuing the tokens for those APIs, but you need to authenticate them in your own application. So authentication exists on like both sides of the wire, right, So it's like you might build it all yourself and you can use passport as like
one piece and your toolkit to do it. But really you shouldn't have to build it all yourself, but you still have to do handle authentication bits in your own application, even though you've outsourced most of it so you can use them together. Well, 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, No,
this, this has been great. Your questions are awesome. Yeah. Sorry, I'm not much of a no just user errortic, I know, but so I would 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 and there's 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 and people like you that do that for me, welcome, what about you and like, what's 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 and you're facing these days? As far as I know, Well, I haven't, I haven't really looked. I've been building something incrementally uh 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 need to be. But yeah, I that that's something I've got.
I've got a little a little project that I've used in a few places over a few nations, and I have tentatively called it lib off because the idea is that it's at some point I'll have like a lib off innit and lib off a knit 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 boiler plate 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 I'm not I'm not building a
lot of 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. 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 ended up being one 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 one 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. 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 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 sso and access to own API. So it's kind of like at that point they want to be their own oothser effectively, right, which is which is a common thing that that companies do as they grow. But it's in my view, even though these things are related, that 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 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 at some layer. Right. And also,
you know you talked earlier about the SPA stuff. So this this off 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 gonna flesh this thing out and I'm gonna I'm gonna make it into a real thing. The next day is you know, major update to browsers. Uh you know, I Frames no longer support it. Yes, right, It's like, okay, so now we can't have seamless authentication anymore
because of clickjacking whatever. All right, so okay, scrap this, come back to it a couple of years later. All Right, I'm gonna I'm gonna 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 our third party cookies starting next month. And it's
like, oh, well that's not gonna work, you know. So that's kind of one of the frustrating things, is be 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, if you call window dot closed, 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 simiss experience, those bugs aren't actually getting fixed. Yeah. Yeah, and it's and it's like every couple of years there's some major change
to the way that browsers work between third parties. Yeah, I think you know that speaks to the sort of like interplay between effectively like an under client side authentication concerns and like back end server side concerns and like, uh, you know, I guess fortunately, in the case of the passport Jass, I like really focused on the back end concerns itself, right, and like kept all the client side stuff out of it. And and you know that's
been scalable and evolvable and in a relatively sustainable way. But to your point, like maybe makes the developer do more of the front end stuff that themselves, right, it's less abstracted that front end stuff it's all broken like it's all, well, yeah, any strategy that you ever would have tried to do this stuff on the front end, it's all broken over the last ten years, Like yeah, it's been for sure, for sure. 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 end. Yeah yeah, yeah, And I think I think that is probably like still 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 back end off the 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 that would be
fun to solve. 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 can be achieved and making it like DEBX friendly. So I still think there's like room room out there to like improve the front end side of things and then upgrade. Are you aware of the
portal spec portal spec? No, I have not come across this 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. And 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 Babbel story where for the rest of time and eternity you have to either use Babbel or you have to use something like like back in the website of the days, what was that one called the soup super popular web socket framework socket I own right like soccket io still implements like an I frame strategy, or they may have removed, 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 I frame where the I frame changes the UURL and the UURL bar, so a portal pops up like a modal. When you click into the portal, the URL changes in the r L 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 O off flow without a redirect. You open up a portal like opening up an I frame, but the portal takes over the r L bar, and then when the portal goes away, the r L bar goes back, so it almost looks like in all respects a redirect, except 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. 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, because I think they're already doing CSS transitions for redirects. Now, 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 with the transition,
it'll feel like a single page application on multiplage. But 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 two thousands without your clicking and tell somebody to do the clickjacking, and then we'll lose it again. Yeah, yeah, that sounds promising.
I mean, that state management problem is like one of the things that has always like hung up, like oh off adoption and you know, like spots in particular, it's like you redirect and you lose all your state that's that's sitting there in the browser, and then you've got to like reconstitute that on the redirect back and it never works, right, 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. Yeah yeah, 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 you know, follow what anything else you're doing. Where do people find you online? Yeah, so Jared Hansen is my handle pretty much upper on Twitter, slash x get hub. You can go to passport jass dot org and and everything will be linked from there. So yeah, check it out. Shoot me questions. Awesome, All right, Well let's do some picks,
Steve. You want to start some picks. 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. 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 a hacker news, Dylan Field, who's the CEO of Figma, put out a blog post and basically they
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 twenty billion dollar merger. Oh wow, it was pretty huge, and a lot of I remember hearing a lot of designers saying, all right, Adobe's going to screw up Pigma. Now I'm getting out of Pigma. 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 Pigma, 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 terriers 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. They're 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 digital displays. You know, for me myself, my vehicle has some stuff on 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 frustrating that try to adjust the temperature and have to like deal with a flip and touch screen when you're driving, it's like just a flip and knob, Like come on, well a knob or even mine has a couple up and down buttons that
you can push pretty easily as well. So yeah, it's 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 me so interesting, and then experience that on my We got a new 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 and probably breaking the UI itself because you're pushing so hard. Right, yeah, right, Okay, time for the jet jokes of the day, and those of you dad joke officionados will be happy to hear that I have my rim shot back, so that will he be practicing for these Oh yes, Jared, you can either laugh or grown all. All responses are welcome. Sort of a simple one today, What did the sushi say to the bee?
What Sabby? Right? So, for those of you who may be a fan of the Budweiser was up commercials from twenty years ago, there's a great one about with Sabby. Just google Budweiser with Sabby and you'll see it. So recently, for my son's birthday, I got him a sort of a simple gift. I got him an alarm clock, but it swears at him instead of beeping, so he's in for a rude of waiting, right.
And then finally, you know, I've talked about 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 posing like a mannequin in a clothing store window. I held that position for a long time. Thank you. Those are my picks, all right. We did
have some silent chuckles just for the listener only, audience. Yes, even even Jared was, you know, having having a mondel on one of those. Yeah, 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 recently there's this old application that I'm working on, and uh it, 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 to 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 my sequel schema TS and postgress 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 hot
fix. Uh So it'll read the actual state of the database and output typescript interfaces. And then there's another package TS to js dot which will translate from those whichever tables or if you 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 it the latest version might work if you use it with typescript, or maybe the latest version would work a user with JavaScript, but we're pinned to the version that we're pinned to. But anyway, so those two tools have helped me and help 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 o RM. Instead, you know this is the type that's being returned earned And so those those two tools have been really helpful for me. And if you're interested in either starting new projects using JavaScript with types, or you are trying to migrate a project to incrementally add type checking. I did a presentation on this. It's up at jswithtypes dot com.
And there's a little NPM module that you can run NPM and NIT 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 JavaScript, it's it's deceptively not easy. 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 but 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, or or if your project is set up in a particularly weird way, it'll you know, you can at least open up the convict file and hopefully see you need to change your lib directory name
or whatever. So and I've been a huge fan. I hope this has come across on the shot. I'm a huge fan of JavaScript types, huge fan. I wish there were simpler ways to do it. I wish there were better tools for it, but I love JavaScript's native type system. I think it's amazing. 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. The rule double equals is not even an exception, it's not an acceptable option. We can use script strict strong typing and JavaScript. And after all, I mean, even if you're using a language like C, I would say that C is very weekly typed. The types are in the tooling. If you have bad tooling, you have
bad types. If you have good tooling, you have good types. And the TSC, the Typescript Checker, is certainly acceptable and will help you have a better experience with jobs. Other picks a little a little quicker, hopefully. But 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 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 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 set 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 wonder they about the size of if you go back, because 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 USBC, which when I did the swamp 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 were sixty five bucks like and 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 USBC, because most people could probably just plug them in with the three point five millimeter cable and be fine. But because I'm plugging them in with USBC, I lose a volume control. So I have to use the look back 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 MACA West, I don't know. But the speakers themselves, they have the Bluetooth option, the USPC option, and the three point five millimeter option, and they just they sound so much better than I would have expected at sixty five dollars. So Creative has done it again. I just huge shout out to them for again it's the Creative t sixties. And then, Okay, I'll be fast on these ones. I promise, I think, no, I promise. I
talked about the Hammerhead metal shower head a few weeks back. Our other shower head and our other bathroom broke, so I bought another one. So I brought it back to my remembers. 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 shower headholders 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 shower head will will save you and you'll never have
to buy another shower head holder again. And then my wife, 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 one hundred 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, you know how warm you want it, so I can turn my side off, I can 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 uh yeah, and it's it's got good ratings, and I look 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 I'll give a link to that. So those are my picks. All right, I'm gonna jump in.
I'm gonna be really really brief. I always do a game pick. The one that I've been playing lately I've picked up before is Risk Legacy or game geek weight of two point five to nine, 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 going to be doing things a few things different. One of them is is we're going to tweet out before we go live every week, so keep an eye on that. You can follow us as a JS jabber on Twitter, you can find a Facebook page. The YouTube channel is top Endevs and 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, it 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 web often and it's like, I want to learn more about webth end. Is there a web off end guy you know? And it turns out yeah, I probably do. So we'll get that lined up and I'm going to 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, kind of like what rails casts used to do for Rails, except it's going to be JavaScript focused. I'm also doing the React series, and then we're going to 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 going to have an expert one week we'll do a Q and 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 meet up 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 you 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. What are your picks? A 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 Wi Fi networking gear. It's a pretty nice equipment that I've enjoyed. Nice. I've heard that recommended rather ubiquitously whenever I look for networking gear. Yep, highly recommended, slick, works well, easy to configure. Nice. All right, Well, thanks for coming Jared, This was fun. Thanks for having
It's always interesting to dive into this stuff too. Well, we'll wrap it up here till next time, folks. Max out