Asli Dan PWA: Pilihan, Bukan Penantang!

Sulit untuk mengatakan dengan tepat di mana celah antara "asli" dan "web" benar-benar dimulai. Saya merasa itu adalah salah satu hal yang telah berputar tepat di bawah permukaan sejak hari-hari awal Flash, hanya untuk meletus baru-baru ini dengan munculnya platform seluler. Terlepas dari itu, para pengembang telah menghadapi “jurang besar” ini, melontarkan hinaan satu sama lain dalam upaya untuk memperkuat pihak mereka sendiri.

Saya tidak tertarik dengan pertarungan itu. Tentu, saya seorang “web guy”, tetapi itu tidak berarti saya tidak dapat melihat daya tarik pengembangan asli; Saya juga seorang pengembang perangkat lunak. Di atas segalanya, saya seorang pragmatis. Saya menyadari setiap proyek berbeda dan bahwa pendekatan kami untuk setiap proyek harus disesuaikan dengan kebutuhan dan tujuan proyek.

Dengan Aplikasi Web Progresif (PWA) yang melanggar batas pengembangan asli, saya pikir ini mungkin saat yang tepat untuk mundur dan mengambil stok dari dua pendekatan ini untuk membangun produk. Harapan saya adalah bahwa kita semua akan pergi dengan kemampuan untuk melihat dengan jelas kekuatan dari setiap pendekatan dengan harapan menemukan kecocokan yang tepat untuk produk yang kita buat.

Perbandingan Cepat-Api

Sejak awal, pengalaman berbasis web telah dibandingkan dengan segala sesuatu mulai dari perangkat lunak desktop ("aplikasi asli") hingga CD-ROM interaktif hingga Flash dan, yang terbaru, hingga aplikasi seluler. Meskipun dinyatakan mati pada banyak kesempatan, web tetap ada. Dalam banyak kasus, itu bahkan melampaui dugaan pembunuhnya (RIP Flash).

Salah satu kekuatan utama web dalam hal ini adalah kemampuan beradaptasinya. Sudah bisa pergi cukup banyak di mana saja ada koneksi internet dan terus mendapatkan kemampuan baru. Semua bahasa pemrograman berevolusi, jadi itu tidak terduga, tetapi seiring waktu, batas web yang berkembang terus merambah wilayah perangkat lunak tradisional.

Namun, satu area di mana web secara historis gagal adalah di bidang kinerja. Perangkat lunak yang diinstal mampu mengikat ke dalam sistem operasi yang mendasarinya dengan cara yang tidak bisa dilakukan web. Mereka ditulis dalam lingua franca tuan rumah mereka, dengan akses langsung ke perangkat keras atau "lebih dekat dengan logam" seperti yang sering kita katakan. Web, yang hampir selalu mengoperasikan satu atau lebih lapisan abstraksi di atasnya, mengalami kesulitan bersaing dalam hal kinerja. Sementara kesenjangan kinerja telah menyempit dari waktu ke waktu, kode asli kemungkinan akan terus berjalan lebih cepat daripada kode web, setidaknya sampai web mampu menafsirkan sinyal secara langsung dari pin perangkat keras.

Seiring dengan keunggulan kinerja, pengembangan asli memiliki akses yang jauh lebih besar (dan lebih awal) ke fitur perangkat seperti NFC, Bluetooth, sensor jarak dan cahaya sekitar, dan banyak lagi. Web terus mendapatkan akses ke fitur-fitur ini juga, tetapi akan selalu tertinggal di belakang asli karena API asli perlu dikembangkan sebelum web dapat memanfaatkannya dan standarisasi di seluruh lanskap browser membutuhkan waktu.

Selain itu, kode asli dapat terhubung ke fitur tingkat OS seperti buku alamat dan kalender. Pemberitahuan push adalah hal besar lainnya, tetapi Service Worker sekarang memungkinkan web untuk memanfaatkan fitur itu juga. Pemrosesan pembayaran juga meningkat di web baru-baru ini. Mungkin akses buku alamat dan kalender akan datang ke web pada akhirnya juga.

