Hacker News Reader

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.

Please don't take this wrong. I think what you're doing is great. I like perf too. I'm just kind of thinking outloud.

For example copy/paste and "define" require you to support selecting text on your canvas and then telling the OS about it when the user picks "copy" or "define". Otherwise you get the bad behavior that 99.99% of all native apps have which is that they don't support selecting anything except in editable textareas so if they display an address I can't copy it into maps.

You could argue the browser should add APIs so you can provide what the user has selected to the OS but, it means every developer has to be perfect. Developers who get it wrong end up making apps that don't follow any OS conventions, don't handle the edge cases, don't handle things when running in other languages, etc etc etc.

To take it to an extreme, maybe the browser should just be a rectangle of pixels and JavaScript. No DOM whatsoever. Imagine we had that world. There'd be no search engines and every page would have a totally unique UI. Some pages you'd use the keyboard to move a cursor to select something. Others would use the mouse. Still others might use a joystick. Some would require IJKL instead of the cursor keys. None of them would have native OS widgets. They'd all use a different font system. Most would probably only support ASCII and maybe ANSI at best.

Instead we have HTML and a DOM and most of these issues are solved and that uniformity has some arguable benefits.

I'm not saying stop your work. I'm just saying I'm there are trade offs. I think an argument can be made either way. Maybe rather than going back to a rect of pixels we should also be lobbying for ways to make the DOM better so we can keep the good parts (universality?) and still do better?

Understood. We just happened to have unconventional constraints that suggested an unconventional solution. There are many ways to lobby for improvements for things (especially Web standards) and perhaps with us showing the limitations of the DOM, we can influence change for the better.

By the way, you’re re-defining Flash but with a canvas and JS :)

For accessibility you can look into what pdf.js does. They put a transparent text on-top of the pdf text (canvas). So you can select it. Pretty clever :)

That's what I was thinking too.

Worth some extra html and style code for those benefits.

Hey, just wanted to say thanks for working on and open sourcing this project. It's amazing!

> 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.

I agree, and I think you are actually doing this in a way that can work (unlike some other attempts in this space).

> 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.

I think this is a really cool project and a technical achievement, but I disagree with this one statement. We don't actually need to "achieve the kinds of experiences". This is my biggest problem with designers I've encountered, they do not see the benefits of the platform and try to design everything the same way. The web has distinct advantages that makes it special and I think way too much effort is put into making it behave like native applications (trying to catch up to its benefits rather than leaning on the web's).

You're entirely on point. This loses touch with the platform; one wouldn't use Material design in an iOS app and expect as much success as a more native experience, and vice versa; the same works for the web. It's a different platform with different goals and expectations.

Also, hey everyone, before you downvote the parent, please recall this article that you voted so highly just a few weeks ago, and consider its implications on building a web ui on top of canvas: https://news.ycombinator.com/item?id=8965048

...but apps are better, and people like them.

Thats bad for the web ecosystem in general. We want the web to be the place people go for content instead of native walled gardens.

Great user experiences make that happen.

Rubbish user experiences that look and feel like a lame 2nd cousin to native apps actively harm the web ecosystem (look at mobile facebook; lots of people just use the app and dont even use the browser on their phone)

A lot of the web's wounds are self-inflicted.

I know I usually prefer apps to the web not because of lack of fancy graphical effects at 60 FPS, but because web pages are so larded up w/ ads and other crap, it's hard to actually read the content. Or they try to do tricky things which somehow break on an iPhone's screen. Etc.

I absolutely disagree with you. Do you know what app was a huge hit in 1999? Yahoo Mail. I probably don't need to tell you what the "user experience" was like on Yahoo Mail in 1999 vs. Eudora and other popular desktop mail clients.

The web's benefits are that powerful.

No, I'm talking about now, not 15 years ago.

The difference was that then there was a meaningful functional difference between a cloud app and a local desktop app. Cloud apps were better, and people appreciated that.

I'm not convinced that web apps, which have worse UI, not access to native apis (camera, notifications, contacts, etc) offer a meaningful benefit over native apps.

You use mail.google.com on your phone? I don't.

How about Twitter? Facebook? Instagram? App or website?

It's because the native app is better.

The web is not special, it just happens to exist. If you keep building experiences for it that are meaningfully less functional than native apps, people will continue to flock to native apps.

sure... it's not all about hitting 60fps animations on a web app; but web apps that are closer to the look and feel of native apps is the way forward if you're building for the web.

apps are the dominant paradigm on phones and tablets because the web experience on touch only devices with tiny screens was terrible when phones and tablets took off. the web experience has improved but still lags behind because the investment in native apps far outstrips the investment in making webapps better on mobile

trying to emulate native apps in the browser is the same losing battle, but the inverse. good luck with canvas

Do you think there is any chance we go back to the web in a few years, and native apps are replaced by links on the phone's home screen?

Do you think it'd work well to use your <text> component as the start of a canvas-based text editor?

No, if you want native applications experience, make native applications. Now you are just breaking the web.

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!

... 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.

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, ...)?

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

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?

Yes, but it's hard to do your own layout on the web because in times that want to width of an element that has text with `flex: 0`, you can't do that. It's mainly useful for things like this where you control everything.

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.

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.

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.