top | item 9029159

Flipboard releases React Canvas

501 points| jordwalke | 11 years ago |github.com | reply

131 comments

order
[+] greggman|11 years ago|reply
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" which is built into OSX and iOS (others?) letting the user select a word and look up its definition in the dictionary. Finally I'm sure there are accessibility issues. And don't forget right to left like Arabic. (https://www.flickr.com/photos/u-e/2680759761/)

UI in a game (the most common place to render a UI yourself) usually doesn't care about these things. I'd hazard a guess though that most apps do. I know I get really annoyed when I can't copy small pieces of text from a native app. For example copying a link to a browser, copying a phone number to my phone, copying an address to maps, etc.

In general DOM makes all of these just work.

[+] mjjohnston|11 years ago|reply
React Canvas author here. I outlined some of the reasons why it is not always the right answer: http://engineering.flipboard.com/2015/02/mobile-web/#Practic... On Flipboard we use DOM where appropriate for text input and areas of the application where performance is less critical.

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.

[+] WickyNilliams|11 years ago|reply
I'm glad someone else said this, you've echoed a lot of my thoughts. I'm a huge react fan, and I think this is super neat - once again showing the flexibility and power of React's component and render model. It'll probably have a big impact on game UI for the web.

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!

[+] diiiimaaaa|11 years ago|reply
... and you can't translate a page, you can't search on a page, you can't select or zoom images, you can't open link in the new tab.

Imho, making custom "DOM" via canvas just to make UI look fancy is not a solution. Web was always about delivering accessible content for everyone.

Though, library might be good for web apps or games that are not content oriented.

[+] peterhunt|11 years ago|reply
These are great points. It also breaks SEO and clipboard and ctrl-f.

With that said you could easily build a component library on top of this that renders to DOM or react-native or canvas or HTML (server-side) depending on what your use case is (just use dependency injection to get a reference to your underlying components). This way you can more easily manage these tradeoffs.

I think this project is so, so exciting and awesome.

[+] Nitramp|11 years ago|reply
The hardest part is actually layout managers, i.e. what happens if you want to support more than one pixel width. With all its clunkiness, CSS & DOM actually solve that.

edit: they actually have their own layout implementation(s). I wonder how those compare to the built in browser versions (performance, correctness, ...)?

https://github.com/Flipboard/react-canvas/blob/master/lib/La...

[+] bonn1|11 years ago|reply
Well said. We also experimented with non-DOM rendering, in particular with WebGL-sprites. We achieved very nice result running constantly at 60fps even on low-end mobiles but it's nothing worth if one doesn't have all the DOM amenities you mentioned or a full integration with the browser environment.
[+] sfjailbird|11 years ago|reply
Anything that needs text input is right out too. The DOM text input field hooks into a lot of native functions.

Unfortunately, that affects most games, which would otherwise be an obvious niche for something like this.

[+] ricardobeat|11 years ago|reply
Each of these features can be implemented on top of a canvas renderer. Not saying it's easy, but can be done. The browser itself does it, everything is 2D textures in the end.
[+] artursapek|11 years ago|reply
I'm building a complicated canvas app[1] for visualizing Bitcoin markets. I resorted to building my own framework on top of canvas, exactly for performance reasons. It's fast, but as a framework I was never too happy with it because it's a little half-baked.

More recently I found and fell in love with React for other frontend work, and use it exclusively now for any view-related work. I might have to go back and rewrite the ugliest parts of my code with this, it looks awesome. Kudos to Flipboard for open-sourcing it.

[1] https://cryptowat.ch

[+] nkohari|11 years ago|reply
Very cool app. I'm going to pass it around to friends who are more into cryptocurrencies than me. :)

Sorry to hijack this thread, but I have a question: you seem to have been successful in stopping left/right swipe from navigating back and forward. The app I'm working on supports horizontal scrolling, but it can be a bit confusing if you mean to scroll and accidentally navigate.

I've tried a few things and looked around for answers, but so far the solutions I've found haven't worked out. Can I ask what your secret is? :)

