30 ms·

You are speaking my language! I would love to see a prototype of this. I've been thinking about it since I saw React Native. I wonder if there's even value in

You are speaking my language! I would love to see a prototype of this. I've been thinking about it since I saw React Native. I wonder if there's even value in something like an asm.js-compiled layout system, which absolutely positions elements. One of the insights of React Native is that to build apps, we really only need a small subset of the web's layout algorithms. Only flexbox, really. So if we recognize this subset, and remove everything else, there main thread can focus on really smooth performance. React Native even performs the flexbox layout on a 3rd thread, and tells the main thread where to absolutely position stuff. Obviously we want to re-use as much of HTML as we can, but there might be some crazy ways to remove stuff from the main thread. EDIT: It should be noted that Mercury, a React-inspired library (https://github.com/Raynos/mercury https://github.com/Raynos/mercury), has examples of running in a web worker. It is pretty cool, but I think it needs to be fleshed out more.

nwienert 12y ago
Me me! I'll be exploring this soon and I'm sure I'll reach out for help before I get too far. Could do a lot of stuff off thread, from data to layout calcs. My profile should have some info related to the hybrid stuff.
- jlongster 12y ago
  Very cool! I'll keep an eye on your work!
  - azakai 12y ago
    Me too. I'd love to chat more about this with both of you, this seems like a direction definitely worth exploring. Maybe we could set up a github project for it? Or talk in an issue on your existing repo, nwienert?
    - nwienert 12y ago
      I'd like to see a github repo. You can hit me up on twitter, info in my profile. I think even just finding the right library to make using webworkers + npm + webpack would be great to start, because honestly its all the other stuff that slows down the thread. React can run on the main thread for the most part. Some reading: https://news.ycombinator.com/item?id=6982485 https://news.ycombinator.com/item?id=6982485 http://stackoverflow.com/questions/18056922/is-there-a-way-to-create-out-of-dom-elements-in-web-worker http://stackoverflow.com/questions/18056922/is-there-a-way-t... Edit: webpack + webwoker: https://github.com/webpack/webpack/tree/master/examples/web-worker https://github.com/webpack/webpack/tree/master/examples/web-...
      - azakai 12y ago
        Cool, I set up a repo and started a wiki on it, https://github.com/kripken/worker-ui/wiki https://github.com/kripken/worker-ui/wiki Not familiar with webpack, will take a look.
        peterhunt 12y ago
        If you're interested in doing it with React, here's a video explaining how to do a custom backend: https://www.youtube.com/watch?v=eNC0mRYGWgc https://www.youtube.com/watch?v=eNC0mRYGWgc You basically need to change BackendIDOperations and ReactEventListener to send/receive messages vs talking to the real APIs. It's already set up in the codebase to do this (because it actually worked at one time). Webpack, per usual, already thought of this and has an answer for you :) https://github.com/webpack/worker-loader https://github.com/webpack/worker-loader
    - jlongster 12y ago
      Sweet. I'll watch out for wherever you guys end up. Might be worth reading one of the react native devs about why animations might still be hard: http://jlongster.com/First-Impressions-using-React-Native#comment-1838941031 http://jlongster.com/First-Impressions-using-React-Native#co... This idea is also why I hooked up the css-layout project (https://github.com/facebook/css-layout https://github.com/facebook/css-layout) to a live demo to play around with: http://layout.jlongster.com/ http://layout.jlongster.com/
      - jordwalke 12y ago
        Yes, in browsers, JS animations are still hard (I might even say impossible to do well for large apps with a lot going on). One anecdote: I spent a month trying to build a 60fps scrolling list view in JS from scratch (JS driving all the animations). No matter how hard I tried, I couldn't make it work on the web. I believe it was image decoding interfering but it's difficult to say why. Then I took that same example, which by that point was optimized, and ported it to React Native in a few hours(where we have off-thread image decoding and timers I can trust) and the example was like butter. Now of course, I had hand optimized the performance, but my point is that on the web, there was nothing I could do, and with React Native, there was something I could do to make animations smooth. This is not to say you should be doing animations in JS, but if you want highly customizable interactions that can be immediately stopped by a touch processed in JS, you should try it out and see how it feels. For things that are "fire and forget", or platform specific, you should try using CoreAnimation/keyframes etc which protects the animation from your business logic.
        mlvljr 12y ago
        Interestingly, this comment, while probably being of the most technical detail / value in the thread, was downvoted by someone :)
        akrymski 12y ago
        what's wrong with -webkit-overflow-scrolling: touch? doing scrolling in js is so last year.
    - spicyj 12y ago
      Also worth looking at some ideas we have for doing cross-thread component hierarchies in React: https://github.com/reactjs/react-future/tree/master/05%20-%20Workers https://github.com/reactjs/react-future/tree/master/05%20-%2...
