Native e PWA: scelte, non sfidanti!

È difficile dire esattamente dove sia iniziata davvero la spaccatura tra "nativo" e "web". Sento che è una di quelle cose che si agitavano appena sotto la superficie sin dai primi giorni di Flash, per poi esplodere più recentemente con l'ascesa delle piattaforme mobili. Indipendentemente da ciò, gli sviluppatori hanno affrontato questa "grande voragine", lanciandosi insulti l'un l'altro nel tentativo di rafforzare la propria parte.

Non ho alcun interesse in quella lotta. Certo, sono un "ragazzo del web", ma ciò non significa che non riesco a vedere il fascino dello sviluppo nativo; Sono anche uno sviluppatore di software. Soprattutto, però, sono un pragmatico. Mi rendo conto che ogni progetto è diverso e che il nostro approccio a ciascuno dovrebbe essere adattato alle esigenze e agli obiettivi del progetto.

Con le Progressive Web Apps (PWA) che invadono il territorio dello sviluppo nativo, ho pensato che questo potesse essere un buon momento per fare un passo indietro e fare il punto su questi due approcci alla creazione di prodotti. La mia speranza è che ce ne andremo tutti con la capacità di vedere chiaramente i punti di forza di ogni approccio nella speranza di trovare la soluzione giusta per i prodotti che creiamo.

Un confronto a fuoco rapido

Fin dall'inizio, le esperienze basate sul Web sono state confrontate con qualsiasi cosa, dal software desktop (le "app native" originali) ai CD-ROM interattivi a Flash e, più recentemente, alle app mobili. Nonostante sia stato dichiarato morto in numerose occasioni, il web ha resistito. In molti casi, è persino sopravvissuto ai suoi presunti assassini (RIP Flash).

Uno dei principali punti di forza del web in questo senso è la sua adattabilità. È stato in grado di andare praticamente ovunque ci sia una connessione Internet e continua ad acquisire nuove funzionalità. Tutti i linguaggi di programmazione si evolvono, quindi non è inaspettato, ma nel tempo i confini crescenti del web hanno continuato a invadere il territorio del software tradizionale.

Tuttavia, un'area in cui storicamente il web è venuto meno è stata quella delle prestazioni. Il software installato è in grado di collegarsi al sistema operativo sottostante in modi che il Web semplicemente non può. Sono scritti nella lingua franca del loro host, con accesso diretto all'hardware o "più vicino al metallo", come spesso diciamo. Il web, che gestisce quasi sempre uno o più livelli di astrazione al di sopra di quello, ha avuto difficoltà a competere quando si tratta di prestazioni. Sebbene il divario di prestazioni si sia ridotto nel tempo, è probabile che il codice nativo continui a funzionare più velocemente del codice Web, almeno fino a quando il Web non sarà in grado di interpretare i segnali direttamente dai pin dell'hardware.

Di pari passo con il vantaggio in termini di prestazioni, lo sviluppo nativo ha un accesso molto maggiore (e precedente) alle funzionalità del dispositivo come NFC, Bluetooth, sensori di prossimità e luce ambientale e altro ancora. Anche il Web ottiene costantemente l'accesso a queste funzionalità, ma rimarrà sempre indietro rispetto a quello nativo perché le API native devono essere sviluppate prima che il Web possa attingere a esse e la standardizzazione nel panorama del browser richiede tempo.

Inoltre, il codice nativo può collegarsi a funzionalità a livello di sistema operativo come la rubrica e i calendari. Le notifiche push erano un altro grosso problema, ma i Service Workers ora consentono al Web di sfruttare anche questa funzione. L'elaborazione dei pagamenti è migliorata in modo simile sul Web di recente. Forse alla fine arriverà anche sul web l'accesso alla rubrica e al calendario.

Tornando per un momento a Service Workers, questa recente aggiunta alla cassetta degli attrezzi dello sviluppatore web ha anche una serie di altri assi nella manica. Innanzitutto, offre un sistema di memorizzazione nella cache molto più robusto di quello che il Web aveva in precedenza con AppCache. Puoi utilizzare Service Workers per gestire le richieste offline, memorizzare nella cache risorse specifiche, sincronizzare i dati con un server remoto quando l'utente non ha nemmeno il sito aperto e molto altro ancora. Forse più di ogni altra singola tecnologia, i Service Workers hanno consentito al Web di offrire un'esperienza più simile a un'app.

I Service Workers sono uno dei tre cardini tecnici delle PWA. Un altro è il Manifesto dell'app Web. Anche se può sembrare un po' noioso, un manifesto di app Web è in realtà uno strumento incredibilmente potente in quanto consente a un sito Web di pubblicizzarsi come app. Questo formato di file JSON relativamente semplice fornisce una vasta gamma di informazioni sul sito Web che descrive e consente a browser e sistemi operativi compatibili con PWA di installare il sito come se fosse un software nativo.

