Merancang Dan Membangun Aplikasi Web Progresif Tanpa Kerangka Kerja (Bagian 1)

Bagaimana cara kerja aplikasi web? Saya tidak bermaksud dari sudut pandang pengguna akhir. Maksud saya dalam arti teknis. Bagaimana sebenarnya aplikasi web berjalan? Apa yang memulai? Tanpa kode boilerplate, apa cara yang tepat untuk menyusun aplikasi? Khususnya aplikasi sisi klien di mana semua logika berjalan pada perangkat pengguna akhir. Bagaimana data dikelola dan dimanipulasi? Bagaimana Anda membuat antarmuka bereaksi terhadap perubahan data?

Ini adalah jenis pertanyaan yang mudah diabaikan atau diabaikan sepenuhnya dengan kerangka kerja. Pengembang menjangkau sesuatu seperti React, Vue, Ember atau Angular, ikuti dokumentasi untuk memulai dan menjalankannya. Masalah-masalah itu ditangani oleh kotak trik kerangka kerja.

Itu mungkin persis seperti yang Anda inginkan. Bisa dibilang, ini adalah hal yang cerdas untuk dilakukan jika Anda ingin membangun sesuatu dengan standar profesional. Namun, dengan sihir yang diabstraksikan, Anda tidak akan pernah bisa mempelajari bagaimana trik sebenarnya dilakukan.

Tidakkah Anda ingin tahu bagaimana triknya?

Aku melakukannya. Jadi, saya memutuskan untuk mencoba membangun aplikasi sisi klien dasar, tanpa kerangka kerja, untuk memahami masalah ini sendiri.

Tapi, saya mendapatkan sedikit di depan diriku sendiri; sedikit latar belakang dulu.

Sebelum memulai perjalanan ini, saya menganggap diri saya sangat mahir dalam HTML dan CSS tetapi bukan JavaScript. Karena saya merasa telah memecahkan pertanyaan terbesar yang saya miliki tentang CSS untuk kepuasan saya, tantangan berikutnya yang saya tentukan sendiri adalah memahami bahasa pemrograman.

Faktanya adalah, saya relatif tingkat pemula dengan JavaScript. Dan, selain meretas PHP Wordpress, saya juga tidak memiliki paparan atau pelatihan dalam bahasa pemrograman lain.

Biarkan saya memenuhi syarat pernyataan 'tingkat pemula' itu. Tentu, saya bisa membuat interaktivitas bekerja di halaman. Beralih kelas, buat simpul DOM, tambahkan dan pindahkan, dll. Tetapi ketika harus mengatur kode untuk apa pun di luar itu, saya tidak tahu apa-apa. Saya tidak percaya diri membangun apa pun yang mendekati aplikasi. Saya tidak tahu bagaimana mendefinisikan satu set data di JavaScipt, apalagi memanipulasinya dengan fungsi.

Saya tidak mengerti tentang 'pola desain' JavaScript — pendekatan yang mapan untuk memecahkan masalah kode yang sering dihadapi. Saya tentu saja tidak merasakan bagaimana mendekati keputusan desain aplikasi yang mendasar.

Pernahkah Anda memainkan 'Top Trumps'? Nah, dalam edisi pengembang web, kartu saya akan terlihat seperti ini (menandai dari 100):

• CSS: 95
• Salin dan tempel: 90
• Garis rambut: 4
• HTML: 90
• JavaSript: 13

Selain ingin menantang diri sendiri di tingkat teknis, saya juga kurang dalam hal desain.

Dengan hampir secara eksklusif mengkodekan desain orang lain selama dekade terakhir, keterampilan desain visual saya tidak memiliki tantangan nyata sejak akhir tahun 1990-an. Merefleksikan fakta itu dan keterampilan JavaScript saya yang lemah, menumbuhkan rasa ketidakmampuan profesional yang semakin meningkat. Sudah waktunya untuk mengatasi kekurangan saya.

Tantangan pribadi muncul di benak saya: merancang dan membangun aplikasi web JavaScript sisi klien.

