3 ms·

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. What, you mean like we do in Servo? https://github.

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. What, you mean like we do in Servo? https://github.com/servo/servo https://github.com/servo/servo :-) Our main thread (if you can call it that) just does compositing and handles dispatching UI events. Script, layout, resource loading, and the rest run concurrently in background threads.

jlongster 12y ago
That's amazing. I hadn't even though about Servo in light of all of this. In current browsers, JavaScript runs in the same thread as the UI, right? In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread? Maybe we should be thinking of all of this in terms that map well to Servo's current architecture. EDIT: What's really exciting about Servo is that hopefully the architecture's parallelism is really sound, even if certain properties of the current web restrain it. Then we can work on ways to remove those properties, and in Servo it's a simple switch to turn on more and more parallelism.
- pcwalton 12y ago
  > In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread? Yes, but we'd like to experiment with new APIs in the future like `getBoundingClientRectAsync()` that will allow pages to do that kind of thing asynchronously.
jordwalke 12y ago
I'm also interested in Servo as well. With React Native, we had the liberty to restrict certain paradigms that don't map well to building a parallelizable pipeline of operations. So the JS thread can't synchronously query for layout, which happens in the next stage, and the layout stage can't synchronously block on reading main thread (UIKit etc) values. By restricting what the programmer can do, it naturally formed a pipeline where layout can be performed in the second stage while JS is determining the next UI update and so on. I'm not sure the extent to which this benefits us right now, but even mobile devices are beginning to have four cores so it seems like a nice property to maintain as long as it doesn't cause problems. Servo sounds cool, and I'm curious how it takes advantage of a similar architecture but while the programmer has free reign to "clog the pipeline" by synchronous queries on layout etc. I'm sure they've thought of it, I'd just like to hear what they came up with.
- jlongster 12y ago
  I just asked pcwalton in #servo on mozilla and he said they want to introduce async versions of all of the DOM APIs like getBoundingClientRectAsync()
  - jordwalke 12y ago
    Awesome. That's exactly what we have on React Native :D We want to make sure that when possible, we choose APIs compatible with the future of the web.

jlongster 12y ago

That's amazing. I hadn't even though about Servo in light of all of this. In current browsers, JavaScript runs in the same thread as the UI, right? In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread? Maybe we should be thinking of all of this in terms that map well to Servo's current architecture. EDIT: What's really exciting about Servo is that hopefully the architecture's parallelism is really sound, even if certain properties of the current web restrain it. Then we can work on ways to remove those properties, and in Servo it's a simple switch to turn on more and more parallelism.

pcwalton 12y ago
> In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread? Yes, but we'd like to experiment with new APIs in the future like `getBoundingClientRectAsync()` that will allow pages to do that kind of thing asynchronously.

jordwalke 12y ago

I'm also interested in Servo as well. With React Native, we had the liberty to restrict certain paradigms that don't map well to building a parallelizable pipeline of operations. So the JS thread can't synchronously query for layout, which happens in the next stage, and the layout stage can't synchronously block on reading main thread (UIKit etc) values. By restricting what the programmer can do, it naturally formed a pipeline where layout can be performed in the second stage while JS is determining the next UI update and so on. I'm not sure the extent to which this benefits us right now, but even mobile devices are beginning to have four cores so it seems like a nice property to maintain as long as it doesn't cause problems. Servo sounds cool, and I'm curious how it takes advantage of a similar architecture but while the programmer has free reign to "clog the pipeline" by synchronous queries on layout etc. I'm sure they've thought of it, I'd just like to hear what they came up with.

jlongster 12y ago
I just asked pcwalton in #servo on mozilla and he said they want to introduce async versions of all of the DOM APIs like getBoundingClientRectAsync()
- jordwalke 12y ago
  Awesome. That's exactly what we have on React Native :D We want to make sure that when possible, we choose APIs compatible with the future of the web.