Alcuni app store stanno persino iniziando a indicizzare le PWA, utilizzando il loro manifest per popolare le voci associate. Dal punto di vista dell'utente, le PWA negli app store non sono diverse dalle app native che le circondano. Sono installabili, disinstallabili e possono persino esporre le loro impostazioni allo strumento di gestione delle app del sistema operativo sottostante. Vale anche la pena notare che le PWA in realtà non hanno bisogno di un utente che le installi esplicitamente per usarle perché, beh, vivono sul web.

Essere sia sul web che sul web significa anche che le PWA sono sempre aggiornate. Gli utenti non dovranno scaricare attivamente nulla di nuovo per accedere a nuove funzionalità. E anche quando vengono implementati nuovi contenuti e funzionalità, è altamente improbabile che un utente debba scaricare nuovamente l'intera PWA come farebbe nel caso della maggior parte delle app native. Semmai, potrebbero ottenere alcune nuove risorse e un nuovo HTML, e ciò accadrebbe abbastanza istantaneamente, non è richiesto alcun app store. Naturalmente, hai ancora l'opzione di scoperta e distribuzione fornita dagli app store, quindi è davvero il meglio di entrambi i mondi.

Essere negli app store mette le PWA sullo stesso piano delle app native in termini di scoperta, distribuzione e monetizzazione. In effetti, potrebbe persino scavalcare il Web su nativo poiché le PWA sono rilevabili anche tramite i motori di ricerca e sono infinitamente più condivisibili delle app perché esistono in un URL. Se ben costruite, le PWA sono anche interoperabili tra browser, piattaforme e dispositivi. Le PWA funzionano anche in browser che non supportano funzionalità come Service Workers, perché le funzionalità PWA sono miglioramenti progressivi.

Il Web offre anche un supporto per l'accessibilità molto maturo, rendendo relativamente facile garantire che i tuoi progetti siano utilizzabili dal maggior numero di utenti. Le interfacce complesse richiedono un po' più di diligenza quando si tratta di programmazione, ma i vantaggi di accessibilità offerti dall'HTML semantico gestiscono l'accessibilità di base con disinvoltura, specialmente quando si tratta di prodotti ricchi di testo, informativi o semplici basati su moduli. Al contrario, è quasi sempre necessario essere consapevoli e incorporare le API di accessibilità nel codice nativo.

Sul tema dello sviluppo, non credo che ci sia un chiaro vincitore quando si tratta di esperienza di sviluppo. Ogni lingua ha i suoi fan e lo stesso si può dire per gli strumenti di sviluppo. Ti piace quello che ti piace e tendi ad essere più efficiente con gli strumenti e le lingue che conosci e di cui sei appassionato. Né il web né lo sviluppo nativo hanno alcun vantaggio distinto lì.

Il punto in cui lo sviluppo nativo brilla, tuttavia, è quando si tratta di garantire un livello costante di qualità per le interfacce utente, costruite utilizzando i loro SDK (Software Development Kit). La maggior parte degli SDK nativi offre strumenti per testare prestazioni, design, funzionalità e altro ancora. Includono anche codice standard, sistemi di progettazione e altri strumenti che aiutano ad aumentare il livello generale delle offerte di software nativo. Certo, ci sono strumenti simili per il web, ma sono sparsi sul web e non sono universali in tutti i diversi ambienti di sviluppo che le persone usano per creare siti web. Non esiste un'unica entità che definisca esperienze web di qualità e fornisca gli strumenti per costruirle (sebbene molti ci abbiano provato).

Quando si tratta di assumere personale per lo sviluppo di un prodotto, è sicuramente più facile assumere persone che sappiano come creare per il web. Mentre scrivo, l'indice del linguaggio di programmazione attualmente classifica JavaScript come il linguaggio più popolare, con Java proprio dietro di esso. C# è al 5° posto, HTML al 7°, CSS al 9° e Swift al 15°. Questo indice incrocia i tag Stack Overflow con le righe modificate nei repository pubblici su GitHub, quindi dovrebbe essere preso con le pinze, ma fornisce un'indicazione abbastanza chiara che molte persone conoscono (e utilizzano) le tecnologie web. D'altra parte, spesso può essere difficile trovare e assumere sviluppatori nativi di talento perché ce ne sono meno e sono molto richiesti.

Un talento scarso significa che probabilmente finirai per pagare di più per lo sviluppo nativo. Ogni progetto è ovviamente diverso e ha caratteristiche e requisiti diversi, ma può essere illustrativo considerare i costi medi di sviluppo come confronto. Commentum suggerisce che la creazione di un'app Web di dimensioni moderate varia da meno di $ 10.000 a $ 150.000. Dal punto di vista nativo, Appster stima che la realizzazione di progetti di app mobili di dimensioni moderate costi tra i 110.000 e i 305.000 USD. Probabilmente è lecito ritenere che i progetti nativi possano costare circa il doppio da sviluppare rispetto a un progetto web. E questo è per piattaforma. Anche le app native in genere richiedono più tempo per essere sviluppate.