Sedang Belajar

Tidak pernah ada sumber daya yang lebih hebat untuk mempelajari bahasa komputasi. Khususnya JavaScript. Namun, saya butuh beberapa saat untuk menemukan sumber daya yang menjelaskan berbagai hal dengan cara yang menarik. Bagi saya, 'You Don't Know JS' dari Kyle Simpson dan 'Eloquent JavaScript' oleh Marijn Haverbeke sangat membantu.

Jika Anda mulai belajar JavaScript, Anda pasti perlu menemukan guru Anda sendiri; orang-orang yang metode penjelasannya cocok untuk Anda.

Hal penting pertama yang saya pelajari adalah tidak ada gunanya mencoba belajar dari guru/sumber yang tidak menjelaskan hal-hal dengan cara yang Anda pahami. Beberapa orang melihat contoh fungsi dengan foo dan bar in dan langsung grok artinya. Saya bukan salah satu dari orang-orang itu. Jika Anda juga tidak, jangan menganggap bahasa pemrograman bukan untuk Anda. Coba saja sumber daya yang berbeda dan teruslah mencoba menerapkan keterampilan yang Anda pelajari.

Ini juga tidak berarti bahwa Anda akan menikmati momen eureka apa pun di mana semuanya tiba-tiba 'klik'; seperti pengkodean yang setara dengan cinta pada pandangan pertama. Kemungkinan besar dibutuhkan banyak ketekunan dan penerapan yang cukup besar dari pembelajaran Anda untuk merasa percaya diri.

Segera setelah Anda merasa sedikit kompeten, mencoba menerapkan pembelajaran Anda akan mengajarkan Anda lebih banyak lagi.

Berikut adalah beberapa sumber yang menurut saya bermanfaat selama ini:

• Fun Fun Fun Fungsi Saluran YouTube
• Kursus Penglihatan Jamak Kyle Simpson
• JavaScript30.com milik Wes Bos
• JavaScript yang Fasih oleh Marijn Haverbeke

Benar, itu saja yang perlu Anda ketahui tentang mengapa saya sampai pada titik ini. Gajah sekarang di ruangan itu, kenapa tidak menggunakan rangka?

Mengapa Tidak Bereaksi, Ember, Angular, Vue Et Al

Sementara jawabannya disinggung di awal, saya pikir topik mengapa kerangka kerja tidak digunakan perlu diperluas.

Ada banyak kerangka kerja JavaScript berkualitas tinggi yang didukung dengan baik. Masing-masing dirancang khusus untuk pembangunan aplikasi web sisi klien. Persis jenis hal yang saya ingin membangun. Saya memaafkan Anda karena bertanya-tanya yang sudah jelas: seperti, err, mengapa tidak menggunakannya?

Inilah pendirian saya tentang itu. Saat Anda belajar menggunakan abstraksi, itulah yang terutama Anda pelajari — abstraksi. Saya ingin mempelajari sesuatu, bukan abstraksinya.

Saya ingat belajar beberapa jQuery di masa lalu. Sementara API yang indah memungkinkan saya membuat manipulasi DOM lebih mudah dari sebelumnya, saya menjadi tidak berdaya tanpanya. Saya bahkan tidak bisa mengaktifkan kelas pada elemen tanpa perlu jQuery. Tugaskan saya dengan beberapa interaktivitas dasar pada halaman tanpa jQuery untuk bersandar dan saya tersandung di editor saya seperti Samson yang dicukur.

Baru-baru ini, ketika saya mencoba untuk meningkatkan pemahaman saya tentang JavaScript, saya mencoba untuk memahami Vue dan React sedikit. Tetapi pada akhirnya, saya tidak pernah yakin di mana JavaScript standar berakhir dan React atau Vue dimulai. Pendapat saya adalah bahwa abstraksi ini jauh lebih berharga ketika Anda memahami apa yang mereka lakukan untuk Anda.

