Native i PWA: wybory, a nie pretendenci!

Trudno powiedzieć dokładnie, gdzie tak naprawdę zaczęła się rozbieżność między „natywnym” a „sieciowym”. Wydaje mi się, że jest to jedna z tych rzeczy, które krążyły tuż pod powierzchnią od wczesnych dni Flasha, a ostatnio pojawiły się wraz z rozwojem platform mobilnych. Niezależnie od tego, programiści zmierzyli się z tą „wielką przepaścią”, rzucając sobie nawzajem obelgi, próbując wzmocnić swoją stronę.

Nie interesuje mnie ta walka. Jasne, jestem „człowiekiem sieciowym”, ale to nie znaczy, że nie widzę uroku rozwoju natywnego; Jestem również programistą. Przede wszystkim jednak jestem pragmatykiem. Zdaję sobie sprawę, że każdy projekt jest inny i nasze podejście do każdego powinno być dostosowane do potrzeb i celów projektu.

Ponieważ progresywne aplikacje internetowe (PWA) wkraczają na teren programowania natywnego, pomyślałem, że to może być dobry moment, aby zrobić krok wstecz i podsumować te dwa podejścia do tworzenia produktów. Mam nadzieję, że wszyscy odejdziemy z możliwością wyraźnego dostrzeżenia mocnych stron każdego podejścia w nadziei na znalezienie odpowiedniego dopasowania do tworzonych przez nas produktów.

Porównanie szybkiego ognia

Niemal od samego początku doświadczenia internetowe porównywano ze wszystkim, od oprogramowania komputerowego (oryginalnych „aplikacji natywnych”), przez interaktywne płyty CD-ROM, po Flash, a ostatnio także aplikacje mobilne. Mimo że wielokrotnie uznano go za zmarłego, sieć przetrwała. W wielu przypadkach przeżył nawet swoich rzekomych zabójców (RIP Flash).

Jednym z głównych atutów sieci w tym zakresie jest jego zdolność adaptacji. Był w stanie dotrzeć praktycznie wszędzie tam, gdzie jest połączenie z Internetem i nadal zyskuje nowe możliwości. Wszystkie języki programowania ewoluują, więc nie jest to nieoczekiwane, ale z biegiem czasu rosnące granice sieci nadal wdzierają się na teren tradycyjnego oprogramowania.

Jednak jednym z obszarów, w którym w historii sieci nie brakowało, była sfera wydajności. Zainstalowane oprogramowanie jest w stanie połączyć się z systemem operacyjnym w sposób, w jaki sieć po prostu nie potrafi. Są napisane w lingua franca ich gospodarza, z bezpośrednim dostępem do sprzętu lub „bliżej metalu”, jak często mówimy. Sieć, która prawie zawsze operuje jedną lub kilkoma warstwami abstrakcji powyżej tego, miała trudności z konkurowaniem pod względem wydajności. Chociaż różnica w wydajności zmniejszyła się z czasem, kod natywny prawdopodobnie będzie działał szybciej niż kod sieciowy, przynajmniej do czasu, gdy sieć będzie w stanie interpretować sygnały bezpośrednio ze styków sprzętu.

Wraz z przewagą wydajności, programowanie natywne ma znacznie większy (i wcześniejszy) dostęp do funkcji urządzenia, takich jak NFC, Bluetooth, czujniki zbliżeniowe i światła otoczenia i nie tylko. Sieć stale zyskuje dostęp do tych funkcji, ale zawsze pozostanie w tyle za natywnymi, ponieważ natywne interfejsy API muszą zostać opracowane, zanim sieć będzie mogła je wykorzystać, a standaryzacja w całej przeglądarce wymaga czasu.

Ponadto kod natywny może łączyć się z funkcjami na poziomie systemu operacyjnego, takimi jak książka adresowa i kalendarze. Powiadomienia push to kolejny duży problem, ale Service Workers umożliwiają teraz korzystanie z tej funkcji również w sieci. Podobnie poprawiło się ostatnio przetwarzanie płatności w Internecie. Być może dostęp do książki adresowej i kalendarza w końcu pojawi się również w sieci.

