React Native vs NativeScript

Łukasz Micał

React Native Developer

When it comes to developing applications on both iOS and Android, there are a number of options available - React Native being one of the most popular. But it’s not the only one.

 

NativeScript is another framework that is used for mobile applications, with a lot of parallels to React Native. However, we don’t need both for a single project so it’s always worth looking at the pros and cons of both to make the best decision based on a given project’s criteria.

So, without further ado, here’s everything you need to know.

 

What is React Native?

 

React Native is a framework for building applications in both Android and iOS platforms with a native feel. It is based on JavaScript and was released by Facebook in 2015. 

 

Advantages of React Native

 

We’ll get into the key differences of React Native vs NativeScript shortly, but here’s what you need to know about React Native’s benefits:

 

 

  • It’s created by Facebook, so it’s very well supported.

  • It’s also open source. There's a large, active community available.

  • It uses JavaScript - one of the most popular and widely used languages.

  • It supports TypeScript.

 

Disadvantages of React Native

 

 

  • On the MVC layer, React Native only covers the view layer. As such, while it can work wonders, you still need other options for the rest of the app.

  • You may still need native developers, depending on the scope of a project, for the last 5-10%.

 

Examples of React Native

 

 

  • Facebook. It’s their framework, so it makes sense that Facebook would use it to develop their mobile apps. This doesn’t just include Facebook, but also WhatsApp and Instagram. React Native is used for their mobile apps.

  • Discord. It runs on both web and mobile but, when it came to the latter, Discord chose React Native for the iOS solution - rather than going the full native route. However, using a framework like this left them open for more expansion, too!

  • Uber Eats. An app used by numerous restaurants, React Native is utilized to keep the dashboard light, agile and highly performant.

 

What is NativeScript?

 

NativeScript is a JavaScript framework for developing mobile applications on both iOS and Android platforms. Like React Native, it is also based on JavaScript. It was released in 2014 by Progress Software EAD (formerly Telerik).

 

Advantages of NativeScript

 

  • It’s owned by Progress Software EAD, so there’s a professional company offering ongoing, regular support.

  • It’s also open source. NativeScript has an active community of its own.

  • Like React Native, it uses JavaScript - so most developers can get to grips with it.

  • It also supports TypeScript.

 

Disadvantages of NativeScript

 

  • Just like React Native, native development may still be needed, depending on the scope or if you’re trying to use the most advanced native hardware features.

 

Examples of NativeScript

 

On NativeScript’s official website, there’s an entire section dedicated to apps built with the framework. However, it’s very noticeable that these are smaller apps - the larger companies don’t seem to trust NativeScript as much as they do React Native.

 

  • MyPuma. A fashion and shopping app.

  • California Court Access App. A local app for courts in California, including appointments, directions and tickets.

  • Beer Tag. An app for scanning beer labels and keeping track of preferred beers.

 

React Native vs NativeScript

 

Now you know a little about each framework, how do they compare side by side? In our opinion, these are the key differences and similarities when trying to determine which framework to use in a project.

 

Similarities

 

Given their nature, both React Native and NativeScript have a lot in common. This is, of course, why they’re both often considered for the same projects; they have very similar purposes.

 

JavaScript

 

Both React Native and NativeScript use JavaScript - by way of ReactJS and Angular, respectively. This means there’s usually no problem finding developers (both at the start and later on), as well as wider third party support. There’s also rarely any compatibility issues.

 

Open-Source

 

Since both options are open-sourced, there’s plenty of support for both. While React Native is backed by Facebook and NativeScript is supported by Progress Software EAD, there’s also a growing community for both. This means that, in addition to regular fixes, there’s a large pool of fixes, additional components and solutions.

 

Code-Sharing

 

Because both options are frameworks for creating applications for both iOS and Android, both understandably utilize codesharing. Depending on the exact app, you could easily have 80-90% of your codebase written in either React Native or NativeScript.

 

Furthermore, React Native and NativeScript both compile to native-default styles, which might lead to some individual work on specific platforms. Again, it all depends on the app being built.

In our experience, React Native is better at styling these assets for each specific platform, whereas NativeScript often leads us to manually style these individually, when needed.

 

Time-Saving

 

Similar to the code base, both options also utilize reusable components. Both frameworks provide a range of native components, so developers don’t need to waste time building the basics or repeating manual tasks over and over. This greatly cuts development time. Specifically, React Native and NativeScript enable developers to focus on the unique and advanced features of your app.

 

Differences

 

It’s the key differences between these frameworks that ultimately decide whether one gets used over the other. Here’s what we consider.

 

JavaScript Variants

 

As one of the most popular languages, there are of course a few variations of JavaScript, with many developers having their own preferences. 

 

