atau artikel keseratus yang mengeluhkan tentang pengembangan web

Di awal tahun, karena terinspirasi oleh terlalu banyak postingan blog, saya mulai memiliki keinginan untuk menggabungkan semua fitur yang pernah saya dengar dimiliki situs web hebat dan membangun aplikasi web yang sempurna. Itu harus cepat. Cepat untuk melukis pertama dan interaktivitas pertama. Situs web harus cepat dalam jutaan cara saat ini karena Anda mengirim aplikasi itu sendiri dan menjalankan aplikasi di ribuan jenis perangkat yang berbeda. Saya juga ingin membuatnya dapat diakses dan berfungsi, sampai batas tertentu, dengan pengaturan browser apa pun. Misalnya, ia harus tetap beroperasi jika JavaScript atau cookie dinonaktifkan. Selain itu, saya menginginkan pengalaman pengembangan yang nyaman dan mudah dipahami, yang bagi saya berarti hanya menggunakan sedikit alat baris perintah dan pustaka dalam prosesnya.

Semuanya terasa sangat menakutkan, dan saya sedikit takut untuk memulai karena saya tidak ingin menulis semuanya hanya untuk menyadari bahwa saya tidak mencapai salah satu tolok ukur saya dan harus menulis ulang semuanya agar sesuai. Di belakang kepala saya, saya terus berpikir ada beberapa unsur utama dalam pengembangan web yang saya lewatkan yang akan membuat semuanya klik. Namun sampai saat itu tiba, aku hanya membiarkan gagasan itu melayang di kepalaku dan menggangguku.

Kemudian Google IO 2018 hadir dan saya menemukan "video luar biasa" Jeff Posnick di PWA multihalaman. Gagasan untuk benar-benar menggunakan kemampuan streaming browser dan menulis JavaScript universal sehingga Anda dapat membuat HTML dari server untuk pemuatan awal, atau sebagai cadangan, dan kemudian juga membuatnya dari pekerja layanan sepertinya merupakan ide yang sangat baru untuk dibuat. aplikasi cepat dan tersedia. Semuanya menggunakan sedikit perpustakaan, alat baris perintah, atau memiliki langkah/konfigurasi pembangunan yang rumit.

Satu-satunya kelemahan yang saya rasakan adalah tidak menggunakan komponen, jadi sepertinya agak terbatas dibandingkan dengan metode pengembangan web lain yang diperbolehkan. Saya pikir itu mungkin sedikit bagian dari daya tariknya, tapi saya pikir saya selalu bisa mengalirkan JavaScript di akhir file untuk mengganti elemen HTML tertentu dengan komponen jika diperlukan.

Setelah menonton videonya beberapa kali dan membaca blog di streaming, akhirnya saya merasa menemukan desain yang saya cari.

Proyek

Sekarang setelah saya mengetahui caranya, saya perlu mencari tahu apa. Saya ingin membuat sesuatu yang sedikit unik dan akan digunakan pada kesempatan tertentu. Saya perhatikan bahwa sebagian besar aplikasi podcasting populer adalah aplikasi asli (kecuali mungkin Spotify jika Anda menghitungnya). Saya merasa, dengan kemajuan dalam dukungan web offline, saya dapat menciptakan pengalaman yang sama baiknya dalam aplikasi web. Mungkin aplikasi saya tidak dapat menyimpan banyak file audio (sulit untuk mengatakannya karena cara beberapa browser membagi ruang ke situs web bisa jadi sedikit misterius), namun, selain itu, saya seharusnya dapat membuat web yang cepat -aplikasi dengan fitur yang hampir setara dengan pengalaman asli apa pun.

Mengapa artikel ini tidak membahas bulan-bulan yang saya habiskan untuk membangun ini? Ya, saya akhirnya berhenti bermain-main dengan ide itu selama dua minggu. Jadi mengapa saya menulis artikel tentang hal itu? Baiklah, saya ingin berbagi perjuangan saya dengan orang-orang yang berpikir untuk menempuh jalan yang sama dan berharap ini bermanfaat bagi mereka. Atau mungkin aku hanya ingin merengek. Namun, di bawah ini adalah masalah yang saya alami saat mengubah pengalaman asli menjadi pengalaman web. Beberapa dari masalah ini khusus untuk proyek tersebut, dan masalah lainnya memiliki solusinya, namun menghadapi masalah ini membuat apa yang saya pikir akan menjadi pengalaman menarik menjadi pengalaman yang membuat frustrasi.

