I suspect "works" is strong - if there's no preemption, it's very easy to hit a deadlock. Consider a program that e.g. mines bitcoin on one goroutine and displays UI on the other. On any normal platform, the UI goroutine would get scheduled on a thread at least occasionally, but if you only have one thread to go around and no preemption, the mining task could just keep mining forever.
How are the two threads communicating? Via a channel? Why can't you schedule when a value is pushed onto a channel? Why do you need preemption in this situation?
The first task is writing to the second when it's done with a computation, but not bothering to check input from the second while it's in the middle of a computation.
Well, this works as long as you're using a separate goroutine and the Go runtime creates more than one thread, right? My claim is that a Go runtime that only creates one thread (which is effectively what Joy is) will not work the way you expect in this case.
Or, more specifically, that if you have N goroutines that consist of infinite loops of pure computation (or really, anything that doesn't involve receiving from a channel), and at least one other goroutine that's receiving from a channel, your runtime needs to generate at least N+1 OS threads or your last goroutine will never get scheduled.
That isn't any different from anything else in the browser though. It's not going to lock up anymore than async JS code would during CPU intensive operations. Which generally don't need to be done in browsers anyways.
