ReactNative Vs NativeScript, chi vincerà?

Tempo di lettura: 6 minuti Skills Updated: framework JavaScript 1) D1 LICENSE AND COSTS • REACTNATIVE: Open source e gratuita. ►voto* 5 • NATIVESCRIPT: Open source e gratuita. ►voto 5 __________________________ 2) D2 Long-term Feasibility • REACTNATIVE: GitHub: - Watch: 2,793 - Star: 42,179 - Fork: 9,642 Enterprise Support: - Facebook Stabile da Marzo 2015, gode di una community molto attiva e numerosa, updates e commit risultano costanti nel tempo. Ha tutti i presupposti per durevolezza e stabilità a lungo termine. ►voto 5 • NATIVESCRIPT: GitHub: - Watch: 573 - Star: 9,106 - Fork: 709 Enterprise Support: - Telerik Stabile da Marzo 2015, ha una community significamente ridotta rispetto React Native. Le attività della community risultano meno regolari, ma comunque molto rappresentative visto il gap nel numero di partecipanti. Con minori garanzie rispetto ReactNative, la tecnologia sembra comunque pronta a garantire supporto a lungo termine. ►voto 3 __________________________ 3) D3 DOCUMENTATION AND SUPPORT • REACTNATIVE: Documentazione ben strutturata. La suddivisione in guide componenti e APIs la rende di facile e immediata lettura. Presenti molti blog/tutorial e articoli non ufficiali. Si nota però una carenza a livello di best practice riguardanti alberatura interna dei files e strutturazione del codice, non colmata da esempi concreti e funzionanti di medio-alto livello. Molto presente e discusso su StackOverflow. StackOverflow tag: - 4.8k followers - 9.4k questions ►voto 3 • NATIVESCRIPT: Documentazione ben strutturata e di facile comprensione per tutti i livelli di expertise. Si concentra principalmente su canali ufficiali, ben supportati e molto descrittivi. Meno presente e discusso su StackOverflow. Stackoverflow tag: - 378 followers - 1.4k questions ►voto 4 __________________________ 4) D4 LEARNING SUCCESS • REACTNATIVE: Il Getting Started suddiviso per iOS/Android permette di avere un ambiente già pronto ad ospitare un’applicazione correttamente funzionante per entrambe le piattaforme, in pochi e semplici passi. Il tutorial introduce i componenti base di un’applicazione, anch’esso ben strutturato. Nonostante, però, resti discutibile la scelta dell’ordine di presentazione delle componenti stesse. Sono sicuramente avvantaggiati nell’apprendimento sviluppatori che conoscono i costrutti nativi o di altri native framework. Vengono, infatti, utilizzati molteplici pattern propri dello sviluppo mobile nativo. Difficile il passaggio dal basic ad applicazioni complesse. Non essendo accompagnato, questo processo crea poca chiarezza nella visualizzazione delle specifiche rispetto all’organizzazione del codice. ►voto 3 • NATIVESCRIPT: Il Getting Started, rispetto a ReactNative richiede maggiori passaggi per preparare l’ambiente ma questo gap viene ampiamente colmato dalla precisione e supporto dato dalla guida. Il tutorial introduce i concetti in maniera semplice e intuitiva comprendendo anche nozioni utili riguardanti Angualr 2 e TypeScript. Per Sviluppatori meno esperti o incuriositi, vengono messi a disposizione esempi, guide e link a fonti ufficiali rispetto ad ogni argomento trattato. Un passo avanti saranno gli sviluppatori Anguar 2: visti i pochi patterns strettamente legati a NativeScript, si è già pronti a sviluppi complessi con questa tecnologia. ►voto 4 __________________________ 5) D5 DEVELOPMENT EFFORT • REACTNATIVE: Una volta appresa la logica dello strumento, diventa davvero veloce costruire applicazioni dal layout semplice. Il codice, se non vi è la presenza di componenti specifiche per piattaforma, è completamente crossplatform. Potrebbe risultare poco vantaggioso per layout complessi: il framework utilizza JSX come linguaggio di Markup e il CSS (in formato JSON) è limitato nelle dichiarazioni. Non è possibile quindi utilizzare estensioni come SCSS e riutilizzare stylesheet web per intero, in quanto i selettori utilizzati sono mobile oriented. ►voto 3 • NATIVESCRIPT: L’effort per il developer è molto basso in quanto ci sono pochissimi patterns che si differenziano da Angualr 2. Il codice, se non vi è la presenza di componenti specifiche per piattaforma, è completamente crossplatform. Il framework utilizza HTML come linguaggio di markup e un subset delle regole CSS. Questo lo rende accessibile anche a Frontender HTML/CSS specific. È inoltre molto semplice gestire le differenze tra iOS/Andorid attraverso l'uso di file specifici. ►voto 5 __________________________ 6) D6 EXTENSIBILITY • REACTNATIVE: Sono presenti molteplici plugins ed estensioni. È bene sottolineare, però, che la loro scrittura da zero richiede competenze in Objective-C e Java per Android. ►voto 3 • NATIVESCRIPT: Estensioni e plugins sono gestiti come moduli npm. I più popolari, supportati da NativeScript, vengono riassunti nella pagina git. NativeScript mette a disposizione API e tutorial per scrivere anche funzionalità ex novo, le quali vengono comunque gestiste via TypeScript, ad eccezione del comando nativo. Diversamente da ReactNative, è facile e intuitivo. ►voto 5 __________________________ 7) D7 MAINTAINABILITY • REACTNATIVE: La modularità propria del codice e la facilità di suddivisione in files dello stesso, ne garantisce un’alta manutenibilità e riusabilità. È inoltre possibile integrare il framework con applicazioni già esistenti e avere un semplice scambio js - nativo. ►voto 4 • NATIVESCRIPT: Grazie anche a TypeScript e Angualr 2 il codice è fortemente modulare, manutenibile e ampiamente riutilizzabile. ►voto 4 __________________________ 8) U1 USER INTERFACE ELEMENTS • REACTNATIVE: ReactNative mette a disposizione molti componenti per la realizzazione di UI Native. Altre, e più specifiche, sono raggiungibili tramite estensioni e plugins. Ci sono inoltre librerie cross platform come NativeBase, Shoutem o altre specifiche per piattaforma. ►voto 4 • NATIVESCRIPT: NativeScript utilizza gli elementi nativi, portandoli ad un livello più alto, invisibile allo sviluppatore, il quale interagisce con essi tramite TypeScript. Resta a libera scelta, l'utilizzo di un codice unico per entrambe le piattaforme o esplorare ogni SO. ►voto 4 __________________________ 9) U2 NATIVE LOOK & FEEL • REACTNATIVE: Il Look & Feel è conforme con quello nativo per entrambe le piattaforme. I componenti nativi vengono infatti renderizzati in base alla piattaforma che li esegue. ►voto 5 • NATIVESCRIPT: Il Look & Feel è conforme con quello nativo per entrambe le piattaforme. I componenti nativi vengono infatti renderizzati in base alla piattaforma che li esegue. ►voto 5 __________________________ 10) U3 BUILD AND DEPLOY • REACTNATIVE: La build è immediata: è sufficiente lanciare un comando da terminale per effettuare una build della piattaforma interessata. Per il deploy e signing è presente un'ampia documentazione per entrambe le piattaforme. ►voto 4 • NATIVESCRIPT: La build è immediata: è sufficiente lanciare un comando da terminale per effettuare una build della piattaforma interessata. Per il deploy e signing è presente un'ampia documentazione per entrambe le piattaforme. ►voto 4 __________________________ 11) U4 RUNTIME PERFORMANCE • REACTNATIVE: Motore di rendering: Nativo (no WebViews). Le performance sono ottime. Non si notano differenze rispetto al nativo sia per iOS che per Android. ►voto 5 • NATIVESCRIPT: Motore di rendering: Nativo (no WebViews). Le performance sono ottime. Non si notano differenze rispetto al nativo sia per iOS che per Android. ►voto 5 *valutazione da 1 a 5. Non assoluta ma da considerarsi in rapporto fra i due framework. CONCLUSIONI: REACTNATIVE ►voto 44 NATIVESCRIPT ►voto 48 Entrambi i framework superano l'esame, come si nota dal confronto. Le uniche differenze si evidenziano esclusivamente nei punti D:Criteria of the developer’s perspective: entrambi riescono a garantire risultati perfettamente conformi con quelli nativi. ReactNative conta su un vasto supporto dalla community e una durabilità a lungo termine, nonostante però sia meno intuitivo e potrebbe quindi perdere questo predominio con l'avvento di framework emergenti che sfruttano meglio le conoscenze pregresse. Nativescript, tecnologia con meno follower (non si tratta comunque di un prodotto indipendente visto che viene supportata da Telerick e ha collaborazioni con Google), ha come grosso vantaggio la possibilità di utilizzare TypeScript e Angular2 ( con html/css) e quindi spesso il know how è già acquisito dalla maggioranza dei Frontender. Come opinione personale ai Developer con conoscenze di sviluppo nativo per azioni strettamente legati a SO e periferiche, consiglierei di utilizzare ReactNative così da poter intervenire in nativo sfruttando al contempo tutta la parte di business logic e navigazione dell'applicazione. Mentre NativeScript lo suggerirei più come strumento per applicazioni spesso ricorrenti dove, oltre alla parte meramente funzionale, si ha anche l'esigenza di un layout accattivante. Oppure ancora è utile per applicazioni che possiedono una parte di componente web. Con NativeScript è possibile utilizzare gran parte del codice come codebase shared tra devices e browsers. E VOI, QUALE PREFERITE? Criteria of the developer’s perspective • D1 License and Costs: this criterion examines licensing costs that accrue for developing and publishing a commercial app based on the respective framework. • D2 Long-term Feasibility: indicators of long-term feasibility are popularity, update behavior, and the development team. Popularity can be assessed through a high diffusion rate among app developers and recognition in the developer community, for example through reviews. A positive update behavior is marked by short update cycles and regular bug-fixes. A framework with a strong development team, ideally backed by several commercial supporters, is more likely to continue to exist in the future. • D3 Documentation and Support: documentation and further support channels assist developers in learning and mastering a framework. • D4 Learning Success: the learning success is examined separately. It mainly depends on the subjective progress of a developer during initial activities with a framework. Intuitive concepts, possibly bearing resemblance to already known paradigms, can be mastered quickly. To a minor extent, this criterion also considers the effort needed for learning new concepts after initial orientation. • D5 Development Effort: the development effort is characterized by the time needed for implementing apps with the framework. Indicators for a framework that ease development are expressive power, an easy-to-understand syntax, reusability of code, and good tool support. The latter includes an Integrated Development Environment (IDE), which facilitates implementation and possibly GUI design, as well as debugging facilities. • D6 Extensibility: this will be easier and more stable if a framework offers corresponding features such as a plug-in mechanism. As a last resort, app developers might adapt the source code of the framework itself, provided it is available. Besides considering the existence of extensibility measures, this criterion assesses their usefulness and accessibility. • D7 Maintainability: this criterion is positively correlated with comprehensibility of the source code and its modularity. Both indicators depend on the framework used to implement the app. A framework that allows for concise but understandable code will improve comprehensibility. Modularity requires the possibility to separate different parts of an app into distinct units of code. Criteria of the user’s perspective • U1 User Interface Elements: this criterion assesses whether a framework offers widgets such as buttons or text fields and their layout in containers, as well as their quality. Structural elements need to address limited screen sizes and particularities of touch-based interaction and support behavioral UI elements such as animations and gestures. • U2 Native Look & Feel: apps with a native UI have a platform-specific appearance and behavior. As this is an often mentioned requirement of apps, this criterion assesses whether a framework offers support for a native look & feel. • U3 Build and deploy: this criterion is positive if the framework offer tool or facilities for build and deploy app easily. Better if it permit a single build process for different platforms. • U4 Runtime Performance: the UI elements need to react quickly to user interactions and animations should be smooth for a high-quality user experience.