Masalah

JavaScript Universal

Seperti disebutkan di atas, saya ingin menulis JavaScript yang berfungsi di Node.js dan di browser. Karena Node.js mendukung modul dalam mode eksperimental (selama Anda menggunakan ekstensi .mjs) dan sebagian besar browser sekarang mendukungnya secara naif, saya merasa nyaman menulis JavaScript dalam modul tanpa bergantung pada alat build. Browser apa pun yang tidak mendukung modul hanya akan mendapatkan pengalaman yang lebih statis yang didapat oleh pengguna dengan JavaScript yang dinonaktifkan.

Masalah yang jelas, yang saya tidak yakin mengapa saya tidak menyadarinya lebih awal, adalah bahwa saat ini tidak ada browser yang mendukung modul yang berjalan di pekerja layanan. Mereka hanya mendukung pengimporan skrip ke pekerja layanan melalui importScripts. Dan karena sebagian besar JavaScript yang saya tulis akan digunakan untuk menghasilkan HTML dan perlu dijalankan di pekerja layanan, saya mengalami beberapa masalah. Saya sempat berpikir saya bisa mengimpor file menggunakan importScripts alih-alih mengimpor, tetapi pekerja layanan tidak dapat mengurai kata kunci ekspor atau impor dalam modul itu sendiri sehingga tidak berfungsi.

Namun, masalah ini bukanlah masalah besar. Vendor browser menyadari masalah ini dan secara aktif mengatasinya. Sementara itu, ada beberapa solusi. Saya bisa menjalankan alat/perpustakaan build yang akan menyelesaikannya, seperti yang ini, atau tidak menggunakan modul. Pada saat itu, saya memutuskan untuk menyalin semua kode modul ke dalam satu file untuk penggunaan pekerja layanan dan setelah saya melihatnya berfungsi, saya berencana untuk mengimplementasikan alat pembangunan atau menggunakan perpustakaan. Namun tidak lama kemudian saya mengalami masalah lain.

DOMParser

Langkah nyata pertama dalam proyek ini melibatkan penguraian RSS feed dari podcast yang dipilih untuk mendapatkan informasi episode. Browser memiliki antarmuka DOMParser yang memudahkan penguraian XML. Sayangnya, Node.js tidak memiliki apa pun di perpustakaan standarnya. Setelah mencari di beberapa perpustakaan di NPM saya "menemukan satu" dengan API yang sama dengan DOMParser. Jadi, saat pengguna mencari podcast, saya mengambil feed, menguraikannya, membuat HTML, dan mengalirkannya ke pengguna. Besar! Sekarang saya hanya perlu melakukannya dari pekerja layanan.

Tampaknya cukup mudah. Setelah pekerja layanan diinstal, ketika pengguna membuat permintaan informasi episode, saya hanya akan mencegat permintaan tersebut. Keluarkan informasi tentang podcast apa yang mereka inginkan. Ambil umpan itu. Dan terakhir, parsing XML, buat HTML, dan masukkan ke respons yang saya buat. Semua dari pekerja layanan.

Karena saya sedang menulis JavaScript universal, saya pikir tidak akan menjadi masalah jika hanya memasukkan kode sisi server saya. Namun, dan Anda mungkin melihat ke mana arahnya, Anda tidak dapat melakukan hal-hal terkait DOM di pekerja layanan. Selain itu, tampaknya DOMParser yang tidak aman untuk thread adalah "juga merupakan masalah". Saya mencari sedikit perpustakaan eksternal untuk mengurai XML yang akan berfungsi di pekerja layanan (sepertinya yang saya gunakan di sisi server), tetapi tidak dapat menemukan apa pun dengan API yang sama. Mungkin saya terlalu pilih-pilih, tapi saya putuskan untuk menyerah saja saat ini karena saat saya menangani masalah ini, masalah lain yang lebih besar terus bermunculan yang membuat saya merasa proyek ini sia-sia.

KOR