Berputar kembali ke Service Worker sejenak, penambahan terbaru ke kotak alat pengembang web ini juga memiliki sejumlah trik lain. Pertama-tama, ia menawarkan sistem caching yang jauh lebih kuat daripada web sebelumnya dengan AppCache. Anda dapat menggunakan Service Worker untuk mengelola permintaan offline, men-cache sumber daya tertentu, menyinkronkan data dengan server jarak jauh saat pengguna bahkan tidak membuka situs, dan banyak lagi. Mungkin lebih dari teknologi tunggal lainnya, Service Worker telah memungkinkan web untuk menawarkan pengalaman yang lebih mirip aplikasi.

Service Worker adalah salah satu dari tiga kunci utama teknis PWA. Satu lagi adalah Manifes Aplikasi Web. Meskipun mungkin terdengar sedikit membosankan, Manifes Aplikasi Web sebenarnya adalah alat yang sangat kuat karena memungkinkan situs web untuk mengiklankan dirinya sebagai sebuah aplikasi. Format file JSON yang relatif mudah ini memberikan banyak informasi tentang situs web yang dijelaskannya dan memungkinkan browser dan sistem operasi yang sadar PWA untuk menginstal situs seolah-olah itu adalah perangkat lunak asli.

Beberapa toko aplikasi bahkan mulai mengindeks PWA, menggunakan Manifest mereka untuk mengisi entri yang terkait. Dari sudut pandang pengguna, PWA di toko aplikasi tidak berbeda dengan aplikasi asli yang mengelilinginya. Mereka dapat diinstal, tidak dapat diinstal, dan bahkan dapat mengekspos pengaturannya ke alat manajemen aplikasi sistem operasi yang mendasarinya. Perlu juga dicatat bahwa PWA sebenarnya tidak membutuhkan pengguna untuk menginstalnya secara eksplisit untuk menggunakannya karena, yah, mereka hidup di web.

Berada di dalam dan di web juga berarti PWA selalu up to date. Pengguna tidak perlu secara aktif mengunduh sesuatu yang baru untuk mengakses fungsionalitas baru. Dan bahkan ketika konten dan fitur baru diluncurkan, sangat tidak mungkin pengguna perlu mengunduh ulang seluruh PWA Anda seperti yang mereka lakukan pada sebagian besar aplikasi asli. Jika ada, mereka mungkin mendapatkan beberapa aset baru dan beberapa HTML baru, dan itu akan terjadi secara instan, tidak diperlukan toko aplikasi. Tentu saja, Anda masih memiliki opsi penemuan dan distribusi yang disediakan oleh toko aplikasi, jadi ini benar-benar yang terbaik dari kedua dunia.

Berada di toko aplikasi menempatkan PWA pada pijakan yang sama dengan aplikasi asli dalam hal penemuan, distribusi, dan monetisasi. Bahkan, itu bahkan dapat membuat web lebih dari yang asli karena PWA juga dapat ditemukan melalui mesin telusur dan jauh lebih dapat dibagikan daripada aplikasi karena mereka ada di URL. Jika dibuat dengan baik, PWA juga dapat dioperasikan di seluruh browser, platform, dan perangkat. PWA bahkan bekerja di browser yang tidak mendukung fitur seperti Service Worker, karena fitur PWA adalah peningkatan progresif.

Web juga menawarkan dukungan aksesibilitas yang sangat matang, membuatnya relatif mudah untuk memastikan proyek Anda dapat digunakan oleh banyak pengguna. Antarmuka yang kompleks memang membutuhkan sedikit lebih banyak ketekunan dalam hal pemrograman, tetapi manfaat aksesibilitas yang diberikan oleh HTML semantik menangani aksesibilitas dasar dengan penuh percaya diri — terutama dalam hal produk berbasis teks, informasional, atau sederhana. Sebaliknya, Anda hampir selalu perlu menyadari dan memasukkan API aksesibilitas ke dalam kode asli Anda.

Pada topik pengembangan, saya tidak berpikir ada pemenang yang jelas dalam hal pengalaman pengembangan. Setiap bahasa memiliki penggemarnya sendiri, dan hal yang sama dapat dikatakan untuk alat pengembang. Anda menyukai apa yang Anda suka, dan Anda cenderung lebih efisien dengan alat dan bahasa yang Anda ketahui dan sukai. Baik web maupun pengembangan asli tidak memiliki keunggulan khusus di sana.

