That's quite timely. I'm writing a soft real time piece of code for use in the browser. It's a nightmare. So many layers underneath that it is very hard to get any kind of idea where latency and throughput issues are coming from.
Maybe you should reconsider.
My definitions:
* hard real time: people will die or things will be destroyed if a certain block of code is not executed within N msecs of something happening
* soft real time: nobody will die but things only really work correctly if a certain block of code is not executed within N msecs of something happening
I write soft real time for a living (a multiplatform DAW). We have to go to great lengths to ensure performance, and we do things that you will NEVER(1) be able to do in a browser.
(1) for any reasonable definition of NEVER
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!
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.