71–80 of 136 posts
Here's an interesting take on the "hybrid" app idea: - React Canvas is your application layer - HTML canvas is your common rendering layer - Browsers are your web runtime - Ejecta[0] is your iOS runtime - (I don't know a native android canvas runtime) [0] http://impactjs.com/ejecta --> renders with WebGL
If rendering UI to a canvas fits your needs then by all means do it. Just be aware that when it comes time to localize to other languages it starts getting hard to support things like CJK where in order to properly work there's an Input Method Editor ( http://i.imgur.com/JmmYwyi.gif ) that needs to be able to read the text. There's also cut/copy/paste which users can't do from text on a canvas. There's also "define"…
Earlier quoted context omitted.
It's css-layout: https://github.com/facebook/css-layout . The same engine used in React Native. It turns out that you only need a portion of CSS for apps. It's very performant.
Huh. Using a reimplemented, minimal CSS engine would mean more or less baked-in cross-browser compatibility, right?
This looks really neat. How does this compare to Famo.us, which also claims at have smooth animations at 60 fps?
Famo uses the DOM, by encoding matrix transforms to strings and sticking them into the attributes of DOM nodes.
Oh my, it is beautiful on the inside. Check out the source. They're totally showing off the power of React component model even when it doesn't render directly to DOM tree: https://github.com/Flipboard/react-canvas/blob/master/lib/Su... It's about describing nested side effects in time, really.
I actually wonder if it can be done even more elegant with RxJS?
If rendering UI to a canvas fits your needs then by all means do it. Just be aware that when it comes time to localize to other languages it starts getting hard to support things like CJK where in order to properly work there's an Input Method Editor ( http://i.imgur.com/JmmYwyi.gif ) that needs to be able to read the text. There's also cut/copy/paste which users can't do from text on a canvas. There's also "define"…
The fun part is tweaking text layout algorithm and letting Hot Loader pick up changes when replacing components. Without browser refreshing, of course.
If rendering UI to a canvas fits your needs then by all means do it. Just be aware that when it comes time to localize to other languages it starts getting hard to support things like CJK where in order to properly work there's an Input Method Editor ( http://i.imgur.com/JmmYwyi.gif ) that needs to be able to read the text. There's also cut/copy/paste which users can't do from text on a canvas. There's also "define"…
That said, doing this on a content-driven site is absolute madness. It breaks so many things, and throws away so many fundamental tenets of the web. by the time they've reimplemented everything they'll have probably lost all performance wins. The fancy animations are a miniscule gain for such a great loss of functionality
Excited to play with this though, since I'm learning canvas and graphics!
If rendering UI to a canvas fits your needs then by all means do it. Just be aware that when it comes time to localize to other languages it starts getting hard to support things like CJK where in order to properly work there's an Input Method Editor ( http://i.imgur.com/JmmYwyi.gif ) that needs to be able to read the text. There's also cut/copy/paste which users can't do from text on a canvas. There's also "define"…
And to your point about accessibility: https://github.com/flipboard/react-canvas#accessibility
You are correct that the DOM just works. But we need a better option on the web in order to achieve the kinds of experiences that people have come to expect from native applications. The hope is that by pushing the browser beyond its limits that we can make progress in this area.
A stronger indictment of the DOM than finding it necessary to combine a CSS parser written in Javascript, a virtual DOM and a canvas based renderer because it is faster than updating the DOM would be difficult to come up with... It looks like amazing work, but it's quite depressing that it's necessary.
Does mobile browser DOM rendering use GPU hardware acceleration?
The rendering happens in batches, the first render is always an expensive operation and includes both "paint" & "layout".
- The "layout"-operation recalculates the tree of visible elements.
- The "paint"-operation paints the element and is commonly done using a software rasterizer.
Every subsequent render happens if an DOM-element triggers a layout or a paint (or both). A re-paint occurs when changes are made to an elements skin that changes visibility, but do not affect its layout. Examples of this include outline, visibility, or background color.
When you use GPU-accelerated CSS properties such as opacity, translate, rotate & scale, both layout- and paint-operations are not executed. The GPU handles the changes for those properties. This is how famo.us wants to achieve its "60fps".
React by itself can cause expensive operations too if you trigger a CSS property that is not GPU-accelerated. In the process of rendering, a DOM-element can be destroyed and recreated when your state or model changes. So be vary of third-party React-components that promise "fluid" or "fast" speeds. IMO animation is still a research-topic for React. Their manual currently lists a method for basic CSS animations and transitions, but it's projects like React Canvas that make React a worthwhile contender for performant animations.
http://facebook.github.io/react/docs/animation.html
Mobile browsers are no different to Desktop browsers, almost every smartphone has a GPU of some sort. So you have 2 main-bottlenecks with every device. The first is the CPU (& RAM), the next one is the GPU (& the GPU-RAM).
What is GPU-accelerated and why:
http://www.html5rocks.com/en/tutorials/speed/high-performanc...
How Reflows and Repaints cause slow javascript:
http://www.stubbornella.org/content/2009/03/27/reflows-repai...