workerd VS webusb

WorkerD isn't anywhere near a "cutdown version of Chromium," it is an incredible platform with years of engineering put into it, from some of the people behind very similar and successful products (GAE, Protocol Buffers, to name some).

WorkerD is open source: https://github.com/cloudflare/workerd

I personally am not a fan of Deno because of how it split the Node JS ecosystem, so that is not a benefit in my eyes. Of course, Workers can run Rust.

Nothing you said here necessitates an API difference.

You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.

I've hit a bunch of issues and limitations with Wrangler over the years.

Eg:

https://github.com/cloudflare/workers-sdk/issues/2964

https://github.com/cloudflare/workerd/issues/1897

Workerd is a JavaScript & WebAssembly-based runtime that powers Cloudflare Workers and other related technologies. You can think of it like the Node.js runtime used to execute JavaScript files. Workerd has its differences from Node.js, however, you can self-host it on any machine.

Standards bodies only standardize things after they've been proven to work. You can't standardize a new idea before offering it to the market. It's hard enough to get just one vendor to experiment with an idea (it literally took me years to convince everyone inside Cloudflare that we should build Durable Objects). Getting N competing vendors to agree on it -- before anything has been proven in the market -- is simply not possible.

But the Durable Objects API is not complicated and there's nothing stopping competing platforms from building a compatible product if they want. Much of the implementation is open source, even. In fact, if you build an app on DO but decide you don't want to host it on Cloudflare, you can self-host it on workerd:

https://github.com/cloudflare/workerd

In any case, I welcome this initiative with my open hands and look forward all the cool apps that people will now build with this!

[1] https://pyodide.org/

[2] https://github.com/cloudflare/workerd/blob/main/docs/pyodide...

[3] https://github.com/cloudflare/workerd/pull/1875

For ref:

- https://blog.cloudflare.com/workerd-open-source-workers-runt...

- https://github.com/cloudflare/workerd

workerd

I think this is for people who want to run their own cloudflare workers (sort of) and since nobody wants to run full node for that, they want a small runtime that just executes js/wasm in an isolated way. But I wonder why they don't tell me how I can be sure that this is safe or how it's safe. Surely I can't just trust them and it explicitly mentions that it still has file IO so clearly there is still work I need to do customize the isolation further. But then they don't show any info on that core usecase. But then that's probably because they don't really want you to use this to run it on your own, they are selling you on running things on their edge platform called "Wasmer Edge". So that's probably why this is so light on information.. the motivation isn't to get you to use this yourself, just to use this their hosted edge platform. But then I wonder why I wouldn't just use https://github.com/cloudflare/workerd which is also open source. Surely that is fast enough? If not then it should show some benchmarks?

> WebUSB is actually a W3C open standard.

This is misleading at best. Here’s what the actual spec says <https://wicg.github.io/webusb/>:

> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

It’s an experimental spec by Google (observe the affiliation of the three editors: all Google); Mozilla has adopted a negative position on it <https://mozilla.github.io/standards-positions/#webusb>; WebKit has not remarked upon it.

This is such a lame argument. You want it to be true but have no evidence that it actually is true.

A lot of the Chrome team's "standards" have problems with accessibility, workability on mobile, security[0], privacy[1], or just battery life. Some are neat experiments that are or only will be used in the wild by advertisers to track and identify users.

Because the Safari/WebKit team doesn't have to chase users for revenue like Mozilla does they can afford to be more conservative with what Google "standards" they support. Being able to offer a tighter privacy posture or efficiency is part of the iOS/macOS sales pitch.

[0] https://github.com/WICG/webusb/issues/50

[1] https://www.theverge.com/2021/4/16/22387492/google-floc-ad-t...

Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.

Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.