Both React Native and NativeScript support TypeScript in addition to ‘pure’ JavaScript. However, the main different is when it comes to additional libraries or framework options. React Native is based on Facebook’s React JS library, while NativeScript uses AngularJS, which makes the latter more compatible with Angular-based frameworks and libraries.

 

While this might not make a difference in the majority of cases, it nonetheless means that developers from an Angular background may favour NativeScript as they can still use the same library components/resources that they’re used to.

 

Native Accessibility

 

As their names suggest, both options aim to provide a native-esque experience. So, as developers, how easy is it for us to access native functionalities when needed? This is arguably one of the biggest differences, at least when it comes to the ‘out of the box’ experience.

 

React Native includes a basic set of API modules which enables developers to access native device functionalities. As a result, we’re often turning to third-party modules but, since the framework is so well supported, the majority of these options have the necessary API bridges to easily implement them without much additional work.

 

However,where these bridges aren’t available, often in the more sophisticated, niche situations, we need to create them ourselves. Even though React Native’s official tools for creating API bridges are available, it does require an intermediate knowledge of the respective native languages. In other words, junior or inexperienced developers (depending on the language) might struggle in these specific situations.

 

On the other hand, NativeScript has an entirely different approach. Rather than using API bridges, it injects the APIs (for both iOS and Android) into JavaScript Virtual Machines. This translates to easier integration and, unlike React Native, no need to learn platform-specific languages to create custom bridges.

 

Of course, there will always be situations where some features are best created as separate modules in a given native language. This includes the likes of video editing or processing, for example, where a fully-native module overcomes any performance burdens of using a native-esque option.

 

React Native vs NativeScript Performance

 

Ultimately, we don’t just want to develop apps quickly; we want them to stay fast and performant when finished as well. So, when it comes to React Native vs NativeScript Performance, which is better?

 

React Native…

 

  • Minimizes changes in the tree hierarchy for optimal rendering, which makes it more efficient

  • Likewise utilizes bundling and tree-shaking, further making the final app light for the user.

  • Doesn’t implement the full MVC framework, so your performance will be impacted by additional choices that need to be made.

 

NativeScript...

 

 

  • Doesn’t have the same optimized rendering as React Native, typically making the final solution slower on larger applications. 

  • Similar to Angular, NativeScript also offers a full MVC solution, so you know what to expect performance wise without having to consider additional frameworks or support.

 

In terms of overall performance, React Native and NativeScript are somewhat similar. Of course, differences will arise depending on the kind of application being built, as well as the platform, viewing device and even the version of the respective framework used. Yet these are not significant choices for choosing a framework - for example, both apps made from React Native, as well as NativeScript, can achieve 60 fps (frame-per-second) animations.

 

Which factors to consider ultimately depends on the need of the application. While NativeScript offers a full MVC framework, for example, it’s other issues often make React Native a preference for lighter, performant products.

 

What about rendering?

 

When talking about React Native vs NativeScript performance, the issue regarding how each renders the UI needs to be addressed in more detail. 

 

Why is this crucial? Speed. The more of the hierarchy tree that needs to be refreshed and rendered a new, the slower the overall app will perform. Naturally, this is a problem that scales in line with the apps size.

 

React Native works around this by creating different trees for each new layout, rendering the differences. As such, any actual loading is automatically kept to a minimum.

Native Script, on the other hand, doesn’t do this. Because it needs to utilize the wider tree structure, it is typically much slower on larger applications. 

 

In our experience, this is an issue that becomes more and more noticeable with scale. After all, React Native can stay performant, while larger apps and trees only create more work for NativeScript solutions.

 

Since NativeScript is Angular-based, you’ll find that much of the performance comparisons are the same as comparing React vs Angular itself. That said, like any option, we also need to consider how many add-ons or third party solutions we use, as this also impacts the final performance. With React Native, this just means being a little smart and thinking ahead with your additional technology choices.

 

Popularity

 

Of course, popularity plays a big role in a choice of framework. An option that’s more loved by develożers will be more highly supported, making it a safe long-term bet.

 

React Native has always proven popular, and the most recent State of JS reports continue to show this. It outperforms native apps in terms of awareness, interest and satisfaction. In other words, developers would rather use (or would prefer to use) React Native then going the native-language route.

 

However, NativeScript is almost absent from the 2019 report, despite being a prominent option in 2018 (but even then, it was less popular than React Native). While React Native proves consistently popular, NativeScript (and Angular) often fails to match.

 

TL;DR - React Native vs NativeScript

 

The framework you use is always important. While NativeScript offers a few benefits, such as TypeScript, this often isn’t what matters when it comes to the final app. React Native’s optimized rendering, faster refreshing and general continued popularity make it a safer and more versatile option in numerous cases. In fact, even though it only covers the View layer, this in itself adds more versatility, as we can pair it with other solutions to make apps our way.

Easter egg ;)