I use some of the apps that are listed above, and I don't really have a problem with the performance.

Can you explain little bit more on how not using the native components can be big problem when your app gets bigger? I am asking because i really consider using React Native.

Or maybe give an example under which circumstances will those app fail to perform?

I used Cordova and the "lag" makes it clear from the first 5 seconds that it is not a native app. But i haven't experienced it from the apps that they listed on their page.

Single JS threads restricts your business logic a lot. If you start doing any serious work in JS, your app will suffer greatly.

Regarding native components, the result is that views just don't look native, animations are not native (even down to different timing functions), view behaviors are different (the RN button fade out on tap is different than UIButton, etc).

On top of that, since the JS thread is responsible for UI rendering and business logic, if your JS thread is busy, UI is "stuck", being unable to rerender until the JS thread is freed.

All these issues pile up to create a bad result at the end. Add to that the human element (not always being mindful of performance implications), and it is worse. But, definitely, the ceiling is very low at how much you can achieve.

I say all these things from experience; I work next to a team of dedicated RN developers at my company. In many cases, the need to drop to native is apparent and necessary, which makes the point of RN moot.

Certainly, RN is better than Cordova; no doubt about that. But it's just not as good as many people want to fool themselves at believing.

I guess, if you are one-man team RN makes good sense since you don't have time to write native for 2 platforms from the beginning. If your app takes off, then switch to native for scaling. Is it possible to partly switch from RN to native? something like convert components one by one to native components, while still running RN for some parts?

Most apps don't need native performance, and most that do only need it in a single component. Really good software architects and devs know where a framework like RN is valuable.

The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.

Without a real architecture you don't get to complain that a hamhanded solution is less than optimal

If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale.

I'm not sure you understand how architecture of a mail or chat app would work.

https://www.checkpoint.com/products/capsule-workspace/#overv...

https://itunes.apple.com/il/app/check-point-capsule-workspac...

RN list views are terrible, as all the data is held in memory. For a chat or a mail apps, that's catastrophic. "Paging on the server" is not a solution; users want all their data on the device.

In my previous comment, I actually meant a different scenario than displaying a list. Take any proper mail client or a chat app; the first thing they do once a user logs in is start preloading previous data that can be found in cloud / on the server. Depending on the amount of data available, that is a very serious undertaking in and of itself, doing it efficiently enough in the background while updating the UI where needed upon insertion. This is just not possible in a single-threaded JavaScript.

Your mindset of only holding a small subset of data on the mobile is erroneous and is empirically not what users want; it's a web mentality and has no place in any app development but web. We went with this approach, albeit for security reasons. The result was the vast majority of users were unhappy. Users wanted a full blown Outlook in their mobile, and there was no reason not to give it to them.

The vast majority of popular chat and email apps keep at least some of the data on the server by default -- Gmail, K9 mail, Outlook itself -- so I don't see where there is proof that users want something different.

The main problem is large redux objects, which you're right - needs major refactoring. It's a pain.

Also is NativeScript multithreaded?

On the other hand, NativeScript's UI mapping is directly on top of the platform widgets, as far as I remember.

The whole point of React Native is to develop apps for both iOS and Android (you seem to be an iOS focused developer so you wouldn't care but many of us are targetting both) and doing that easily (for those who build RN and those who use it) means we have to create a standard set of behaviors that work across both platforms and work far better than running a web app in a webview. React Native achieves that goal. But it also has an enormously capable ecosystem with companies like Airbnb and Wix making substantial contributions to things like Native cross platform Navigation libraries.

When it comes to threading, the native views run in the main UI thread (just like native views would in any native environment) while the JS business logic runs in its own thread. To minimize serialization costs between JS and Native a lot has been done so JS objects like styles are passed by numeric reference. You can always use something like react-native-fetch-blob to natively fetch an image or some other heavy asset and go around the JS-Native bridge. But you can also use Inage component to fetch and remder images without serializing over the bridge. The user community has many other examples and great libraries to complement React Native. All you have to do is be curious rather than judgemental and harshly criticizing things that you obviously lack in-depth knowledge about.

When it comes to layout, Flexbox and support for percentage based siIng give us the primitives we need to replicate the familiar responsive grid systems we use on the web. See this for example:

https://github.com/idibidiart/react-native-responsive-grid

And as far back as August 2015, I was able to create a custom keyboard in Obj-C and expose it as a React Native component:

https://m.youtube.com/watch?v=YV3p09KoYKw

There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving.

So Facebook has shared their work with us and we shared our work with the community. What do you have to share besides criticism of other people's work? Do you have any work of your own that helps others build things? Put it out there and open it to criticism from random folks on the internets. Let's see your true genius!

"If you were right then all of us who love React Native and have used it to build amazing cross-platform UX are wrong or have less insight than you, which cannot be true unless you've got some real insight or something, which is certainly not true."

I work at Wix. I have a lot of insight into what I am talking about. We have one of the largest React Native applications out there. I have also contributed to the react-native project itself, and have intimate knowledge of how most of it operates. I have, and am, building tools to improve work with RN. I have an extensive iOS knowledge, and I have access to Android developers with extensive Android knowledge. We happen to share our opinion on RN.

"There is nothing that could not be done with a combination of platform specific knowledge and React Native, and the technology is still evolving."

Try running JS business logic concurrently. (Multiple JS VMs does not count.)

"What do you have to share besides criticism of other people's work?"

What a ridiculous statement. So I can't criticize terrible technology unless I, alone, have created a competing tech to Facebook, who employs hundreds of engineers?

Nonetheless, here are some open source projects which I have contributed or created:

https://github.com/wix/AppleSimulatorUtils

https://github.com/wix/detox

https://github.com/wix/DTXSourceMaps

https://github.com/wix/DetoxInstruments (WIP - no read me or documentation yet)

https://github.com/LeoNatan/LNNotificationsUI

https://github.com/LeoNatan/LNPopupController

https://github.com/LeoNatan/LNInterpolation

Before that I worked at Check Point Software Technologies, a security company, where contributing open source was frowned upon.

Any software that does not use the full benefit of each platform it is running on is mediocre at best for me, let alone something that is limited to a single thread, and reinvents the wheel for simple and/or solved stuff, such as navigation, animation and OS widgets.

I do think that of all the cross-platform approaches, going the native UI and C/C++ business logic approach is best.

NativeScript does not support GL/ThreeJS but RN does so I expect games will be built on top of RN. And when that happens we should get lots of new entrants in the ecosystem and greater creative mass.

I fear it’s JS development mindset in general. I mean, you start a new project in RN, you get 1200 NPM dependencies. You start work, and you get thousands of dependencies. All that piles up to a huge amount of code that has to be parsed on start up (no ahead of time compilation or JIT).

Having a NullPointerException/"undefined" in my code means I have to go hunt the bug for a couple of minutes. Having it in my buildtool means I my productivity drops to zero for an hour.

RN also keeps using deprecated and old version of android-buildtools.

Fun fact: "NullPointerException" gives 2.47 million results on google.

"cannot read property of undefined" gives 3.71 million results.

(Background: I'm a Java, Kotlin and JavaScript developer, shipped an app using react-native for the Views only, but Kotlin for the business-logic. I also picked some fights with the RN-maintainers on github issues.)

I agree but tachyons.css is different.

OP asked for "margin and layout" guides.

Tachyons gives you exactly that. A dimensional and typographic scale without forcing you into their framework, because it uses atomic classes.

http://tachyons.io/#style