Back to blog home page

Angular 2 NativeScript Vs. React Native

Posted by on May 20, 2016

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 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.

Conclusion

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.

  • kommentz

    Thanks for the post. I’m grateful for both NativeScript and ReactNative and while these native-ish frameworks have advanced, I wouldn’t call their paradigm and the decisions around them new or anything that falls into the ‘until recently’ category. I got 60 FPS games into the iTunes store using Adobe AIR with sprite sheet animations on an iPhone 4 in 2010. The problem was, nobody knew about it — so thanks for spreading the word! Phones are fast enough today that it’s really very hard to tell the difference *sometimes*. Of course, sometimes it’s easy to tell the difference but usually the people quick to say that will quote $60K per platform to build todo apps.

  • Nice write up. Just want to clarify that NS does not require NG2. In fact, NS has less opinions than React itself. You can bare bones it all the way with JS alone. I’d like to recommend this comparision: https://www.quora.com/What-are-the-key-difference-between-ReactNative-and-NativeScript

  • Nice article … can you clarify your points and facts for these for please?

    > NativeScript as the UI is not typically resource-intesive enough to warrant a more platform-focused approach
    Why? It seems you feel NS is resource intensive and slower than React Native? Is it? If so, in what scenarios is this fact based?

    > use of Angular 2 to drive the application’s architecture negates a lot of the speed benefit that React Native brings
    How does A2 negate speed that React native brings?

    > the integration of Angular 2 and NativeScript carries further at the slight expense of deeper native device integration.
    What is the expense? What features of device integration don’t you get?

    Thanks!

    • > NativeScript as the UI is not typically resource-intesive enough to warrant a more platform-focused approach.
      Why? It seems you feel NS is resource intensive and slower than React Native? Is it? If so, in what scenarios is this fact based?

      >>Itay: It’s actually the other-way around. NativeScript is actually not a massive burden, is what I was trying to say – namely, that apps using NativeScript will typically have other concerns that would negate the performance benefits of transitioning to a more native-code approach (no point in improving UI rendering by 100 milliseconds when the network call to populate that UI will take 300 milliseconds is essentially my point here)

      > How does A2 negate speed that React native brings?

      >>Itay: The patterns required to pursue Angular2 will, in many cases, result in code that does not run as quickly as a react equivalent. This is a simple matter of React being a library while Angular is an opinionated framework – there may be some cases where an optimization is in opposition to the pattern expected by Angular, in which case you’ll need to hack around it – this isn’t a problem with a library like React, because they don’t try to enforce architecture patterns as heavily as Angular2 does. An example comparison would be a rails app trying to do multi-database work – you need to override some core rails configuration, which adds additional operations for the same call that, in a skinnier DAO library, might not be necessary.

      > the integration of Angular 2 and NativeScript carries further at the slight expense of deeper native device integration.
      What is the expense? What features of device integration don’t you get?

      >>Itay: In this case I’m talking about built-in integration. Angular2 is extensible enough that native functionality may be able to be modeled, but when we get to that point then we’re not talking “Angular2 vs React”, but rather “Angular2 and plugins vs React.” The example I was thinking of when I wrote this is the Samsung S-Pen (I have a galaxy note 4 phone and a galaxy note tablet – both of which come with the enhanced stylus). This kind of hardware variation is not usually handled well by these kind of “one size fits all” frameworks – that’s what I was getting at. That being said, we can amend this statement to either offer specifics, or add a “without plugins” qualifier.

      • Thanks for the thoughtful reply.

        OK, so I misread you then … you were actually saying NS and RN performance is about the same in your experience. Is that it?

        RE: the Angular 2 patterns “resulting in code that does not run as quickly as a react equivalent.” … I don’t understand what patterns cause that to be slower than React. Could you quantify those? I’m feeling that this is more of a developer preference. I have seen no evidence that suggests either of those (Angular 2 or React) is faster than the other overall.

        On your last statement … I’d like to hear more from the NS team on this.

        Overall, I’m just looking for some facts to substantiate your statements that A2 will cause device integration problems and be slower (I am paraphrasing your comments). If this is true, I’d like to hear why and under what circumstances. This would be great to follow up with the Angular team, NS team, etc. Without that information, it’s opinion … and I sense you have some experience that you could share to help clarify this.

        Thanks for sharing!

        • Hey,

          TJ from the NativeScript team here. I appreciate the time you put into writing this article up, and I just wanted to clarify some things from our end.

          First of all, although I agree that we (NativeScript) provide more cross-platform UI abstractions than React Native does, we also give you the same ability to embrace the multi-platform nature of mobile app development if you choose. In NativeScript apps you can define different templates for iOS or Android, different templates for phones versus tablets, or you can perform small tweaks within your templates to build an optimized view for users on their devices. We want to give you the option of writing once when it makes sense, but also to customize how you render to each environment where that makes sense too. The tooling Angular 2 provides makes this surprisingly easy to manage, as you can write your JavaScript/TypeScript component code once, and then define either one or multiple templates depending on your use case.

          @itayher:disqus: “This is a simple matter of React being a library while Angular is an opinionated framework – there may be some cases where an optimization is in opposition to the pattern expected by Angular, in which case you’ll need to hack around it – this isn’t a problem with a library like React, because they don’t try to enforce architecture patterns as heavily as Angular 2 does.”

          I’m going to agree with @johnpapa7:disqus that I’d like to see some data to substantiate these claims. The data I’ve seen on the topic shows the two frameworks as being relatively comparable from a performance perspective—which I can anecdotally agree with based on my own experience building with both—and IMO it’s more important to pick a framework that matches your own development preferences and methodologies. It’s worth noting that at a low level, NativeScript is a runtime and we run fine without any frameworks at all. We could support React, but we’ve found that Angular 2 gives our users the very best experience because it provides the very architecture patterns you refer to in your comment. The structure Angular 2 enforces, especially with the addition of TypeScript, more closely resembles the patterns that Android and iOS enforce for native development, and as such it was a natural fit for us.

          @Itay Herskovits: “In this case I’m talking about built-in integration. Angular 2 is extensible enough that native functionality may be able to be modeled, but when we get to that point then we’re not talking “Angular 2 vs React”, but rather “Angular 2 and plugins vs React.” The example I was thinking of when I wrote this is the Samsung S-Pen (I have a galaxy note 4 phone and a galaxy note tablet – both of which come with the enhanced stylus). This kind of hardware variation is not usually handled well by these kind of “one size fits all” frameworks – that’s what I was getting at. That being said, we can amend this statement to either offer specifics, or add a “without plugins” qualifier.”

          I think you’re conflating a framework discussion (React vs. Angular) with the ability of native frameworks to access native APIs. You can access 100% of native APIs with either React Native or NativeScript—neither framework limits you. Now, the way you access those APIs differs between the two frameworks. In React Native you access these APIs with native Objective-C or Java code and expose that custom code to your JavaScript. Here are the docs to give you an idea: https://facebook.github.io/react-native/docs/native-modules-ios.html#content. In NativeScript we give you 100% access to native APIs in JavaScript/TypeScript directly. It’s NativeScript’s defining feature and the reason we call the framework NativeScript in the first place. If you’re curious about how the architecture works you can read more at http://developer.telerik.com/featured/nativescript-works/.

          But regardless, overall neither React Native nor NativeScript limit you in terms of getting at the metal. With NativeScript we provide a bit more structure for your development—more cross-platform abstractions, optional Angular 2 & TypeScript, integration, and so forth. With React Native you need to roll a bit of that on your own, but you have a bit more flexibility if you really know what you’re doing as a native mobile app developer. Neither approach is right; neither approach is wrong. As always it makes sense to take the time to evaluate each framework and see which is a better fit for your team and your company. If you want to get started with NativeScript I’d recommend starting out with our tutorial at http://docs.nativescript.org/angular/tutorial/ng-chapter-0.

          If you have any other questions about NativeScript let me know. Thanks again for writing this up!

          • > @TJ VanToll “…and IMO it’s more important to pick a framework that matches your own development preferences and methodologies.” >> This is the key point we’re trying to make here, well that and the basic difference between a library like React – which doesn’t enforce a program architecture – and a framework like Angular2 which, even when combined with NativeScript, is enforcing an opinionated way of doing things. I’ll grant that the opinions expressed by angular are similar to best practices with app development, but the central point still stands: one of the downsides of choosing an opinionated framework is that when you disagree with the opinion being put forth you need to work around the framework’s expectations, adding extra code that wouldn’t otherwise be needed. There aren’t specific cases or performance data because this is an architecture and program design concern, not a specific concern related to the performance of Feature A versus Feature B. As the problem domain we’re discussing here is literally “any application that can be developed on a mobile device”, it only makes sense that some applications may run into limitations of the pattern – there’s no way to get around this while having a framework that has an opinion of the “right” way to do things. And it’s important to note that the impact of this “difference of opinion” may be getting far more attention than it deserves – this was simply calling attention to one of the tradeoffs you face when choosing a framework with an opinion. There won’t be drastic performance differences (odds are they won’t even be noticeable in the context of an internet-based mobile app), but they should still be noted. We could also concede that in many of those cases it’s just a side effect of not fully grasping the pattern, but that’s a secondary issue that can’t really be addressed here effectively.

            > @TJ VanToll “I think you’re conflating a framework discussion (React vs. Angular)…” >> I think this is the core of the discussion and disagreement. Both frameworks give you the capacity to get at the “bare metal” to code specific functionality. That’s why I didn’t really cover this in-depth in the blog, as since both offer the same access, it doesn’t make sense to really compare and contrast the two. However, the point I was making here was perhaps a bit more subtle, and rooted in the purpose of the post to compare React Native vs Angular2 and NativeScript. So we are approaching this from the perspective of the frameworks in isolation, as the differences become a lot more nuanced once you start tying these frameworks and libraries into their respective platforms. Thus, yeah – there’s some conflation occurring – but we’re actually looking at that higher level discussion of frameworks versus the lower level discussion of getting at the bare metal. Does that make sense?

            > @TJ VanToll “But regardless, overall neither React Native nor NativeScript limit you in terms of getting at the metal…” >> Neither approach is right; neither approach is wrong.” – This is ultimately the point we’re trying to make. Choosing Angular2 and NativeScript over ReactJS does not limit the applications you can build. There are no “strong” arguments against either, on the surface, aside from the point you make re: ReactNative coders having to roll some abstractions on their own. That’s probably another source of disconnect here – we’re trying to discuss the specifics of shades of gray. It’s also important to note that we’re looking at a more specific scope that is slightly higher up the stack than the discussions we’ve been having about accessing bare metal functionality – that’s an architectural and development decision that needs to take place regardless of the choice of framework.

            Thank you for the opportunity for peer review! This discussion has been great, and if nothing else anyone who comes across this post will have excellent auxiliary information from respected figures in the community to assist in making a decision.

          • Hey @itayher:disqus,

            Thanks for your replies; they indeed make sense to me. I think at the end of the day the NativeScript w/Angular vs. React Native discussion ends up being an Angular vs. React discussion, which is a heated debate that we won’t be able to settle in this thread ????

            Thanks again for writing this up, and if you have any other questions about NativeScript feel free to reach out at any time—https://twitter.com/tjvantoll.

          • This discussion alone deserves a complete post! Thank you Itay, TJ and John for the insights.

            Let’s continue the fight with NativeScript vs. Ionic 2 ;D

          • 1antares1

            IDEM!

            What would be of this article without the precious author and nothing more and nothing less with the great league of the code: @johnpapa7:disqus and @tjvantoll:disqus? 😛
            Awesome to read!

            Thanks.

          • speigg

            NativeScript w/ support for both Angular and React would be amazing. I personally favor the React UI development paradigm, but Nativescript makes it far easier to leverage native apis (and thus, I am using Nativescript).

          • Kobzol

            I’d love to work with Nativescript, but two things are really limiting me right now – blank NS apps boots in ~5-6 seconds (on a relatively powerful 6.0 Z3 compact), RN app boots under a second. I’m having the same boot problem with Ionic 2 (even a blank tutorial app).
            The other one is development speed – NS live reload is tedious, as it often doesn’t work or it takes too long to update. RN updates the app in a second and also offers hot reloading, which enables to patch the code without reloading the app at all.

          • Mahesh

            Hey @tjvantoll:disqus nice a guy from NS team here. I have seen Reat Native Apps like FB, Airbnb seems like supper faster and extraordinary user interface when comparing to NS show case apps. Can you name an app which developed using NS+A2. I was doing research on NS vs RN since 45 days for my project.

            Thanks

          • Hey @mahesh565:disqus,

            MeWatt is a good one (https://www.nativescript.org/showcases#mewatt) and it has a pretty cool story behind it (see http://www.telerik.com/docs/default-source/case-studies-documents/nativescript_mewatt_cs.pdf). My personal favorite is ShoutOutPlay on iOS (see https://itunes.apple.com/us/app/shoutoutplay/id1130768471?mt=8,) but note that you’ll need a paid Spotify account to really test that one out.

          • Mahesh

            @tjvantoll:disqus MeWatt, I have seen it before, there is nothing to see. I can only see login screen, rest of click are not working. Being a login form also seems like a Cordova app. While checking ReactNative I have found Airbnb, the user experience is next level.

    • We released another article that just focus on Native vs Hybrid – http://dev-backand-blog.pantheonsite.io/native-vs-hybrid/ which compare the Ionic (Cordova) approach to the native. And again there is no one conclution and it depends on your app but this sentence summarize it all: ” While there are many cases where Native development is the right choice, if your application is focused on communicating with remote servers, Hybrid development will often be the best choice for your cross-platform application.”

  • Steven Myers

    ” However, the use of Angular 2 with NativeScript requires adopting a traditional Angular architecture for your application’s code”

    I don’t feel this is true. You can write an Angular 2 app that doesn’t follow a traditional Angular architecture; therefore you can write a NativeScript app that doesn’t follow a traditional Angular architecture?

  • JimTheMan

    Great article. It’s great that web developers can leverage JavaScript to make high performance native apps as well!

  • Sandeep Khandewale

    Great post and Great discussion. Not every time, reading through comments is this informative.

  • Sam

    This blog suggests that react native is faster than angular 2 nativescript. I do not think that this is the case. See the performance tests between the two frameworks here:

    https://www.pluralsight.com/guides/front-end-javascript/angular-vs-react-a-side-by-side-comparison

    • Sebastian Scholle

      Thanks for the link Sam. I believe the article in the link however does NOT measure either NativeScript nor React-Native performance.