> But I would dread having to try and recover a Passkey with Google, who would I even talk to?
That's not what this blog post is about. This blog post is not about using a passkey to login to your email.
This blog post is about using a passkey to login to a website (404 Media) that currently supports login via "magic links," i.e. instead of passwords, they always send you a "forgot my password" link, which you click on in your email.
If you currently login to 404 Media with a magic link, and then decide to login to 404 Media via passkey, and you lose your passkey, you can just get a new magic link sent you via email and reset your passkey, or, if you want, you could just skip the passkeys and go back to always using magic links.
Using passkeys to login to your email itself is a whole different ball of wax. Gmail does not have a simple "forgot my password" email that it sends. (That would be pointless if Gmail is your only email address!)
The "forgot my password" flow for Google/Gmail can involve a bunch of factors, including backup email addresses, backup recovery codes, recovery contacts, SMS, push notification to other apps you've logged into. Google doesn't document all of the factors they consider, and neither do any of the other major email providers.
I get it: it would be scary to login to Google via passkey if Google is your passkey manager, especially because there's no way to export a passkey from one passkey manager to another. Can you trust Google's recovery system?
That's a hard problem for Google, but it's a trivial problem for 404 Media. They just send you a magic link, and rely on Google to keep your email secure.
And, let's face it, most of us run sites that are much more like 404 Media than they are like Google.
> I’m going to assume that you know what passkeys are and that you’ve used them with your Google, PayPal, or TikTok account, or some other online account.
That's the biggest mistake that passkey advocates make: assuming that if you've used passkeys, you know what passkeys are. Or that you can watch a short video explanation describing the benefits of passkeys, and then you "know what a passkey is."
Here's what a passkey is:
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
Passkeys can be public/private keypairs, or they can just be secret passwords. Webauthn is designed by committee, so there's always more than one way to do it.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If your site/app is comfortable with magic links, or a simple "forgot my password" email, then it would also make sense to let users add a passkey by clicking a link in an email.
If your site/app doesn't have a "forgot my password" flow, you don't need one for passkeys, either. (But, surely you have something in place…? Even Yubikeys/SSH/PGP private keys can be lost.)
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that lock in, and there's something good and bad about it.
Instead, password managers recommend that sites/apps allow each user to have multiple passkeys. Sites/apps may or may not actually allow that, but that's the only way to be sure a given user can login with both Google's password manager and Apple's password manager: give each password manager its own passkey for each site.
I think Ricky is completely right in this case that if you're a site like 404 Media using magic links today, passkeys are just better. As a user, if your passkey doesn't work or gets lost, you can just click "forgot my passkey" and get another magic link, and set up a new passkey.
Thanks for the write up, that's a really nice way to explain passkeys, better than most of the guides found online. It’s tough to convey just how big a leap passkeys can be to folks in the tech bubble, because they’re often disconnected from the everyday password headaches most people deal with.
For example, I was helping my mom pay a bill online the other day, and it turned into a circus of scribbled passwords in a notebook, adding minor tweaks to a common master password, having to rely on "forgot my password" emails just to also need to confirm via sms codes, too bad if you can’t access your phone. It was wild. Introducing passkeys into her workflow would totally remove these frictions.
Of course the way password managers are being treated like a new walled garden is not the best but this cannot be used to discredit what really looks like a valid solution to the problem of having to remember too many credentials.
Social media apps need users, and they need users to return and re-engage. The data is clear that even very basic algorithmic feeds get better engagement, presumably by showing users better stuff than whatever happens to be newest.
You can't possibly do anything to "put an end to this."
Twitter and Bluesky both allow you to see a chronological feed, though you have to jump through some hoops to get to it. Just use that.
> Social media apps need users, and they need users to return and re-engage.
And this is where the goals of the platforms and their users are at odds with each other.
> Just use that.
The problem is that while I can "just use that", which of course I do, the mere presence of an algorithmic timeline, let alone as the default option, still substantially shapes the way people post and share.
People post differently when they expect interactions from outside of their usual network vs when they don't. I had my tweets get uncomfortably popular on several occasions, presumably because the algorithm decided so, and I didn't enjoy that.
Then there's also the problem that some people you follow will use the algorithmic feed and will repost things from there. Again, this wouldn't happen if it didn't exist, and it's not something I can influence with my choices.
What I want is for content to spread organically again. I want the platform to be a dumb pipe between me and the people I follow. I don't want it to have any agency whatsoever. And I don't want "influencers" to be possible.
So, as long as someone can do algorithmic feeds, someone will, and people will use it, even you, because algorithmic feeds are just better than chronological feeds.
> I don't want "influencers" to be possible.
This one is truly hopeless. We've had influencers at least as long as we've had the written word.
> Showing people what they like is the best way to get them to come back.
There are different usage scenarios of social media. You seem to imply that people use it for entertainment, and yes, the companies themselves sure make them optimized for that. But I want to use social media for staying up to date on my friends' lives and nothing else. Most existing platforms actively resist this use case because it doesn't grow metrics.
> I guess your only hope would be to make it illegal, worldwide, to provide algorithmic feeds.
Well, at least I'm working on two fediverse projects. There are no algorithms on the fediverse. You see posts from the people you follow, in the order in which they were posted, and nothing else.
> We've had influencers at least as long as we've had the written word.
That's different. Those "influencers" always became such organically, because people voluntarily spread their "content". This is vastly different from the platform itself stepping in and non-consensually shoving this content into millions of faces because its black-box algorithm said so.
Twitter’s (X) “following” feed is not a purely chronological feed. I will often see tweets from people I follow on “For You” that don’t show up in the other feed.
It also tries really hard to direct you over to the For You feed silently at any chance it can get.
Also among followers it will surface tweets that it thinks will drive engagement and show/not show retweets based on algorithm.
Meth producers need users, and they need users to return and re-engage. The data is clear that even a small amount of meth introduced into a community generates higher return on investment, presumably by giving its users a high that's better than not being high.
You can't possibly do anything to "put an end to this".
"Holding kids back" is not the reason EdTech fails at scale.
The problem is that people who succeed in tech are able to effectively educate themselves, alone, without a dedicated human teacher supervising them or a group of student peers. (You need this skill to succeed in tech, learning new APIs/languages from written materials and online videos.)
The techies who build/fund EdTech wrongly assume that everyone could do this if only they had access to the learning materials, or if the tech vaguely simulated a teacher (an interactive textbook).
But for most students, fitting in with peers and earning the respect of their teacher is the only reason they're bothering to learn at all.
(For kids especially, adult career prospects feel so remote that it scarcely seems worth the trouble, whereas earning respect right now is a very, very concrete problem!)
Banding kids into grades is the only thing making most kids succeed. I guess that is a "crying shame," but it's a tragedy, not a policy failure.
> everyone could do this if only they had access to the learning materials, or if the tech vaguely simulated a teacher
Everyone could do it if they were taught to teach themselves, it's funny we've almost come full circle back to the original intention of public education and universities.
I believe (almost) everyone can teach themselves something provided they have the material to learn from (videos, books, teachers, etc.).
This is because if people can't truly be taught to teach themselves there's no larger point in schooling unless you have only exceptional teachers throughout. Mediocre and bad teachers, which are far more common, make it so students end up having to teach parts of the material to themselves (which unfortunately leads to a tonne of rote memorisation) - this to me is where the true benefit of public education and standardised testing is, not the information retained.
The point of school was never fill our heads with facts we will never use in the workforce - most blue collar work is learnt on the job (or can be taught in short time), and white collar work is (generally*) done by those who learnt to teach themselves (as proved by them earning something like a college degree in spite of the bad and mediocre teachers).
* I say generally because there are white collar jobs that don't require it. And there are rote-memorisers who have such good memory they can make it into these positions, generally though upon hitting the workforce they stagnate, leave, or learn to learn (ever had an incompetent middle manager who only knew how to follow procedure?)
You're absolutely right, even in this thread there's a ton of "I was able to teach myself, so clearly everyone would be geniuses if only the system didn't hold them back" posts. It's the same thing that led to a lot of the problems with the OLPC project (check out the book "The Charisma Machine" if you're interested in that subject).
> The problem is that people who succeed in tech are able to effectively educate themselves
Not by magic, though. Those who take an interest in tech are forced to learn how to educate themselves in order to fulfill their interest in tech. The same story applies to many other interests. Of course, it is possible one will never develop any interests...
> But for most students, fitting in with peers and earning the respect of their teacher is the only reason they're bothering to learn at all.
But is socialization the only thing most children can take an interest in, or does sticking children in these rigid school environments take away from them discovering other interests? In other words, is this just a symptom of them being in the wrong environment, rather than the nature if it?
Furthermore, if socialization really is the only interest, why can't it still be used to force learning how to educate oneself? If fitting in and admiration are a compelling reason to learn in general, why would it not be equally compelling towards learning how to learn?
> Banding kids into grades is the only thing making most kids succeed.
Of course, that questions if most kids should succeed. What for? Being from the most educated region in the most educated nation, it's not clear what we actually get for it. The popular tropes don't hold up. Other parts of the world are much more progressive, economically vibrant, healthier, etc. It is hardly the worst place in the world, but a relative backwater compared to other much less educated places.
You don't have to go back many generations to find populations not exposed to much, if any, formal education and they don't seem to have ended up any worse off than the average person today. I expect there is a strong case to be made that people with a vision can leverage educational resources as a force multiplier to propel themselves well beyond what those earlier generations could have ever dreamed of been capable of, but for the average Joe just trying to fit in...? Perhaps we are missing the forest for the trees.
I think it should be Option 2, "Automatically reset the content when anything in the selected <option> changes."
But furthermore, I think it should be possible to turn <selectedoption> mirroring entirely off, e.g. with an attribute like <selectedoption mirroring="none">, and I think most developers using reactive frameworks should prefer to do that.
If I'm using any reactive framework designed to do targeted DOM updates, I want my framework to be in complete control. When an option is selected, I'll populate <selectedoption> myself. When an <option> is modified, I modified it, and I know which <option> is selected, so I'll perform a targeted DOM update of <selectedoption> as well.
You had a whole separate podcast episode about how/why having the browser itself do targeted DOM updates is an enormous can of worms, mostly for attribute vs. property reasons. https://offthemainthread.tech/episode/putting-react-in-the-b... And anyway, every framework wants to handle mutations differently, and framework designers are in consensus that we haven't picked a clear winner yet. So, as nice as it would be if we had a replaceHTML API that everybody loved, we don't have that now, and we shouldn't hold up customizable <select> for this.
<selectedoption> mirroring is for folks who don't want to use any JavaScript (and I think that's a good thing). In that case, mirroring all updates automatically, synchronously, is the simplest thing that can possibly work.
Developers who want optimal performance want full control, and they just want to turn mirroring entirely off.
Thanks for the feedback! Fwiw, there's no point populating <selectedoption> yourself. Just don't use <selectedoption>. It's optional. That's probably what I'd do in most cases where I'm using a framework.
And another. When I add <selectedoption>, I get a warning in the console, "A descendant of a <select> does not follow the content model. <selectedoption> one </selectedoption> "
Those sound like bugs but I'm not really familiar with the implementation. I haven't played with it much either. I'm just an outsider interested in the feature design.
An attractive future direction might be to re-implement Htmx in React:
• The server sends a JSON blob that React converts into virtual DOM components.
• That would solve the component state problem.
• It would mean we require no special bridge to use React
components.
• It would let us use our React-connected web fetching library, and carefully avoid the queuing choices made by Htmx.
• It would solve the morphdom problems and browser DOM input elements problem, too, which is pretty much a solved problem in React.
In this way, we could drop the Htmx dependency but retain the benefits of the idea. That is, given a budget to embark on such a big piece of work.
RSC is still experimental, and the default implementation assumes that you're going to run JS on the server, which undermines some of the point of HTMX.
But someday (likely in the next year or so) the RSC wire format will be standardized, and then any language can generate RSC JSON for React to consume.
But client-side includes are inherently slower on first load than server-side includes, because they require an additional round trip to fetch the partial content.
That performance hit is particularly painful for the header. You either have to show a flash of content without the header, causing the page to jump around when the header loads in, or slow down the entire page while you wait for the second round-trip request.
"But what about subsequent page loads, where the header is in the browser's cache?" That's fine, but the savings are pretty minimal. Headers and footers are typically not a lot of bytes on the wire, so there's not a huge savings.
If all you want is the developer experience of writing HTML "by hand" without copying and pasting your header, server-side includes are a battle-tested solution.
A lot of people have asked this question. There are a bunch of simple GUI-builder tools, including GUI builders for the web, but none of them are popular, due to the sweet spot of supply and demand that Hypercard hit.
When Hypercard launched, it came with every Mac, it was free, and there was nothing else like it available on the Mac. On the Mac, the alternative to Hypercard was to layout UI widgets in code, with no GUI builder at all, or eventually to pay $$$ for a professional-grade IDE like CodeWarrior. As an entry-level user with no budget, if you wanted a GUI builder for the Mac, you got Hypercard, or nothing. This created a community of Hypercard enthusiasts.
Furthermore, when Hypercard launched, Macs had a standard screen resolution. Every Mac sold had a screen resolution of 512x342 pixels, so you could know for sure how your cards would look on any Mac. Supporting resizable GUIs is one of the hardest things to do in any GUI builder. (How should the buttons layout when the screen gets very small, like a phone? Or very wide, like a 16:9 monitor?) Today, Xcode uses a sophisticated constraint solver / theorem prover to allow developers to build resizable UIs in a GUI; it works pretty well, I think, but it's never going to be as easy to learn as "drag the button onto the screen and it's going to look exactly like that everywhere."
The last issue is the real killer for modern Hypercard wannabes: it's a small step from a web GUI builder to raw HTML/CSS. You don't have to pay big bucks to have access to professional-grade HTML, CSS, and JavaScript. Sure, they're not that easy to learn, but you can teach a kid to write interactive web pages, no problem.
As a result, the demand for a simple GUI builder is lower than it was for Hypercard, and even when you do capture a user, they tend to outgrow your product, and there are a zillion competitors, so none of them can build a community with real traction.
> Http pipelining should make it fast to load them from your server with the rest
That's true, but it should be emphasized that it's only fast if you bundle your dependencies, too.
Browsers and web developers haven't been able to find a way to eliminate a ~1ms/request penalty for each JS file, even if the files are coming out of the local cache.
If you're making five requests, that's fine, but if you're making even 100 requests for 10 dependencies and their dependencies, there's a 100ms incentive to do at least a bundle that concatenates your JS.
And once you've added a bundle step, you're a few minutes away from adding a bundler that minifies, which often saves 30% or more, which is usually way more than you probably saved from just concatenating.
> The only advantage to using one of those cdn-hosted versions is that it might help with browser caching
And that is not true. Browsers have separate caches for separate sites for privacy reasons. (Before that, sites could track you from site to site by seeing how long it took to load certain files from your cache, even if you'd disabled cookies and other tracking.)
That's not what this blog post is about. This blog post is not about using a passkey to login to your email.
This blog post is about using a passkey to login to a website (404 Media) that currently supports login via "magic links," i.e. instead of passwords, they always send you a "forgot my password" link, which you click on in your email.
If you currently login to 404 Media with a magic link, and then decide to login to 404 Media via passkey, and you lose your passkey, you can just get a new magic link sent you via email and reset your passkey, or, if you want, you could just skip the passkeys and go back to always using magic links.
Using passkeys to login to your email itself is a whole different ball of wax. Gmail does not have a simple "forgot my password" email that it sends. (That would be pointless if Gmail is your only email address!)
The "forgot my password" flow for Google/Gmail can involve a bunch of factors, including backup email addresses, backup recovery codes, recovery contacts, SMS, push notification to other apps you've logged into. Google doesn't document all of the factors they consider, and neither do any of the other major email providers.
I get it: it would be scary to login to Google via passkey if Google is your passkey manager, especially because there's no way to export a passkey from one passkey manager to another. Can you trust Google's recovery system?
That's a hard problem for Google, but it's a trivial problem for 404 Media. They just send you a magic link, and rely on Google to keep your email secure.
And, let's face it, most of us run sites that are much more like 404 Media than they are like Google.