That sounds overly dramatic to me. I'm writing a DAW of sorts for the browser, and while I wouldn't use it on stage, it works well enough to produce music on. I didn't even add AudioWorklet support yet, and I will probably release without it and consider it if users complain about stutters etc.

Have you tested on a variety of platforms? In my experience, some are very good about this (e.g Chrome on macOS) and some are a common source of problems (e.g. Firefox on Linux, at least with PulseAudio).

It seems to work well on the popular platforms (chrome, safari, ios, android) although I haven't tried linux yet. Wasm performance can vary between browsers though, which will impact the experience a lot.

"DAW of sorts"

Obviously, one can do music creation and audio processing in a browser.

The parameters that matter are what N is in the "N msecs" I mentioned above, how much audio (e.g. tracks) and how much processing (i.e. DSP).

When you make N small enough, make the track count large enough, and do enough DSP, it's never going to work inside a browser (it sometimes won't work outside the browser).

If N is large enough, the track count small enough and/or there's not too much DSP going on .... have fun!

It is a MIDI application that is only useful when delivered via the web. I don't have much choice there. So yes, it is a hard path. But then again, if I can get it to work then it will be a very neat little project. So for now I'll just stoically plod through and try to eliminate each of the little gotcha's one-by-one.

But the ease with which apparent guarantees are tossed around by browser documentation (with regards to time) only to see them solidly trashed in real life is depressing.