worker-ui
worker-ui copied to clipboard
kripken
react-canvas
https://github.com/flipboard/react-canvas
renders React to a canvas element, hoping for fast hardware acceleration, which I assume means it uses 2D canvas. A WebGL version might be interesting.
Reading more about this, it looks amazing. It brings React to the web and already has excellent performance. The only possible things to improve might be
- WebGL instead of canvas 2D (e.g. through a canvas 2D implementation of what they need, targeting WebGL).
- Worker proxying.
Yeah, I definitely saw that! It's very cool. It even uses the css-layout project that we talked about.
A version with WebGL and running the app code in a web worker would be neat. It would be very similar to React Native in that we wouldn't have a lot of the normal APIs, like IndexedDB, and we would need to create a "bridge" to the main thread. I have two concerns with that:
- Cross-worker communication can't be that fast. I mean, this is just going off intuition, but I worry that it's not fast enough for the app to update itself and send the data to the main thread all within 16ms.
- Having to still call a bunch of APIs and do stuff on the main worker, where rendering is happening, is still definitely going to cause dropped frames. A good example is image decoding. I've heard that all browsers do image decoding on the main thread, which suddenly drops a few frames. It's also extremely hard to see what the cause of these dropped frames are, but the single-threaded nature of the web makes this hard... (which is where Servo comes in, but that's a long way off)
The reason I'm assuming the app needs to update in 16ms is because JavaScript-powered animations are necessary for the mobile web, as they constantly respond to gestures (or some kind of physics engine).
What would be super interesting is if we ever get actual multi-threading for asm.js code. Games are pushing for this, and obviously you know way more about the possibility of that, but I wouldn't be surprised to see it in the long-term. When that happens, if we are allowed to give a WebGL context to a thread, then anything is game!
Message-passing is fairly fast, but regardless, if it's mostly one-way, then you have just an initial latency issue, but running animations can be fast.
There are some experiments with multithreading, but it's mostly a standardization open question at this point.
This part is definitely up for debate, but animations can't just be a "send this animation once and start it" signal from the JS thread to the main thread. We really need frame-by-frame JavaScript powered animations, because animations that respond to gestures (scrolling, sliding, etc) need to be tightly tied to the JS events. There's also physics-based UIs which need to be run in JS. A lot of times you also need to depend on some app state for mobile animations, like when scrolling show the next few items in a list when you scroll to a certain point.
Facebook learned all of this after years of experimenting, and React Native is highly optimized for it. They are actually betting on JS animations. They can make sure that the JS event loops runs at 16ms (since on its own thread & no sync DOM APIs) and that messages across the bridge are fast enough.
This allows you to do really complicated, but smooth animations.
We already use react for our 2D HTML5 UIs. We've developped a plugin for our 3D engine (https://github.com/aerys/minko) to have a cross-platform HTML5 DOM overlay on top of "native" 3D. This way we can build a 100% cross-platform app with a responsive UI on Windows, OSX, Linux, Android, iOS and HTML5.
React is THE framework we've been using for those UIs and it's awesome. With react-canvas we can get even better performances and compatibility I guess. A WebGL mode would be even better.
Separating the UI thread from the 3D rendering (and the physics) thread/workers would be cool.
IMHO this is incredible news for x-platform developers.
We've tossed around the idea of a WebGL mode in React Canvas. It doesn't help our particular use case, as the majority of images we render on Flipboard are not served with cross-domain headers. But it would be interesting to see.
