With WebUSB, you can program a microcontroller without needing to install local software. With Web Bluetooth, you can wirelessly capture data from + send commands to that microcontroller.

As a developer, these standards prevent you from needing to maintain separate implementations for Windows/macOS/Linux/Android.

As a user, they let you grant and revoke sandbox permissions in a granular way, including fully removing the web app from your computer.

Browsers provide a great cross-platform sandbox and make it much easier to develop secure software across all platforms.

WebUSB and Web Bluetooth are opt-in when the site requests a connection/permission, as opposed to unlimited access by default for native apps. And if you don't want to use them, you can choose a browser that doesn't implement those standards.

What other platform (outside of web browsers) is a good alternative for securely developing cross-platform software that interacts with hardware?

I’m ok with needing non-browser software for those things.

> Browsers provide a great cross-platform sandbox and make it much easier to develop secure software across all platforms.

Sure, until advertising companies find ways around and through those sandboxes because browser authors want the browsers be capable of more, in the name of a cross platform solution. The more a browser can do, the more surface area the sandbox has. (An advertising company makes the most popular browser, by the way.)

> What other platform (outside of web browsers) is a good alternative for securely developing cross-platform software that interacts with hardware?

There isn’t one, other than maybe video game engines, but it doesn’t matter. OS vendors need to work to make cross-platform software possible; it’s their fault we need a cross-platform solution at all. Every OS is a construct, and they were constructed to be different for arbitrary reasons.

A good app-permission model in the browser is much more likely to happen, but I don’t see that really happening, either. “Too inconvenient for users [and our own in-house advertisers/malware authors]” will be the reason.

MacOS handles permissions pretty well, but it could do better. If something wants local network permission, the user gets prompted. If the user says no, those network requests fail. Same with filesystem access. Linux will never have anything like this, nor will Windows, but it’s what security looks like, probably.

Users will say yes to those prompts ultimately, because as soon as users have the ability to say “no” on all platforms, sites will simply gate site functionality behind the granting of those permissions because the authors of those sites want that data so badly.

The only thing that is really going to stop behavior like this is law, and that is NEVER going to happen in the US.

So, short of laws, browsers themselves must stop doing stupid crap like allowing local network access from sites that aren’t on the local network, and nonsense stuff like WebUSB. We need to give up on the idea that anyone can be safe on a platform when we want that platform to be able to do anything. Browsers must have boundaries.

Operating systems should be the police, probably, and not browsers. Web stuff is already slow as hell, and browsers should be less capable, not more capable for both security reasons and speed reasons.

There are definitely legitimate reasons—for example, a browser-based CAD system communicating with a 3D mouse.

The phone is ringing—Java Applets called B-)

The article discusses how that turns into an infinite loop and causes a hang.

When you subtract a small float from a very large float, the value doesn't change. This is because the "steps" between float values increase with the size of the value (i.e. floats have coarser resolution for larger magnitudes)

To see this in action, try running the following in a JavaScript interpreter:

console.log(1_000_000_000_000_000_000 - 1);

But that’s “impossible”. It’s an angle between 0 and 2pi. When transformed it might go over a bit so they added the check.

It will “never” become big.

So why check? It’s unnecessary.

Thus the bug.

This was touched on in the video a little bit—essentially, the TypeScript codebase has a lot of polymorphic function calls, and so is generally hard to JIT optimize. JS to Go therefore yielded a direct ~3.5x improvement.

The rest of the 10x comes from multi-threading, which wasn't possible to do in a simple way in the JS compiler (efficient multithreading while writing idiomatic code is hard in JS).

JavaScript is very fast for single-threaded programs with monomorphic functions, but in the TypeScript compiler's case, the polymorphic functions and opportunity for parallelization mean that Go is substantially faster while keeping the same overall program structure.