Hacker News Reader

Comment by bobajeff | Hacker News Reader

I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default.

I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.

View on HN

> Web Workers being crippled

As Tom said, you can't do layout or prerendering-to-bitmap in a web worker: there's no DOM or Canvas API unless you bring your own, and despite Emscripten it's foolhardy to bring your own. If you want to decode a JPEG, you have to do that on the main thread and pass it to the worker right now (except in Firefox with its nonstandard ImageData API). [0] Which brings us back to square one.

> no one ever comes close to native widgets

I think a lot of that has to do with the fact that the iOS UIKit internal code for animations is closed source - the best anyone can do is reverse engineer, move their thumb and see how things react. What are the Bezier points on the curve used for the fade when you "back-swipe" from the left of the screen? Good luck figuring that out - it's possible, but only barely. Tom hinted at the idea that if developers were better organized, they might be able to replicate things better, but it would still be an uphill battle.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...

Since you are in native you could decode in native in a different thread and pass the decoded data into the Webview, but not sure if thats really better since you would still have to create an image object from the raw bitmap data.

The curves used in iOS are all pretty standard, they're easily to replicate if you want.

It's pretty easily to replicate iOS functionality in iOS itself just because it's a better environment, it's not the 'secret' numbers.

But if taking the example of Paper, it's built on top of Pop which is absolutely open source and handles all the animations: https://github.com/facebook/pop.

So in theory you should be able to replicate all this stuff on the web, but you can't because it's just not build with highly responsive UI in as the focus.

You should help me do this! I have physics / spring based animations in my todo for a React hybrid app platform I'm working to launch now.

There's quite a bit of hyperbole in this talk. Some web apps do in fact come close to native, but to the trained eye of a Facebook software engineer it will feel miles behind. Your average Joe doesn't give a shit, as long as they can use the app. If they did, Facebook's Paper wouldn't have been such a flop.

This is absolutely a great point, and honestly, I used this exact argument early on in the development of React Native to convince folks that cared a ton about craft and were super worried about performance, that it's more important to make sure you have a reliable application that adds value to peoples' lives, before you even earn the right to start thinking about craft.

My phrasing was somewhat hyperbolic, but I basically said: "Do you honestly think that a person, in the middle of a natural disaster, trying to determine whether or not their family and friends are okay, gives a sh about 60fps animations?"

The real value of React Native is that it allows engineers who know React (and React is really, really easy to learn btw), to build great feeling applications without putting in a ton of effort. Sure, it's possible to get close enough on web, but it's really, really hard to do so.

One of the things we tout in product infrastructure at Facebook is that when building frameworks, you need to enable engineers to fall into the "pit of success". The asynchronous nature of this implementation allows application logic to be run off the main thread by default, which we think is a huge advantage over a traditional web model.

The best part of React Native, if it can deliver on its promises, is that it will provide web developers with a toolset they can use that will satisfy customers or product managers who demand perfect native experiences (whether or not it makes business sense to demand it).

I think the poor reviews of Facebook's HTML5 mobile app shook the company to the core and they swung a bit far in the other direction, abandoning the possibility that the web will ever be mobile ready. I think the truth lies somewhere in the middle; no, you can't get native performance from the web, but you can get close. And every year it gets a little closer because phones are getting ridiculously powerful.

All this said, I think Facebook's approach to the platform fragmentation problem is clever and worth checking out, but I'd still bet on HTML5 over the long term.

Don't underestimate the users. They might use different words, but their comments and ratings will tell the story of web/hybrid suffering. Unfortunately web is not meant for apps, but for interactive documents.

Don't overestimate users either. It's very easy to build for other geeks rather than the General public. Netflix apps are almost all built using web technologies and it doesn't seem to bother most users. I think there's been an overemphasis on pixel perfect UI and on UX in general but people don't want nice UI's, they want useful apps.

For Netflix, the interface can only get in the way. People are there to watch movies and that's basically it. You can't "nail" the interface like you can with applications you interact with more.

It feels like there is a bias against web based apps in general because I usually have a bad experience with them or stop using an application when I get annoyed with the user experience. I'm sure it's possible to create a good user experience with a non-native toolkit. It just seems like the people that really give a damn go native in order to offer a better experience.

> For Netflix, the interface can only get in the way.

I would argue that for most apps, the interface can only get in the way - Facebook included.

Indeed. If I look at Slack which I believe is actually a wrapped HTML5 on iOS + Android it looks already very good.

But it doesn't have a lot of gestures+animations+images, so that might be the difference.

I don't think Slack is a HTML5 app, at least on Android. The apk contains ~2.5MB of bytecode and half a meg of layouts.

Wow. Indeed. thanks! I really thought that they were HTML5 based on how similar the HTML5 version is compared to the Android experience. Thanks again!

I think Slack is partially HTML5 and partially native on mobile.

iOS version is also a native app. As they look almost identical to web version, lots of people assume it's HTML5.

I've already asked them this question. Slack is native.

The desktop app is HTML5

with gpu-accelerated css transitions, requestAnimationFrame, virtual dom and web workers, the experience can be damn close. he makes it seem like "no comparison", this is provably false at least for the apps he demoed. for games, native is still necessary. what react offers beyond performance though, is definitely awesome.

imo, the talk comes off a bit like a sales pitch at a pep rally.

I don't know - but given Facebook's past with WebView on their flagship app I feel they would be best qualified to say whether or not those solutions once fully implemented are satisfactory.

It could be the case that the features you mentioned are suitable today for web applications targeting the latest iPhone on browsers on the latest standards, but not when React was first developed.

You're absolutely right that it is possible to get close. I think my main point here, (though I probably didn't cover this well enough and I was being somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the default on web, and it's actually really, really hard to get there.

Sorry for coming across as a sales person. Someone tweeted about a previous presentation of mine in the past asking "who the hell is this marketing guy they had do this talk". I assure you I'm not in either marketing, or sales, I just get really excited sometimes.

I thought the talk had a nice balance of pitching the idea of native React and the technical ideas behind it.

You're right that it's possible to get really, really close, but the effort required is very large and best avoided if possible. Not to mention, there will always be subtle differences between your UX and native, and it sucks to be in a position where you have to defend that difference to, say, your CEO who's asking why "it just feels different." Or worse, he can put his finger on exactly why it feels different and it's some tiny glitch that's out of your control but ruins the "polish" of the app in his opinion. It puts you in the position of either busting your ass to achieve the impossible or defending mediocrity.

It also sucks to explain to your CEO why it's taken so long to develop multiple versions of the apps. Theres tradeoffs for everything..

Do you have any examples of apps that come damn close ?

not full apps, but some demos off the top of my head:

http://tympanus.net/Development/SidebarTransitions/

http://tympanus.net/Tutorials/CaptionHoverEffects/index.html

i think his answer was that all the magic numbers and heuristics that make the physics and animations and whatnot feel perfectly native are black boxes. if you want to make a "native" iOS/Android experience on the mobile web, you literally need to guess about all of those things -- and it'll always feel a bit off. probably a corollary of the uncanny valley

Isn't that exactly what Famo.us did, http://vimeo.com/86664858 .

Things are still being figured out. There are lots of experiments to make layouts render faster and motions more fluid; Virtual DOMs, JavasScript layout managers, canvas, WebGL, GPU accelerated CSS transforms.

I'm pretty sure an app like Paper is possible using web technologies (if you only support the latest browsers). I don't even see why they bring Paper as an example since I think the app is pretty shit UX wise.

Reply on news.ycombinator.com