[arasmussen]

The point of React Native isn't to create a delightful product experience.

The point is to create the equivalent experience of a native app with a delightful development and organizational experience.

- Instead of having separate teams develop your iOS, Android, and now OS X apps, one product team can make all three and share the majority of the code.

- Instead of a slow frustrating compile cycle you get live reloading.

[mbrock]

I could write a Lovecraftian short story about my experience with React Native. Trying to turn a web app into a delightful React Native app nearly sank me into depression & burnout.

[Edited to clarify that of course I can't blame my mental health problems on a UI framework... but I keep the formulation for the sake of sympathy with anyone else who may feel less than "delightful."]

It was pretty cool at first, after a couple of months of trying to get the thing working decently without crashing, lagging, or just sucking, I gave up on the whole project.

I don't doubt that many people use React Native with delight. But there are aspects of it that are likely to cause frustration. It's a mashup of two incommensurable platforms, and in the gap between them there is horror.

[neoeldex]

You do realize that React itself is only 3 years old. React native is even only about a year old.

What expectation do you have when deciding to use a framework which hasn't even released it's 1.0 yet.

[mbrock]

Yeah, of course. Well, I was hopeful, based on the glowing copy and what I had heard.

[st3v3r]

Then why the hell has it been released already?

[switch007]

So you're supposed to explain to your boss that the poor user experience is due to you picking something that was easier to develop with?

[coldtea]

You understand that in realistic professional scenarios it's rather the boss (especially a technical boss), that will dictate that it's ok to have something easier to develop with.

Poor user experience doesn't mean much if you are not on the market soon enough.

Which should be obvious on HN, and it's a point PG himself has iterated several times...

[OldSchoolJohnny]

There are a lot of devs on here with little to no real world experience or not enough to make sound judgements as far as I can tell anyway. I'm not sure if it's better to enlighten them or to ignore them since they are the sort of people that are willing to post their baseless opinions for the world to see.

[st3v3r]

"Poor user experience doesn't mean much if you are not on the market soon enough."

90% of the time this doesn't apply. The "need it done last week" attitude is mostly undeserved.

[coldtea]

For enterprise projects, yes. For startups competing for eyeballs, it's quite important.

[st3v3r]

Again, I don't believe that. A month? Sure. A week? No.

[hrktb]

TBH this kind of solution is more often pushed by bosses than devs.

Any management person will throw in a "you've done X on this platform, why don't you try to reuse most of your stuff on this other platform ?", just in case it's actually doable.

[gurkendoktor]

In my experience as a mobile app freelancer, many prospective clients(=bosses) insist on portable/JavaScript frameworks for new projects. I guess it is because native iOS/Android programmers are expensive, and a single JavaScript programmer rotating between platforms with a shared codebase is both cheaper and easier to manage than two or more native app programmers (at least in theory).

[bobwaycott]

I feel bad for you if you've met such bosses. As one, and as someone who has worked under several, I've never once experienced a boss knowing or saying such things. I've only ever seen it come from developers.

Edit: Just to clarify, there may be instances where a mgmt type has asked if X on platform Y can be reused on platform Z easily. I've never seen it go beyond the ask.

[kcole16]

React Native doesn't deliver a poor user experience though. It's not the right choice for every project, but in most cases users won't be able to discern between RN and native.

[Ambroos]

On iOS maybe, but not on Android. You have to reimplement a lot of the things you get for free when developing native apps yourself. Most animations etc, you all have to add it yourself. Problem with that is that the React Native team has some decent iOS stuff, but for Android it's all sorely lacking.

Besides Facebook's Ad Manager (which barely cuts it) I haven't seen any React Native app on Android that didn't feel horrible (and not like an Android app).

[briandear]

Does the Facebook app use React "Native'? Because that app is a horrible power hog and vastly glitchy and buggy. That is a poor user experience compared to what a well written native iOS app could deliver. Users might not know its a poor experience because that can't compare to how fast and responsive the app would be if it were actually written in Swift.

There are people in this world that think Olive Garden is great Italian food. There are people in this world that think React "Native' is a good user experience.

Why does Facebook absolutely insist on avoiding writing actual native apps? As in Swift for example. It seems like they are almost allergic to actual native and instead focus on this inferior cross platform stuff.

In 'most cases' users won't know the difference? sure they will; they'll notice that the app they're using sucks more than other apps on their phone. They'll tolerate the glichiness, the occasional blank data screen during a load because they care about the content more than the terrible experience. All because a developer or the CTO somehow thinks "it works well enough" is the same as "let's really give our users the best possible experience." I am amazed that Facebook has thousands of employees but can't be bothered to write a single line of code in Swift. They've been insisting on this stubborn course of action since the beginning of their mobile experience. Does Zuckerberg just hate Obj C or Swift? Why are they making the mobile experience into the lowest common denominator? Why does their Facebook app feel like some cheap PhoneGap experiment? My Facebook app on iOS performs exactly the same as it does on a years-old Android phone.. And that's ridiculous. I have superior hardware and yet I get to run an inferior app because JavaScript? It's like socialism for apps: make everyone equally miserable.

The simple fact is this: I hate cross platform systems because they end up averaging the quantity of the mobile experience with capabilities being reduced to support the lowest common denominator. If I want my apps to run as terrible as many do on Android, I will use an Android. It's lazy development. It's a means for the JavaScript crowd to avoid leaning Swift (or Java) so they can provide middling to bad mobile apps rather than actually building the absolute highest quality product they could build.

Even Facebook does it! I feel like the React Native ecosystem is doing more to reduce the quality of the mobile app experience than anything else. Apps are being turned into these average pieces of crap with only the UI being slightly different. Does anyone have any performance benchmarks on a React "Native" compared to Swift? Any data at all? Or are we just so excited to write apps in React that we fail to care? If we care about 'cross platform' development -- we can already do that; it's called 'the web.' Let stop foisting inferior mobile apps on people just because we can.

[zelos]

The Facebook app doesn't use React Native[1]. It used to be HTML5 but they rewrote it mostly native[2]

[1] https://facebook.github.io/react-native/showcase.html [2] https://www.facebook.com/notes/facebook-engineering/under-th...

[arasmussen]

There are definitely parts of the Facebook app built in React Native. I built some of them. :)