Namun, yang menonjol dari pengembangan asli adalah dalam hal memastikan tingkat kualitas yang konsisten untuk UI, yang dibuat menggunakan SDK (Software Development Kits) mereka. Sebagian besar SDK asli menawarkan alat untuk menguji kinerja, desain, fungsionalitas, dan lainnya. Mereka juga menyertakan kode boilerplate, sistem desain, dan alat lain yang membantu meningkatkan standar keseluruhan penawaran perangkat lunak asli. Tentu, ada alat serupa untuk web, tetapi alat tersebut tersebar di seluruh web dan tidak universal di semua lingkungan pengembangan berbeda yang digunakan orang untuk membuat situs web. Tidak ada entitas tunggal yang mendefinisikan pengalaman web berkualitas dan menyediakan alat untuk membangunnya (meskipun banyak yang telah mencoba).

Dalam hal staf pengembangan produk, pasti lebih mudah untuk mempekerjakan orang yang tahu cara membangun untuk web. Saat saya mengetik, Indeks Bahasa Pemrograman saat ini menempatkan JavaScript sebagai bahasa paling populer, dengan Java tepat di belakangnya. C# berada di urutan ke-5, HTML di urutan ke-7, CSS di urutan ke-9, dan Swift di urutan ke-15. Indeks ini merujuk silang tag Stack Overflow dengan garis yang diubah di repositori publik di GitHub, jadi itu harus diambil dengan sebutir garam, tetapi ini memberikan indikasi yang cukup jelas bahwa banyak orang tahu (dan menggunakan) teknologi web. Di sisi lain, seringkali sulit untuk menemukan dan merekrut pengembang asli berbakat karena jumlahnya lebih sedikit dan permintaannya tinggi.

Bakat yang langka berarti Anda kemungkinan besar akan membayar lebih untuk pengembangan asli. Setiap proyek jelas berbeda dan memiliki fitur dan persyaratan yang berbeda, tetapi dapat menjadi ilustrasi untuk melihat biaya pengembangan rata-rata sebagai perbandingan. Comentum menyarankan bahwa membangun aplikasi web berukuran sedang berkisar dari di bawah US$10.000 hingga US$150.000. Di sisi asli, Appster memperkirakan bahwa proyek aplikasi seluler berukuran sedang membutuhkan biaya antara US$110.000 dan US$305.000 untuk pembangunannya. Mungkin aman untuk berasumsi bahwa proyek asli cenderung menghabiskan biaya sekitar dua kali lipat untuk dikembangkan sebagai proyek web. Dan itu per platform. Aplikasi asli juga biasanya membutuhkan waktu lebih lama untuk dikembangkan.

Perlu dicatat bahwa ada opsi untuk membangun perangkat lunak asli menggunakan teknologi web tanpa membangun PWA. Kerangka kerja seperti React Native, PhoneGap, Ionic, dan Appcelerator Titanium memungkinkan Anda menghasilkan kode asli dari HTML, CSS, dan JavaScript. Menggunakan salah satu alat ini dapat menurunkan biaya staf dan pengembangan Anda jika dibandingkan dengan mempekerjakan tim pengembang asli, tetapi dalam hal akses ke fitur perangkat, proyek Anda akan terbatas pada yang telah diterapkan oleh kerangka kerja. Rencanakan sesuai.

Setelah aplikasi dikembangkan, Anda juga harus memperhitungkan biaya pemeliharaan berkelanjutan dari aplikasi atau aplikasi tersebut. Menanggapi survei yang dijalankan oleh Clutch, Dom & Tom merekomendasikan penganggaran 50% dari harga awal produk di tahun pertama, 25% di tahun kedua, dan antara 15-25% untuk setiap tahun setelahnya.

Setelah Anda memiliki pemahaman yang baik tentang bagaimana web dan pengembangan asli dibandingkan dan kontras, Anda dapat mulai menilai kekuatan dan kelemahan mana yang relevan dengan proyek Anda. Anda mungkin harus melakukan beberapa pengorbanan, dan itulah yang diharapkan. Tidak ada solusi satu ukuran untuk semua. Dan jika ada, itu tidak akan cocok dengan siapa pun.

Mari kita jalankan beberapa proyek hipotetis untuk memperjelas perbedaan antara pengembangan untuk native dan PWA.

Proyek #1: Aplikasi Asli yang Ada

