Neuigkeiten von trion.
Immer gut informiert.

React Native oder NativeScript? Eine Auswahlhilfe für Entscheider

React Native oder NativeScript? - Eine komparative Analyse für Enterpriseanwender
Im Bereich der mobilen Anwendungsentwicklung von nativen Apps gibt es viele Wege, die zum Ziel führen. Aus bereits im Vorfeld beschriebenen Gründen [1] [2] konnten wir diese Auswahl an Wegen für die meisten praktischen Anwendungsfälle bereits auf die beiden Cross-Platform-Frameworks React Native und NativeScript reduzieren.

Aber welches der beiden Frameworks sollte man denn nun für die eigene Anwendung verwenden? Die Lösung dazu und die Antwort auf weitere Fragen werden in dieser Analyse behandelt.

Für die Lesenden, die sich zunächst einmal grundlegend mit den beiden Frameworks auseinandersetzen möchten, haben wir bereits jeweils einen Artikel zu React Native[1] und einen zu Native Script [2] vorbereitet.

Vorgehensweise

Diese Analyse basiert aus einer zusammengestellten Datengrundlage unterschiedlicher Indikatoren, Eigenschaften und Entscheidungskriterien für die allgemeine Frameworkauswahl [3] [4] [5] [6]. Die Kriterien wurden im Hinblick auf mobile Anwendungsentwicklung und Cross Platform Frameworks ausgebaut und angepasst.

Entscheidungskriterien

Popularität und Unterstützer

Hersteller

Hersteller und Anbieter haben unzweifelhaft immense Auswirkungen auf die Weiterentwicklung und langfristige Unterstützung für eine Softwarebibliothek.

React Native stammt initial von Facebook und wird weiterhin von den beteiligten Entwicklern unterstützt. NativeScript wurde von Telerik entwickelt. Die Firma selbst wurde 2014 von Progress Software für gut 260 Millionen US-Dollar gekauft. Mit gut 400 Millionen US-Dollar Umsatz und ca. 1 500 Mitarbeitern Ende 2019 ist Progress Software kein Kleinunternehmen. Facebook hat das Jahr 2019 mit gut 70 Milliarden US-Dollar Umsatz und knapp 45 000 Mitarbeitern abgeschlossen.

Größe der Community

Insbesondere bei communitygetriebenen Projekten ist die Größe und das Engagement der Community nach Cruz. et al. von großer Relevanz [6]. Da es sich sowohl bei React Native als auch bei NativeScript um Open-Source-Projekte handelt, gibt es hier jeweils eine ganze Community, die an dem Projekt arbeitet.

Bei React Native haben sich auf GitHub über 2 100 Entwickler beteiligt und über 87 200 Nutzer einen Stern gegeben. Bei NativeScript sind dagegen nur 169 Entwickler beteiligt. Zum Veröffentlichungszeitpunkt des Artikels hat dieses Projekt auf GitHub 18 500 Sterne.

Auf StackOverflow gibt es zu React Native über 75 000 Fragen, während bei NativeScript nur 6500 vorliegen.

Relevanz auf Google Trends

Die Relevanz in der Google Suche auf Basis der Anzahl der Suchanfragen gilt nach wie vor als guter Indikator für die komparative Relevanz eines Themas. React Native erhält hier einen Score von 87, während NativeScript 3 erhält. Der Score wird zwischen 1 und 100 gemessen, sofern ausreichend Daten vorliegen.

Figure 1. Google Trends Scores im Zeitverlauf für React Native(blau) und NativeScript (rot).

Beliebtheit in der Entwicklercommunity

Die Beliebtheit unter Entwicklern ist insbesondere bei neueren Technologien in Enterpriseprojekten relevant, da sich für beliebtere Technologien eher mehr Entwickler finden lassen. Auch die Auswirkung auf Motivation und Leistungsbereitschaft sollte nicht vernachlässigt werden.

Als Datengrundlage für diese Beliebtheit dient hier die StateOfJs-Umfrage von 2019 [7]. Hier wurde neben weiteren Fragen auch nach der Verwendung in bestehenden Projekten sowie nach potenzieller Wiederverwendung in neuen Projekten gefragt.

