djrenren

If it’s a simple change, they might accept a PR. If it isn’t, well that’s your answer. Not worth allocating engineers for it.

All non-enterprise big tech uses of passkeys (Google, Apple & Microsoft Accounts), do not require an attestation statement (or in spec-parlance, use the `None` or `Self` Attestation Types).

The presence of other attestation types in the spec allows passkeys to replace the use of other classes of authentication that already exist (e.g. smartcard). For example, it's very reasonable for a company to want to ensure that all their employees are using hardware Yubikeys for authentication. Furthermore, sharing the bulk of implementation with the basic case is a huge win. Codepaths are better tested, the UIs are better supported on client computers, etc.

The presence of attestations in the spec, does not impinge on user freedom in any meaningful way.

CBOR isn't a hobby spec. It's integral to the WebAuthn API spec. Every time someone uses a passkey, CBOR is used to exchange messages with the authenticator

Well, this is only sort of true. When you’re writing HTML you’re restricted to attributes but custom elements are JavaScript objects and are free to respond to property updates on the object. Relying solely on strings is a limitation of your templating engine.

For example lit-html templates support syntax like:

<my-element .someProp=${new Foo()}></my-element>

You can absolutely follow a discipline like this which recreates this separation in a framework that lacks it

Please remember that Web Components are much more akin to an ABI for web projects and not a full-featured framework.

Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use.

If you attempt to build a web app using just web components and no libraries, you'll quickly find that you're doing lots of manual DOM updates (no templating engine) and lots of manual state management (no data management API).

As an ABI, it's wildly successful. It does, in fact, just work. It's just very low level.

> They are not even in the same arena as React.

This is 100% correct. I think a lot of the disappointment about web components comes from a mismatch in expectation between the spec writers and what people when they think "components".

Web Components allow you to make new HTML elements. That is, you can make new kinds of DOM nodes out of other DOM nodes. This is powerful, but the resultant API is still a DOM-level API, and not a full templating system like React.

On the other hand, because all these templating systems (React, lit, svelte, etc.) ultimately boil down to a series of DOM manipulations, this allows you to create a kind of element that can be plugged into all of these systems.

Custom elements are a lot more akin to the C ABI. Than a fully featured framework.

As someone who just had to answer this for my startup, the value of React is that it's robust and immensely hire-able. If you're looking for frontend developers, the one thing you can always expect is at least passable React knowledge.

Everything else, even if it has a better technical fit for your project, is likely riskier for your organization.

> You don't need those in React either.

I mean... sometimes you do, that's why they exist. But yeah, most of the time you don't.

> Whatever you do in Web Components can probably (most likely) be done in React.

Of course! React is a good and powerful framework. But everything you do in React can be done in Angular 1.0 or even backbone.js. As always with frameworks it's about the productivity / performance ratio for your team (or for libraries, the ratio for your consumers).

> After all, Web Components are a solidified 2010-era design.

A lot of the web components related APIs are being actively developed including constructable stylesheets, shadow DOM APIs and more. Regardless, the era of design is not a great point in either the "pro" or "con" column, and is usually an ambiguous shorthand for the actual quality being critiqued.

Forgot to mention, the knock-on effect of this thought process is that if you want to adopt web components, you still need a templating approach. And you'll find that most of your code is templates, and only a few are really components.

I've found webcomponents to be really good at encapsulating anything that doesn't directly query application state.

Specifically there are two type of components that really thrive as web components (as opposed to react):

1. Highly interactive components - Components that implement complex interaction management (but sort of agnostic to application state) are ideal web components. You don't need to mess around with `useEffect` or `useMemo`. You get really tight control of rendering and state updates.

2. Highly internally stateful components - Components that track a lot of state that doesn't escape the component, work great as web component. You get strong encapsulation without a framework requirement.

React conflates two concepts that I think are better when separated: templates, and components. Templates provide a "re-render the world" approach, and components encapsulate state and interaction patterns. Conflating these two things causes the standard useEffect and useMemo headaches. It also means that any consumer of your component, must also use your templating system (react's render function).

The `lit` library does this separation extremely well, allowing you to implement components using templates if you want, or not. And consumers do not care how the internals are implemented.

Really cool to see these issues are on the roadmap.

I remain skeptical on timeline for these but if the plans speed up dev time work out, then this is great news.