Wracając na chwilę do Service Workers, ten niedawny dodatek do zestawu narzędzi web developera ma też w zanadrzu wiele innych sztuczek. Przede wszystkim oferuje znacznie bardziej niezawodny system buforowania niż wcześniej w sieci z AppCache. Możesz użyć Service Workers do zarządzania żądaniami w trybie offline, buforowania określonych zasobów, synchronizowania danych z serwerem zdalnym, gdy użytkownik nie ma nawet otwartej witryny, i wiele więcej. Być może bardziej niż jakakolwiek inna pojedyncza technologia, Service Workers umożliwiły sieci Web oferowanie bardziej zbliżonej do aplikacji.

Service Workers są jednym z trzech technicznych filarów PWA. Kolejny to Manifest aplikacji internetowej. Choć może to zabrzmieć trochę nudno, Manifest aplikacji internetowej jest w rzeczywistości niezwykle potężnym narzędziem, ponieważ umożliwia witrynie reklamowanie się jako aplikacja. Ten stosunkowo prosty format pliku JSON zapewnia bogactwo informacji na temat witryny, którą opisuje, i umożliwia przeglądarkom i systemom operacyjnym obsługującym PWA instalowanie witryny tak, jakby była to oprogramowanie natywne.

Niektóre sklepy z aplikacjami zaczynają nawet indeksować PWA, używając swojego Manifestu do wypełniania powiązanych wpisów. Z perspektywy użytkownika aplikacje PWA w sklepach z aplikacjami nie różnią się niczym od otaczających je aplikacji natywnych. Można je instalować, odinstalowywać, a nawet udostępniać swoje ustawienia narzędziu do zarządzania aplikacjami w systemie operacyjnym. Warto również zauważyć, że PWA tak naprawdę nie potrzebują użytkownika, aby jawnie je instalował, aby z nich korzystać, ponieważ, cóż, żyją w sieci.

Bycie zarówno w sieci, jak i w Internecie oznacza również, że PWA są zawsze aktualne. Użytkownicy nie muszą aktywnie pobierać niczego nowego, aby uzyskać dostęp do nowych funkcji. A nawet po wprowadzeniu nowej zawartości i funkcji jest bardzo mało prawdopodobne, że użytkownik będzie musiał ponownie pobrać całe PWA, tak jak w przypadku większości aplikacji natywnych. Jeśli już, mogą otrzymać kilka nowych zasobów i trochę nowego kodu HTML, a stanie się to całkiem natychmiast, bez konieczności korzystania ze sklepu z aplikacjami. Oczywiście nadal masz opcję odkrywania i dystrybucji zapewnianą przez sklepy z aplikacjami, więc naprawdę jest to najlepsze z obu światów.

Bycie w sklepach z aplikacjami stawia PWA na równi z aplikacjami natywnymi pod względem odkrywania, dystrybucji i zarabiania. W rzeczywistości może nawet przeskoczyć sieć nad natywną, ponieważ PWA można również znaleźć za pomocą wyszukiwarek i nieskończenie łatwiej jest udostępniać je niż aplikacje, ponieważ istnieją pod adresem URL. Dobrze zbudowane aplikacje PWA są również interoperacyjne w różnych przeglądarkach, platformach i urządzeniach. Programy PWA działają nawet w przeglądarkach, które nie obsługują funkcji, takich jak Service Workers, ponieważ funkcje PWA są progresywnymi ulepszeniami.

Sieć oferuje również bardzo dojrzałą obsługę ułatwień dostępu, dzięki czemu stosunkowo łatwo można zapewnić, że Twoje projekty będą używane przez jak największą liczbę użytkowników. Złożone interfejsy wymagają nieco większej staranności, jeśli chodzi o programowanie, ale korzyści związane z dostępnością, jakie zapewnia semantyczny HTML, pozwalają z dużym rozmachem obsługiwać podstawową dostępność — zwłaszcza w przypadku produktów zawierających dużo tekstu, informacji lub prostych formularzy. W przeciwieństwie do tego prawie zawsze musisz być świadomy i uwzględniać interfejsy API ułatwień dostępu w swoim kodzie natywnym.

Jeśli chodzi o rozwój, nie sądzę, aby był wyraźnym zwycięzcą, jeśli chodzi o doświadczenie programistyczne. Każdy język ma swoich fanów i to samo można powiedzieć o narzędziach programistycznych. Podoba Ci się to, co lubisz, i zwykle pracujesz wydajniej dzięki narzędziom i językom, które znasz i którymi się pasjonujesz. Ani web, ani programowanie natywne nie mają tam żadnej wyraźnej przewagi.

