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