davidkhess

I think that's coming regardless. AI just might be the perfect storm to bring the timeline in considerably.

One way it works is if you think of cognitive debt as the "house". As in "the house always wins".

Should probably mention that Guido ended up on the team working on a pretty credible JIT effort. Though Microsoft subsequently threw a wrench in it with layoffs. Not sure the status now.

Last time I looked at SQRL, it had an unfixable man-in-the-middle problem.

Though, general acceptance of QR Codes does seem to have finally taken off.

Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.

Normal usage would require a reauthentication - i.e. FaceId or TouchId - to produce the passkey.

I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security.

One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account.

It's going to be interesting to see how those alternatives play out in real world situations.

Ditto. I started out on Twisted back in the day and stayed with it for 6 years all they way up until they introduced deferreds combined with yield/generators (the same technique which is the heart of today's asyncio).

It was great at the time but ultimately tiresome. It introduced framework specific incantations all over the place and any framework using I/O had to be Twisted-aware in order to use it straight-forwardly. The exact same complaints I have today of asycnio.

I went to gevent 10 years ago and have never regretted it. If you have some reasonable knowledge of threading and synchronization then it is a really nice developer experience.

You are jumping to mistaken conclusions based on one review, the motivations of which you don't know.

I think cross-platform apps are commonly misapplied and really only make economic sense with the appropriate assumptions. Once a company has the necessary resources they should go native and go all in on platform conformity.

But for many folks, that's not a feasible place to start from.

I find Qt/QML for cross-platform mobile applications to be a great solution. It uses the same basic architecture as Flutter – they both do not use native widgets and instead draw the entire UI on a blank graphics canvas. I think that approach preserves the most code between platforms and reduces the kinds of presentation hitches that HTML web view and hybrid native widget approaches can run into.

In relation to the particular problems of technical debt related to third party modules mentioned in this article, QML rides on top of Qt which is a 26 year old C++ cross-platform toolkit with a lot of mature technology in it. I.e. there is a lot more "batteries included".

There are still plenty of times you have to "go native" to integrate something Qt doesn't cover but it apparently isn't as often as with Flutter.

Not retired though - currently at Microsoft.