Nativ și PWA: alegeri, nu provocatori!

Este greu de spus exact de unde a început cu adevărat ruptura dintre „nativ” și „web”. Simt că este unul dintre acele lucruri care s-au agitat chiar sub suprafață încă de la începuturile lui Flash, pentru a erupe mai recent odată cu ascensiunea platformelor mobile. Oricum, dezvoltatorii s-au înfruntat peste această „mare prăpastie”, lanțându-se insulte unii altora în încercarea de a-și consolida propria parte.

Nu mă interesează acea luptă. Sigur, sunt un „tip web”, dar asta nu înseamnă că nu pot vedea atracția dezvoltării native; Sunt, de asemenea, un dezvoltator de software. Mai presus de toate, însă, sunt un pragmatist. Îmi dau seama că fiecare proiect este diferit și că abordarea noastră față de fiecare ar trebui să fie adaptată nevoilor și obiectivelor proiectului.

Având în vedere că Progressive Web Apps (PWA) invadează terenul dezvoltării native, m-am gândit că acesta ar putea fi un moment bun pentru a face un pas înapoi și a face bilanțul acestor două abordări pentru construirea de produse. Speranța mea este că vom pleca cu toții cu capacitatea de a vedea clar punctele forte ale fiecărei abordări în speranța de a găsi cea mai potrivită pentru produsele pe care le creăm.

O comparație cu foc rapid

Aproape de la început, experiențele bazate pe web au fost comparate cu orice, de la software pentru desktop („aplicațiile native“ originale) la CD-ROM-uri interactive la Flash și, cel mai recent, la aplicații mobile. În ciuda faptului că a fost declarat mort de mai multe ori, web-ul a persistat. În multe cazuri, a supraviețuit chiar și presupușilor săi ucigași (RIP Flash).

Unul dintre punctele forte ale web-ului în acest sens este adaptabilitatea acestuia. A fost capabil să meargă aproape oriunde există o conexiune la Internet și continuă să câștige noi capabilități. Toate limbajele de programare evoluează, așa că nu este neașteptat, dar de-a lungul timpului granițele tot mai mari ale web-ului au continuat să pătrundă pe terenul software-ului tradițional.

Cu toate acestea, un domeniu în care web-ul a rămas scurt în trecut a fost cel al performanței. Software-ul instalat se poate lega de sistemul de operare de bază în moduri pe care web-ul pur și simplu nu poate. Sunt scrise în lingua franca a gazdei lor, cu acces direct la hardware sau „mai aproape de metal”, așa cum spunem adesea. Web-ul, care operează aproape întotdeauna unul sau mai multe straturi de abstractizare deasupra acesteia, a avut dificultăți în a concura când vine vorba de performanță. În timp ce decalajul de performanță s-a redus de-a lungul timpului, este posibil ca codul nativ să continue să ruleze mai repede decât codul web, cel puțin până când web-ul devine capabil să interpreteze semnale direct de pe pinii hardware-ului.

Mână în mână cu avantajul de performanță, dezvoltarea nativă are acces mult mai mare (și mai devreme) la funcțiile dispozitivului, cum ar fi NFC, Bluetooth, senzori de proximitate și lumină ambientală și multe altele. Web-ul obține în mod constant acces și la aceste funcții, dar va rămâne întotdeauna în urma native, deoarece API-urile native trebuie dezvoltate înainte ca web-ul să le poată accesa, iar standardizarea în cadrul browser-ului necesită timp.

În plus, codul nativ se poate conecta la funcții la nivel de sistem de operare, cum ar fi agenda și calendarele. Notificările push au fost încă una importantă, dar lucrătorii de servicii permit acum ca web-ul să profite și de această funcție. Procesarea plăților s-a îmbunătățit în mod similar pe web recent. Poate că accesul la agendă și la calendar va ajunge în cele din urmă și pe web.

