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.
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.
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.
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!
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.
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, ...)?
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.
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.
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.
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? :)
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
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.
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.
It's worth mentioning that much of the code that integrates with React internals is based on the work in react-art: https://github.com/reactjs/react-art
This is the same technique used by Netflix for their React-based television UI.
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.
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.
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?
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.
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.
The fun part is tweaking text layout algorithm and letting Hot Loader pick up changes when replacing components. Without browser refreshing, of course.
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.
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.
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?
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.
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.
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.
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 ;-)
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)?
[+] [-] greggman|11 years ago|reply
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
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
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
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
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
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
[+] [-] sfjailbird|11 years ago|reply
Unfortunately, that affects most games, which would otherwise be an obvious niche for something like this.
[+] [-] ricardobeat|11 years ago|reply
[+] [-] artursapek|11 years ago|reply
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
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
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
[+] [-] hamxiaoz|11 years ago|reply
[+] [-] danabramov|11 years ago|reply
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
[+] [-] mjjohnston|11 years ago|reply
This is the same technique used by Netflix for their React-based television UI.
https://www.youtube.com/watch?v=eNC0mRYGWgc
[+] [-] miguelrochefort|11 years ago|reply
[+] [-] cnp|11 years ago|reply
[+] [-] vowelless|11 years ago|reply
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
[+] [-] vidarh|11 years ago|reply
It looks like amazing work, but it's quite depressing that it's necessary.
[+] [-] bsimpson|11 years ago|reply
[+] [-] walterbell|11 years ago|reply
[+] [-] dkarapetyan|11 years ago|reply
If the joke is lost please go read about the similarities between react and immediate mode rendering systems.
[+] [-] JoshMilo|11 years ago|reply
[+] [-] angersock|11 years ago|reply
[+] [-] peteorpeter|11 years ago|reply
- 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
[+] [-] arcticgeek|11 years ago|reply
[+] [-] wallflower|11 years ago|reply
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
[+] [-] tomaskafka|11 years ago|reply
[+] [-] danabramov|11 years ago|reply
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
> 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
[+] [-] drhayes9|11 years ago|reply
[+] [-] marknadal|11 years ago|reply
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
In other words, why is HTML like this:
Preferable to something like this (which can easily be done with some helper methods wrapping the verbose React DOM methods): 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
[+] [-] philnash|11 years ago|reply
* 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
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
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
[+] [-] efields|11 years ago|reply
Posting b/c someone from Flipboard is probably monitoring this thread ;-)
[+] [-] abm91|11 years ago|reply
[+] [-] megaman821|11 years ago|reply
[+] [-] ZenoArrow|11 years ago|reply
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)?
[+] [-] danabramov|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]