Tam, gdzie programowanie natywne błyszczy, jest jednak kwestia zapewnienia spójnego poziomu jakości interfejsów użytkownika, zbudowanych przy użyciu ich zestawów SDK (zestawów programistycznych). Większość natywnych zestawów SDK oferuje narzędzia do testowania wydajności, projektowania, funkcjonalności i nie tylko. Obejmują one również standardowy kod, systemy projektowe i inne narzędzia, które pomagają podnieść ogólną poprzeczkę oferty oprogramowania natywnego. Jasne, istnieją podobne narzędzia dla sieci, ale są one rozproszone w sieci i nie są uniwersalne we wszystkich środowiskach programistycznych, z których korzystają ludzie do tworzenia witryn. Nie ma jednej jednostki definiującej jakość doświadczeń internetowych i dostarczającej narzędzi do ich tworzenia (choć wielu próbowało).

Jeśli chodzi o personel przy rozwoju produktu, zdecydowanie łatwiej jest zatrudnić ludzi, którzy wiedzą, jak tworzyć dla sieci. Kiedy piszę, Indeks Języków Programowych obecnie plasuje JavaScript jako najpopularniejszy język, z Java tuż za nim. C# jest na 5 miejscu, HTML na 7, CSS na 9, a Swift na 15. Ten indeks odwołuje się do tagów Stack Overflow z liniami zmienionymi w publicznych repozytoriach na GitHub, więc należy go traktować z przymrużeniem oka, ale daje dość wyraźną wskazówkę, że wiele osób zna (i używa) technologii internetowych. Z drugiej strony znalezienie i zatrudnienie utalentowanych rodzimych programistów może być trudne, ponieważ jest ich mniej i są bardzo poszukiwani.

Niewielki talent oznacza, że ​​prawdopodobnie zapłacisz więcej za rozwój natywny. Każdy projekt jest oczywiście inny i ma inne cechy i wymagania, ale porównanie średnich kosztów rozwoju może być ilustracją. Comentum sugeruje, że koszt stworzenia średniej wielkości aplikacji internetowej waha się od 10 000 do 150 000 USD. Appster szacuje, że po stronie natywnej projekty aplikacji mobilnych średniej wielkości kosztują od 110 000 do 305 000 USD. Prawdopodobnie można bezpiecznie założyć, że tworzenie projektów natywnych może kosztować około dwa razy więcej niż projekt internetowy. I to na platformę. Tworzenie aplikacji natywnych zwykle zajmuje więcej czasu.

Warto zauważyć, że istnieją opcje budowania natywnego oprogramowania przy użyciu technologii internetowych bez budowania PWA. Struktury, takie jak React Native, PhoneGap, Ionic i Appcelerator Titanium, umożliwiają generowanie natywnego kodu z HTML, CSS i JavaScript. Korzystanie z jednego z tych narzędzi może obniżyć koszty personelu i rozwoju w porównaniu z zatrudnieniem zespołu rodzimych programistów, ale pod względem dostępu do funkcji urządzenia Twój projekt będzie ograniczony do tych, które zostały wdrożone przez framework. Zaplanuj odpowiednio.

Po opracowaniu aplikacji musisz również uwzględnić bieżące koszty utrzymania tej aplikacji lub aplikacji. W odpowiedzi na ankietę przeprowadzoną przez Clutch, Dom & Tom zaleca budżetowanie 50% początkowej ceny produktu w pierwszym roku, 25% w drugim roku i 15-25% na każdy następny rok.

Gdy już dobrze zrozumiesz, jak porównuje się i kontrastuje programowanie internetowe i natywne, możesz zacząć oceniać, które mocne i słabe strony są istotne dla Twojego projektu. Prawdopodobnie będziesz musiał dokonać pewnych kompromisów i tego można się spodziewać. Nie ma jednego uniwersalnego rozwiązania. A gdyby tak było, nie pasowałoby do nikogo.

Przyjrzyjmy się kilku hipotetycznym projektom, aby wyraźniej skoncentrować się na rozróżnieniu między programowaniem natywnym i PWA.

Projekt nr 1: Istniejąca aplikacja natywna