Katakanlah Anda telah melalui proses membangun aplikasi asli. Jika semuanya berjalan dengan baik, tidak ada alasan untuk mengubah arah. Jangan membuang semua pekerjaan Anda yang ada untuk beralih ke PWA kecuali Anda memiliki alasan yang sangat bagus untuk melakukannya. Saya hanya dapat benar-benar memikirkan satu skenario yang mungkin perlu dipertimbangkan untuk beralih ke PWA: Membawa dukungan untuk OS baru ke dalam campuran. Dan meskipun demikian, sangat masuk akal jika kebutuhan aplikasi Anda dapat dipenuhi oleh web saja.

Jika Anda menambahkan dukungan untuk platform baru ke suatu produk, itu menciptakan peluang sempurna untuk mengevaluasi kebutuhan dan tujuan proyek sehubungan dengan biaya untuk memenuhi kebutuhan tersebut. Jika web tidak sesuai dengan tugas, tetap gunakan yang asli. Namun, jika ya, jeda dan pertimbangkan ini: Menambahkan dukungan untuk platform baru menggunakan PWA akan memungkinkan Anda untuk mendukung platform tambahan (termasuk web) di masa mendatang dan bahkan memungkinkan Anda untuk mengganti aplikasi asli yang ada setelah PWA memiliki telah diuji secara menyeluruh.

Jika mengganti aplikasi asli yang ada dengan PWA tampaknya tidak terpikirkan oleh Anda, pertimbangkan ini: Starbucks dan Twitter sudah menjajaki ide ini.

Jika ada alasan khusus mengapa Anda perlu menjaga aplikasi Anda tetap asli, masih ada baiknya mempertimbangkan untuk "mengalihdayakan" fitur aplikasi tertentu ke web. Beberapa tahun yang lalu, saya sedang mengerjakan sebuah proyek untuk perusahaan jasa keuangan besar, dan mereka memilih untuk memindahkan alur masuk untuk aplikasi asli mereka ke web untuk memungkinkan mereka meluncurkan fitur keamanan lebih cepat daripada toko aplikasi biasa. proses persetujuan memungkinkan mereka untuk mencapai. Mungkin proyek Anda memiliki kebutuhan serupa yang dapat dipenuhi oleh web untuk memenuhi aplikasi asli Anda.

Proyek #2: Aplikasi Lintas Platform yang Ada

Jika Anda sudah memiliki aplikasi yang bekerja lintas platform, kemungkinan besar Anda akan mengeluarkan banyak uang untuk pengembangan dan pemeliharaan aplikasi tersebut. Anda juga mungkin melihat beberapa perbedaan fitur dalam aplikasi karena setiap platform asli cenderung memiliki garis waktu pengembangannya sendiri. Aplikasi untuk pengecer Target, misalnya, saat ini memungkinkan pengguna untuk mengelola daftar belanja di iOS, tetapi versi Android tidak memiliki fitur itu. Dalam banyak hal ini mirip dengan perbedaan yang kadang-kadang kita lihat antara versi "desktop" dan "seluler" dari sebuah situs web.

Jika web sudah menjadi bagian dari campuran lintas platform Anda, ini memberikan peluang bagus untuk melipatgandakan investasi Anda di sana dan mempertimbangkan untuk mengganti aplikasi asli Anda dengan PWA. Alat seperti sonar dan Lighthouse dapat memberi Anda wawasan tentang seberapa baik persiapan situs Anda yang sudah ada untuk ifikasi PWA dan mereka juga dapat memberi tahu Anda apa yang perlu Anda kerjakan. Dari sana, mengubah situs web Anda menjadi PWA relatif mudah. Bahkan ada alat gratis yang dapat membantu Anda meningkatkan situs Anda ke PWA dalam beberapa menit. Namun, jika tidak, sebenarnya tidak ada banyak insentif untuk melakukan langkah ini kecuali perbedaan fitur antar platform menjadi sangat buruk atau Anda mempertimbangkan untuk menambahkan platform asli (atau web) ke dalam campuran.

Proyek #3: Produk Lintas Platform Baru

Jika Anda memulai proyek baru yang ditujukan untuk lebih dari satu platform, membuat dan memeliharanya di satu tempat sebagai PWA pasti ada di atas meja. Bergantung pada anggaran dan staf Anda, kemungkinan besar anggaran Anda akan membengkak. Yang mengatakan, jika produk Anda memerlukan koneksi langsung ke perangkat keras atau OS yang mendasarinya, Anda mungkin masih harus menggunakan yang asli. Tetapi sebelum Anda menempuh rute itu, buatlah daftar semua persyaratan Anda dan kemudian verifikasi apa yang dapat dilakukan web (dan apa yang tidak dapat dilakukan). Pastikan untuk memeriksa dukungan di lebih dari satu browser juga.