Pada bagian di atas saya membuatnya seolah-olah mengambil feed di pekerja layanan adalah proses yang sederhana. Dan mengapa hal itu tidak terjadi. Ya, hanya sedikit feed yang memiliki header CORS sehingga pekerja layanan, atau JavaScript apa pun yang dijalankan dari domain, tidak akan memiliki akses ke konten dalam permintaan. Saya dapat mem-proxy feed dari server saya dan membiarkan pekerja layanan menguraikannya. Ini bukan ide yang buruk sampai saya menyadari bahwa dalam kebanyakan kasus, file audio juga tidak memiliki header CORS di dalamnya.

Anda sebenarnya tidak perlu membuat permintaan CORS untuk file audio agar pengguna dapat memutarnya dari situs Anda, namun saya baru-baru ini membaca artikel ini oleh Gerardo Rodriquez yang membahas bagaimana permintaan buram untuk gambar lintas asal memakan banyak ruang di cache pekerja layanan karena berbagai alasan dan saya berasumsi hal yang sama juga berlaku untuk file audio. Karena sebagian besar aplikasi melibatkan penyimpanan file audio dalam cache untuk penggunaan offline, ini akan menjadi masalah.

Saya akhirnya menemukan satu perusahaan hosting podcast yang menambahkan header CORS ke feed dan file audio mereka, Libsyn. Saya pikir saya setidaknya bisa menguji aplikasinya menggunakan salah satu podcast yang mereka host. Tapi ada jebakan yang sangat licik menungguku. Akhirnya tautan yang disediakan Libsyn di feed mereka untuk file audio mengarahkan Anda ke situs lain. Itu saja tidak masalah, karena browser baru-baru ini diperbaiki untuk menangani permintaan CORS yang merespons dengan status 302. Namun server juga merespon permintaan preflight dengan status 302 yang merupakan respon tidak valid sehingga permintaan gagal. Setidaknya itulah yang menurut saya sedang terjadi. Sulit untuk membedakan CORS.

Hal ini cukup mengecewakan dan menyadarkan saya bahwa mungkin perlu waktu lama hingga hal ini benar-benar dapat dilakukan. Tentu saja, seperti yang saya sebutkan di atas, selalu ada opsi untuk menyiapkan proxy untuk memenuhi permintaan Anda. Namun, saya tidak menyukai metode tersebut karena bukan hanya bandwidth yang menjadi perhatian, namun bagian dari desain aplikasinya adalah pekerja layanan akan mampu menangani sebagian besar permintaan dan hanya memerlukan sedikit komunikasi ke server. Memproksi segala sesuatu sepertinya akan melemahkan gagasan itu.

Kesimpulan

Saya sangat menyukai pengembangan web dan arahnya. Saya mencoba membangun sesuatu yang sangat spesifik berdasarkan apa yang mungkin dilakukan saat ini tanpa membuat kompromi apa pun, jadi tidak mengherankan jika saya menemui masalah. Sungguh luar biasa saya bisa mencapai sejauh ini dan banyak hal yang bahkan tidak mungkin dilakukan setahun yang lalu di sebagian besar browser. Selain itu, beberapa masalah yang saya sebutkan kemungkinan besar akan diperbaiki dalam waktu dekat.

Secara keseluruhan, ini adalah pengalaman belajar yang luar biasa dan saya sangat menyukai ide streaming situs baik dari server maupun pekerja layanan. Sejauh ini saya hanya mendengarnya digunakan untuk situs mainan, tapi menurut saya ini akan mendapatkan daya tarik di masa depan. Saya tidak sabar untuk mencoba membuat situs web ini lagi dalam satu atau dua tahun dan melihat sejauh mana kemajuan saya.

P.S. Saat menulis artikel ini, saya menyadari bahwa artikel ini pada dasarnya telah berubah menjadi versi pesimis dari "artikel yang jauh lebih baik" yang ditulis oleh Paul Kinlan di mana dia mencapai sesuatu yang sangat mirip dan mengatasi semua masalah yang saya sebutkan di atas. Saya menemukannya tepat ketika saya menyerah pada proyek ini, tetapi tidak menyadari betapa miripnya artikel saya pada akhirnya sampai saya selesai. Artikel ini pada dasarnya adalah pecahan gelas tidak resmi yang setengah kosong.