Vale la pena notare che esistono opzioni per la creazione di software nativo utilizzando le tecnologie Web senza creare una PWA. Framework come React Native, PhoneGap, Ionic e Appcelerator Titanium ti consentono di generare codice nativo da HTML, CSS e JavaScript. L'utilizzo di uno di questi strumenti potrebbe ridurre i costi di personale e sviluppo rispetto all'assunzione di un team di sviluppatori nativi, ma in termini di accesso alle funzionalità del dispositivo, il tuo progetto sarà limitato a quelli implementati dal framework. Pianifica di conseguenza.

Una volta sviluppata l'app, devi anche tenere conto dei costi di manutenzione continua di detta o app. In risposta a un sondaggio condotto da Clutch, Dom & Tom consiglia di preventivare il 50% del prezzo iniziale del prodotto nel primo anno, il 25% nel secondo anno e tra il 15-25% per ogni anno successivo.

Una volta che hai una conoscenza decente di come si confrontano e contrastano lo sviluppo web e nativo, puoi iniziare a valutare quali punti di forza e di debolezza sono rilevanti per il tuo progetto. Probabilmente dovrai fare dei compromessi, e c'è da aspettarselo. Non esiste una soluzione valida per tutti. E se ci fosse, non starebbe bene a nessuno.

Esaminiamo un paio di ipotetici progetti per mettere a fuoco più chiaramente le distinzioni tra sviluppo per nativi e PWA.

Progetto n. 1: un'app nativa esistente

Diciamo che hai già completato il processo di creazione di un'app nativa. Se tutto sta andando bene, non c'è motivo di cambiare rotta. Non buttare via tutto il tuo lavoro esistente per passare a una PWA a meno che tu non abbia davvero una buona ragione per farlo. Posso davvero pensare solo a uno scenario che potrebbe giustificare la considerazione di un passaggio a PWA: portare il supporto per un nuovo sistema operativo nel mix. E anche in questo caso, ha davvero senso solo se le esigenze della tua app possono essere soddisfatte solo dal Web.

Se si aggiunge il supporto per una nuova piattaforma a un prodotto, si crea l'opportunità perfetta per valutare le esigenze e gli obiettivi del progetto in relazione al costo per soddisfare tali esigenze. Se il Web non è all'altezza del compito, mantieni il nativo. In tal caso, tuttavia, fai una pausa e considera questo: l'aggiunta del supporto per la nuova piattaforma utilizzando una PWA ti consentirebbe di supportare piattaforme aggiuntive (incluso il Web) lungo la strada e potrebbe persino consentirti di sostituire la tua applicazione nativa esistente una volta che la PWA ha stato accuratamente testato.

Se la sostituzione di un'app nativa esistente con una PWA ti sembra impensabile, considera questo: Starbucks e Twitter stanno già esplorando questa idea.

Se ci sono motivi specifici per cui devi mantenere le tue app native, può comunque valere la pena considerare di "esternalizzare" alcune funzionalità dell'app sul Web. Alcuni anni fa, stavo lavorando a un progetto per una grande società di servizi finanziari e hanno deciso di spostare il flusso di accesso per le loro app native sul Web per consentire loro di implementare le funzionalità di sicurezza più rapidamente rispetto al tipico app store processo di approvazione ha permesso loro di raggiungere. Forse il tuo progetto ha esigenze simili che il Web potrebbe consentire alla tua app nativa di soddisfare.

Progetto n. 2: un'app multipiattaforma esistente

Se hai un'app esistente che funziona su più piattaforme, probabilmente sborserai un sacco di soldi per lo sviluppo e la manutenzione in corso di quell'app. Probabilmente vedrai anche alcune funzionalità in-app divergenti poiché ogni piattaforma nativa tende ad avere una propria sequenza temporale di sviluppo. L'app per il rivenditore Target, ad esempio, attualmente consente agli utenti di gestire una lista della spesa su iOS, ma la versione Android non ha questa funzionalità. Per molti versi è simile alla divergenza che a volte vediamo tra le versioni “desktop” e “mobile” di un sito web.