Revenind pentru un moment la Service Workers, această adăugare recentă la setul de instrumente al dezvoltatorului web are și o serie de alte trucuri în mânecă. În primul rând, oferă un sistem de stocare în cache mult mai robust decât a avut web-ul anterior cu AppCache. Puteți folosi Service Workers pentru a gestiona solicitările offline, a stoca în cache resurse specifice, a sincroniza datele cu un server la distanță atunci când utilizatorul nici măcar nu are site-ul deschis și o tonă mai mult. Poate mai mult decât orice altă tehnologie unică, lucrătorii de servicii au permis internetului să ofere o experiență mai asemănătoare aplicației.

Lucrătorii de servicii sunt unul dintre cei trei piloni tehnici ai PWA. Un altul este Web App Manifest. Deși poate suna puțin plictisitor, un Web App Manifest este de fapt un instrument incredibil de puternic, deoarece permite unui site web să se facă publicitate ca aplicație. Acest format de fișier JSON relativ simplu oferă o mulțime de informații despre site-ul web pe care îl descrie și permite browserelor și sistemelor de operare care acceptă PWA să instaleze site-ul ca și cum ar fi un software nativ.

Unele magazine de aplicații încep chiar să indexeze PWA-uri, folosind Manifestul lor pentru a-și popula intrările asociate. Din perspectiva utilizatorului, PWA din magazinele de aplicații nu diferă cu nimic de aplicațiile native din jurul lor. Sunt instalabile, dezinstalabile și chiar își pot expune setările instrumentului de gestionare a aplicațiilor sistemului de operare de bază. De asemenea, merită remarcat faptul că PWA-urile nu au nevoie de fapt de un utilizator care să le instaleze în mod explicit pentru a le utiliza, deoarece, ei bine, trăiesc pe web.

A fi atât pe web, cât și pe web înseamnă, de asemenea, că PWA-urile sunt mereu la zi. Utilizatorii nu vor trebui să descarce în mod activ nimic nou pentru a avea acces la noi funcționalități. Și chiar și atunci când conținutul și funcțiile noi sunt lansate, este foarte puțin probabil ca un utilizator să fie nevoie să-ți descarce din nou întregul PWA, așa cum ar face-o în cazul majorității aplicațiilor native. În orice caz, ei pot primi câteva active noi și ceva HTML nou și s-ar întâmpla destul de instantaneu, fără a fi nevoie de magazin de aplicații. Desigur, mai aveți opțiunea de descoperire și distribuție oferită de magazinele de aplicații, așa că într-adevăr este cel mai bun din ambele lumi.

A fi în magazinele de aplicații pune PWA pe picior de egalitate cu aplicațiile native în ceea ce privește descoperirea, distribuția și monetizarea. De fapt, poate chiar să arunce web-ul peste nativ, deoarece PWA-urile pot fi descoperite și prin motoarele de căutare și sunt infinit mai ușor de partajat decât aplicațiile, deoarece există la o adresă URL. Când sunt bine construite, PWA-urile sunt, de asemenea, interoperabile între browsere, platforme și dispozitive. PWA funcționează chiar și în browsere care nu acceptă funcții precum Service Workers, deoarece funcțiile PWA sunt îmbunătățiri progresive.

Web-ul oferă, de asemenea, suport de accesibilitate foarte matur, ceea ce face relativ ușor să vă asigurați că proiectele dvs. sunt utilizabile de către cel mai mare număr de utilizatori. Interfețele complexe necesită un pic mai multă diligență atunci când vine vorba de programare, dar beneficiile de accesibilitate oferite de HTML semantic gestionează accesibilitatea de bază cu aplomb - mai ales când vine vorba de produse cu conținut greoi de text, informații sau simple bazate pe formulare. În schimb, aproape întotdeauna trebuie să fii conștient și să încorporezi API-urile de accesibilitate în codul tău nativ.

Pe tema dezvoltării, nu cred că există un câștigător clar când vine vorba de experiența de dezvoltare. Fiecare limbă are fanii săi și același lucru se poate spune despre instrumentele pentru dezvoltatori. Îți place ceea ce îți place și ai tendința de a fi mai eficient cu instrumentele și limbile pe care le cunoști și de care ești pasionat. Nici web-ul, nici dezvoltarea nativă nu au niciun avantaj distinct acolo.

