Facebook mangerà tutto con React Native.

Con la benedizione e la leva di una entusiasta comunità open source, Facebook guadagnerà rapidamente quote di mercato nelle categorie hardware e software mobili.

Come consumatori, saremo estremamente grati quando Facebook estinguerà le quote di mercato mobile di Google e Apple. Come sviluppatori, non dovremo scrivere applicazioni per iOS, Android, Web e VR con basi di codice disgiunte.

Questa non è una strategia a somma negativa come abbracciare, estendere, estinguere.

La comunità open source sta convergendo su una serie di standard e Facebook trarrà il massimo da essa perché Facebook ha la maggior parte del talento ingegneristico di React.

Facebook rilascerà un telefono con un nuovo tipo di sistema operativo che spezzerà il duro duopolio di Apple e Google con 10 miglioramenti dell’ecosistema. Questo non sarà difficile da fare – quando uscirà il primo buon telefono di Facebook, le persone capiranno quanto Apple e Google si siano appoggiati sui loro allori duopolistici.

La rivoluzione mobile è stata un grande balzo in avanti per i consumatori e un grande balzo indietro per gli sviluppatori. Omologazioni dell’app store black box, piattaforme di sviluppo opache, linguaggi non JavaScript, ridondanza del codice: l’elenco dei problemi nell’ecosistema mobile duopolistico è numeroso. React risolverà tutto.

Perché React è popolare?

La produttività degli sviluppatori è migliorata. I critici di JSX di solito decidono di apprezzare lo strano markup dopo averlo provato. Nella mia esperienza, passare da TODO MVC a un’app complessa richiede meno sforzi in React che in AngularJS.

Il codice dichiarativo semplifica il ragionamento sul comportamento dell’applicazione. “React avvolge l’API mutativa e imperativa del DOM con una dichiarativa, che aumenta il livello di astrazione e semplifica il modello di programmazione”. I componenti di React descrivono lo stato dell’interfaccia utente in ogni momento.

Il flusso di dati a senso unico porta a enormi miglioramenti delle prestazioni. “Il flusso di dati unidirezionale di React mantiene tutto modulare e veloce”, scrive Pete Hunt. La velocità di React viene confrontata con altre librerie JavaScript nella divertente conversazione di Ryan Florence di ReactJS Conf Europe.

Quali sono le sinergie tra Flux, React, GraphQL e Relay?

Le librerie di Facebook sono accoppiate liberamente. Non è obbligatorio utilizzare alcuna combinazione specifica.

  • React utilizza i componenti di visualizzazione con un flusso di dati unidirezionale. Il flusso di dati a direzione singola semplifica il rendering DOM.
  • Il flusso è un modello per il ragionamento sulle applicazioni con flusso di dati unidirezionale. Risolve alcuni problemi del controller vista modello, come gli aggiornamenti a cascata. La comunità ha iterato su Flux con impazienza, con Redux di Dan Abramov come implementazione preferita.
  • Il relè è un framework per il recupero dei dati nelle applicazioni React. Uno sviluppatore può specificare la sua query all’interno di un componente, adiacente a dove utilizza il risultato della query. Diverse query all’interno dei sottocomponenti possono essere ridotte in una singola query, sottraendo dal round-trip-time per recuperare i dati da un server.
  • GraphQL è un linguaggio di query di dati per la descrizione di dipendenze di dati complessi e nidificati. Il relè utilizza GraphQL come linguaggio di query.

NewStack scrive :

L’idea centrale dietro Relay e GraphQL è che il codice di visualizzazione è il posto migliore per individuare il codice di recupero dei dati. Per fare ciò, ogni componente di React specificherà i suoi dati necessari usando le query GraphQL; Il relè quindi recupererà i dati specificati da GraphQL. Ci si potrebbe chiedere quale sia il valore aggiunto di Relay e perché GraphQL non raggiunga il server stesso per i dati, invece di specificare solo le esigenze dei dati. Il motivo è che ogni query GraphQL non si associa a Relay che esegue una richiesta del server, poiché ciò comporterebbe importanti penali di prestazione; questo sarebbe inefficiente perché spesso si specifica la stessa dipendenza dei dati in più punti.

Invece, Relay accetterà tutte le diverse query inviate e le raggrupperà insieme. Ciò significa che se si disponevano di più componenti React che specificano tramite GraphQL la stessa dipendenza dei dati, entrambi otterranno i propri dati dalla stessa richiesta del server tramite Relay. Per me, questo sembra simile al modo in cui i componenti di React dichiarano tutte le loro esigenze di rendering al DOM virtuale, che quindi si differenzia con il DOM effettivo prima di eseguire qualsiasi manipolazione. Sia il DOM virtuale che il relè consentono agli sviluppatori React di dichiarare esplicitamente le esigenze dei loro componenti, senza dover cercare di essere minimali per motivi di prestazioni.

Come funziona React Native?

“Impara una volta, scrivi ovunque” era il mantra originale di React Native.

Il nuovo slogan è “piattaforma orizzontale”. Ho visto le diapositive che descrivono questa piattaforma orizzontale a React Conf 2016, ma non sono ancora ampiamente distribuite online.

Fondamentalmente, React Native si trova in cima a qualsiasi piattaforma e la riattiva. Per “orizzontale” significano orizzontale su TV, telefoni, cuffie VR, monitor, hardware – qualsiasi cosa. Sembrerebbe arrogante se non ci fosse già una comunità open source intenzionata a costruire questa roba.

