I think #2 is the kicker. Libraries are a place where web workers make a lot of sense, because the payoff for the extra work is multiplied by everyone who uses it. And as time goes on and JS libraries do more and more heavy lifting, it makes sense that they would benefit from multi-threading.<p>But that same thing works against a library developer when it comes to browser compatibility. It means you have to write a fallback, and that's particularly annoying when it comes to web workers.<p>The other problem as I see it is that the model of not sharing memory makes it a lot trickier to squeeze performance out. A lot of situations that would benefit from multi-threading are situations where you're processing a big chunk of data. If you have to copy those big chunks of data in and out of your worker, you sacrifice a lot of the performance you're working so hard to achieve.<p>Transferable objects will help a lot with that, but that's very new, and it will be even longer before you can just take it as a given.