Allgemein wurde React Native relativ gesehen öfter verwenden als NativeScript und hat daher keine explizite Fragekategorie in der Umfrage erhalten. Dieser Datenpunkt ist damit nur begrenzt vergleichbar. Allerdings wird NativeScript unter "Other Tools" mit 42.6% am häufigsten erwähnt. Dabei handelte es sich um ein Freitextfeld in der Umfrage.

Bei React Native sind von denen, die es bereits verwendet haben oder es zumindest kennen und gerne verwenden würden, 72.5% positiv gestimmt. Das ist zumindest mehr als bei den anderen Frameworks der Umfrage (Electron, Cordova, Ionic, NW.js, Native Apps).

Figure 2. State of JS Umfrageergebnisse: Beliebtheit.

In der Kurzübersicht stellen wir zur Popularität der Frameworks also folgendes fest:

Table 1. Popularität und Unterstützer - Übersicht (Zeitpunkt: 16.05.2020)
Beschreibung der Metric React Native Native Script

Unterstützer

Facebook

Telerik

Community (GitHub Sterne/Contributer)

>2 100

>169

Community GitHub Sterne

>87 200

>18 500

Community Stackoverflow Fragen

>75 000

>6 500

Relevanz Google Trends (score)

87

3

Beliebtheit StateOfJs (positive sentiment der Verwender und Interessierten)

72,5%

-

Entwicklungstempo

Das Tempo der Weiterentwicklung von Abhängigkeiten in Enterpriselösungen ist häufig ein zweischneidiges Schwert.

So verbessert ein höheres Tempo eines verwendeten Frameworks natürlich Agilität und Anpassungsfähigkeit der übergeordneten Anwendung. Im Fall mobiler Anwendungen kann es dadurch etwa schneller möglich sein, neue mobile Betriebssysteme zu unterstützen und neue Funktionalität auszunutzen.

Auf der anderen Seite geht ein hohes Tempo häufig auch mit einer schnellen Obsoleszenz einher. Es sollte eigentlich ständig migriert werden, da nur so bestehende Sicherheitslücken und Bugs gefixt werden können. Wenn es dabei jedoch jedes Mal zu Inkompatibilitäten durch fehlende Rückwärtskompatibilität kommt, und das Upgrade mit einer umfangreicheren Migration einhergeht, kann dies die Kosten schnell explodieren lassen.

Zur Beurteilung des Entwicklungstempos wurden für die jeweils letzten 15 größeren Releases (Stand: 16. Mai 2020) die Releasezeitpunkte analysiert und die Tage seit dem letzten Major Release ausgerechnet und geplotted.

Figure 3. Anzahl der Tage seit letztem größeren Release und gleitende Durchschnittswerte

Die grünen Linien gehören zu React Native während die blauen Linien zu NativeScript gehören. Es wird offensichtlich, dass die Volatilität (quasi die Unregelmäßigkeit der Releases) bei React Native höher ist und die Releases in jüngerer Zeit weiter auseinanderliegen.

Bei React Native liegt die durchschnittliche Wartezeit zwischen größeren Releases bei 66,9 Tagen, während sie bei NativeScript bei 61.3 Tagen liegt. Zusätzlich veröffentlich das Entwicklungsteam hinter React Native pro größerem Release durchschnittlich 4,4 Patches. Bei NativeScript sind es 2.4 Patches.

Beide Frameworks hatten damit über die letzen 15 Releases durchschnittlich etwa 6 größere Releases pro Jahr. Dazu kommen nocheinmal 14 (NativeScript), bzw. 26 (React Native) kleinere Aktualisierungen. Diese kommen abgesehen von ein paar Ausnahmen ohne Breaking Changes aus [8] [12].

Lizenz

Beide Frameworks sind recht offen lizenziert. Während React Native auf die MIT-Lizenz setzt, wird bei NativeScript die Apache 2.0 Lizenz verwendet.

