With React Native it’s not all sugar and spice

I&#x27;m working on an Android app.<p>I use react-native solely for the UI which I update, redux-style, with a state-tree. The state and all it&#x27;s transition and event-handling is done in Kotlin&#x2F;Java. I&#x27;ve written a small helper that generates kotlin-Interfaces from the react&#x2F;jsx-files and automatically connects everything.<p>This way I have react&#x27;s HotReload and the other benefits for UI-design and a proper typed language and IDE for networking and everything else. Including compile-time checking of events and properties of the UI.<p>Plus: Kotlin can compile to JavaScript, so if I ever want to port the whole thing to iOS, i just have to switch out a few APIs.

I find irrelevant gifs embedded in a blog post like this make the entire article unreadable. It&#x27;s distracting and annoying.

The criticism on the tooling seems excessive for the benefits it provides. On one hand you don&#x27;t spend the time equally on the terminal, the text editor, dev tools and the platform&#x27;s IDE. You&#x27;ll normally spend most of your time in the text editor and the emulator. You&#x27;ll have to use the other tools here and there, but in exchange most of your code will be shared across platforms.<p>Regarding code organization, I found redux to be a well established tool with clear patterns.

&gt; With each framework or platform we develop with we need to adapt to the conventions. From back end work using frameworks like Rails and Elixir to native mobile projects each has it’s own way to hang together a project.<p><i>Some</i> have their own way to hang together a project. Much of the React ecosystem is not so opinionated. A lot of JavaScript out there exists in codebases in a variety of languages and frameworks—Rails, PHP, Node... you name it. Modern JavaScript build tools reflect the need for script sources and build targets to reside anywhere based on what the site JavaScript is being used <i>in</i>. I&#x27;d say this historical influence is showing in React Native.<p>However, I also think this makes sense for React Native. It&#x27;s possible it&#x27;s getting introduced into apps which already have conventions based on the platform the app is for and the team writing it. It might not make sense for React Native to come up with a new set of conventions when you&#x27;re working with multiple platforms and existing codebases.<p>&gt; But the real value is in sharing code, maintaining projects and on boarding new members to a project team. [...] We’ve spent a long time viewing projects on GitHub and picking and choosing what we feel is the best way a project should be structured.<p>Conventions—whether they&#x27;re forced on you by the framework authors or developed by the community—are still part of learning a framework and working with it for the first time. I&#x27;d say what author came away with here is even more important than just having <i>some</i> convention—they landed with something they really think is best for their projects! The real cost here is that onboarding developers will also include time for them to get familiar with this project structure, but is that really so much to ask?

I wouldnt recommend react for any app which you want togo big. In the end, you need to rewrite it to native code anyway, because you want to use the latest feature, or because you have bugs because react native doesnt follow the platform guidelines (activities, activity stack, etc)

&gt; When you develop a fully native app you do it pretty much in one place. On iOS you’re in Xcode, for Android you’re in Android Studio. With React Native you have a terminal (with a couple of panes), a text editor, perhaps Redux Remote DevTools plus your IDE for the platform you’re targeting.<p>It&#x27;s not like those IDEs can&#x27;t be configured to work with the raw tools.

If you want a single IDE, vscode is really great.

You should do your due diligence before using a framework&#x2F;library&#x2F;technology for production code. Don&#x27;t just follow the hype.<p><a href="http:&#x2F;&#x2F;www.sheshbabu.com&#x2F;posts&#x2F;guidelines-to-choose-a-javascript-library&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.sheshbabu.com&#x2F;posts&#x2F;guidelines-to-choose-a-javasc...</a>

I don&#x27;t mind switching between different contexts, I frequent the terminal for git an other stuff anyway. I think it is fairly magic that one may finally develop the same code for both iOS and Android. Huge productivity win, especially using Clojurescript!<p>I agree with the instability though, nothing for someone afraid of rumbling around in the RN source code to solve things like this <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react-native&#x2F;issues&#x2F;7720" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;react-native&#x2F;issues&#x2F;7720</a>

Many of the points made in the article boil down to React Native still being a relatively new framework, and the team and community behind it iterating <i>very</i> quickly.<p>Sure there will be growing pains starting out, but the benefits that are coming from this new direction are, in my opinion, worth all the effort. I&#x27;ve written several apps utilizing React Native now, and love the efficiency boost it gives me.

If you&#x27;re looking for an all-in-one development environment, my team is building an IDE specifically for React Native. It&#x27;s free and open source.<p>Deco IDE<p><a href="https:&#x2F;&#x2F;www.decosoftware.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.decosoftware.com&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;decosoftware&#x2F;deco-ide" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;decosoftware&#x2F;deco-ide</a>

HN community, how would I make my core model + business logic cross-platform? I want to re-use the model and its behavior (like some data evaluators) in my Web app, on Android and iOS without rewriting it every time from scratch. I&#x27;m fine with creating native code for the UI. but I&#x27;d like to share at least some code. What would you recommend?

For me C++ is all I need for portable native code, no need to add extra layers that kind of work, that only increase code entropy and debugging efforts.<p>Directly available in iOS, Android, WP, Tizen, Ubuntu SDKs.<p>The only major problem is the way Google disregards their NDK stack, while Microsoft and NVidia engineers are able to do what Google PhDs are not.