I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively.
This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly.
As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough.
I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.
"React Native uses a JavaScript runtime, but the UI is not HTML and it doesn't use a WebView. You use JSX and React Native specific components to define the UI."
"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."
This is an important point to note as a lot of the problems associated with hybrid apps in the past come down to them being based on WebViews.
The GP implies that the only reason a company would go with React Native is to make life easier for it's dev's at the expense of performance. That's clearly not true and I believe the GP knows it.
If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement, growth and advertisement numbers every quarter. Choosing a technology that hurts those numbers would be a poor decision.
Performance doesn't come for free it often comes at the cost of stability and slower time to market. In the case of React Native versus having separate Native teams it also comes at the cost of synchronizing different product teams and dealing with the bugs that come out of that.
To sum up, if React Native was a poor choice it would reflect in the user engagement/growth numbers and wouldn't last long within a metrics driven public company like Facebook.
So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers? Otherwise, it is a very big compromise, in regards to UX and performance. UX is not native - it reimplements basic concepts from each OS on its own in JS, which is neither good for UX (it doesn't look or feel right), and performance suffers due to bridge shenanigans, JS VM and shadow view hierarchy (aka shadow DOM).
"So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers?"
I'm very sorry if my comment came across as a rant, that was not my intent. I actually never made the claim that React Native makes developers lives easier in that comment.
My main point was that raw performance is not the only thing that matters to users. App stability and the time that it takes to get new features to market are also things that users care about, sometimes at the expense of performance.
Facebook/Instagram make product and technology decisions based on metrics. Making life easier for their developers is a secondary concern. If a feature is not moving the engagement numbers in the right direction, it gets cut.
The proof of this is Paper, a beautiful fast native app that was originally meant to the replacement for the main Facebook app. It's numbers sucked, so Facebook cut it.
Paper was never designed to be a Facebook replacement, but a PoC in engagement through UI using Facebook. The released a lot their findings and tools to the OS community as well (Tinder took their animation mechanics). Btw 1 billion DAU would have never agreed to that level of rethinking for the app.
So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don't have control there).
" Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex,"
React Native is not based on WebViews/HTML. It uses a virtual DOM on top of native views:
"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."
This is quite different from similar Javascript based efforts such as Cordova.
> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack
I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical.
As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster.
In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native.
What is "adequate"? Any long term task still hangs the business logic thread - the only thread - unless you fallback to native. At what point does constant fallback to native for implementing what is not possible in JS a detriment to development? You may say, multithreading is an edge-case, but is it? I have not been involved in a single project where actual multithreading was not needed.
Also, the way RN is implemented internally, such as async bridge and layout (CSSLayout / "yoga"), it is quite impossible to use native optimized views, such UITableView with reusable views, because this API is designed for synchronous API calls.
The only thing I can say for both of you are that you're both right. We need to optimize for the user and optimize for the people getting the improvements to the user as fast as possible. Anything else is just technical debt :)
I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively.
This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly.
As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough.
I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.