Totuși, locul în care dezvoltarea nativă strălucește este atunci când vine vorba de asigurarea unui nivel consistent de calitate pentru interfețele de utilizator, construite folosind SDK-urile lor (Kiturile de dezvoltare software). Majoritatea SDK-urilor native oferă instrumente pentru testarea performanței, designului, funcționalității și multe altele. Acestea includ, de asemenea, cod standard, sisteme de proiectare și alte instrumente care ajută la ridicarea standardului general al ofertelor de software nativ. Sigur, există instrumente similare pentru web, dar ele sunt împrăștiate pe web și nu sunt universale în toate mediile de dezvoltare diferite pe care oamenii le folosesc pentru a construi site-uri web. Nu există o singură entitate care să definească experiențe web de calitate și să furnizeze instrumentele pentru a le construi (deși mulți au încercat).

Când vine vorba de personal pentru dezvoltarea unui produs, este cu siguranță mai ușor să angajezi oameni care știu să construiască pentru web. Pe măsură ce scriu, Indexul limbajului de programare clasifică în prezent JavaScript drept cel mai popular limbaj, cu Java chiar în spatele acestuia. C# este pe locul 5, HTML pe locul 7, CSS pe locul 9 și Swift pe locul 15. Acest index face referințe încrucișate etichetelor Stack Overflow cu linii modificate în depozitele publice de pe GitHub, așa că ar trebui luat cu puțină sare, dar oferă o indicație destul de clară că mulți oameni cunosc (și folosesc) tehnologiile web. Pe de altă parte, poate fi adesea dificil să găsești și să angajezi dezvoltatori nativi talentați, deoarece sunt mai puțini și sunt la mare căutare.

Talentul limitat înseamnă că probabil vei ajunge să plătești mai mult pentru dezvoltarea nativă. Fiecare proiect este evident diferit și are caracteristici și cerințe diferite, dar poate fi ilustrativ să privim costurile medii de dezvoltare ca o comparație. Comentum sugerează că construirea unei aplicații web de dimensiuni moderate variază de la sub 10.000 USD până la 150.000 USD. La nivel nativ, Appster estimează că proiectele de aplicații mobile de dimensiuni medii costă între 110.000 USD și 305.000 USD pentru a fi construite. Este probabil sigur să presupunem că proiectele native vor costa aproximativ de două ori mai mult decât un proiect web. Și asta pe platformă. De obicei, dezvoltarea aplicațiilor native durează mai mult.

Este demn de remarcat faptul că există opțiuni pentru construirea de software nativ folosind tehnologii web fără a construi un PWA. Framework-uri precum React Native, PhoneGap, Ionic și Appcelerator Titanium vă permit să generați cod nativ din HTML, CSS și JavaScript. Utilizarea unuia dintre aceste instrumente ar putea reduce costurile de personal și dezvoltare în comparație cu angajarea unei echipe de dezvoltatori nativi, dar în ceea ce privește accesul la caracteristicile dispozitivului, proiectul dvs. va fi limitat la cele implementate de cadrul. Planificați în consecință.

Odată ce aplicația este dezvoltată, trebuie să luați în considerare și costurile de întreținere în curs ale aplicației sau aplicațiilor respective. Ca răspuns la un sondaj realizat de Clutch, Dom & Tom recomandă bugetarea a 50% din prețul inițial al produsului în primul an, 25% în al doilea an și între 15-25% pentru fiecare an ulterior.

Odată ce aveți o înțelegere decentă a modului în care se compară și contrastează dezvoltarea web și cea nativă, puteți începe să evaluați care sunt punctele forte și punctele slabe relevante pentru proiectul dvs. Probabil că va trebui să faceți unele compromisuri și asta este de așteptat. Nu există o soluție unică pentru toate. Și dacă ar exista, nu s-ar potrivi bine nimănui.

Să parcurgem câteva proiecte ipotetice pentru a aduce mai clar diferențele dintre dezvoltarea pentru nativ și PWA.

Proiectul #1: O aplicație nativă existentă