Bei der Apache 2.0 Lizenz ist die Verwendung des Projektnamens etwas ristriktiver. In der Praxis entscheiden sich die Lizenzen allerdings nicht wirklich relevant. So ist man etwa nicht zur Herausgabe des gesamten Quellcodes verpflichtet, wie dies bei GPL-Lizenzen der Fall sein kann.

Table 2. Lizenz
Framework Lizenz

React Native

MIT

NativeScript

Apache v 2.0

Programmierung und Pattern

React Native und NativeScript unterstützen beide nativ JavaScript (ES 6) und TypeScript.

NativeScript wirbt außerdem auf der Website mit guten Integrationsmöglichkeiten von Angular und Vue.js. React Native dagegen ist näher an React orientiert und wirbt mit Component-Reuse von React-Komponenten.

NativeScript verwendet für das Styling außerdem CSS, während React Native auf CSS-ähnliche Styleselektoren setzt.

Beide Frameworks unterstützen Android und iOS und generieren jeweils eine App für jedes Betriebssystem aus dem gemeinsamen Quellcode.

In Bezug auf Design Patterns ist React Native wie auch React sehr am Komponentensystem orientiert. Komponenten werden als abgeschlossene Einheiten betrachtet und enthalten alle dazugehörigen Domainobjekte, Programmlogik und Styles.

NativeScript dagegen setzt auf starke MVC-Trennung. Hier werden Anzeigestruktur, Styling und Programmlogik stark entkoppelt. Das Styling geschieht über CSS, die Strukturdefinition und Anordnung der UI-Elemente über WPF-artige XML-Definitionen und die Programmlogik in TypeScript- oder JavaScript-Dateien. Die Programmlogik ist dabei über Observables mit UI-Struktur verbunden.

React Native hat ein etwas restriktiveres Statemanagement. Anstatt von einfachen Klassen- oder Instanzvariablen wird hier insbesondere bei UI-nahem Code ein effectively-final Statemanagement mit klaren Statusübergängen verwendet. Mehr dazu im Artikel zu React Native [1].

Beide Anwendungs-Frameworks unterstützen Hot Reloading beim Speichern geänderter Quellcodedateien. NativeScript bietet zusätzlich noch Apps, beispielsweise für Android an, mit denen der entwickelte Code direkt auf einem Smartphone getestet werden kann. Sogar ohne USB-Debugging. Auch für React Native gibt es hierfür Apps, allerdings von dritten Parteien.

Table 3. Komparative USPs im Bezug auf Programmierung und Design Patterns (ungeordnet)
React Native NativeScript

react-nah

echtes CSS Styling

komponenten-orientiert

strikte MVC-Trennung

Performance

Einige Quellen berichten von signifikanten Performanceunterschieden zwischen React Native und NativeScript. Diese konnten wir im Mai 2020 nicht reproduzieren. Es ist wahrscheinlich, dass diese Performancedifferenzen zu einem früheren Zeitpunkt bestanden und bei NativeScript vor einiger Zeit Maßnahmen zur Performanceangleichung ergriffen wurden. Darauf weisen zumindest die Changelogs hin. [8]

Vergleichbar mit Ionic oder Corova sind React Native und NativeScript von der Performance her kaum: Beide Frameworks kompilieren den Quellcode in eine native App mit nativen UI Komponenten. Dadurch und in Kombination mit dem durchgehend reaktiven Observermodell performen sie in fast allen Anwendungsfällen signifikant besser als die Lösungen mit WebView. Sogar bei trivialen Layouts.

Stabilität scheint aktuell bei keinem der beiden Frameworks ein besonderes Problem darzustellen. Allerdings gab es bei React Native ab und an Breaking Changes bei Versionssprüngen. Diese sind dann allerdings im Changelog explizit unter "BREAKING CHANGES" erwähnt.

Häufig sind diese jedoch nicht seitens des Frameworks motiviert, sondern aufgrund einer Änderung an der unterliegenden Plattformen notwendig. So gab es sowohl bei React Native als auch bei NativeScript Mitte letzten Jahres eine neue Version mit größeren Änderungen, die aufgrund der Einführung der neuen Extension Library AndroidX erforderlich wurde [13].

Testbarkeit