Oleh karena itu, jika saya akan mempelajari sesuatu, saya ingin memahami bagian inti dari bahasa tersebut. Dengan begitu, saya memiliki beberapa keterampilan yang dapat ditransfer. Saya ingin mempertahankan sesuatu ketika rasa kerangka bulan saat ini telah dikesampingkan untuk 'hal baru yang panas' berikutnya.

Baik. Sekarang, kita mengetahui mengapa aplikasi ini dibuat, dan juga, suka atau tidak suka, bagaimana aplikasi itu dibuat.

Mari kita beralih ke hal apa yang akan terjadi.

Ide Aplikasi

Saya membutuhkan ide aplikasi. Tidak ada yang terlalu ambisius; Saya tidak memiliki delusi untuk membuat bisnis baru atau muncul di Dragon's Den — mempelajari JavaScript dan dasar-dasar aplikasi adalah tujuan utama saya.

Aplikasi harus menjadi sesuatu yang saya punya kesempatan untuk melakukan secara teknis dan membuat pekerjaan desain setengah layak untuk boot.

Waktu singgung.

Jauh dari pekerjaan, saya mengatur dan bermain sepak bola dalam ruangan kapan pun saya bisa. Sebagai penyelenggara, sangat menyakitkan untuk dicatat secara mental siapa yang telah mengirimi saya pesan untuk mengatakan bahwa mereka bermain dan siapa yang tidak. Biasanya dibutuhkan 10 orang untuk permainan, 8 orang dalam sekali push. Ada daftar sekitar 20 orang yang mungkin atau mungkin tidak dapat memainkan setiap permainan.

Ide aplikasi yang saya tentukan adalah sesuatu yang memungkinkan memilih pemain dari daftar, memberi saya hitungan berapa banyak pemain yang telah mengonfirmasi bahwa mereka bisa bermain.

Saat saya memikirkannya lebih lanjut, saya merasa saya dapat sedikit memperluas cakupannya sehingga dapat digunakan untuk mengatur aktivitas berbasis tim yang sederhana.

Memang, saya hampir tidak pernah membayangkan Google Earth. Namun, itu memiliki semua tantangan penting: desain, manajemen data, interaktivitas, penyimpanan data, organisasi kode.

Dari segi desain, saya tidak akan menyibukkan diri dengan apa pun selain versi yang dapat berjalan dan bekerja dengan baik di area pandang ponsel. Saya akan membatasi tantangan desain untuk memecahkan masalah di layar kecil saja.

Ide inti tentu saja bersandar pada aplikasi gaya 'yang harus dilakukan', di mana ada banyak contoh yang ada untuk dilihat sebagai inspirasi sementara juga memiliki perbedaan yang cukup untuk memberikan beberapa tantangan desain dan pengkodean yang unik.

Fitur yang Dimaksudkan

Daftar poin-poin awal fitur yang ingin saya desain dan kodekan terlihat seperti ini:

• Kotak input untuk menambahkan orang ke daftar;
• Kemampuan untuk mengatur setiap orang ke 'masuk' atau 'keluar';
• Alat yang membagi orang menjadi tim, default ke 2 tim;
• Kemampuan untuk menghapus seseorang dari daftar;
• Beberapa antarmuka untuk 'alat'. Selain pemisahan, alat yang tersedia harus mencakup kemampuan untuk mengunduh data yang dimasukkan sebagai file, mengunggah data yang disimpan sebelumnya, dan menghapus semua pemain sekaligus;
• Aplikasi harus menunjukkan hitungan saat ini tentang berapa banyak orang yang 'Masuk';
• Jika tidak ada orang yang dipilih untuk permainan, itu harus menyembunyikan pembagi tim;
• Modus bayar. Pengalihan dalam pengaturan yang memungkinkan pengguna 'dalam' memiliki sakelar tambahan untuk menunjukkan apakah mereka telah membayar atau belum.

Pada awalnya, inilah yang saya anggap sebagai fitur untuk produk yang layak minimum.

Desain