[+] snissn|11 years ago|reply
Looks awesome! Two quick questions:

1) Your site looks very similar to bitcoinwisdom ( which i love). Did that come about by coincidence or design? Are there any open source tools that you were able to build off of that bitcoinwisdom also uses?

2) Could you build out support for visualizing financial markets like stocks and the price of oil? The bitcoin ecosystem has a bunch of great UI, but it's difficult to find good web products for actual securities

[+] cnp|11 years ago|reply
I did the same a while back, which paired Backbone with Easel / Create.js for both interface and game elements. It worked ~ok~, but was never quite what I wanted and a lot of cleanup was still required in order to achieve solid performance.
[+] hamxiaoz|11 years ago|reply
Looks awesome! Can you share any architecture info? The frontend is built on d3+reactjs+jquery, how about the backend?
[+] danabramov|11 years ago|reply
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.

[+] karanbhangui|11 years ago|reply
Looking at the author, not surprising. I was an intern in Yahoo! Mobile's web team in 2009, and sat beside Michael Johnston. He was incredibly productive and talented, and was the backbone of the whole mobile team. Everyone came to him for advice. I remember he wrote a sophisticated color picker in an afternoon, and the code was a work of art.
[+] miguelrochefort|11 years ago|reply
Can you point out to what exactly is notable about this code? I don't see anything special.
[+] cnp|11 years ago|reply
Is it possible -- literally -- to write more clear code? Stunning implementation
[+] vowelless|11 years ago|reply
I have generally done systems and backend work, so usually C/C++/Go/Python. React is making me extremely excited to do some frontend work!

Is React a good introduction to the land of frontend programming? Or do I first need to familiarize myself with vanilla JS and go bottom up to React?

[+] vladev|11 years ago|reply
I actually wonder if it can be done even more elegant with RxJS?
[+] vidarh|11 years ago|reply
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.

[+] bsimpson|11 years ago|reply
Don't worry, there will be a new flag `document.useStricter` that will turn off all the cruft that makes the DOM slow so you don't need to patch around it with libraries. It'll become a Chrome experimental flag after the editor's draft is released in 2022.
[+] walterbell|11 years ago|reply
Does mobile browser DOM rendering use GPU hardware acceleration?
[+] dkarapetyan|11 years ago|reply
New job description for front-end web developers: 5+ years of designing game engines and optimizing rendering pipelines.

If the joke is lost please go read about the similarities between react and immediate mode rendering systems.

[+] JoshMilo|11 years ago|reply
Honest question, would studying immediate mode rendering systems improve my understanding of React's system of doing things? If so, do you have a resource I could use?
[+] angersock|11 years ago|reply
It is kind of interesting watching yet another round of retained-vs-immediate mode play out.
[+] peteorpeter|11 years ago|reply
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

[+] cpr|11 years ago|reply
React Native can be the core of your iOS/Androis runtime.
[+] arcticgeek|11 years ago|reply
It's funny to watch the world very slowly reinvent Adobe Flex.
[+] wallflower|11 years ago|reply
Flex was ahead of its time with Spark.

It was behind its times with mxmlc. mxmlc made it painfully clear, even with incremental compile, that you were building a client-server application in a web age.

Once you wanted to build custom UIs, you lost the "WYSIWYG" GUI rapid development environment that was the whole selling point that Adobe came in with.

The data synchronization system worked but it was opaque and how (at the time) they made their money.

Flex lost to the open web.

[+] ivanb|11 years ago|reply
Yes. It is funny to observe how engineers implement technology A by means of technology B and then go backwards and implement B through A. The spiral continues.
[+] tomaskafka|11 years ago|reply
Or WPF. React = WPF for web (and is still awesome).
[+] danabramov|11 years ago|reply
LOL, didn't expect it to work with React Hot Loader practically out of the box (except for <Text> for some reason): https://github.com/Flipboard/react-canvas/pull/3/files

The fun part is tweaking text layout algorithm and letting Hot Loader pick up changes when replacing components. Without browser refreshing, of course.

