Over a million developers have joined DZone.

Angular 2 NativeScript vs. React Native

DZone's Guide to

Angular 2 NativeScript vs. React Native

In this article, we’ll look at using JavaScript to create a cross-platform native app experience by examining React Native and the combination of AngularJS 2 and NativeScript. We’ll look at what each has to offer, then compare the two to provide a heuristic for making the right choice for your application.

· Mobile Zone ·
Free Resource

Image title

Cross-platform apps face a crucial choice in their development planning phase—should the application be developed as a native app, or should it be developed as a hybrid or web-based application? This question used to impact the amount of work to be done—namely, until recently, choosing to pursue a native approach for your application meant consigning your development team to simultaneously developing functionality in Objective C/Swift (for iOS) or Java (for Android). However, this is no longer a consideration when it comes to creating a native app experience. Below we’ll look at using JavaScript to create a cross-platform native app experience by examining React Native and the combination of AngularJS 2 and NativeScript. We’ll look at what each has to offer, then compare the two to provide a heuristic for making the right choice for your application.

Why Go Native?

Native apps have a number of advantages over hybrid and HTML 5-based apps. First, native applications are closer to the device’s processor, meaning that, on average, native code will perform better than equivalent code written for a hybrid framework. Additionally, a native app lets you build in some features that may not be available in your hybrid framework of choice, as you can target specific platforms with specific features, integrating with the hardware on a mobile device can be done right in the same set of source code, rather than having to include a custom module or non-web component in a hybrid app. Couple this with being able to provide an idiomatic user experience for a given device, and choosing to develop a native app becomes a much more compelling choice. By using a framework with a native component, we can further mitigate the costs necessary to develop the app natively.

React Native

In March 2015, Facebook introduced React Native, a tool built to allow developers to use the same base JavaScript code on either iOS or Android. As React was a set of functions with minimal external side effects and a tangential dependency on a DOM, Facebook was able to abstract away the use of a DOM as the primary rendering model into a pattern that allows for the easy substitution of native components instead of web views and HTML components. Thus, using the same code, an application can implement alert windows using UIAlertView on iOS and android.app.AlertDialog on Android, all without having to write any extra native code to support the UI views. Couple this with React’s focus on speed and dirty-rendering, and you can build a blazing-fast cross-platform mobile application with only one code base.

AngularJS 2 + NativeScript

The team at Telerik (now a brand owned by Progress) originally developed Kendo UI with tight Angular integration. When used for hybrid apps and HTML 5 apps, this created a consistent cross-platform UI experience simply by leveraging the tools provided in the framework. When Telerik began working on NativeScript to provide a true cross-platform native experience, the dependence of Angular 1.x on tight coupling with a DOM for rendering posed problems when attempting to create a native UI map for Angular applications. However, with the advent of Angular 2, this all changed. Angular 2’s looser coupling with a DOM for rendering allowed the developers of NativeScript to perform similar tasks to those performed by Facebook when genericizing React Native – abstracting away view rendering and components so that a DOM was no longer necessary. As a result, Angular 2 integrates easily with NativeScript, allowing you to code your native app in a declarative style that can run on any mobile device platform.

Comparing the Two

The crucial thing to realize when comparing the two native-focused approaches is that React Native and NativeScript share a fundamental difference in approach to how they construct native apps from the same code base. NativeScript takes a holistic approach, working to be a true “Write it once, run it anywhere” framework. This means that a lot of the UI elements used will be decidedly lower-level, as NativeScript is attempting to manage the UI in a transparent and repeatable way between the multiple platforms it supports. Add in the coupling with Angular 2, and you can create cross-platform applications that, through the virtue of Angular’s declarative UI focus, are more conceptually consistent than an application having to interpret between multiple UI paradigms.

On the other side of the debate is React Native, which chooses to embrace – rather than hide – its multi-platform nature. This means that while you can write React Native code in a platform-agnostic manner, you can also get down to the platform-specific UI layer. Stated another way, React’s goal is to abstract the business logic while supporting the differences inherent in UI rendering between each platform, while NativeScript has a focus on creating a singular development experience regardless of platform. Couple this with React’s focus on speed of rendering and execution, and you can easily create performance-focused cross-platform apps that can both run on the same code base, and leverage platform-specific components at will.

 Which approach you prefer will ultimately be dependent upon the needs of your application – relatively generic database-powered apps will likely favor NativeScript as the UI is not typically resource-intesive enough to warrant a more platform-focused approach. And even in that case, the use of Angular 2 to drive the application’s architecture negates a lot of the speed benefit that React Native brings to the table. However, the use of Angular 2 with NativeScript requires adopting a traditional Angular architecture for your application’s code, something which React’s library approach doesn’t require. Additionally, with NativeScript being a separate project from Angular 2, this introduces additional dependencies into your application’s pipeline – a problem not as pronounced with React Native, which handles all of the cross-platform functionality in the React framework itself.


Cross-platform application development has seen rapid advances, and the recent proliferation of cross-platform and native development frameworks will only continue this pattern. Choosing between React Native and a combination of Angular 2 and NativeScript is, in many ways, similar to choosing between React and Angular themselves. React is designed as a blazing-fast lightweight rendering framework to be leveraged within the context of a larger application, and React Native continues this pattern of providing tools instead of patterns. Angular, on the other hand, is an opinionated application development framework that has a “right way” of developing applications in mind, something that the integration of Angular 2 and NativeScript carries further at the slight expense of deeper native device integration.

Thus the choice between the two is largely the same. Is you application focused on complex UI with lots of rendering and custom elements? If so, React Native might be the right choice for you. However, if having a single cross-platform code base with a declarative UI paradigm is more in-line with what you envision for your application’s architecture, then combining Angular 2 and NativeScript can help you realize the same gains you’d see in adopting Angular for a web application, all while maintaining similar development patterns and program architecture.

Get a free backend-as-a-service for your Angular and React applications with Backand.

cross-platform ,experience ,react ,angular ,native ,ui ,application ,integration

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}