[zelos]

Interesting - is there an intention to rewrite the whole thing gradually and move away from native? Any reason it's not listed on the React Native site?

[code-antagonist]

The Facebook app for iOS is actually mostly Objective-C [1] / Objective-C++. [2]

[1] http://quellish.tumblr.com/post/126712999812/how-on-earth-th... [2] http://componentkit.org/

[pcwalton]

JavaScript is faster in most cases than Objective-C.

(I'm not going to dispute that cross-platform toolkits can have less native fidelity than compared to coding to the native toolkit can. I just don't like the Objective-C vs. JavaScript performance myth.)

[robenkleene]

Huh? What's the Objective-C vs. JavaScript performance myth?

Here's a link showing Objective-C beating JavaScript handily: https://medium.com/@harrycheung/mobile-app-performance-redux...

But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?

[pcwalton]

That's an interesting benchmark, and I'd need to dive into the details to see what is going on. Perhaps there is some sort of JIT slow path. I would not expect method-heavy Objective-C to beat JavaScript. In general:

> But is this even a debate? Wouldn't you expect a compiled, manual memory managed, language to be faster than an interpreted language with garbage collection?

Objective-C is not compiled in terms of method dispatch, nor it is manually memory managed. Instead, all method dispatch happens through essentially interned string lookup at runtime, backed by a cache. Objective-C also has a slow garbage collector--atomic reference counting for all objects. (Hans Boehm has some well-known numbers showing how slow this is compared to any tracing GC, much less a good generational tracing GC like all non-Safari browsers have.)

