Why I'm Not a React Native Developer

Complaining about longevity of React Native and then recommending two proprietary, non-open-source competitors is, frankly, absurd. If Facebook ever abandons React Native we have all of the code and can continue to support it ourselves. If Microsoft or Appcelerator ever shut down their platforms for any reason, we&#x27;re SOL.<p>While there are some valid concerns with using React Native, the productivity gain and community make it a more than worthwhile trade off.

- No clear roadmap<p>Indeed this would be nice to have!<p>- No guarantees from Facebook about longevity<p>As more products within Facebook (eg: Instagram) and companies outside of Facebook are depending on this (Airbnb, Netflix, Alibaba, Microsoft, Baidu, Uber), there is a bigger community of folks who share the burden of keeping it going.<p>- Legal concerns<p>This is the same license as React. Given the breadth of companies depending on React (all of those mentioned above, plus thousands more), I suspect that their legal departments considered it to be acceptable. If you don&#x27;t, that&#x27;s certainly fine!<p>- JavaScript problems<p>JavaScript does have plenty of problems, but it&#x27;s also what enables a lot of the nice things about React Native (x-platform, ota updates, resource sharing -- as the author identified).<p>- Alternate frameworks: Xamarin, Appcelerator<p>I&#x27;d like to see the author write a similar assessment of these tools! It&#x27;s worth noting that the author seemed to be unaware of the existence of React Native for UWP, maybe that would alter his assessment.

Great article. On a side node, however: please don&#x27;t write code like this:<p><pre><code> var weAreConnected = Math.floor(Math.random() * 10) &gt; 5 if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } </code></pre> Instead, simplify the logic<p><pre><code> var weAreConnected = Math.floor(Math.random() * 10) &gt; 5 this.setState({ isConnected: weAreConnected }) </code></pre> The random choice is also overy complicate (and on a side node, the value is more likely to be false then true due incorrect comparision operator usage)<p><pre><code> var weAreConnected = Math.random() &lt; 0.5 this.setState({ isConnected: weAreConnected }) </code></pre> If we use ES6, we can use the shorthand notation to simplify the code even more<p><pre><code> const isConnected = Math.random() &lt; 0.5 this.setState({ isConnected })</code></pre>

Wonderful article! As a JavaScript developer, this is the first time I have seen a well-written critique of the language shortfalls. Usually these counter-arguments can&#x27;t help but feel like flame wars.<p>That said, I think every JS feels these pressures internally. In 2015, some were even brave enough to give it a name — &quot;JavaScript Fatigue&quot;. I personally work with TypeScript. But each time you kickoff a new project these days, the task of getting past all the boilerplate work seems to be increasingly difficult.

While I can&#x27;t argue the shortcomings of js, it&#x27;s hard to not see most of the argument as a strong stance of statically typed languages that get compiled against those of dynamically typed languages that evaluate at run time. Both types of languages have their time and place and I wonder if bringing that discussion dilutes the discussion to avoid react native.<p>On the point of community versus big company support I can&#x27;t help but observe what appears to be anti open source sentiment conveyed as fact. While many of us have seen fads come and go we have to admit the wild success and stability of many open source libraries without formal agreements to maintain them. Everything from Rails, to Django, to jQuery, and Linux distros. There is a caveat here that JS libs do seem to die out faster and have questionable quality but again plenty are also great.<p>I think the choice of React Native really boils down to understanding the platform and source. If you understand how React Native leverages the toolkits and interacts with the system I think you have the tools you need to make a good decision.<p>For me I prefer native development where I can easily control and limit dependencies. If I want to hit all devices or most I&#x27;ll build a great responsive web app. At the end React Native is today NOT a production level solution that will cover android and iPhone devices, android is a separate toolkit.<p>My rambling is done I suppose. If anything can be gleaned from this it is to understand the risks and be mindful of the costs of adopting a new framework and dev environment. If you are careful, intentional, and lean on smart teammates for help you will be just fine.

Opens with how other articles on React Native haven&#x27;t been comprehensive, goes on to fill most of it about JS short comings like we haven&#x27;t been aware for a decade.<p>And the recommendation at the end for Flutter, which shares all attributes of RN (open source, free, cross platform, from a large tech company, but one known for killing projects), was strange. It made the argument essentially I want RN but not a dynamically typed language.

Very convincing. Now I really want to use react native!Thanks. The author points to lots of benefits and advantages in using react native, then shows some legal stuff you might or might not worry about (with a tinfoil hat example), then complains A LOT about javascript, making it very clear he doesn&#x27;t really get it and can&#x27;t understand how its ecosystem currently works.

Hmmm I&#x27;m not writing articles about Elixir downsides, form the simple reason - I don&#x27;t know this language well. Your article was written to show downsides of JavaScript, but example codes was written terrible. A lot of mistakes, weird examples and no basic knowledge how JavaScript is interpreted at runtime

There is no need to complain about Javascript once again, we know it all, the Flow criticism about the percentage of .js files is ridiculous, what is the percentage of Xamarin C# in all C# files ? The whole number is more important that the ratio. Also the portability of Xamarin is overestimated, you choose to use native non portable components or non native one but portable. The longevity of Xamarin is also overestimated, this is closed source software where React Native is open. This is not a good article overall.

I simply cannot bring myself to use Appcelerator or Flutter. Isn&#x27;t Appcelerator expensive (like Xamarin used to be)? Xamarin is ok, but keep in mind unless you use Forms, you are still using the iOS and Android SDK&#x27;s so you still need to be proficient in both, so it is not as xplat as you think. Flutter would be ok, but I don&#x27;t trust Google with Dart and it looks extremely underpowered with no community.

You don&#x27;t have to write JavaScript code to use React Native: <a href="https:&#x2F;&#x2F;github.com&#x2F;drapanjanas&#x2F;re-natal" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;drapanjanas&#x2F;re-natal</a>

I tried react a native a couple of weeks ago but due to a change in android versions the hello world tutorial wouldn&#x27;t work. I got the distinct impression that it doesn&#x27;t simplify android development, just adds it&#x27;s own complexity on top.<p>The whole native widgets thing gave reminds me of GWT&#x2F;AWT too, we&#x27;re going around in circles.

Really ? No opinions on this very well written article on HN. Surprised!