Să presupunem că ați trecut deja prin procesul de creare a unei aplicații native. Dacă totul merge bine, nu există niciun motiv pentru a schimba cursul. Nu aruncați toate lucrările existente pentru a trece la un PWA decât dacă aveți un motiv foarte bun pentru a face acest lucru. Mă pot gândi cu adevărat la un singur scenariu care ar putea justifica luarea în considerare a trecerii la PWA: Aducerea în amestec a suportului pentru un nou sistem de operare. Și chiar și atunci, are sens doar dacă nevoile aplicației dvs. pot fi satisfăcute numai de web.

Dacă adăugați suport pentru o nouă platformă unui produs, acesta creează oportunitatea perfectă de a evalua nevoile și obiectivele proiectului în ceea ce privește costul satisfacerii acestor nevoi. Dacă web-ul nu este la înălțime, rămâneți cu nativ. Dacă este, totuși, întrerupeți și luați în considerare acest lucru: Adăugarea de suport pentru noua platformă folosind un PWA vă va permite să susțineți platforme suplimentare (inclusiv web-ul) pe drum și vă poate permite chiar să înlocuiți aplicația nativă existentă odată ce PWA a fost testat temeinic.

Dacă înlocuirea unei aplicații native existente cu o PWA vi se pare de neconceput, luați în considerare acest lucru: Starbucks și Twitter explorează deja această idee.

Dacă există motive specifice pentru care trebuie să vă păstrați aplicațiile native, merită să luați în considerare „externalizarea” anumitor funcții ale aplicației pe web. În urmă cu câțiva ani, lucram la un proiect pentru o mare firmă de servicii financiare și ei au ales să mute fluxul de conectare pentru aplicațiile lor native pe web, pentru a le permite să lanseze funcții de securitate mai rapid decât magazinul de aplicații tipic. procesul de aprobare le-a permis să realizeze. Poate că proiectul dvs. are nevoi similare pe care web-ul ar putea să le îndeplinească aplicația dvs. nativă.

Proiectul #2: O aplicație existentă pe mai multe platforme

Dacă aveți o aplicație existentă care funcționează pe mai multe platforme, probabil că veți plăti o mulțime de bani pentru dezvoltarea și întreținerea în curs a aplicației respective. De asemenea, probabil că vedeți unele divergențe în cadrul aplicației, deoarece fiecare platformă nativă tinde să aibă propria cronologie de dezvoltare. Aplicația pentru retailerul Target, de exemplu, permite în prezent utilizatorilor să gestioneze o listă de cumpărături pe iOS, dar versiunea pentru Android nu are această funcție. În multe privințe, este similar cu divergența pe care o vedem uneori între versiunile „desktop” și „mobile” ale unui site web.

Dacă web-ul face deja parte din mixul dvs. multiplatformă, oferă o bună oportunitate de a vă dubla investițiile acolo și de a lua în considerare înlocuirea aplicațiilor native cu PWA. Instrumente precum sonarul și Lighthouse vă pot oferi o perspectivă asupra cât de bine este pregătit site-ul dvs. existent pentru identificarea PWA și vă pot spune, de asemenea, la ce trebuie să lucrați. De acolo, transformarea site-ului dvs. într-un PWA este relativ simplă. Există chiar și instrumente gratuite care vă pot ajuta să vă actualizați site-ul la un PWA în câteva minute scurte. Dacă nu este, totuși, nu există prea multe stimulente pentru a face această mișcare, cu excepția cazului în care diferența de caracteristici între platforme devine cu adevărat flagrantă sau vă gândiți să adăugați încă o platformă nativă (sau web) în amestec.

Proiectul #3: Un nou produs multiplatform

Dacă începeți un nou proiect care vizează mai mult de o platformă, crearea și menținerea acestuia într-un singur loc ca PWA ar trebui să fie cu siguranță pe masă. În funcție de bugetul și personalul dvs., este probabil să vă extindeți cel mai mult bugetul. Acestea fiind spuse, dacă produsul dvs. necesită o conexiune directă la hardware sau la sistemul de operare subiacent, este posibil să fie necesar să deveniți nativ. Dar înainte de a merge pe acel traseu, faceți o listă cu toate cerințele dvs. și apoi verificați ce poate face web-ul (și ce nu poate). Asigurați-vă că verificați pentru asistență și în mai multe browsere.