Bei React Native wird seitens Facebook die Testingbibliothek Jest [9] gepushed. Jest ermöglicht sowohl einfach Unit-Tests als auch komplexere seleniumartige Oberflächentests auf Basis von Snapshots. Hierbei wird mit bestimmten UI-Elementen interagiert und es kann auf Ausgaben gewartet werden. Auch Mocks sind leicht umsetzbar.

Bei NativeScript werden in der Dokumentation unterschiedliche Testingframeworks für JUnit-Testing vorgestellt, etwa Jasmine oder Mocha [11]. Für End-To-End-Testing wird Appium empfohlen, mit dem jegliche mobilen Anwendungen getestet werden können [10].

Enterprise Users

Es gibt inzwischen viele Unternehmen außer Facebook, die React Native für ihre Apps verwenden. Dazu zählen etwa Microsoft, Tesla, Soundcloud, Uber, Tencent, Salesforce, Bloomberg oder Walmart.

Es gibt allerdings auch Beispiele aus der Unternehmenswelt, bei denen Unternehmen von React wieder weg migriert sind. Airbnb hat dazu eine fünfteilige Artikelserie veröffentlicht [14]. Es ist zu beachten, dass viele dortgenannten Painpoints inzwischen seitens React Native behoben wurden.

Bei NativeScript ist die Liste der bekannteren Unternehmen etwas kürzer. Erfolgsbeispiele von der Website von NativeScript sind Sennheiser, Magpi, PUMA oder Deloitte

Wie ist das ganze nun einzuordnen?

Analyse

React Native ist im Vergleich zu NativeScript das signifikant populärere Framework. Dies zeigt sich in Google Trends, der StateOfJs-Umfrage von 2019 [7] sowie der über 10-fachen Engagementrate auf GitHub und StackOverflow. Auch gibt es signifikant mehr bekannte Namen unter den tatsächlichen Verwendern des Frameworks. Diese Popularität ist möglicherweise der Unterstützung durch Facebook bei Entwicklung und Vermarktung geschuldet.

Eine hohe Popularität kann insbesondere bei langlaufenden Enterpriseprojekten wichtig sein, da hier die Kosten für eine Migration sehr schnell nach oben schießen können. Eine kleinere Community und weniger kommerzielle Unterstützer in Kombination mit einem geringeren Marktanteil erhöhen natürlich die Wahrscheinlichkeit eines Entwicklungsstopps aufgrund zu weniger Nutzer und einer stärkeren Position eines Substituts. Natürlich kann es auch bei größeren Communities zu Spaltungen und massiven Einschränkungen in der Rückwärtskompatibilität kommen, wie es beispielsweise bei Python 2 und Python 3 in der Vergangenheit schon der Fall war.

Eine größere Community impliziert also nicht in jedem Fall auch eine bessere langfristige Orientierung. Das viele verfügbare Material für React Native auf Google und insbesondere Stack Overflow erleichtert außerdem für neue Entwickler den Einstieg und untertützt beim Entwicklungsprozess immens. Hier versucht NativeScript mit einer umfassenden eigenen Dokumentation und Getting-Started-Guides nachzuhelfen. React Native hat natürlich auch derartige Guides und Tutorials, setzt aber allgemein eher auf den Content der Community.

Die Releasezyklen sind bei beiden Frameworks schwer planbar und die Releases sind sehr unregelmäßig. Bei NativeScript scheinen die Releasezyklen sich über die letzten Releases jedoch bei ca. 50 Tagen Abstand eingefunden zu haben. Bei React Native ist es nach wie vor sehr volatil.

Zusätzlich gibt es bei React Native für jeden Release durchschnittlich doppelt so viele Minorpatches wie bei NativeScript.

Allgemein geht der Trend bei React Native eher zu längeren Releasezyklen, während es bei NativeScript in Richtung kürzerer Zykeln geht. Dies lässt sich in der Abbildung 4 oben anhand des gleitenden Durchschnitts über die letzten 5 Releases ablesen. Weniger Tage bedeuten hier eine höhere Agilität (s. oben) und weniger Volatilität erhöht die Planbarkeit und Verlässlichkeit, sowie die Wartbarkeit im Enterpriseumfeld.

