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:
Sure, but instead of waiting another year for this to be launched - with a beta version precaution and inevitable bugs - why not remove the limited hard-coded Node paths and references now and ship something 80:20?
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
Because given the same input data structure every correct implementation generates exactly the same byte sequence, so it's useful for signing. This isn't true of many other data formats, including JSON and protocol buffers.
Thanks for pointing this out. I should probably mention this approach in my article for cases when you need to work with slotted elements but don't want to inherit all page styles.
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.
That is why we have a library to make it easier to work with these low level functions: Lit. And because Lit uses these functions, it can be a lot more lightweight compared to React & Angular etc.
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.
Some of the most productive teams I've worked with (not as a dev) have been for tech stacks I personally don't enjoy using. Java, .NET/C#, React, etc. In practice, I'd rather quickly hire a local senior Java/C# dev for 1X than scour the interwebs to hire a Golang dev that requires relocation for 1.5-2X.
If I was going to learn a language though, I'd probably learn Golang. Their rate is so much higher.
I find this argument so absurd. If you know JavaScript and basic programming, you can use any front-end framework.
We're hyper-specializing people in a specific framework that then don't even understand the basics of JavaScript itself.
I already find the divide between frontend and backend developers unnecessary the majority of the time. This takes it a step further and in turn creates monstrosities like the leftpad debacle.
Can we stop with this nonsense? Hire good developers and let them spend 5 minutes to learn the god damn framework of the week. If your hire can't learn React in a week, I have some bad news for you.
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.
I completely agree. Recently I listened to a podcast where Brad Frost talked about web components being useful for design systems, as you can make a button in a web component and have that defined no matter what JS framework the dev team (or teams) want to use company-wide.
One issue I see though and I almost feel dumb for saying it, I don't like how web component code looks. Using innerHTML feels really weird when your team is so used to using JSX for react components for example. I don't think this would stop me from researching web components more but does anyone feel similarly or have a solution or obvious answer for me in this area?
You don't have to use innerHtml. The ShadowRoot pretty much acts like a document. So you can also use appendChild. Combined with a template element you can completely avoid innheHtml. You could even use jsx to create the template element I suppose.
> You don't need to mess around with `useEffect` or `useMemo`. You get really tight control of rendering and state updates.
You don't need those in React either. Whatever you do in Web Components can probably (most likely) be done in React.
After all, Web Components are a solidified 2010-era design. The reason React has hooks now because people have moved on, and are exploring other ways of building stuff. The only mistake React did was to keep reactivity on component level (hence all the hooks and their weird rules) when most people moved on to more granular reactivity. Hell, even Angular did.
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.
> I mean... sometimes you do, that's why they exist.
They exist because they're useful, but you can write traditional React components that look a lot closer to Web Components, if you think that's better.
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 find that they can work very well with state but since state is typically passed via attributes (downstream), it means that components can only share state with each other via strings. I found this to be an advantage, not a drawback because simple interfaces are at the core of my coding philosophy and strings make it infeasible to pass complex instances or functions to other components.
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:
Interesting. I recognize that lit-html is much more lightweight than React and others but personally I really like to avoid any magic at all and I like being forced to pass strings between components. It reminds me of an Alan Kay quote about OOP "The big idea is messaging". You want your components to be passing around messages, not state. This seems to go against FP philosophy but I've found that it really works for OOP. After all, OOP is traditionally about state encapsulation and prioritizing concern boundaries over logic/state boundaries as in FP.
Note that it's still possible to pass complex objects to native we components but only imperatively via properties so it's a lot higher friction (as it should be).
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.
The first two points will be addressed in the next major release with typed catchers. The latest release notes[1] call this out, and in fact reference the same Github issue.
Additionally, it looks like they're even addressing one of the most common criticisms - having to declare requirements/guards on every handler. See "Associated Resources".
But honestly, “middleware”? That was already taken years ago, long before the web took off. In fact, it was first used before the web was even invented!
https://github.com/microsoft/typescript-go