The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here:
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:
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.
Web Components are really just the minimal APIs required to allow the implementation of new HTML elements. This includes things like:
- Responding to being attached to the DOM
- Encapsulating DOM nodes (the Shadow DOM)
- Scoped styling (Shadow DOM + User defined stylesheets + CSS parts)
It is definitively not a templating engine. It doesn't provide any new APIs for creating DOM nodes, or mutating them a la React or handlebars or lit-html. Templating is basically the "next step up the stack". Using shadowDom.innerHTML = `...`; is basically a stand-in for having an actual templating engine.
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.
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.
After using Rocket in production for a year now. I'd really recommend Actix Web. Don't get me wrong, Rocket has some really nice features and good UI, but a couple things have proved to be real pain points:
- Middleware ("fairings" in rocket parlance) can't respond to requests. This means your access control has to be replicated on every route as a guard.
- Guards can result in errors (for example, if the request doesn't have a valid Auhorization header), but you can't set the response body without a nasty workaround that causes other issues [1]
- Guards also have tricky performance gotchas. When multiple handlers match the same route, rocket will try them all in priority order. Often these variants have the same or similar sets of guards, but guards don't cache by default. Doing your own caching gets tricky especially in the presence of workaround [1].
All this to say, Rocket works well, but it has some unique problems that come from its early design decisions (e.g. the guard error messages which has an open issue) and some from ongoing decisions (i.e. the project seems to committed to the fairing model over standard middleware).
Many of these problems are fixable by community members like you, but actix avoids several of these and has a larger developer base. I've heard good things about axum and the docs look great but I haven't had much experience so I can't offer a strong recommendation.