Ein im Enterpriseumfeld sicherlich sehr wichtiger Punkt ist Lizenzierung. React Native setzt hier auf MIT, während NativeScript Apache 2.0 verwendet. Beide Lizenzen sind relativ offen.

Zwischen den beiden Frameworks gibt es auch strukturell einige Unterschiede. Ein relevanter Stichpunkt ist hier das MVC-Pattern. Ohne strukturelle Trennung zumindest von User Interface und Programmlogik kann es bei größeren Anwendungen schnell sehr unübersichtlich werden. Wartung und Bugfixing werden mangels klar definierter Struktur schnell zu überaus aufwendigen und zeitraubenden Angelegenheiten. NativeScript legt hier im Kontrast zu React Native großen Wert auf diese MVC-Trennung. Positiv anzumerken ist außerdem die Verwendung von CSS zum Styling an Stelle der CSS-artigen proprietären Lösung bei React Native.

React Native ist weniger strikt und gibt den Entwicklern größere Freiheiten, was insbesondere in großen Teams ohne Absprachen zu unterschiedlichsten Vorgehensweisen führen kann. So kann in React Native beispielsweise sowohl sehr objektorientiert, als auch sehr funktional programmiert werden. Hier wäre es sicherlich sinnvoll, seitens der Projektsteuerung einige Design Guidelines vor Beginn des Projektes festzulegen, um ein Maintainability-Desaster zu vermeiden.

In Bezug auf Performance tun sich die beiden Frameworks nur wenig. Eventuelle Performanceunterschiede, die in der Vergangenheit möglicherweise bestanden, sind heute offenbar ausgemerzt.

Erwähnenswert ist hier zusätzlich, dass sowohl NativeScript als auch React Native nicht die optimale Wahl für grafisch aufwendige Anwendungsfelder wie AR oder 3D-Rendering sind. Für Spiele oder Augmented-Reality-Projekte sollte die Wahl eher auf Cross-Plattform 3D Engines wie Unity oder gleich vollnative Anwendungen fallen.

Im Bezug auf die Testbarkeit schlagen sich beide Frameworks ähnlich gut.

Welches Framework also für welchen Anwendungsfall?

Fazit

Diese Frage sollte nach diesem Artikel hoffentlich jeder für sich selbst beantworten können. Falls nicht helfen wir natürlich gerne.

Für unsere Projekte ist insbesondere die striktere MVC-Trennung in NativeScript ein relevanter Punkt. Darauf legen unsere Kunden wert, da sich diese Stärke insbesondere in größeren Projekten hervorragend ausspielen lässt. Spätestens wenn Designer und Entwickler nicht mehr die gleiche Person sind, kanne es hier bei React Native zu Konflikten kommen.

Wenn die Rollenaufteilung im Team eher komponentenbasiert abläuft, funktioniert das natürlich auch mit React Native. Hier sind die zu einer Komponente gehörenden Teile wie Logik und UI eher beieinander. Natürlich ließe sich das auch mit Nativescript und einer vernünftigen Projektstruktur so abbilden.

Aus Erfahrung können wir berichten, dass die Entwicklungsgeschwindigkeit bei React Native Apps ganz zu Beginn des Projektes aufgrund des geringeren strukturellen Overhead signifikant höher sein kann. Bei trivialen oder aus vielen atomaren Komponenten bestehenden Userinterfaces lassen sich die Vorteile von React Native hier gut ausspielen.

Referenzen




Zu den Themen React, NativeScript, Vue und Angular bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:

Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.

Über Steffen Jacobs

Steffen Jacobs (M.Sc) hat Wirtschaftsinformatik an der Universität Mannheim studiert und ist als Consultant und Software-Entwickler tätig. In seiner Freizeit engagiert er sich im OpenSource Umfeld.

  • Geschrieben von Steffen Jacobs am 6. Juli 2020
Feedback oder Fragen zu einem Artikel - per Twitter @triondevelop oder E-Mail freuen wir uns auf eine Kontaktaufnahme!

Kategorien

Nach Jahr

Zur Desktop Version des Artikels