Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flipboard releases React Canvas

github.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Flipboard releases React Canvas

#101

Post by Touche »

shadowmint wrote: post #94
Touche wrote: post #93

Earlier quoted context omitted.

> 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 an…

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

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.

Re: Flipboard releases React Canvas

#102

Post by shadowmint »

Touche wrote: post #101
shadowmint wrote: post #94

Earlier quoted context omitted.

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

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.

Re: Flipboard releases React Canvas

#104

Post by wallflower »

arcticgeek wrote: post #98

It's funny to watch the world very slowly reinvent Adobe Flex.

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.

Re: Flipboard releases React Canvas

#105

Post by dilap »

shadowmint wrote: post #94
Touche wrote: post #93

Earlier quoted context omitted.

> 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 an…

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

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.

Re: Flipboard releases React Canvas

#107

Post by aaronyo »

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:

  
          
          
            Lorem ipsum...
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?

Re: Flipboard releases React Canvas

#109

Post by iLoch »

aaronyo wrote: post #107

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: Lorem ipsum... 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 requ…

For me, I find it much easier to get an understanding of the structure of the components by looking at hierarchical markup vs. plain old JS. Everyone has a different idea of how they want to lay out their JS, but most people know/agree on what XML should look like.

Re: Flipboard releases React Canvas

#110

Post by greggman »

mjjohnston wrote: post #79
greggman wrote: post #52

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"…

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

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?

Post reply on HN