Desain dimulai pada secarik kertas. Itu mencerahkan (baca: menghancurkan) untuk mengetahui betapa banyak ide yang luar biasa di kepala saya ternyata menggelikan ketika mengalami pengawasan bahkan sedikit yang diberikan oleh gambar pensil.

Oleh karena itu, banyak ide dengan cepat dikesampingkan, tetapi sisi sebaliknya adalah bahwa dengan membuat sketsa beberapa ide, itu selalu mengarah pada ide-ide lain yang tidak akan pernah saya pertimbangkan.

Sekarang, desainer yang membaca ini kemungkinan akan seperti, "Duh, tentu saja" tapi ini adalah wahyu yang nyata bagi saya. Pengembang terbiasa melihat desain tahap selanjutnya, jarang melihat semua langkah yang ditinggalkan di sepanjang jalan sebelum titik itu.

Setelah puas dengan sesuatu sebagai gambar pensil, saya akan mencoba dan membuatnya kembali dalam paket desain, Sketch. Sama seperti ide-ide yang hilang pada tahap kertas dan pensil, jumlah yang sama gagal untuk melewati tahap fidelitas Sketsa berikutnya. Yang tampaknya bertahan sebagai artboard di Sketch kemudian dipilih sebagai kandidat untuk dikodekan.

Saya akan menemukan bahwa ketika kandidat tersebut adalah kode bawaan, persentase juga gagal berfungsi karena berbagai alasan. Setiap langkah fidelity memaparkan tantangan baru agar desain bisa lolos atau gagal. Dan kegagalan akan membawa saya secara harfiah dan kiasan kembali ke papan gambar.

Dengan demikian, pada akhirnya, desain yang saya dapatkan sedikit berbeda dari yang saya miliki di Sketch. Berikut adalah mockup Sketch pertama:

Bahkan saat itu, saya tidak mengalami delusi; itu adalah desain dasar. Namun, pada titik ini saya memiliki sesuatu yang saya yakini dapat bekerja dengan baik dan saya berusaha keras untuk mencoba dan membangunnya.

Persyaratan Teknis

Dengan beberapa persyaratan fitur awal dan arahan visual dasar, sudah waktunya untuk mempertimbangkan apa yang harus dicapai dengan kode.

Meskipun kebijaksanaan yang diterima menyatakan bahwa cara membuat aplikasi untuk perangkat iOS atau Android adalah dengan kode asli, kami telah menetapkan bahwa niat saya adalah untuk membangun aplikasi dengan JavaScript.

Saya juga ingin memastikan bahwa aplikasi mencentang semua kotak yang diperlukan untuk memenuhi syarat sebagai Aplikasi Web Progresif, atau PWA seperti yang lebih dikenal.

Jika Anda tidak mengetahui apa itu Aplikasi Web Progresif, inilah 'elevator pitch'. Secara konseptual, bayangkan aplikasi web standar tetapi yang memenuhi beberapa kriteria tertentu. Kepatuhan terhadap kumpulan persyaratan khusus ini berarti bahwa perangkat pendukung (seperti telepon seluler) memberikan hak istimewa khusus kepada aplikasi web, membuat aplikasi web lebih besar daripada jumlah bagian-bagiannya.

Di Android, khususnya, hampir mustahil untuk membedakan PWA, yang dibuat hanya dengan HTML, CSS, dan JavaScript, dari aplikasi yang dibuat dengan kode asli.

Berikut adalah daftar periksa Google untuk persyaratan agar aplikasi dianggap sebagai Aplikasi Web Progresif:

• Situs dilayani melalui HTTPS;
• Halaman responsif di tablet & perangkat seluler;
• Semua URL aplikasi dimuat saat offline;
• Metadata disediakan untuk layar Tambahkan ke Beranda;
• Muat pertama dengan cepat bahkan di 3G;
• Situs bekerja lintas-browser;
• Transisi halaman tidak terasa seperti diblokir di jaringan;
• Setiap halaman memiliki URL.

Selain itu, jika Anda benar-benar ingin menjadi kesayangan guru dan aplikasi Anda dianggap sebagai 'Aplikasi Web Progresif Teladan', maka aplikasi tersebut juga harus memenuhi persyaratan berikut:

• Konten situs diindeks oleh Google;
• Metadata Schema.org disediakan jika sesuai;
• Metadata sosial disediakan jika sesuai;
• URL kanonik disediakan bila diperlukan;
• Halaman menggunakan History API;
• Konten tidak melompat saat halaman dimuat;
• Menekan kembali dari halaman detail akan mempertahankan posisi gulir pada halaman daftar sebelumnya;
• Saat diketuk, input tidak dikaburkan oleh keyboard di layar;
• Konten dapat dibagikan dengan mudah dari mode mandiri atau layar penuh;
• Situs responsif di seluruh ukuran layar ponsel, tablet, dan desktop;
• Perintah pemasangan aplikasi apa pun tidak digunakan secara berlebihan;
• Prompt Add to Home Screen dicegat;
• Muat pertama sangat cepat bahkan pada 3G;
• Situs menggunakan jaringan cache-first;
• Situs dengan tepat memberi tahu pengguna saat mereka offline;
• Memberikan konteks kepada pengguna tentang bagaimana notifikasi akan digunakan;
• UI yang mendorong pengguna untuk mengaktifkan Pemberitahuan Push tidak boleh terlalu agresif;
• Situs meredupkan layar saat permintaan izin ditampilkan;
• Pemberitahuan push harus tepat waktu, tepat, dan relevan;
• Menyediakan kontrol untuk mengaktifkan dan menonaktifkan notifikasi;
• Pengguna masuk di seluruh perangkat melalui API Manajemen Kredensial;
• Pengguna dapat membayar dengan mudah melalui UI asli dari API Permintaan Pembayaran.

Kriuk! Saya tidak tahu tentang Anda tetapi hal-hal kedua itu sepertinya banyak pekerjaan untuk aplikasi dasar! Kebetulan ada banyak item di sana yang tidak relevan dengan apa yang saya rencanakan. Meskipun begitu, saya tidak malu untuk mengatakan bahwa saya menurunkan pandangan saya hanya untuk lulus tes awal.

Untuk seluruh bagian dari jenis aplikasi, saya percaya PWA adalah solusi yang lebih berlaku daripada aplikasi asli. Di mana game dan SaaS bisa dibilang lebih masuk akal di toko aplikasi, utilitas yang lebih kecil dapat hidup dengan cukup bahagia dan lebih berhasil di web sebagai Aplikasi Web Progresif.

Sementara pada subjek saya melalaikan kerja keras, pilihan lain yang dibuat sejak awal adalah mencoba dan menyimpan semua data untuk aplikasi di perangkat pengguna sendiri. Dengan begitu, tidak perlu terhubung dengan layanan data dan server dan berurusan dengan login dan otentikasi. Untuk di mana keterampilan saya berada, mencari tahu otentikasi dan menyimpan data pengguna sepertinya hampir pasti akan menggigit lebih dari yang bisa saya kunyah dan berlebihan untuk pengiriman aplikasi!

Pilihan Teknologi

Dengan gagasan yang cukup jelas tentang apa tujuannya, perhatian beralih ke alat yang dapat digunakan untuk membangunnya.

Saya memutuskan sejak awal untuk menggunakan TypeScript, yang dijelaskan di situs webnya sebagai "... superset yang diketik dari JavaScript yang dikompilasi ke JavaScript biasa." Apa yang saya lihat dan baca dari bahasa yang saya sukai, terutama fakta bahwa bahasa itu belajar sendiri dengan sangat baik untuk analisis statis.

Analisis statis berarti sebuah program dapat melihat kode Anda sebelum menjalankannya (misalnya ketika statis) dan menyoroti masalah. Itu tidak selalu dapat menunjukkan masalah logis tetapi dapat menunjukkan kode yang tidak sesuai dengan seperangkat aturan.

Apa pun yang dapat menunjukkan kesalahan saya (pasti banyak) saat saya melanjutkan harus menjadi hal yang baik, bukan?