Załóżmy, że przeszedłeś już proces tworzenia aplikacji natywnej. Jeśli wszystko idzie dobrze, nie ma powodu, aby zmieniać kurs. Nie wyrzucaj całej swojej dotychczasowej pracy, aby przejść na PWA, chyba że masz naprawdę dobry powód, aby to zrobić. Naprawdę mogę wymyślić tylko jeden scenariusz, który może uzasadniać rozważenie przejścia na PWA: Dodanie wsparcia dla nowego systemu operacyjnego do miksu. A nawet wtedy ma to sens tylko wtedy, gdy potrzeby Twojej aplikacji mogą zostać zaspokojone przez samą sieć.

Jeśli dodajesz do produktu obsługę nowej platformy, stwarza to doskonałą okazję do oceny potrzeb i celów projektu pod kątem kosztów zaspokojenia tych potrzeb. Jeśli sieć nie jest w stanie sprostać zadaniu, trzymaj się natywnego. Jeśli jednak tak jest, zatrzymaj się i rozważ to: Dodanie obsługi nowej platformy za pomocą PWA umożliwiłoby obsługę dodatkowych platform (w tym sieci) w przyszłości, a nawet umożliwiłoby zastąpienie istniejącej aplikacji natywnej, gdy PWA zostały dokładnie przetestowane.

Jeśli zastąpienie istniejącej aplikacji natywnej PWA wydaje ci się nie do pomyślenia, rozważ to: Starbucks i Twitter już badają ten pomysł.

Jeśli istnieją konkretne powody, dla których musisz zachować swoje aplikacje natywne, nadal warto rozważyć „outsourcing” niektórych funkcji aplikacji do sieci. Kilka lat temu pracowałem nad projektem dla dużej firmy świadczącej usługi finansowe, która zdecydowała się przenieść przepływ logowania do swoich natywnych aplikacji do sieci, aby umożliwić im szybsze wdrażanie funkcji bezpieczeństwa niż w typowym sklepie z aplikacjami proces zatwierdzania umożliwił im osiągnięcie. Być może Twój projekt ma podobne potrzeby, które sieć może zaspokoić Twoja natywna aplikacja.

Projekt #2: Istniejąca aplikacja wieloplatformowa

Jeśli masz istniejącą aplikację, która działa na wielu platformach, prawdopodobnie wydasz dużo pieniędzy na ciągły rozwój i utrzymanie tej aplikacji. Prawdopodobnie zauważysz również pewne rozbieżności w funkcjach w aplikacji, ponieważ każda platforma natywna ma zwykle własny harmonogram rozwoju. Na przykład aplikacja dla sprzedawcy Target pozwala obecnie użytkownikom zarządzać listą zakupów na iOS, ale wersja na Androida nie ma tej funkcji. Pod wieloma względami jest to podobne do rozbieżności, jaką czasami obserwujemy między wersją „komputerową” i „mobilną” strony internetowej.

Jeśli sieć jest już częścią Twojej wieloplatformowej mieszanki, stanowi dobrą okazję do podwojenia swoich inwestycji i rozważenia zastąpienia aplikacji natywnych programami PWA. Narzędzia takie jak sonar i Lighthouse mogą dać Ci wgląd w to, jak dobrze przygotowana jest Twoja istniejąca witryna do weryfikacji PWA, a także podpowiedzą, nad czym musisz popracować. Stamtąd przekształcenie Twojej witryny w PWA jest stosunkowo proste. Istnieją nawet bezpłatne narzędzia, które mogą pomóc w uaktualnieniu witryny do PWA w ciągu kilku minut. Jeśli jednak tak nie jest, to naprawdę nie ma zbyt wiele zachęty do wykonania tego ruchu, chyba że rozbieżność funkcji między platformami stanie się naprawdę rażąca lub rozważasz dodanie kolejnej platformy natywnej (lub sieci) do miksu.

Projekt #3: Nowy produkt międzyplatformowy

Jeśli rozpoczynasz nowy projekt na więcej niż jedną platformę, tworzenie i utrzymywanie go w jednym miejscu jako PWA zdecydowanie powinno znaleźć się na stole. W zależności od budżetu i personelu, prawdopodobnie najbardziej rozciągnie się budżet. To powiedziawszy, jeśli Twój produkt wymaga bezpośredniego połączenia ze sprzętem lub podstawowym systemem operacyjnym, nadal może być konieczne przejście na natywny. Ale zanim pójdziesz tą drogą, zrób listę wszystkich swoich wymagań, a następnie zweryfikuj, co może zrobić sieć (a czego nie). Pamiętaj, aby sprawdzić wsparcie w więcej niż jednej przeglądarce.