Proyek #4: Produk Baru yang Sangat Fokus

Jika Anda sedang membangun produk baru dan bagian dari seluruh tujuan produk itu adalah koneksi mendalamnya ke platform tertentu, tentu saja, buat untuk platform itu. Misalnya, jika produk Anda bergantung pada platform Pesan Apple atau integrasi dengan HomeKit, tentu saja, buat untuk iOS dan/atau macOS di Swift. Jika produk Anda paling sesuai dengan kebutuhan pengguna melalui widget atau Anda sedang membuat peluncur khusus, sebaiknya Anda membuat Android, dan Anda harus menggunakan Java.

Namun, tidak semua fitur asli adalah taman bertembok. Sementara Alexa Amazon, Siri Apple, dan Asisten Google semuanya memerlukan kode asli (atau JSON API) untuk berintegrasi dengan aplikasi Anda, menariknya Microsoft Cortana akan mengaktifkan suara PWA Anda hanya dengan menggunakan file XML yang ditautkan dari head HTML Anda. Mungkin orang lain akan mengikuti jejak mereka.

PWA Atau Asli? Pilihan ada padamu

Web dan asli masing-masing memiliki banyak hal untuk ditawarkan. Jika Anda bertanya kepada saya mana yang lebih baik, saya hanya akan menjawab "Tergantung" karena memang demikian. Saya tidak mengelak atau tidak berkomitmen; mencari tahu mana yang cocok untuk proyek Anda sepenuhnya bergantung pada kebutuhan spesifik proyek Anda. Ini membutuhkan pertimbangan apa yang Anda bangun, komposisi tim yang ada yang ditugaskan untuk membangunnya atau tim yang perlu Anda pekerjakan untuk melakukannya, dan anggaran yang harus Anda kerjakan. Dalam banyak kasus, web kemungkinan menawarkan semua yang Anda butuhkan untuk mencapai tujuan proyek Anda, tetapi selalu ada pengecualian. Jika Anda ingin menjelajahi kemungkinan yang ditawarkan web, saya telah menyertakan beberapa sumber di akhir artikel ini.

Hal terpenting yang dapat Anda lakukan saat menimbang pendekatan yang berbeda untuk pengembangan perangkat lunak — atau kerangka kerja yang berbeda, perpustakaan, bahasa, sistem desain, dll. — adalah mempertimbangkan pilihan Anda sehubungan dengan proyek yang ada. Lakukan riset dan pertimbangkan pilihan Anda. Dan jangan biarkan diri Anda terombang-ambing oleh pemasaran yang cerdik, demo seksi, atau fanboy fanatik. Termasuk yang satu ini.

Sumber Daya Terkait PWA

• Pembuat PWA
  Alat pembuatan situs web-ke-PWA 3 langkah dengan rekomendasi dan resep yang bermanfaat. Ini juga memungkinkan Anda untuk mengubah PWA Anda menjadi aplikasi asli yang dapat diinstal untuk Windows, Android, dan iOS.
• Peta Jalan Progresif untuk Aplikasi Web Progresif Anda
  Jason Grigsby tentang bagaimana timnya mulai memasukkan aspek PWA ke dalam situs web mereka selama beberapa bulan, dengan baik menunjukkan bagaimana fitur yang berbeda dapat ditambahkan sedikit demi sedikit.
• Ya, Proyek Web Itu Harus Menjadi PWA
  Ikhtisar peluang UX (dan risiko) PWA, yang ditulis oleh Anda.
• Aplikasi Web Progresif di MDN
  Sebuah hub untuk semua bagian teknis yang perlu Anda ketahui tentang karakteristik PWA yang berkualitas.
• Apa yang Dapat Dilakukan Web Hari Ini
  Lihat API yang didukung perangkat, OS, dan browser Anda. Apa yang Anda temukan mungkin akan mengejutkan Anda.
• Dapatkah saya menggunakan?
  Basis data definitif tentang API dan fitur apa yang tersedia di setiap browser utama dan bagaimana dukungan itu mengukur relatif terhadap browser yang sebenarnya digunakan orang. Ini juga dapat memberi Anda pandangan yang sangat baik ke masa lalu untuk melihat seberapa kompatibel fitur-fitur tertentu.