Flipboard Engineering

You can! The problem in that case is it's not a convolution (blur) per se. Each pixel is an average of subpixels P(1)=S1(1)+S2(1)+...+Sn(1), P(2)=S1(2)+...+Sn(2) -- but as you can see there are no elements in common between pixels, which is the case with convolution. That is, in the deconvolution case there are as many variables as unknowns, whereas in the upscaling case you're creating unknowns out of a single variable.

To estimate those subpixels then you're going to be forced to make additional assumptions; if you assume they are independent you would simply estimate Sk(j)=P(j). The traditional (easiest) assumption is that the image is somewhat "bandlimited" -- it does not have many variations (frequencies) faster than once per pixel (so no equal or faster than subpixel variation). If this were the case, you could reconstruct the subpixels perfectly [1], save for some noise. But this is not always the case (and fails spectacularly when you have edges), resulting in upscale blur. So simple linear upscaling algorithms by reaching a compromise between blur and edge enhancing.

If you want to do better though, you have to use non-linear kernels and have good underlying models for your image content. A promising approach is to use machine learning/NNs: http://engineering.flipboard.com/2015/05/scaling-convnets/

[1] https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

Agreed -- squeezing these native app elements into the document-based paradigm of the web is a horrid, Frankenstein's monster of an idea. It's like doing app development in Excel.

If native web apps are to be more of a universal thing, I believe there ought to be a blank-canvas "meta-browser" layer that sits above the browser and that all web apps (including today's browsers) are built on top of. Basically a lightweight, sandboxed pseudo-OS that offers a robust standard library, a URL scheme and easy networking support, some sort of bytecode, maybe a UI toolkit, etc. Web apps would still take up the same amount of space and would still be able to run without installing, but they would now be endowed with native performance, app-specific features, and a consistent, functional UI. (Quiz: how often do your back/forward buttons fail when using, for example, your bank's website? The fact that these two ubiquitous controls simply break the web more often than not should be telling.)

Shoehorning all that stuff into a hyperlinked, navigable document browser is insanity, and you can always feel it unless your web-app has basically reimplemented the DOM from scratch[1]. The web is currently layered upside-down and I think web apps won't lose their reputation until this is fixed.

[1]: http://engineering.flipboard.com/2015/02/mobile-web

The most important thing about React's update performance is that it's ~O(n) of the size of the virtual dom. If React's performance is a problem you can window the input data, do things more efficiently in your render, tweak shouldComponentUpdate. The goal isn't to be as fast as possible but rather to be fast enough and for non-mobile you can hit that target with only the occasional tweak. For mobile, you can get as exciting as you like[1] but I've never had to go beyond the above steps.

[1] http://engineering.flipboard.com/2015/02/mobile-web/

You can build things that are faster than React in benchmarks. Pretty much every vdom based library/framework/language is faster than React in benchmarks and absolute performance has never been a stated goal of the project. The framework does help you out in ways that don't show up on benchmarks like this. An example would be batching DOM updates, which is much harder when you have components mucking around directly with their internal set of nodes.

I also favor using an immutable data tree with a corresponding shouldComponentUpdate and only rendering on rAF but those force architectural decisions on the project.

I tried submitting a reddit thread (https://www.reddit.com/r/reactjs/comments/474odi/what_about_reactcanvas/), but it didn't get much traction... I think because the videos got pulled. I hope you guys don't mind if I ask this question here, and I apologize if I'm being naive in some way:

Aditya Punjani's later Flipkart talk (https://youtu.be/m2tvYGCdOzs) mentioned the importance of mobile web apps and 60 FPS.

Ben Alpert's talk mentioned (https://youtu.be/-RJf2jYzs8A?t=1378) "React Native for the web" would be awesome.

There was even a lightning talk on react-native-web which attempts to do this using the traditional DOM (https://www.youtube.com/watch?v=RBg2_uQE4KM)

Whatever happened to Flipboard's React Canvas (http://engineering.flipboard.com/2015/02/mobile-web/ and https://github.com/Flipboard/react-canvas) being a solution to these problems? There's pretty good browser availability and although there's currently no perfect solutions for things like accessibility, SEO, or server-side rendering... I failed to se a real "nail in the coffin". Did it just never gather enough momentum?

Having worked on what I would classify as a very large and complicated mobile/desktop web app for a few years now, I would probably choose a different direction if I had access to enough developers.

I'm fairly convinced at this point that with enough developers, the best approach is adaptive if you plan on building a web app with considerable complexity. Completely isolated development, fully custom design and code for mobile.

With an adaptive site you have the choice to include or exclude elements which may have a major performance impact on the app, including for instance: entire view/component trees, media queries, heavy JS like graphs or ads. You also get to make web-unfriendly decisions like using a custom renderer if you think it will produce a higher quality experience, like Flipboard's React Canvas from several years ago: https://engineering.flipboard.com/2015/02/mobile-web

Overall it's still very context dependent, but I would recommend for larger teams to not completely discount adaptive mobile sites if they're looking to build the highest quality mobile experiences.

React (outside of React Native) is being used on many high traffic websites.

- Facebook comments, chat, search, ads creation, photo upload, tablet website... and basically every new product being written.

- Entire Instagram website

- Yahoo Mail: http://yahooeng.tumblr.com/post/101682875656/evolving-yahoo-mail

- A lot of the Khan Academy front-end: http://khan.github.io/react-components/

- Netflix website and TV experiences: http://conf.reactjs.com/schedule.html#beyond-the-dom-how-netflix-plans-to-enhance-your-television-experience

- Many Airbnb new products: http://www.slideshare.net/spikebrehm/the-evolution-of-airbnbs-frontend

- Flipboard mobile website: http://engineering.flipboard.com/2015/02/mobile-web/

- ...