Se il Web fa già parte del tuo mix multipiattaforma, offre una buona opportunità per raddoppiare i tuoi investimenti e considerare la possibilità di sostituire le tue app native con PWA. Strumenti come sonar e Lighthouse possono darti un'idea di quanto sia ben preparato il tuo sito esistente per la PWA-ificazione e possono anche dirti su cosa devi lavorare. Da lì, trasformare il tuo sito Web in una PWA è relativamente semplice. Esistono anche strumenti gratuiti che possono aiutarti ad aggiornare il tuo sito a una PWA in pochi minuti. Se non lo è, tuttavia, non c'è davvero molto incentivo a fare questa mossa a meno che la divergenza delle funzionalità tra le piattaforme non diventi davvero eclatante o tu stia considerando di aggiungere un'altra piattaforma nativa (o il Web) al mix.

Progetto n. 3: un nuovo prodotto multipiattaforma

Se stai dando il via a un nuovo progetto rivolto a più di una piattaforma, crearlo e mantenerlo in un unico posto come PWA dovrebbe sicuramente essere sul tavolo. A seconda del budget e del personale, è probabile che aumenti ulteriormente il budget. Detto questo, se il tuo prodotto richiede una connessione diretta all'hardware o al sistema operativo sottostante, potresti comunque aver bisogno di diventare nativo. Ma prima di intraprendere quella strada, fai un elenco di tutti i tuoi requisiti e quindi verifica cosa può fare il Web (e cosa non può). Assicurati di controllare il supporto anche in più di un browser.

Progetto n. 4: un nuovo prodotto iperfocalizzato

Se stai costruendo un nuovo prodotto e parte dell'intero scopo di quel prodotto è la sua profonda connessione a una piattaforma particolare, costruisci con tutti i mezzi per quella piattaforma. Ad esempio, se il tuo prodotto si basa sulla piattaforma Messaggi di Apple o sull'integrazione con HomeKit, crea con tutti i mezzi per iOS e/o macOS in Swift. Se il tuo prodotto soddisferà al meglio le esigenze degli utenti tramite un widget o stai creando un launcher personalizzato, è meglio creare Android e dovrai utilizzare Java.

Tuttavia, non tutte le caratteristiche native sono giardini recintati. Mentre Alexa di Amazon, Siri di Apple e Google Assistant richiedono tutti codice nativo (o un'API JSON) per integrarsi con la tua app, è interessante notare che Cortana di Microsoft abiliterà la tua PWA vocale utilizzando solo un file XML collegato dalla head del tuo HTML. Forse altri seguiranno il loro esempio.

PWA o nativo? La scelta è tua

Il web e il nativo hanno molto da offrire. Se dovessi chiedermi quale è meglio, risponderei semplicemente "Dipende" perché è così. Non sono evasivo o non impegnativo; capire quale sia la soluzione giusta per il tuo progetto dipende interamente dalle esigenze specifiche del tuo progetto. Richiede di prendere in considerazione ciò che stai costruendo, la composizione del team esistente incaricato di costruirlo o il team che dovrai assumere per farlo e il budget con cui devi lavorare. In molti casi, il Web probabilmente offre tutto ciò di cui hai bisogno per raggiungere gli obiettivi del tuo progetto, ma ci sono sempre delle eccezioni. Se vuoi esplorare le possibilità offerte dal web, ho incluso alcune risorse alla fine di questo articolo.

La cosa più importante che puoi fare quando soppesare diversi approcci allo sviluppo del software - o diversi framework, librerie, linguaggi, sistemi di progettazione, ecc. - è considerare le tue opzioni in relazione al progetto in questione. Fai le tue ricerche e valuta le tue opzioni. E non lasciarti influenzare in un modo o nell'altro da marketing intelligente, demo sexy o fan rabbiosi. Compreso questo.

Risorse relative a PWA

• Costruttore di PWA
  Uno strumento di creazione da sito Web a PWA in 3 passaggi con consigli e ricette utili. Ti consente inoltre di trasformare la tua PWA in app native installabili per Windows, Android e iOS.
• Una road map progressiva per la tua app web progressiva
  Jason Grigsby su come il suo team ha iniziato a incorporare aspetti delle PWA nel proprio sito Web nel corso di diversi mesi, dimostrando bene come le diverse funzionalità possono essere aggiunte un po' alla volta.
• Sì, quel progetto Web dovrebbe essere una PWA
  Una panoramica delle opportunità (e dei rischi) UX delle PWA, scritta da te veramente.
• App Web progressive su MDN
  Un hub per tutte le informazioni tecniche che devi sapere su cosa caratterizza una PWA di qualità.
• Cosa può fare il Web oggi
  Dai un'occhiata alle API supportate dal tuo dispositivo, sistema operativo e browser. Quello che trovi potrebbe sorprenderti.
• Posso usare
  Il database definitivo di quali API e funzionalità sono disponibili in tutti i principali browser e come tale supporto si misura rispetto ai browser che le persone stanno effettivamente utilizzando. Può anche darti un'eccellente vista indietro nel tempo per vedere quanto sono compatibili con le versioni precedenti alcune funzionalità.