The method lookup issue has massive consequences for optimization. Because JavaScript has a JIT, polymorphic inline caching is feasible, whereas in Objective-C it is not. It's been well known in Smalltalk research since the '80s that inline caching is essentially the only way to make dynamic method lookup acceptably fast. Moreover, JavaScript has the advantage of speculative optimization: when a particular method target has been observed, the JIT can perform speculative inlining and recompile the function. Inlining is key to all sorts of optimizations, because it converts intraprocedural optimizations to interprocedural optimizations. It can easily make 2x-10x of a difference or more in performance. This route is completely closed off to Objective-C (unless the programmer manually does imp caching or whatnot), because the compiler cannot see through method lookups.

Apple engineers know this, which is why Swift backed off to a more C++-like model for vtable dispatch and has aggressive devirtualization optimizations built on top of this model implemented in swiftc. This effort effectively makes iOS's native language catch up to what JavaScript JITs can already do through speculation.

[randommodnar]

Actually JavaScript is compiled JIT by most engines these days. While it's not the fastest, it certainly can be quite fast.

[w0utert]

Source please, because unless you have anything to back this up, your claim can only be considered grade-A FUD.

Sometimes I feel like using JavaScript too much transports people to some kind of imaginary JavaScript fairy land full of rainbows and unicorns. I read the craziest things about JavaScript development even though I can't comprehend why so many people believe it has any redeeming positive qualities over other languages, besides ubiquity.

[pcwalton]

See my reply to the sibling comment for the explanation. There haven't been enough cross-language benchmarks here to say definitively, but as a compiler developer I can tell you the method lookup issue is really fundamental and in fact is most of the reason for Swift's (eventual) performance advantage over Objective-C.

[st3v3r]

No, it's not.

[the_gipsy]

I've seen cordova/phonegap being used as a MVP. Then slowly some screens got rewritten in their native platforms, starting with the most critical ones.

All by manager's and client's decision. It was a horrible experience overall.

[bmelton]

Exactly. Except, the time to do it is before you decide on a tool, when the company is comparing time to value vs. quality.

Whether or not the experience is great isn't a deal-breaker, it's a factor in the decision making process. For plenty of companies out there, having a less-than-perfect application that they can deploy to many platforms in a month or two with a single or couple of developers is a choice that might get made, when the alternatives are either much longer timetables or many more dollars.

[cballard]

Using a language in which 1 + "1" == "11" instead of one of the best type and null-safe languages to be developed in the past few years is not exactly my idea of a delightful experience, but interface as a pure function of state is a good idea.

[briandear]

So degrade the experience just to make the product team happy? What product team worth a darn would actually be ok with that?

Did we forget the customer somewhere? What ever happened to trying to wow your customers rather than simply tolerating them?

This attitude makes me crazy angry. That one comment just revealed everything that's wrong with many product companies: just give the user a 'good enough' experience. If you aren't striving to create a delightful user experience than you're disrespecting your users. Laziness.

If Steve Jobs had heard you say that, he would have fired you in an instant -- and for good reason. We owe our users a delightful experience, giving them anything less is just unacceptable.

[jon-wood]

A product team with limited time and money. We'd all love to have best in class apps on every platform, but there's only so many hours in the day, and only so many developers on the team. At some point we have to make tradeoffs, and sometimes the right one is to deliver something imperfect now rather than perfection later.

[arasmussen]

> So degrade the experience just to make the product team happy?

Which part of "equivalent" did you miss?

You're entirely missing the point. This isn't about product experiences whatsoever. You can ship equivalently delightful experiences in React Native as you can in pure native apps. The point of React Native isn't to make your app more delightful.

The point is to develop it faster, in a more enjoyable manner, and enable one product team to develop for multiple platforms. This is an incredible win organizationally and for developer experience.

> Steve Jobs would have me fired

Check your ego.

[st3v3r]

If the product team isn't happy, then the product isn't getting made. If the product team gets burnt out halfway through development, it shows.

[rimantas]

And the result is they share the majority of the code and do not share the gazillion of tweaks for each plafrom, thus negating any advantage gained?