Yeah. The OP should spend a day or two making HTML5 prototypes for the key aspects and see if it's really true that it's "slow".
The UI is not the hot code, it's the audio mixing. So long as the audio mising is faultless, it doesn't matter too much if it takes an extra video frame to update the dB display.
Because there are thousands of people working to maintain the code in the browser stack every day that are on his side then.
I can assure you that users complain when the GUIs of DAWs start to run below 30fps, and really the expectation these days is that "performant" GUIs run at 60fps.
I am suggesting confirming if it is actually "slow" for the "key aspects".
You and the OP are just assuming it can't do whatever it is at "30fps"... if you're right, it will only take ten minutes if it's so bad, or an hour or two if it's subtle, to actually confirm whatever the worst thing is.
The "extra frame" I was thinking of is graphics pipeline latency, not redraw time.
Well now you're assuming what I'm assuming, which is fair enough because I assumed by your comment that you were saying the UI responsiveness isn't really a concern in DAWs. It's definitely a secondary concern, but people are accustomed to buttery smooth UIs and complain when they're not.
That said, I'd argue that even latency is still a concern for things like meters. If they are noticeably out of sync with what you hear then users will again complain.
The UI is not the hot code, it's the audio mixing. So long as the audio mising is faultless, it doesn't matter too much if it takes an extra video frame to update the dB display.
Because there are thousands of people working to maintain the code in the browser stack every day that are on his side then.