- gnrlbzik 12y ago
  oh nice, thanks for mentioning this.
malandrew 12y ago
We explored this at a previous company I worked at. The conclusion at the time was that the message passing model was not yet efficient enough at the time because of serialization/deserialization which nullified any performance gains. Transferrable objects at the time were really new. If the support for shared memory has improved, it might now make sense. The biggest problems with performance are: - GC pauses - triggering reflow - marshalling data across interfaces (serialization/deserialization of native types into strings and back again). That last one is an absolute killer when it comes to applying 3D matrix transforms. Basically, you're taking an array of floats, serializing them into a string to do an element.style property assignment, so that the browser can then take that stringified representation and convert it back into an array of floats that it can apply. Huge perf hit here.
- Yahivin 12y ago
  You can now transfer typed array data using the newest postMessage API. http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
- jordwalke 12y ago
  I haven't found serialization to be anywhere near the bottleneck. How long does it take to serialize/deserialize a 16 element array? I could see how this would be an issue if you had hundreds of them per frame. But for most purposes an entire 16 element array is overkill and you could probably come up with a more compressed description of the transforms (scale, rotate, translate) and consider adding a pooling layer. People attribute pauses to GC, when it's sometimes just the browser container environment acting up and there's nothing we can do about it - so it's easy to write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(), i.src="http...") could block the JS thread for as much as 19ms. In a larger app, it's easy to write that off as GC, but (at least on iOS) the performance tooling is really lacking and it's tough to find the culprit. Reflowing is a big deal, I agree.
  - peterhunt 12y ago
    Blowing out texture memory accidentally was also a big deal when I was measuring this stuff.
leonkenneth 12y ago
I am not a maintainer and I just tried it briefly so I am not 100% sure of the allegations they make on their front-page, but it seems like http://gridstylesheets.org http://gridstylesheets.org are using Workers to run their layout algorithm (Cassowary Constraint Solver) and absolute-position elements (using 3D transforms). EDIT: Searching for "Worker" right now didn't bring any mention, but it seems it is a very recent edit (cf https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5dd9a72c1a3df0c1ca0c758553 https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5d...).

nwienert 12y ago

Me me! I'll be exploring this soon and I'm sure I'll reach out for help before I get too far. Could do a lot of stuff off thread, from data to layout calcs. My profile should have some info related to the hybrid stuff.

