RReverser

It sounds like you're talking about the W3C standards track (correct me if I'm wrong, just guessing from the context) whereas I'm talking about the spec itself as the document and the API. Those are two different things after all.

All browser engines have been following living specs even for core stuff like HTML/CSS instead of the W3C "officially finalised" standards for a while now, so I didn't bring the latter up as they weren't relevant to the conversation about the spec itself or its stability.

However, I admit that I missed myself and should've called out that the spec, while stable, is still a draft - that's a mistake on my part.

Funny how you use words like "insult" yet don't see the irony in the tone you use when talking to other people :)

Good day to you too.

Is it? It's worth keeping in mind that it's users and apps that comprise the web, not the implementation details of any given browser.

Ah yeah, that should be easier! I was mostly coming from the perspective of trying to get DSLR working in the demo :)

I understand where you're coming from, but at the same time it's a feature defined as a finalized spec in the Web incubator. Even if it's currently implemented by one engine, 1) that engine is used in browsers from many different vendors - Google, Microsoft, Samsung, etc. which represent a huge chunk of the Web and 2) there's still hope that other browsers will implement it in the future.

For example, File System Access API was also part of WICG and similarly deemed by commenters as Chrome-only API because it implemented it first, but is now at least partially implemented in Safari 15.2. Who knows what we'll see adopted next? As long as there's a Web spec and apps using an API, browser vendors can prioritise.

If it didn't even ask for permission, most likely it didn't use WebUSB, but connected via HTTP to a crappy local executable preinstalled by the vendor.

Such implementations exposing all sorts of critical stuff over local HTTP servers are often highly insecure, and are the very reason why WebUSB and other device APIs are being pushed as part of the browser.

Because that browser provides a universal API that works across pretty much all the popular operating systems, whereas the alternative is to build and maintain code for each of those systems separately.

Unfortunately, that's not entirely true. If your device is designed for WebUSB and has its specific descriptor, then yeah, you don't need to change any drivers.

However, as mentioned in the article, if it's a "well-known" device, then you still need to use Zadig and override the driver to something like WinUSB.

I don't think it's worse because: 1) Wasm was designed to be easily decompilable / convertible to a text assembly representation by design, whereas for other platforms it requires fairly sophisticated disassemblers 2) Wasm can interact with the outside world (any I/O) only via explicitly defined import points, which are easy to intercept and/or replicate even if you don't know what's inside the binary itself.

Good point regarding the offline capabilities, I'm not sure how well the Internet Archive will handle Wasm, but for the rest - WebUSB was already stabilized and isn't considered experimental (although I admit that didn't stop some other non-cross-browser APIs from being removed in the past).

Companies that want to do so, already embed "ring home" mechanisms in their apps that periodically connect to the Internet and check that you still hold a valid license or refuse to continue working.

It seems this depends a lot more on the company policy rather than specific technology used for the implementation.

Btw, author of the port / demo / article here - happy to answer any questions you have :)

You can likely visit the old version of the website via Internet Archive or save an offline snapshot yourself if you want, so it would be no different to driver on an offline computer.

To be fair, Edge is also Chromium-based (I guess that's what the previous author meant, rather than specifically Chrome-only).

But yeah, I'm also hoping for WebUSB to make its way to other browsers, but for now I'll take any improvement to building & distributing apps across many operating systems at once :)

Yeah Rust's wasm-bindgen has integration between Rust async-await and JavaScript promises which doesn't have same restrictions: https://rustwasm.github.io/wasm-bindgen/reference/js-promise...

However, Asyncify is useful in other scenarios - where you want to shim out an API that is normally synchronous in C / Rust land, with an async JS implementation.

async-await, like any coroutine-based mechanism, requires changing every single function in the entire callstack to be async as well, which is usually not feasible in such scenarios (e.g. when shimming out some basic filesystem API). That's where Asyncify helps a lot.

> As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics;

FWIW that's exactly what the linked post describes :)

The Github Pages situation is definitely unfortunate. We tried to contact them for couple of months to ask to add an option for COOP/COEP before the deprecation, but didn't have any luck with our contacts.

Nice! Just noticed the backlink from those release notes to the article as well.

1) Oops, thanks for pointing out the mistake. Will fix in a few minutes. 2) The freaky thing is, I'm fairly sure I didn't even see or look at Rayon's official example in README when I came up with that example for my crate I only came up with it because I was _just_ working on root mean square errors in another side-project. That's hell of a coincidence.

That's nowhere typical, even in London you'll find that only in higher-end companies.

(Author here - sorry, just noticed this post got to HN a few days ago.)

True, I've considered describing that feature too, but in the end decided it would be too much deviation for the article that is already fairly large. That integration is very interesting on its own, but solves slightly different set of problems - that is, it can' t be used for bridging regular synchronous APIs like WASI in back-compat manner, but rather requires your entire stack to be built on top of async APIs.

If it is, that's indeed an even better solution, but most likely at least majority of your dependencies just use regular std:: APIs that are sync-only.

Describing those tradeoffs and doing meaningful comparison of two approaches feels like a whole separate blog post :)

No, that's never allowed - that's the strength of Wasm. Any unchecked helpers are for language-level semantic blocks within Wasm memory itself, not for leaving the sandbox. So worst case you might override and corrupt your own data.

> already uncommon

It's definitely not uncommon though. Just to provide one example: how often do you use all the arguments to `.map` callback?

Usually you'd write something like `arr.map(x => x + 1)`.

However, to spell out all the arguments you'd have to write `arr.map((x, i, arr) => x + 1)`.

And there's tons of other functions like that in stdlib or 3rd-party libs that people use without passing or accepting all the args. That's why this optimisation is so useful.

I guess you'd have to make series of patches to GDB to make it work, as well as to build your own DevTools extension once the API is stable, but in theory should be possible, yeah.

Did you mean ChromeDevSummit talk or there was a separate WebSummit talk on this too?

You will be able to build your own extension with any backend in the future, but I'm curious what you're looking to gain from that?

I don't know whether GDB understands the Wasm-specific constructs in DWARF, while the current integration uses LLDB under the hood, which does support those.

Thanks, going to fix soon-ish! Not sure how it slipped by.

It does work with basic Rust compiled to Wasm, but most of the ecosystem uses wasm-pack / wasm-bindgen, which currently doesn't support DWARF.

You can subscribe to https://github.com/rustwasm/wasm-bindgen/issues/2389, but, unfortunately, wasm-pack currently is maintainerless until someone steps in. (see https://twitter.com/ag_dubs/status/1319651621698232322)

Interesting, are you on the latest Chrome Canary? If so, could you please report a bug with a simple repro to the https://bugs.chromium.org/p/chromium/issues/entry?template=D... link mentioned in the article?

> Answering my own question, a little, I use figma.com a lot. But the potential seems so great, and the available PWAs so poor....

It's just that WebAssembly, like any new technology, can and usually is used in very specific paths that require it.

As a result, it's true that there is not that many full WebAssembly-powered PWAs, although the ones that are, like Figma you already mentioned or Google Earth or various Blazor-powered apps already speak for themselves.

However, there is even more apps and websites out there that use Wasm either directly or via library dependencies for calculations, graphics or even things like hyphenation - in my research https://github.com/mnater/Hyphenopoly was one of the most popular Wasm-powered libs used across a bunch of CMS and blog platforms - probably the last place you would expect to find WebAssembly in, and yet...