Dopo aver creato un’app Web in React.js, uno sviluppatore che desidera eseguire il porting su iOS o Android nativi deve riscrivere un po ‘di codice, ma il riutilizzo del codice è spesso nel campo di gioco del 60-80%. È molto meglio che riscrivere un’intera app in iOS e Android.

Le applicazioni native di React sono costituite sia da JavaScript che da codice nativo (Java o Objective C). JavaScript viene eseguito in una macchina virtuale sul dispositivo mobile e comunica con il codice nativo tramite un’interfaccia di passaggio messaggi JSON.

La motivazione di React Native era che Facebook ha perso la velocità degli sviluppatori quando gli ingegneri hanno iniziato a costruire le versioni mobili del sito Web di Facebook. Questo è un problema in qualsiasi organizzazione con app mobili su più piattaforme.

Gli sviluppatori Web possono vivere ricaricare il loro JavaScript semplicemente salvando i loro file e aggiornando la pagina. Gli ingegneri iOS e Android devono ricompilare l’intera app per vedere eventuali modifiche.

Questo punisce un’app ricca di design come Facebook, in cui gli sviluppatori vogliono modificare un pixel e vedere immediatamente il risultato.

Cosa non è React Native: la soluzione per app webview JavaScript di Appcelerator; Esportazione a due comandi di Meteor in nativo. Il porting di un’app dal Web al cellulare con buone prestazioni richiede lavoro.

Gli ingegneri di Facebook scrivono del porting di un’app dal web a React Native:

L’app doveva contenere molte logiche aziendali complesse per gestire accuratamente le differenze nei formati di annunci, fusi orari, formati di date, valute, convenzioni valutarie e così via. Gran parte di questo era già scritto in JavaScript. La prospettiva di scrivere tutto quel codice in Objective-C solo per poi scriverlo in Java per la versione Android dell’app non era allettante, né sarebbe efficiente. In React Native sarebbe facile implementare la maggior parte delle superfici dell’interfaccia utente che volevamo costruire, visualizzando molti dati sotto forma di elenchi, tabelle o grafici. Gli ingegneri di prodotto potrebbero essere immediatamente produttivi nell’implementare queste opinioni, purché conoscessero React.

Oggi, React è il terreno comune tra iOS, Android e sviluppatori web. Tra cinque anni, sarà il terreno comune tra tutti gli sviluppatori di applicazioni.

Gli ingegneri iOS e Android non saranno presto sostituiti dagli ingegneri React, ma Facebook sta abbattendo il silos tra ingegneri mobili e web.

Qual è la strategia aziendale di Facebook per mangiare l’ecosistema mobile con React?

Pronostico: Facebook costruirà un sistema operativo React.

Facebook vuole “unificare le implementazioni di basso livello e forse parlare direttamente con la GPU. Possiamo avere React che emette sul DOM virtuale e parla direttamente con la GPU e bypassare tutto questo stack che è preparatorio e costruire un nuovo stack progettato per React ”, ha affermato Christopher Chedeau.

Lo sviluppo di app native è attualmente ostacolato dai processi di revisione del Play Store e dell’App Store per iOS, che richiedono ore, giorni o mesi di tempo di consegna per inviare un aggiornamento e renderlo disponibile agli utenti.

Facebook vuole che gli sviluppatori mobili possano spedire le loro app native in modo continuo, proprio come fanno gli sviluppatori web.

“Sappiamo che il progetto [React] in questo momento è buono, ma non è qui che vogliamo andare. Siamo a lungo termine. Ci siamo profondamente impegnati. ”

Sebastian Markbage: “Stiamo cercando di vedere sempre più di queste modalità di output. Possiamo parlare di web, Android, disegno su tela, iOS. Ma molte aziende stanno facendo [altre] cose. Netflix sta prendendo di mira le TV utilizzando React e hanno un altro livello di visualizzazione. vogliamo rendere più semplice ottenere React su altre piattaforme su cui non ci stiamo concentrando in modo specifico. Altre società utilizzano React per i giochi, quindi eseguire React su console di gioco è una priorità per loro. Stiamo cercando di renderlo più disaccoppiato dal DOM e continuare con questa idea di React come modello di programmazione. ”

I dispositivi Android utilizzano Linux con la macchina virtuale Java. Java fornisce il runtime sottile per comunicare con l’infrastruttura cloud pesante di Google. Questo non è l’unico modello per “telefono stupido e smart cloud”.

La JVM potrebbe essere sostituita con Node.js per un modello di runtime tutto JavaScript.

La legge di Atwood è sempre presente. JavaScript sta diventando veloce con WebAssembly. Gli sviluppatori stanno convergendo su JavaScript perché è più divertente e veloce da imparare rispetto ai dispositivi mobili.

Dobbiamo rompere il duopolio mobile:

Sappiamo già che ci sono due sistemi operativi mobili dominanti là fuori. Ma la situazione attuale non consente a nessuno di sperimentare, non senza passare attraverso gli interessi e le lenti dei due giocatori dominanti: Apple e Google.

Ecco perché abbiamo bisogno di un terzo sistema operativo mobile per rompere questo duopolio e portarci verso un ambiente più aperto affinché chiunque possa innovare, senza permesso. Tanto più che i telefoni cellulari hanno iniziato a democratizzare e ampliare la portata della tecnologia in tutto il mondo … perché non dovremmo quindi anche democratizzare il sistema operativo mobile?

Oltre a migliorare la rilevabilità, la maggiore capacità di connettersi con gli utenti e una maggiore copertura geografica, un ambiente più aperto per l’innovazione mobile offre agli utenti di tutto il mondo la scelta .

Sembra una grande opportunità per Facebook.


Originariamente pubblicato su www.quora.com .