jlongster 12y ago
Very cool! I'll keep an eye on your work!
- azakai 12y ago
  Me too. I'd love to chat more about this with both of you, this seems like a direction definitely worth exploring. Maybe we could set up a github project for it? Or talk in an issue on your existing repo, nwienert?
  - nwienert 12y ago
    I'd like to see a github repo. You can hit me up on twitter, info in my profile. I think even just finding the right library to make using webworkers + npm + webpack would be great to start, because honestly its all the other stuff that slows down the thread. React can run on the main thread for the most part. Some reading: https://news.ycombinator.com/item?id=6982485 https://news.ycombinator.com/item?id=6982485 http://stackoverflow.com/questions/18056922/is-there-a-way-to-create-out-of-dom-elements-in-web-worker http://stackoverflow.com/questions/18056922/is-there-a-way-t... Edit: webpack + webwoker: https://github.com/webpack/webpack/tree/master/examples/web-worker https://github.com/webpack/webpack/tree/master/examples/web-...
    - azakai 12y ago
      Cool, I set up a repo and started a wiki on it, https://github.com/kripken/worker-ui/wiki https://github.com/kripken/worker-ui/wiki Not familiar with webpack, will take a look.
      - peterhunt 12y ago
        If you're interested in doing it with React, here's a video explaining how to do a custom backend: https://www.youtube.com/watch?v=eNC0mRYGWgc https://www.youtube.com/watch?v=eNC0mRYGWgc You basically need to change BackendIDOperations and ReactEventListener to send/receive messages vs talking to the real APIs. It's already set up in the codebase to do this (because it actually worked at one time). Webpack, per usual, already thought of this and has an answer for you :) https://github.com/webpack/worker-loader https://github.com/webpack/worker-loader
  - jlongster 12y ago
    Sweet. I'll watch out for wherever you guys end up. Might be worth reading one of the react native devs about why animations might still be hard: http://jlongster.com/First-Impressions-using-React-Native#comment-1838941031 http://jlongster.com/First-Impressions-using-React-Native#co... This idea is also why I hooked up the css-layout project (https://github.com/facebook/css-layout https://github.com/facebook/css-layout) to a live demo to play around with: http://layout.jlongster.com/ http://layout.jlongster.com/
    - jordwalke 12y ago
      Yes, in browsers, JS animations are still hard (I might even say impossible to do well for large apps with a lot going on). One anecdote: I spent a month trying to build a 60fps scrolling list view in JS from scratch (JS driving all the animations). No matter how hard I tried, I couldn't make it work on the web. I believe it was image decoding interfering but it's difficult to say why. Then I took that same example, which by that point was optimized, and ported it to React Native in a few hours(where we have off-thread image decoding and timers I can trust) and the example was like butter. Now of course, I had hand optimized the performance, but my point is that on the web, there was nothing I could do, and with React Native, there was something I could do to make animations smooth. This is not to say you should be doing animations in JS, but if you want highly customizable interactions that can be immediately stopped by a touch processed in JS, you should try it out and see how it feels. For things that are "fire and forget", or platform specific, you should try using CoreAnimation/keyframes etc which protects the animation from your business logic.
      - mlvljr 12y ago
        Interestingly, this comment, while probably being of the most technical detail / value in the thread, was downvoted by someone :)
      - akrymski 12y ago
        what's wrong with -webkit-overflow-scrolling: touch? doing scrolling in js is so last year.
  - spicyj 12y ago
    Also worth looking at some ideas we have for doing cross-thread component hierarchies in React: https://github.com/reactjs/react-future/tree/master/05%20-%20Workers https://github.com/reactjs/react-future/tree/master/05%20-%2...
gnrlbzik 12y ago
oh nice, thanks for mentioning this.

malandrew 12y ago

We explored this at a previous company I worked at. The conclusion at the time was that the message passing model was not yet efficient enough at the time because of serialization/deserialization which nullified any performance gains. Transferrable objects at the time were really new. If the support for shared memory has improved, it might now make sense. The biggest problems with performance are: - GC pauses - triggering reflow - marshalling data across interfaces (serialization/deserialization of native types into strings and back again). That last one is an absolute killer when it comes to applying 3D matrix transforms. Basically, you're taking an array of floats, serializing them into a string to do an element.style property assignment, so that the browser can then take that stringified representation and convert it back into an array of floats that it can apply. Huge perf hit here.

Yahivin 12y ago
You can now transfer typed array data using the newest postMessage API. http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
jordwalke 12y ago
I haven't found serialization to be anywhere near the bottleneck. How long does it take to serialize/deserialize a 16 element array? I could see how this would be an issue if you had hundreds of them per frame. But for most purposes an entire 16 element array is overkill and you could probably come up with a more compressed description of the transforms (scale, rotate, translate) and consider adding a pooling layer. People attribute pauses to GC, when it's sometimes just the browser container environment acting up and there's nothing we can do about it - so it's easy to write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(), i.src="http...") could block the JS thread for as much as 19ms. In a larger app, it's easy to write that off as GC, but (at least on iOS) the performance tooling is really lacking and it's tough to find the culprit. Reflowing is a big deal, I agree.
- peterhunt 12y ago
  Blowing out texture memory accidentally was also a big deal when I was measuring this stuff.

leonkenneth 12y ago

I am not a maintainer and I just tried it briefly so I am not 100% sure of the allegations they make on their front-page, but it seems like http://gridstylesheets.org http://gridstylesheets.org are using Workers to run their layout algorithm (Cassowary Constraint Solver) and absolute-position elements (using 3D transforms). EDIT: Searching for "Worker" right now didn't bring any mention, but it seems it is a very recent edit (cf https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5dd9a72c1a3df0c1ca0c758553 https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5d...).