Proiectul #4: Un nou produs hiper-concentrat

Dacă construiți un produs nou și o parte din întregul scop al produsului este conexiunea sa profundă cu o anumită platformă, construiți-o pentru platforma respectivă. De exemplu, dacă produsul dvs. se bazează pe platforma Apple Messages sau pe integrarea cu HomeKit, creați prin toate mijloacele pentru iOS și/sau macOS în Swift. Dacă produsul dvs. va satisface cel mai bine nevoile utilizatorilor prin intermediul unui widget sau construiți un lansator personalizat, cel mai bine este să creați Android și va trebui să utilizați Java.

Nu toate caracteristicile native sunt însă grădini cu ziduri. În timp ce Alexa de la Amazon, Siri de la Apple și Asistentul Google necesită cod nativ (sau un API JSON) pentru a se integra cu aplicația dvs., este interesant Cortana de la Microsoft vă va activa PWA prin voce folosind doar un fișier XML legat de la head codului HTML. Poate că alții le vor urma exemplul.

PWA sau nativ? Alegerea este a ta

Web-ul și nativul au fiecare multe de oferit. Dacă ar fi să mă întrebați care este mai bun, aș răspunde pur și simplu „Depinde”, pentru că așa este. Nu sunt evaziv sau lipsit de angajare; a afla care este cea potrivită pentru proiectul dvs. depinde în întregime de nevoile specifice ale proiectului dvs. Este nevoie să luați în considerare ceea ce construiți, componența echipei existente însărcinate cu construirea acestuia sau echipa pe care va trebui să o angajați pentru a face acest lucru și bugetul cu care trebuie să lucrați. În multe cazuri, web-ul oferă probabil tot ce aveți nevoie pentru a vă îndeplini obiectivele proiectului, dar există întotdeauna excepții. Dacă doriți să explorați posibilitățile oferite de web, am inclus câteva resurse la sfârșitul acestui articol.

Cel mai important lucru pe care îl puteți face atunci când cântăriți diferite abordări ale dezvoltării software - sau diferite cadre, biblioteci, limbaje, sisteme de proiectare etc. - este să luați în considerare opțiunile dvs. în legătură cu proiectul în cauză. Cercetați-vă și cântăriți-vă opțiunile. Și nu vă lăsați influențați într-un fel sau altul de marketing inteligent, demonstrații sexy sau fanboys turbați. Inclusiv pe acesta.

Resurse legate de PWA

• PWA Builder
  Un instrument de creare de site-uri web la PWA în 3 pași, cu recomandări și rețete utile. De asemenea, vă permite să vă transformați PWA în aplicații native instalabile pentru Windows, Android și iOS.
• O foaie de parcurs progresivă pentru aplicația dvs. web progresivă
  Jason Grigsby despre modul în care echipa sa a început să încorporeze aspecte ale PWA-urilor în site-ul lor web pe parcursul mai multor luni, demonstrând frumos modul în care diferitele caracteristici pot fi adăugate puțin la un moment dat.
• Da, acel proiect web ar trebui să fie un PWA
  O privire de ansamblu asupra oportunităților (și riscurilor) UX ale PWA, scrisă cu adevărat de dumneavoastră.
• Aplicații web progresive pe MDN
  Un hub pentru toate elementele tehnice pe care trebuie să le știți despre ceea ce caracterizează un PWA de calitate.
• Ce poate face web astăzi
  Aruncă o privire la API-urile suportate de dispozitivul, sistemul de operare și browserul tău. Ceea ce vei găsi s-ar putea să te surprindă.
• Pot folosi
  Baza de date definitivă a API-urilor și a caracteristicilor disponibile în fiecare browser major și cum se măsoară suportul în raport cu browserele pe care oamenii le folosesc de fapt. De asemenea, vă poate oferi o vedere excelentă înapoi în timp pentru a vedea cât de compatibile sunt anumite funcții.