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.

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:

https://github.com/microsoft/typescript-go

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

This is a great approach for components that want to inherit all styling from their context.

In cases where you want to introduce just a little styling, the CSS Parts API is really cool: https://developer.mozilla.org/en-US/docs/Web/CSS/::part

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.

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.

There is work going on, developing a native templating system in the browser which may interest you. It's called the DOM Parts proposal and you can find info on it here: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

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.

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.

[1] https://github.com/rwf2/Rocket/issues/749#issuecomment-91629...

Dependencies in package.json are essentially just links to the npm CDN. (admittedly with a constraint solver in front that determines the exact link to use).

`npm install` is equivalent to `https://deno.land/manual@v1.31.1/tools/vendor` in that they both fetch your dependencies and store them locally, so your app can run without downloading the deps.

The just-in-time builds section of the linked article describes an approach where you dynamically bundle, at request time. If your server already has all the deps vendored then it won't need to fetch them at runtime and your app will stay up even if the URLs go down.

One of the authors of FaCT here. This is a great question, because at first blush it feels like it might. movfuscator creates a branch-less program. But my guess is that we’ll run into two key problems:

1. Leakage via cache. If our memory access patterns are influenced by secret data, then we can detect variance in execution time as a result of cache hits/misses. Movfuscator generates code that does lots of loads and stores using application data as addresses so my guess is that even if your source program didn’t depend on secrets in this way, the output code probably still would.

2. Termination rules. Movfuscator programs run inside a giant loop. Every execution of that loop drives execution forward, and every instruction is executed on every loop. Even if the body of this loop is constant-time (see above for why it’s probably not), we need to consider how the program actually terminates. For example if I write the following C code:

    for (int i = 0; password[i] != 0 && entry[i] != 0; i++) {
      if (password[i] != entry[i]) return false;
    }
    return true;

Hey, one of the paper authors here, this has been a serious problem in the past (and present), but is definitely improving. For example, intel’s docs state that cmove is constant-time on recent hardware. ARM’s DIT (data-independent timing) [1] extension provides hardware-level guarantees and intel has extensive docs on how to use their chips for constant-time coding [2]

[1] https://developer.arm.com/documentation/ddi0601/2020-12/AArc...

[2] https://www.intel.com/content/www/us/en/developer/articles/t...

Hey, one of the paper authors here. If the compiler stopped here, yes this would be an error, but subsequent transformations (described in section 4.2) eliminate the branch ensuring that timing is equivalent regardless of the value of notRet.

Hey just a heads up, on the web (or at least in CSS) px is resolution independent. It represents 1/96th of an inch [1].

The web has physical, font-relative, and viewport-relative lengths which all serve slightly different purposes. Like you, I find font-relative to be super useful much of the time, but the others have their place as well. I just want to point out that CSS specifically doesn't have a resolution-dependent measurement.

Using pixel (1/96 in) sizes for a font is fine if you care about the physical size of the font being displayed. Starting from the system default font-size as you suggest will also work, but you'll need to test it on all the platforms (especially if you use a custom font).

[1] https://www.w3.org/TR/css-values-4/#absolute-lengths

I dont think Rust traps on overflow in release builds

This seems like an odd choice... do you know the rationale? (or have a link to an issue/RFC I could go read)

Don't forget that if it works over http(s), it's a lot easier to build a web interface for, and that's a big win for ease of use!

Looks like the current code doesn't support it.

https://github.com/wasmerio/python-ext-wasm/blob/master/src/...

but in theory it shouldn't be too hard™

Hey one of the authors here! Crazy that someone else posted this, I'm happy to answer any questions.

I also just gave a talk about this at POPL2019 in Lisbon. Slides are here: https://docs.google.com/presentation/d/1yuC_LvNuFbnhO3aASTQ8...

I don't believe this would work with the rustc compiler because, although it uses Cargo to build, it has a special process that bootstraps the compiler by building itself.

Yeah, doc tests are part of rustdoc and they essentially strip out the comments and generate test functions using libtest. I'm not very familiar with the internals, but they're here: https://github.com/rust-lang/rust/blob/master/src/librustdoc...

You can do the same on rustc by just doing --keep-stage 0. This doesn't work with with codegen-like stuff but for a lot of changes it works.

Hi author here, I won't lie, it's rough. I definitely built this whole website and wrote the blog during my "compile breaks". On the bright side, typechecking is super fast so I only really have to wait when making algorithmic changes. Still, especially for anything that does code generation, you'll be tweaking the algorithm a good deal.