We’ve discussed this in the channel but a few things I wanted to bring up:
We said we should do workers be default, but depending on structure, this may well prevent users from using any framework (e.g. Meteor) that isn’t built for workers and/or potentially that all user code needs to be in the worker and write their own bridges for anything they need on the DOM (in the UI thread). That’s a very major barrier for adoption, but there are some way around it (none of which are ideal).
In general for “top” performance, we want only the renderers in the UI thread. That means building the scene graph and working with it, etc, in a worker thread. This introduces the kinds of problems I mention above, but like Famous, if we avoid direct DOM access, it’s not the end of the world, it’s a potentially fair trade off.
We also spoke about sending calculations (component updates) to worker threads. On the one hand it’s quite nice since we can split this up over all available cores, on the other hand, we need to remember that everything happens over messaging, so the
calcalation + copy there + copy back of data + management overhead needs to take less time than doing the calculation on the existing thread. There is a newer web worker technology that let’s you do zero copy transfers, but then the original data is no longer available on the initiating thread, so it would have to be copied beforehand too.
Also as @oldschooljarvis just mentioned, we initiate workers from the UI thread, but they have to load their own scripts, so we introduce some additional latency.