Jika Anda tidak terbiasa dengan TypeScript, pertimbangkan kode berikut dalam JavaScript vanilla:

 console.log(`${count} players`); let count = 0;

Jalankan kode ini dan Anda akan mendapatkan kesalahan seperti:

 ReferenceError: Cannot access uninitialized variable.

Bagi mereka yang bahkan memiliki sedikit kecakapan JavaScript, untuk contoh dasar ini, mereka tidak memerlukan alat untuk memberi tahu mereka bahwa segala sesuatunya tidak akan berakhir dengan baik.

Namun, jika Anda menulis kode yang sama di TypeScript, ini terjadi di editor:

Saya mendapatkan umpan balik tentang kebodohan saya bahkan sebelum saya menjalankan kode! Itulah keindahan analisis statis. Umpan balik ini sering seperti memiliki pengembang yang lebih berpengalaman duduk bersama saya menangkap kesalahan saat saya pergi.

TypeScript terutama, seperti namanya, mari Anda tentukan 'tipe' yang diharapkan untuk setiap hal dalam kode. Ini mencegah Anda secara tidak sengaja 'memaksa' satu jenis ke jenis lainnya. Atau mencoba menjalankan metode pada sepotong data yang tidak berlaku — metode larik pada objek misalnya. Ini bukan jenis hal yang selalu menghasilkan kesalahan saat kode dijalankan, tetapi tentu saja dapat menyebabkan bug yang sulit dilacak. Berkat TypeScript, Anda mendapatkan umpan balik di editor bahkan sebelum mencoba menjalankan kode.

TypeScript tentu saja tidak penting dalam perjalanan penemuan ini dan saya tidak akan pernah mendorong siapa pun untuk menggunakan alat seperti ini kecuali ada manfaat yang jelas. Menyiapkan alat dan mengonfigurasi alat di tempat pertama dapat menghabiskan waktu, jadi pertimbangkan penerapannya sebelum menyelam.

Ada manfaat lain yang diberikan oleh TypeScript yang akan kita bahas di artikel berikutnya dalam seri ini, tetapi kemampuan analisis statis saja sudah cukup bagi saya untuk ingin mengadopsi TypeScript.

Ada pertimbangan langsung dari pilihan yang saya buat. Memilih untuk membangun aplikasi sebagai Aplikasi Web Progresif berarti saya perlu memahami Pekerja Layanan sampai taraf tertentu. Menggunakan TypeScript berarti memperkenalkan semacam alat build. Bagaimana saya mengelola alat-alat itu? Secara historis, saya telah menggunakan NPM sebagai manajer paket tetapi bagaimana dengan Benang? Apakah layak menggunakan Benang sebagai gantinya? Berfokus pada kinerja berarti mempertimbangkan beberapa alat minifikasi atau bundling; alat seperti webpack menjadi semakin populer dan perlu dievaluasi.

Ringkasan

Saya menyadari kebutuhan untuk memulai pencarian ini. Kekuatan JavaScript saya lemah dan tidak ada yang bisa menahan beban selain mencoba mempraktikkan teori. Memutuskan untuk membangun aplikasi web dengan vanilla JavaScript adalah keputusan saya.

Saya telah menghabiskan beberapa waktu untuk meneliti dan mempertimbangkan opsi untuk membuat aplikasi dan memutuskan bahwa menjadikan aplikasi sebagai Aplikasi Web Progresif paling masuk akal untuk keahlian saya dan kesederhanaan ide yang relatif.

Saya membutuhkan alat pembuatan, manajer paket, dan selanjutnya, banyak kesabaran.

Pada akhirnya, pada titik ini pertanyaan mendasar tetap ada: apakah ini sesuatu yang benar-benar dapat saya kelola? Atau apakah saya akan direndahkan oleh ketidakmampuan saya sendiri?

Saya harap Anda bergabung dengan saya di bagian dua ketika Anda dapat membaca tentang alat pembuatan, pola desain JavaScript, dan cara membuat sesuatu yang lebih 'seperti aplikasi'.