Projekt 4: Nowy, hiperskoncentrowany produkt

Jeśli budujesz nowy produkt, a częścią całego celu tego produktu jest jego głębokie połączenie z konkretną platformą, za wszelką cenę zbuduj dla tej platformy. Na przykład, jeśli Twój produkt opiera się na platformie Apple Messages lub integracji z HomeKit, za wszelką cenę skompiluj dla iOS i/lub macOS w Swift. Jeśli Twój produkt najlepiej spełni potrzeby użytkowników za pomocą widżetu lub jeśli tworzysz niestandardowy program uruchamiający, najlepiej jest zbudować system Android i będziesz musiał używać języka Java.

Jednak nie wszystkie rodzime elementy to ogrody otoczone murem. Podczas gdy Alexa firmy Amazon, Siri firmy Apple i Asystent Google wymagają natywnego kodu (lub interfejsu API JSON), aby zintegrować się z Twoją aplikacją, co ciekawe, Cortana firmy Microsoft włączy Twoje PWA za pomocą głosu, używając tylko pliku XML połączonego z head kodu HTML. Być może inni pójdą w ich ślady.

PWA czy natywny? Wybór nalezy do ciebie

Zarówno sieć internetowa, jak i natywna mają wiele do zaoferowania. Gdybyś zapytał mnie, co jest lepsze, odpowiedziałbym po prostu „To zależy”, ponieważ tak jest. Nie jestem wymijający ani niezobowiązujący; ustalenie, który jest odpowiedni dla twojego projektu, zależy całkowicie od konkretnych potrzeb twojego projektu. Wymaga wzięcia pod uwagę tego, co budujesz, składu istniejącego zespołu, który ma to zrobić lub zespołu, który będziesz musiał zatrudnić, a także budżetu, z którym musisz pracować. W wielu przypadkach sieć prawdopodobnie oferuje wszystko, czego potrzebujesz, aby osiągnąć cele projektu, ale zawsze są wyjątki. Jeśli chcesz poznać możliwości, jakie oferuje sieć, zamieściłem kilka zasobów na końcu tego artykułu.

Najważniejszą rzeczą, jaką możesz zrobić, rozważając różne podejścia do tworzenia oprogramowania — lub różne frameworki, biblioteki, języki, systemy projektowania itp. — to rozważenie opcji w odniesieniu do danego projektu. Przeprowadź badania i rozważ swoje opcje. I nie daj się zwieść w taki czy inny sposób przez sprytny marketing, seksowne prezentacje lub wściekłych fanboyów. Łącznie z tym.

Zasoby związane z PWA

• Konstruktor PWA
  Narzędzie do tworzenia w trzech krokach strony internetowej do PWA z pomocnymi zaleceniami i przepisami. Umożliwia także przekształcenie PWA w instalowalne aplikacje natywne dla systemów Windows, Android i iOS.
• Progresywna mapa drogowa dla Twojej progresywnej aplikacji internetowej
  Jason Grigsby o tym, jak jego zespół zaczął wprowadzać aspekty PWA do swojej witryny w ciągu kilku miesięcy, ładnie pokazując, jak różne funkcje można dodawać po trochu.
• Tak, ten projekt internetowy powinien być PWA
  Przegląd możliwości (i zagrożeń) UX związanych z PWA, napisany przez Ciebie.
• Progresywne aplikacje internetowe na MDN
  Centrum dla wszystkich technicznych elementów, które musisz wiedzieć o tym, co charakteryzuje wysokiej jakości PWA.
• Co może dziś zrobić sieć
  Przyjrzyj się interfejsom API, które obsługuje Twoje urządzenie, system operacyjny i przeglądarka. To, co znajdziesz, może cię zaskoczyć.
• Mogę uzyć
  Ostateczna baza danych o tym, jakie interfejsy API i funkcje są dostępne w każdej większej przeglądarce i jak to wsparcie mierzy się w stosunku do przeglądarek, z których faktycznie korzystają ludzie. Może również zapewnić doskonały widok w przeszłość, aby zobaczyć, jak pewne funkcje są wstecznie kompatybilne.