[+] amelius|11 years ago|reply
Last time I checked, measuring font sizes using the canvas was horribly slow. So, I wonder how they perform measurements necessary for automatic line-wrapping, et cetera. Are they doing these measurements fully in javascript?

> Custom fonts are not currently supported but will be added in a future version.

Ok, that is a pity. I wonder if it has something to do with the complexity of implementing measureText fully in javascript.

[+] mjjohnston|11 years ago|reply
Custom fonts are supported on flipboard.com using the same rendering engine. It was just a matter of time to extract the Flipboard specific bits out. This is coming soon.
[+] drhayes9|11 years ago|reply
What are the accessibility implications of drawing all controls of a web app to the canvas using React? Are there ARIA annotations available for React already?
[+] marknadal|11 years ago|reply
holy flipboard, did you see they re-implemented a subset of CSS into JS? https://github.com/facebook/css-layout I was literally thinking about doing something similar the other day for an experimental/learning project.

React is taking over the web, and I'm excited for it - coming from a person who is incredibly cynical about frameworks. React is proving itself as a powerful library, not an assumption driven framework.

[+] aaronyo|11 years ago|reply
Big fan of React. For others using it, why use JSX instead of just doing everything in js?

In other words, why is HTML like this:

  <Group style={styles.group}>
          <Image style={styles.image} src='http://...' />
          <Text style={styles.text}>
            Lorem ipsum...
          </Text>
        </Group>
Preferable to something like this (which can easily be done with some helper methods wrapping the verbose React DOM methods):

  $group({styles: style.group},
    $image({styles: image, src: 'http://...'}),
    $text({styles: style.text},
       'Lorem ipsum...'));
No pre processing step required, and of course it's natural to imbed js in, er..., js.

What am I missing? Why keep the HTML part in all this?

[+] mmgutz|11 years ago|reply
Is it me or are these React frameworks heading towards the ideas in XAML and MXML?
[+] philnash|11 years ago|reply
Out of the box browser features that have been removed/destroyed by the quest for 60fps:

* Copy/paste (holding on an article gives the options to email or report)

* Pinch to zoom

* Double tap to zoom (opens links instead)

* iOS swipe forwards and backwards (renders the page swipe animation twice, at 60fps I guess)

* iOS Reader View (go on, try it, I laughed)

And most importantly

* Any sort of accessibility

60fps doesn't matter to someone who can't see the screen.

60fps doesn't matter to someone who relies on assistive technologies to surf the web.

60fps doesn't really matter.

[+] polskibus|11 years ago|reply
This is a great project indeed. However, as many here have already pointed out, there are many limitations to this approach, SEO and lack of ctrl+f for example.

Which reminds me of flash. Most flash controls had similar drawbacks. I think web development shouldn't repeat that mistake (again).

It also reminds me that Google Docs took similar approach. As far as I remember they use a lot of canvas with a bit of DOM intertwined where necessary.

[+] devongovett|11 years ago|reply
This is great. Can't wait for the WebGL version ;-)

Also, it would be really cool to run everything except rendering in a worker thread and send rendering commands to the UI thread, like react-native does.

[+] cnp|11 years ago|reply
My god this is so fucking awesome! Great work guys and gals. Shows precisely what a good, wide-ranging idea means in practice.
[+] efields|11 years ago|reply
I'm guessing http://flipboard.com/explore should be a good demo (in mobile safari, upper-right link off the home page), but it's just infinitely loading for me.

Posting b/c someone from Flipboard is probably monitoring this thread ;-)

[+] abm91|11 years ago|reply
Fix pushed ;-)
[+] megaman821|11 years ago|reply
This looks really neat. How does this compare to Famo.us, which also claims at have smooth animations at 60 fps?
[+] ZenoArrow|11 years ago|reply
Looks really good. My only real question would be about something drab but practical: SEO.

As the components are rendered to canvas, would the metadata that usually feeds SEO be harder to generate? Is that something you could fix through use of the parallel DOM (it's mentioned briefly on the page)?