Hacker News Reader

Comment by reaperman | Hacker News Reader

The overall article is extremely clearly written and well-diagrammed, as you'd expect from someone who writes software for test/metrology equipment. It does look pretty different from your usual web-dev retrospective, and shares more in common with "$BROWSER Internals" style articles.

The thesis:

> I recently spent some time building a browser-based signal analyzer (spectrogram + oscilloscope) as part of one of my projects. I ended up using some very modern browser APIs and technologies that I'd not worked with before, and I discovered a lot of really interesting patterns and techniques that I'd never seen before in a web app.

> Building this application has made it clear to me that the modern web is extremely well-suited to building complex multi-threaded and graphics-intensive applications.

View on HN

Demo doesn't work on FF in Windows 10, not clear that it's meant to run anywhere other than on Chrome or Safari.

So I'm not really sure the author's thesis has been validated, as interesting and useful as the concept appears to be.

Firefox is lagging behind on a lot of the more esoteric web APIs. I think it's a choice by the Firefox team, and a valid one given the effort required, Mozilla's relatively limited resources, and how few devs actually want or need these APIs. Firefox is more like a "website viewer" than a "web app host" like Chrome and Safari. I think that's what a lot of Firefox users want, and why they choose that browser. It might even be useful to differentiate between them instead of calling everything a 'web browser' in the future.

To that end I don't think it's a fair criticism of web app developers or Firefox that apps like this don't work in your browser.

The specs that firefox chooses not to implement are stuff like web midi for security concerns. Firefox does not try to market itself as a "website viewer" that does not support "web apps"

You must have missed the announcement. Firefox now supports web midi, their security concerns where BS all along anyway.

I can't speak on the specific details of web midi, but after the spate of poorly designed browser features with intrinsic security vulnerabilities (eg canvas fingerprinting), it's reasonable to be wary of things coming down the pipeline.

That always makes good sense. I think Chrome got this one right though, have a reasonable protection against abuse and trust that the end user is capable of weighing the risks.

Really, there isn't an issue around fingerprinting? https://twitter.com/denschub/status/1582730985778556931

The issue around fingerprinting is secondary because it isn't a security issue but a privacy issue, and this is a problem anyway for which there isn't a really good technical solution.

The security issues that were mentioned (someone bricking synths on purpose via SysEx messages) has afaik never actually happened.

Hmm it should be working in Firefox - as long as you're using the latest version instead of ESR it should be good; works for me on Firefox 113.0 on Linux.

Some browsers have anti-autoplay-ad protections built in that prevent audio from playing until you interact with the page. You might have to click the page or press a key on the keyboard to get it started.

Works great here (Firefox 113.0.1 on Windows)

This works fine for me (Firefox, Ubuntu, tracking protection set to max, uBlock origin on, privacy badger on, resistFingerprinting on). You need to click the play button to make it go, of course, but then it just works.

Maybe there's a setting you've disabled previously and have since forgotten about?

"$BROWSER Internals style articles" sounds like something I would crave for. Do you have any examples with actual "$BROWSER Internals"?

Reply on news.ycombinator.com