Smashing Podcast Episode 45 Dengan Jeremy Wagner: Apa Itu JavaScript yang Bertanggung Jawab?

Episode ini telah didukung dengan baik oleh teman-teman terkasih kami di Wix, platform bagi para profesional untuk membangun situs klien, mengelola proyek yang kompleks, dan mengembangkan bisnis online. Terima kasih!

Dalam episode ini, kita berbicara tentang JavaScript yang Bertanggung Jawab. Apa artinya kode bertanggung jawab, dan bagaimana seharusnya kita mendekati proyek secara berbeda? Saya berbicara dengan ahli Jeremy Wagner untuk mencari tahu.

Tampilkan Catatan

• Situs web JavaScript yang bertanggung jawab
• Beli buku dari A Book Apart
• Situs web pribadi Jeremy
• Jeremy di Twitter

Update mingguan

• Hukum Fitts Dalam Era Sentuhan yang ditulis oleh Steven Hoober
• Desain Web Dilakukan dengan Baik: Sangat Tidak Ada Gunanya ditulis oleh Frederick O'Brien
• Semua yang Ingin Anda Ketahui Tentang Membuat Antarmuka Pengguna Suara yang ditulis oleh Nick Babich & Gleb Kuznetsov
• Implikasi WordPress Bergabung dengan Protokol Blok yang ditulis oleh Leonardo Losoviz
• Thoughts On Markdown ditulis oleh Knut Melvar

Salinan

Drew McLellan: Dia seorang penulis teknis, kutu buku kinerja web, pengembang dan pembicara, saat ini bekerja di Google. Dia menulis untuk A List Apart, CSS-Tricks dan Smashing Magazine, dan merupakan penulis judul baru, Responsible JavaScript for A Book Apart. Jadi kita tahu dia adalah teknisi dan komunikator yang terampil, tetapi tahukah Anda bahwa dia ingin mengelilingi dunia dengan papan dayung standup? Teman-temanku yang hebat, tolong sambut Jeremy Wagner. Hai jeremy, apa kabar?

Jeremy Wagner: Saya hebat. Apa kabar?

Drew: Saya sangat baik. Terima kasih. Saya ingin berbicara dengan Anda hari ini tentang ide JavaScript Bertanggung Jawab ini. Apakah ini semacam pendekatan atau teknik baru, atau apakah Anda benar-benar berbicara tentang menggunakan JavaScript secara bertanggung jawab?

Jeremy: Saya benar-benar berbicara tentang menggunakan JavaScript secara bertanggung jawab. Jadi per arsip HTTP, kami telah melihat peningkatan median hampir 58% dalam jumlah JavaScript yang diunduh oleh perangkat seluler dari sekitar 290 kilobyte menjadi hampir 500 kilobyte pada tahun lalu.

Drew: Wah.

Jeremy: Jadi ketika saya berbicara tentang penggunaan JavaScript secara bertanggung jawab, ini adalah jenis pendekatan pertama pengguna untuk mengatakan ... untuk secara kritis mengevaluasi apa yang kami bangun dan apa tujuan dari apa yang kami bangun dilayani oleh praktik pengembangan web modern, jadi berbicara. Dan saya rasa itu semacam ... mungkin tidak main-main, tapi saya tidak mengambil jab pada pengembangan web modern, tetapi satu produk sampingan dari pengembangan web modern adalah sangat mudah untuk menambahkan dependensi ke proyek. Semuanya adalah pemasangan MPM dan setiap pemasangan MPM memiliki biaya, biaya itu bervariasi. Namun yang kami lihat adalah bahwa dalam data arsip HTTP itu, persentil ke-95… artinya 5% pengalaman yang paling lambat… atau bukan yang paling lambat, tetapi yang mengirimkan JavaScript paling banyak, yang telah meningkat pada tahun lalu sekitar 875 kilobyte menjadi sekitar 1,4 megabyte.

Drew: Wah.

Jeremy: Jadi jumlah besar JavaScript yang ditransfer dan memiliki implikasi kinerja pemuatan dan kinerja runtime.

Drew: Jadi Anda menyebutkan kinerja di sana. Sepertinya pengalaman web modern dari sudut pandang saya seperti 10% HTML dan CSS dan 90% JavaScript. Dan harus ada semacam pertimbangan kinerja untuk itu. Maksud saya, Anda berbicara tentang semacam jumlah data yang kami transfer, tetapi ada pertimbangan kinerja lain di sana dengan memiliki banyak JavaScript.

Jeremy: Benar. Jadi memiliki koneksi internet yang lambat dan Anda tahu ... di mana saya tinggal di Amerika Serikat, jika Anda pergi cukup jauh di luar kota besar, itu menjadi agak sulit tergantung di mana perginya ... untuk mengatasi seberapa lambat internet di semacam ini daerah pedesaan dan penting atas orang-orang yang tinggal di daerah seperti ini. Jadi, aspek kinerja pemuatannya sudah cukup menantang ketika Anda mulai mengirimkan megabita JavaScript, tetapi Anda mungkin juga berurusan dengan seseorang yang tidak memiliki iPhone… seperti iPhone X atau seperti iPhone 13.

Jeremy: Mereka mungkin hanya menggunakan ponsel biasa atau semacam ponsel Android murah, hanya mencoba menavigasi kehidupan. Maksud saya, pikirkan hal-hal seperti perbankan online, bantuan pengangguran, atau bantuan pemerintah lainnya, portal seperti itu untuk aplikasi. Pembelajaran online, hanya ada banyak tempat di mana JavaScript yang berlebihan benar-benar dapat berdampak buruk bagi orang-orang yang mungkin tidak cukup beruntung untuk tinggal di area metro yang besar atau bahkan di area metro yang tidak terlayani dengan baik oleh internet broadband dan mereka yang menggunakan perangkat yang lebih lambat . Saya agak berpikir sebagai pengembang, kami memiliki kecenderungan untuk melihat… kami membeli MacBook atau perangkat kelas atas ini, dan terkadang kami tidak benar-benar melihat di mana masalah ini dapat muncul ketika kami menggunakan JavaScript secara berlebihan.

Drew: Dan seperti yang Anda sebutkan di sana, kadang-kadang individu-individu yang paling dirugikan karena tidak dapat mengakses layanan yang dihukum karena hal semacam ini. Orang-orang tanpa koneksi data yang cepat atau tanpa perangkat yang sangat mumpuni terkadang mengakses layanan yang berarti segalanya bagi… itu berarti segalanya bagi mereka yang dapat mereka akses. Jadi ini hampir menjadi masalah hak asasi manusia dalam beberapa hal.

Jeremy: Ya. Maksud saya, kita cenderung melihat kinerja web dibingkai dalam hal nilai bisnis. Saya adalah konsultan kinerja untuk beberapa e-com dan seperti perusahaan makanan besar, e-com besar… seperti toko, seperti outlet elektronik dan sangat menggoda untuk melakukan itu, bukan? Karena ketika Anda bekerja untuk bisnis, maksud saya, jelas Anda ingin keuangan sehat dan kinerja web memang berperan dalam hal itu menurut saya. Saya pikir ada sejumlah studi kasus yang membuktikan hal itu. Namun, ada aspek manusia dan bahkan untuk bisnis, seperti misalnya toko kelontong dan hal semacam itu. Ya, mereka didorong oleh pendapatan. Mereka ingin memiliki keuangan yang sehat dan kinerja web adalah bagian dari itu, tetapi mereka juga melayani kebutuhan kritis, bukan? Seperti Anda harus makan, kan?

Jeremy: Dan seperti beberapa orang mungkin terikat di rumah karena satu dan lain alasan. Mereka mungkin tidak bisa dengan mudah masuk ke dalam mobil. Mereka mungkin tidak punya mobil. Jadi mereka mengandalkan layanan ini untuk mendapatkan rezeki, tetapi lebih dari itu, bantuan jika mereka membutuhkannya dan terutama seperti intervensi krisis dan hal semacam itu. Saya tidak berpikir itu terlalu tidak masuk akal untuk mengatakan bahwa pasangan yang telah dilecehkan dan diusir dari rumah mereka mungkin beralih ke ponsel cerdas mereka dan, dan memukul Google untuk mencoba menemukan portal untuk intervensi dan bantuan krisis. Dan jenis JavaScript dapat menghalangi jenis tujuan tersebut dan untuk melayani kebutuhan manusia tersebut. Ketika kita memiliki kecenderungan untuk terlalu bersandar padanya.

Drew: Maksud saya, kami telah, kami telah melihat sekilas hal itu selama 18 bulan terakhir dengan COVID dan orang-orang akan diisolasi, dan seperti yang Anda katakan, perlu memesan bahan makanan untuk dikirim. Web menjadi penyelamat bagi mereka pada saat itu. Mereka merasa di bawah cuaca, tidak dapat meninggalkan akomodasi mereka karena mereka terisolasi dan mereka harus mendapatkan makanan dan mereka harus mendapatkan persediaan penting. Jadi ya, itu adalah bagian yang semakin penting dari kehidupan sehari-hari bagi kita semua, saya pikir.

Jeremy: Tepat sekali. Dan kembali ke jenis cerita perangkat, Tim Kadlec menulis karya yang luar biasa beberapa tahun yang lalu, saya pikir itu dua tahun, mungkin tiga tahun yang lalu, tapi itu disebut Memprioritaskan Long Tail of Performance. Dan ketika Anda melihat itu… jadi dalam bahasa kinerja web, kita berbicara tentang data lab versus data lapangan. Dan data lab seperti saat Anda menjalankan mercusuar atau Anda melempar situs web ke pengujian halaman web untuk melihat bagaimana kinerjanya. Itu semua adalah alat yang sangat berguna, tetapi ketika Anda melihat data lapangan itu, Anda benar-benar mulai mendapatkan gambaran yang lebih besar dan pandangan yang lebih luas tentang siapa audiens Anda sebenarnya. Dan dalam artikel ini, Tim Kadlec berbicara tentang apa artinya memprioritaskan kinerja ekor panjang. Artinya, semua perangkat yang… mungkin tidak sekuat dan sekuat perangkat yang mungkin dimiliki pengembang.

Jeremy: Dan ide di balik artikel itu adalah jika kita dapat fokus pada persentil ke-90 atau ke-95 itu, kita… dan meningkatkan pengalaman itu untuk orang-orang itu, kita sedang membangun web yang lebih cepat untuk semua orang, termasuk mereka yang menggunakan perangkat cepat. Dan serang titik data itu di AS dan ini hanya dari seperti statcounter.com. Sesuatu seperti 28 poin… sekitar 28% orang menggunakan perangkat iOS yang ditangkap oleh alat ini. Dan sekitar 21% di antaranya adalah Android. Dan Android cenderung mewakili sebagian besar perangkat, karena Android tidak monolitik. Beberapa produsen perangkat membuat ponsel Android, tetapi untuk membedakannya dengan dunia, karena dunia lebih dari sekadar Amerika Serikat, sekitar 16% orang yang menggunakan iOS dan sekitar 41% orang yang menggunakan Android. Jadi, benar-benar membayar untuk memprioritaskan pengalaman yang lebih lambat atau berpotensi lebih lambat itu.

Drew: Saya membaca di buku Anda tentang pelambatan termal perangkat, yang bukan sesuatu yang benar-benar pernah saya pertimbangkan sebelumnya. Apa kekhawatiran di sana?

Jeremy: Kekhawatiran di sana, dan saya tidak seperti ahli mikroprosesor dengan cara apapun. Saya hanya pengembang web yang mungkin menulis terlalu banyak, tapi… jadi ide di balik pembatasan termal dan ini ada di semua sistem, tidak hanya seperti ponsel dan tablet, adalah bahwa mikroprosesor akan… ketika mengambil beban kerja yang berlebihan atau benar-benar hanya beban kerja pada umumnya, produk limbah dari pekerjaan itu adalah panas. Dan perangkat memiliki cara untuk mengurangi ini. Seperti laptop Anda memiliki perangkat pendingin pasif dan aktif.

Jeremy: Jadi seperti perangkat pendingin pasif seperti heat sink atau semacam penyebar panas. Dan bagian aktifnya seperti kipas untuk lebih efisien menyebarkan panas. Beberapa seperti build PC kustom mungkin menggunakan pendingin cair, yang merupakan contoh yang relatif lebih ekstrem, tetapi ponsel tidak memilikinya karena di mana Anda akan benar-benar memasang kipas dalam semua itu, jika portabilitas adalah jenis Anda. hal, kan?

Jeremy: Jadi agar perangkat ini dapat mengatasi beban kerja yang berat ini, mereka dapat secara artifisial mengurangi kecepatan prosesor, seperti mengurangi laju jam hingga perangkat tersebut memasuki kondisi di mana laju jam dapat dinaikkan. Dan itu memiliki implikasi karena jika Anda mengunyah berton-ton dan berton-ton dan berton-ton JavaScript, Anda memiliki potongan besar seperti ini, nah itu memulai pemrosesan, bukan? Jadi banyak proses melalui evaluasi dan parsing dalam kompilasi dan kemudian eksekusi. Dan jika Anda melakukannya dengan satu atau dua megabita JavaScript, dan Anda memiliki banyak proses lain yang terjadi di latar belakang seperti tab yang berbeda, hal semacam itu, yang dapat menempatkan status Anda... yang meningkatkan kemungkinan bahwa perangkat dapat memasuki keadaan tercekik secara termal, yang berarti bahwa ia akan kurang mampu melakukan pekerjaan ekstra itu.

Drew: Jadi ini semacam umpan balik negatif. bukan? Anda memberi perangkat banyak pekerjaan yang harus dilakukan. Itu menjadi sangat panas dan kemudian kurang mampu untuk benar-benar melakukan pekerjaan itu karena harus mencekik kembali.

Jeremy: Benar. Dan sekali lagi, saya bukan ahli mikroprosesor. Saya yakin jika, jika, jika seorang insinyur yang benar-benar akrab dengan ini, mungkin bisa mengoreksi saya pada beberapa hal, tetapi ide umumnya adalah ya, karena tekanan lingkungan meningkat, perangkat kurang mampu mengatasi beban kerja yang berat ini sampai tekanan itu berkurang.

Drew: jadi kami menulis JavaScript untuk semua jenis spektrum perangkat dari Apple M1 Max terbaru adalah prosesor baru, bukan? Laptop hingga perangkat yang hampir tidak memiliki cukup RAM yang berfungsi untuk merender halaman web. Tetapi web tidak dimulai seperti ini, pendengar yang lebih muda mungkin tertarik untuk mengetahui bahwa kami dulu membangun pengalaman web interaktif tanpa JavaScript sama sekali. Kerangka kerja kami yang besar dan berat akan menjadi kehancuran kami.

Jeremy: Saya akan mengatakan bahwa kerangka kerja memiliki waktu dan tempat dan mereka yang membaca kutipan dari buku ini mungkin mendapatkan gagasan bahwa saya anti-kerangka. Dan saya sangat kritis terhadap beberapa kerangka kerja, tetapi kerangka kerja tersebut memiliki tujuan dan memungkinkan untuk menggunakannya dengan cara yang mempertahankan pengalaman pengguna yang baik atau dapat menghasilkan pengalaman pengguna yang baik. Tapi apa yang menurut saya tidak cukup untuk kita lakukan adalah mengevaluasi secara kritis kerangka kerja ini dalam hal bagaimana mereka membahayakan ... kinerja waktu berjalan, bukan? Jadi jenis hal yang saya bicarakan, di mana jika Anda mengklik sebuah tombol, dan perangkat membutuhkan waktu sekitar satu detik, mungkin dua detik untuk menanggapi masukan itu, karena ada banyak hal yang terjadi di latar belakang. Anda memiliki hal-hal JavaScript pihak ketiga seperti mengumpulkan analitik dan kemudian Anda memiliki hal-hal lain yang berjalan di utas.

Jeremy: Dan jika Anda tidak secara kritis mengevaluasi kinerja runtime dari suatu kerangka kerja, Anda mungkin meninggalkan beberapa peluang untuk melayani pengguna Anda dengan lebih baik. Jadi contoh yang baik, saya selalu suka menggunakan reaksi versus pra-tindakan. Saya sudah agak menggedor drum ini untuk sementara waktu. Saya melakukan artikel untuk Trik-CSS beberapa waktu lalu yang memprofilkan interaksi klik dasar seperti menu navigasi seluler. Dan kedengarannya sepele, tetapi apa yang Anda temukan adalah bahwa di semua perangkat reaksi memberikan kinerja runtime yang lebih baik, tetapi pada dasarnya memiliki API yang sama. Ada perbedaan, ada beberapa perbedaan kecil dan hal-hal yang dapat diselesaikan dengan compat pra-tindakan, tapi sesederhana itu… dan saya seharusnya tidak mengatakan pilihan yang sederhana, tapi pilihan itu, pilihan mendasar itu bisa menjadi perbedaan antara sebuah pengalaman. yang bekerja sangat baik untuk semua pengguna atau setidaknya sebagian besar pengguna, atau pengalaman yang hanya berfungsi dengan baik untuk beberapa pengguna. Semoga itu masuk akal.]

Drew: Maksud saya, dengan semua kerangka kerja dan alat pembangunan, mereka tampaknya semakin baik setiap saat dalam melakukan hal-hal seperti menggoyang pohon dan mengoptimalkan bundel yang mereka kirimkan dan bagaimana mereka kemudian dikirimkan ke browser. Saat menggunakan kerangka kerja besar, apakah ada titik kritis yang Anda pikirkan di mana Anda menulis aplikasi besar, begitu banyak kode Anda sendiri, sehingga kerangka kerja memungkinkan Anda mengirimkan lebih sedikit kode karena semua abstraksinya?

Jeremy: Itu pertanyaan yang sulit untuk dijawab. Salah satu aspeknya adalah bahwa kerangka itu sendiri mewakili sejumlah kode yang tidak dapat Anda optimalkan. Jadi memiliki kerangka yang tipis, seperti pra-aksi atau sejenisnya… Atau seperti mantra misalnya, itu sangat membantu. Tetapi masalah yang saya lihat dan menurut saya data dari jenis arsip HTTP mendukung poin ini adalah bahwa setiap kali kita memiliki kemajuan dalam mikroprosesor dan jaringan yang semakin cepat, kita cenderung mengkonsumsi keuntungan itu, bukan?

Jeremy: Kami cenderung hanya berada di treadmill di mana kami tidak pernah benar-benar maju. Dan saya tidak tahu, seperti saya tidak waskita tentang apa sejarah ... atau maaf, seperti apa masa depan kerangka kerja. Saya yakin ada beberapa keuntungan efisiensi yang dapat dikumpulkan. Tapi apa yang kita lihat di lapangan dalam hal berapa banyak JavaScript mentah seperti ... hanya jumlah mentah JavaScript yang digunakan. Tidak memberi tahu saya bahwa ini adalah masalah yang bisa kita keluarkan secara otomatis. Saya pikir kita harus… kita harus menjadi manusia dan campur tangan serta membuat keputusan yang terbaik untuk kepentingan pengguna. Kalau tidak, saya tidak melihat kami keluar dari treadmill ini, mungkin tidak dalam karir saya, tapi saya tidak tahu.

Drew: Dalam buku tersebut Anda berbicara tentang situs web dan aplikasi web dan bagaimana memahami perbedaannya dan mana yang sedang Anda kerjakan membantu Anda memilih strategi untuk mengembangkan dan mengoptimalkannya. Ceritakan sedikit tentang itu.

Jeremy: Itu pertanyaan yang sangat bagus. Dan saya menulis tentang ini dalam artikel dengan judul yang sama yang saya tulis untuk A List Apart yang disebut Responsible JavaScript Part One, yang merupakan pendahuluan dari buku ini. Apakah itu kami memuat banyak ke dalam terminologi ini. Seperti sebagai penulis teknis, saya melihat keduanya digunakan secara bergantian. Apa yang saya lihat adalah dengan situs web, implikasinya adalah semacam pengalaman multi-usia, bukan? Itu kumpulan dokumen. Sekarang sebuah dokumen… dokumen-dokumen itu mungkin memiliki fungsionalitas yang tertanam seperti pulau-pulau kecil ini, seperti istilah yang belakangan ini berkembang, pulau-pulau kecil fungsionalitas yang memungkinkan orang untuk menyelesaikan sesuatu.

Jeremy: Tapi kemudian ada aplikasi web dan aplikasi web semacam ini memiliki konotasi fungsi seperti aplikasi asli. Jadi kita berbicara tentang aplikasi satu halaman, kita berbicara tentang sejumlah besar JavaScript untuk mendorong interaktivitas yang kompleks. Dan ada kalanya model aplikasi web masuk akal. Seperti misalnya, Spotify adalah contoh yang bagus untuk ini. Itu berfungsi lebih baik sebagai aplikasi web. Anda tidak akan benar-benar ingin mencoba menggunakannya atau mendesainnya sebagai aplikasi multihalaman. Seperti situs web tradisional, tapi saya pikir ini bukan default yang berkelanjutan karena ketika default Anda untuk setiap proyek adalah mengatakan, "Yah, semua yang kita butuhkan untuk mengirimkan aplikasi satu halaman, seperti router sisi klien dan kerangka kerja yang berat dan membongkar semua pemrosesan rendering ini dari seperti server ke klien.” Saya pikir di situlah Anda mulai mencapai titik di mana Anda mengecualikan pengguna meskipun secara tidak sengaja, tetapi tetap mengecualikan mereka.

Drew: Apakah ada jurang besar, menurut Anda antara orang-orang yang mengambil pendekatan kami akan menerbitkan situs web dan mungkin memiliki fungsi interaktif apa pun dan mereka yang mengatakan, “Kami adalah perusahaan perangkat lunak, kami membuat produk, produk perangkat lunak, dan platform kami yang akan kami kirimkan melalui web, bukan aplikasi asli untuk berbagai platform.” Apakah mungkin mereka mendekati masalah dengan cara yang sama sekali berbeda? Apakah pertimbangannya berbeda tergantung pada pandangan Anda pada saat itu?

Jeremy: Itu pertanyaan yang sulit. Jadi-

Drew: Sulit bagi saya untuk mengatakannya.

Jeremy: Saya akan mengatakan bahwa perusahaan yang ... jadi contoh yang baik akan menjadi seperti berita, kan? Mereka dilayani dengan baik oleh jenis model situs web, karena secara harfiah adalah kumpulan dokumen, artikel. Dan orang-orang yang mengembangkan pengalaman-pengalaman itu mungkin akan memiliki keahlian yang berbeda daripada mengatakan perusahaan seperti Spotify atau perusahaan yang memiliki aplikasi web besar seperti Envision atau sejenisnya. Jadi ya, saya pikir mereka akan melihat ini dari sudut yang berbeda. Cara saya melihatnya adalah bahwa ada segmen… atau setidaknya begitulah persepsi saya tentang komunitas pengembangan web pada umumnya adalah bahwa ada segmen orang, pengembang web yang berasal dari pengembangan perangkat lunak non-tradisional latar belakang, kan? Dan saya salah satu dari orang-orang ini, saya bermain-main dengan web ketika saya masih seperti anak-anak, bukan?

Jeremy: Seperti di sekolah menengah dan membuat halaman penggemar bodoh untuk semua menyukai video game pada waktu yang sangat saya sukai. Dan saya tidak pernah mendapatkan pendidikan ilmu komputer semacam itu. Ada konsep ilmu komputer yang saya ambil selama ini. Lalu ada juga segmen pengembang, terutama menurut saya yang telah muncul dalam lima hingga 10 tahun terakhir yang mendekati ini dengan cara yang lebih berorientasi pada ilmu komputer. Dan saya pikir itu akan… perbedaan dan pengalaman itu akan mengarahkan masing-masing kelompok untuk menarik kesimpulan mereka sendiri tentang cara terbaik untuk mengembangkan web. Tapi saya pikir satu-satunya cara Anda benar-benar dapat… Agar Anda dapat mengembangkan web secara berkelanjutan adalah dengan mengevaluasi secara kritis apa yang sedang Anda bangun dan mencoba menyelaraskan pendekatan yang paling baik melayani pengguna produk tersebut. Dan di situlah situs web dan model aplikasi web berada di kepala saya ketika saya mengevaluasi hal-hal ini.

Drew: Ya. Ini menarik. Maksud saya, di dalam buku, Anda sebenarnya mengutip beberapa karya saya. Terima kasih banyak. Dan pilihan teknologi membosankan saya pada dasarnya memperhatikan PHP Apache dan taburan JavaScript yang digulung tangan dapat membuat pengalaman pengguna yang sangat tajam secara default, tanpa perlu melakukan optimasi tertentu. Saya pikir itu membuat pengalaman pengguna yang luar biasa bagi pengunjung front-end yang datang dan melihat konten di situs.

Drew: Tapi sebenarnya, saya merasa seperti itu lingkungan untuk membuat konten semacam sisi lain, setelah Anda masuk dan menerbitkan barang-barang Anda di situs. Saya pikir itu sedikit menderita karena dibangun dengan pendekatan situs web, daripada pendekatan aplikasi web berat JavaScript, begitu banyak sehingga saya berpikir ... atau mungkin perlu keduanya. Saya perlu terus menerbitkan bagian depan dalam HTML dan CSS statis yang bagus dan sedikit JavaScript. Tapi backend di mana saya ingin memberikan pengalaman pembuatan konten mungkin pilihan teknologi yang berbeda akan lebih baik. Ini cukup menarik karena tidak selalu harus satu hal atau yang lain bukan? Ini bukan pilihan biner. Ini lebih merupakan spektrum, katamu?

Jeremy: Ya tentu saja. Dan saya pikir kita mulai melihat lebih banyak diskusi di komunitas tentang pengembangan web menjadi spektrum seperti itu. Terus terang untuk orang-orang yang mungkin tertarik dengan buku saya, itu pasti berasal dari sisi spektrum situs web. Dan lagi, karena saya merasa itu selalu seperti default yang bagus. Jika Anda tidak tahu bagaimana Anda ingin membangun sesuatu, mungkin yang terbaik adalah mencoba membangunnya dengan cara yang meminimalkan penggunaan JavaScript dan meminimalkan mendorong lebih banyak pekerjaan ke klien. Yang mengatakan, saya pikir memperhatikan adalah pengalaman yang sangat baik. Saya pikir teknologi yang sudah usang dan semacam ini benar-benar "membosankan" benar-benar bekerja dengan baik untuk tugas yang ada. Dan ia melakukannya dengan cara yang seperti terbuka dan memungkinkan bagi pengembang, bukan?

Jeremy: Anda tidak harus memiliki pengetahuan yang mendalam seperti... toko manajemen negara bagian atau kerangka kerja manajemen negara bagian untuk benar-benar melakukan hal-hal semacam ini. Dan saya pikir perhatian itu dilayani dengan baik oleh pendekatan khusus itu. Tetapi menurut pendapat Anda, saya pikir ada peluang di situs web mana pun untuk bergerak lebih dekat ke tengah spektrum tanpa memasukkan semua perutean sisi klien seperti kerangka kerja berat yang mengelola segala sesuatu di klien dan hal semacam itu. Saya pikir pendekatan pulau mulai mengeksplorasi seperti apa itu. Dan saya akui, saya mungkin tidak sengaja melakukan beberapa jenis pulau. Saya pikir kami sudah cukup lama, kami hanya belum benar-benar memberi nama. Tapi saya pikir sekarang kami telah mengidentifikasi bahwa seperti mungkin titik tengah, kami mungkin mulai melihat pengalaman web yang memberikan pengalaman pengguna yang baik, tetapi masih lebih interaktif. Mudah-mudahan itu tidak terlalu berkelok-kelok.

Drew: Ini sedikit mengingatkan kita pada hari-hari ketika kita akan menyematkan pulau Flash atau-

Jeremy: Ya.

Drew: Sesuatu di halaman di mana ini adalah bagian interaktif kecil kami, dan sisanya mengalir.

Jeremy: Ya Seperti Flash, astaga, tiga iterasi portofolio pribadi saya di luar perguruan tinggi benar-benar jelek untuk tiruan Flash tingkat lanjut dan seperti efek melayang. Dan hal itu benar-benar menyenangkan. Dan terkadang saya merindukannya seperti ada banyak konten yang akan hilang begitu saja karena kami tidak menggunakan Flash lagi. Dan itu benar-benar menyebalkan, tapi di satu sisi itu semacam pendahulu dari pulau semacam ini yang sedang kita bicarakan. Yang mana Anda bisa memiliki seperti halaman web statis dan segalanya, tetapi kemudian Anda akan memiliki pengalaman interaktif yang sangat kaya ini seperti yang dijatuhkan tepat di tengah-tengahnya.

Drew: Untuk waktu yang lama, peningkatan progresif telah dianggap sebagai cara praktik terbaik untuk membangun pengalaman web. Apakah masih demikian, menurut Anda?

Jeremy: Saya akan mengakui bahwa itu mungkin ... tidak mungkin saya akan memberikan bahwa lebih banyak pekerjaan untuk melakukan peningkatan progresif karena di satu sisi, Anda agak membagi pengalaman pengembangan Anda. Anda mencoba memberikan fungsionalitas minimum yang layak dari situs web dengan cara yang dapat ditangani server seperti interaksi utama ini. Tapi di atas itu, Anda berkata, "Oke, sekarang saya ingin memfasilitasi interaksi ini agar sedikit lebih lancar dengan JavaScript." Saya masih berpikir ini adalah cara yang layak untuk mencapai tujuan Anda dengan situs web atau aplikasi atau produk Anda.

Jeremy: Tapi apa yang akan saya katakan adalah bahwa saya tidak akan pernah merekomendasikan bahwa setiap interaksi di situs web harus difasilitasi oleh semacam pola navigasi sinkron ini. Jadi seperti contoh yang baik mungkin halaman checkout Anda untuk situs web econ Anda pasti harus memiliki rute server. Anda harus memiliki rute server untuk menambahkan barang ke keranjang, dan kemudian Anda harus dapat mengurutkan cukup banyak JavaScript untuk membuatnya sedikit lebih menyenangkan sehingga semuanya bisa menjadi sedikit lebih cepat dan lebih asinkron.

Drew: Dalam hal mengukur kinerja. Kami mendengar banyak tentang vital web inti, terutama dari Google. Apakah itu benar-benar tolok ukur yang harus kita ukur? Atau hanya itu yang Google ingin kita pikirkan? Saya sekarang menghargai ini mungkin pertanyaan sulit yang Anda mulai bekerja di Google.

Jeremy: Ya, ya. Anda tahu, jadi saya berbicara untuk diri saya sendiri di sini. Menurut saya, web vitals adalah… web vital inti awal adalah upaya yang baik untuk menentukan bagian mana dari pengalaman pengguna yang penting. Saya pikir metrik seperti pergeseran tata letak kumulatif dan cat Contentful terbesar mulai memikirkan pengalaman dengan cara yang benar-benar belum mulai kami ukur. Sebelum pergeseran tata letak kumulatif, karena jika pernah ada momen di mana Anda marah, ketuk itu karena tombol suka bergerak di sekitar halaman atau sesuatu. Maksud saya, saya pikir itu hal yang berguna untuk mengukurnya. Itu tidak sempurna. Dan saya pikir siapa pun yang bekerja di web vitals inti akan setuju bahwa peningkatan diinginkan dalam beberapa metrik ini. Ada metrik lain yang belum tentu saya setujui sepenuhnya. Seperti penundaan input pertama adalah metrik yang agak sulit untuk dipasang.

Jeremy: Saya pikir itu sangat berguna, kan? Karena apa yang Anda maksudkan secara harfiah adalah kami ingin mengukur penundaan dan interaktivitas pada interaksi pertama yang dibuat pengguna, tetapi konteksnya kurang, bukan? Karena beberapa… banyak hal dapat memengaruhinya karena tidak selalu terkait dengan JavaScript. Penundaan input pertama dapat mewakili penundaan yang terjadi dengan memfokuskan bidang formulir, bukan? Jenis hal itu, hal-hal dalam HTML. Saya pikir metrik tersebut… metrik seperti penundaan input pertama dapat… mereka dapat bermanfaat jika Anda dapat mengontekstualisasikannya dengan hal-hal seperti entri dari API tugas panjang, pengaturan waktu elemen, dan hal-hal semacam itu. Saya akhirnya berpikir bahwa masa depan web vitals inti akan membuktikan bahwa itu akan membantu dan berperan dalam mengukur apa yang membuat pengalaman pengguna yang baik. Itu pendapat pribadi saya.

Drew: Saya kira itu, itu salah satu hal yang selalu dapat Anda ukur terhadap diri sendiri, mengukur peningkatan Anda sendiri atau apakah pengalaman Anda menjadi lebih buruk jika skor Anda berubah, tidak terlalu peduli dengan lampu lalu lintas, tetapi peduli tentang apa yang Anda ketahui tentang konteks situs Anda dan bagaimana perubahan telah membuat peningkatan.

Jeremy: Saya pikir metrik seperti pergeseran tata letak kumulatif sangat baik, tetapi mereka juga dapat mengambil manfaat dari sedikit peningkatan. Seperti berdiri, pergeseran tata letak kumulatif, sebagian besar mengukur pergeseran tata letak yang terjadi selama pemuatan. Dan seperti yang kita ketahui, ketika pengguna mengunjungi suatu halaman dan tiba di halaman tersebut, perubahan tata letak dapat terjadi kapan saja, bukan? Jadi pasti ada pekerjaan yang saya pikir bisa dilakukan untuk memperbaiki cara kita mengamati fenomena semacam itu, pasti.

Drew: Saya pikir stabilitas tata letak adalah salah satu hal yang sebenarnya sedikit lebih sulit untuk dicapai saat Anda bekerja dengan peningkatan progresif. Terkadang ketika Anda memuat halaman yang dirender server dan kemudian mulai meningkatkannya di klien, ada bahaya membuat perubahan tata letak semacam itu, bukan?

Jeremy: Tentu saja. Dan di situlah hidrasi komponen menjadi agak rumit karena dimensi komponen itu dapat berubah karena sejumlah alasan. Seperti mungkin ada konten yang ada di komponen sisi klien yang tidak ditampilkan di server karena status yang tidak dievaluasi sampai dijalankan di klien. Ini masalah yang sangat sulit. Saya tidak akan duduk di sini dan berpura-pura memiliki seperti peluru perak untuk itu.

Drew: Saya ingin berbicara sedikit tentang semacam dinamika impor dan pemecahan kode, keduanya merupakan teknik yang berbeda untuk masalah mengunduh dan menjalankan sekumpulan besar JavaScript di awal pengalaman. Apakah ada risiko pengoptimalan yang berlebihan dengan membuat banyak permintaan kecil, terutama pada proyek-proyek kecil yang paling sederhana, atau apakah itu sesuatu yang sama sekali tidak ada salahnya dalam menerapkan semacam dari awal yang mendahului bahwa Anda akan memiliki masalah ini? Atau haruskah Anda menunggu sampai Anda benar-benar melihat masalah kinerja sebelum memikirkan hal-hal semacam itu?

Jeremy: Jadi saya akan merekomendasikan ujung ekor dari apa yang baru saja Anda katakan adalah cara yang baik untuk memimpin dengan ini. Kita tidak boleh mencoba untuk mengoptimalkan sebelum waktunya kecuali tentu saja pengoptimalan tersebut dapat dicapai dengan sangat cepat dan mudah, tetapi jika dibutuhkan banyak upaya untuk mengoptimalkan sejak dini, ketika tidak ada banyak masalah kinerja, saya berpendapat bahwa pemecahan kode mungkin adalah sesuatu yang tidak harus terjadi. Anda mungkin dapat memuat fungsionalitas itu di depan.

Jeremy: Tapi misalnya, saya membicarakan hal ini di buku. Jika Anda memiliki interaksi bernilai tinggi yang didorong oleh sebagian besar JavaScript, dan bagi saya, sebagian besar JavaScript dapat berarti 20 kilobyte karena melalui kabel yang dikompresi dan itu bisa berakhir menjadi potongan JavaScript sebesar 60 kilobyte. Kemudian jika Anda dapat menarik itu keluar pada bundel utama atau salah satu dari segudang bundel Anda, situs Anda mungkin dikirimkan, Anda akan membantu kinerja startup.

Jeremy: Tapi dalam buku ini, saya membahas teknik tentang persepsi ketika… atau setidaknya mencoba untuk memahami kapan pengguna dapat membuat interaksi bernilai tinggi. Jadi contoh yang saya gunakan adalah sepotong JavaScript. Itu digunakan untuk memvalidasi konten formulir karena validasi formulir HTML sangat bagus, tetapi juga tidak dapat ditata, dan cukup mudah. Tidak ada banyak fleksibilitas untuk hal-hal seperti, ketik sama dengan email, bukan? Ia menilainya dengan cara tertentu. Namun, validasi formulir pada klien sangat membantu karena kami juga dapat menatanya. Dan kita bisa menyelaraskan tampilan validasi tersebut agar lebih mendekati seperti apa estetika brand atau seperti apa estetika website. Jadi dalam contoh ini, apa yang saya lakukan adalah, saya katakan, jika pengguna memfokuskan… bahkan hanya memfokuskan salah satu bidang dalam formulir, itulah titik di mana kita memuat bagian JavaScript itu.

Jeremy: Jadi mudah-mudahan pada saat itu, dan saya berharap karena perlu beberapa saat untuk mengisi formulir bahwa jaringan memiliki cukup waktu untuk menariknya sehingga ketika impor dinamis dipanggil, itu hanya dapat menghasilkan uang untuk dapatkan apa yang sudah dimuat sebelumnya. Ini adalah sesuatu yang telah saya kerjakan sedikit di sana-sini, dan sulit untuk dilakukan dalam semua situasi. Seperti misalnya, Anda tidak dapat melakukan ini dengan andal sepanjang waktu saat mengarahkan kursor karena beberapa perangkat tidak memiliki penunjuk yang bagus. Mereka memiliki ... mereka ... itu input tap, kan? Jadi hover terjadi pada waktu yang berbeda daripada jika Anda memiliki pointer yang bagus, misalnya.

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy: Hal yang terus-menerus saya lakukan sejak diluncurkan adalah mengacaukan API cat CSS. Saya sangat suka API cat. Maksudku, itu selalu ada dengan sendirinya…. seperti dengan caranya sendiri, karena seperti konteks 2D kanvas telah menjadi sesuatu. Karena itu… bagi mereka yang tidak sadar, CSS pain API adalah cara di mana Anda dapat menyematkan konteks kanvas 2D dan membuat parameter dan mengontrolnya dengan CSS, yang membuka banyak kemungkinan yang sangat menarik, seperti Anda dapat menganimasikan hal-hal yang Anda sebelumnya tidak bisa menghidupkan dan hal semacam itu.

Jeremy: Dan baru-baru ini saya melakukan penyegaran blog. Yaitu… Saya adalah seorang geek Final Fantasy yang hebat, seperti Final Fantasy II yang baru saja saya putar ulang dan jadi, ada 15 dari mereka dan 16 akan keluar kapan-kapan, tapi ini semacam bidang retro. Jadi saya telah menggunakan API cat CSS untuk menghasilkan dunia acak menggunakan ubin yang berbeda. Jadi ada seperti sungai dan hal-hal yang seperti mengalir dan ubin rumput dan pohon dan hal semacam itu. Dan parameterisasi itu seperti jika pengguna mengunjungi situs web saya dalam mode gelap… pekerjaan pengecatan itu akan dirender seolah-olah itu malam hari. Itu hanya akan memiliki semacam overlay di atasnya dan hal semacam itu.

Jeremy: Tapi API lukisannya luar biasa. Saya harus memberi tahu Tim Holman. Dia, saya melihatnya di JSConf Australia dan dia berbicara tentang karya seni generatif. Itu benar-benar hanya, itu benar-benar seperti membuat saya tertarik. Dan kemudian Sam Richard, di CSSConf sehari sebelumnya berbicara tentang API lukisan CSS, ketika kedua hal itu datang bersama untuk saya, itu seperti, "Wow, ini sangat keren." Jadi saya benar-benar melakukan sesuatu yang disebut Paintlets! Ini adalah Paintlets.Herokuapp.com jika Anda mengunjungi dan Chrome dan Anda harus, sayangnya, karena belum didukung dengan sangat baik. Anda dapat melihat seperti sekumpulan karya seni acak yang berbeda yang dihasilkan secara acak dan .. ya, saya baru saja ... itulah yang saya alami, maaf. Cerita panjang tentang itu.

Drew: Luar biasa. Kedengarannya bagus.

Jeremy: Ya. Ya.

Drew: Jika Anda, pendengar terkasih ingin mendengar lebih banyak dari Jeremy, Anda dapat menemukannya di Twitter di mana dia @malchata dan menemukan presentasi tulisan, video, dan proyeknya di situs web pribadinya, jeremy.codes, JavaScript yang Bertanggung Jawab tersedia sekarang dari A Buku Terpisah. Dan Anda dapat menemukan informasi lebih lanjut tentang itu di responsibilityjs.dev. Terima kasih telah bergabung dengan saya hari ini Jeremy, apakah Anda memiliki kata-kata perpisahan?

Jeremy: Maju saja dan buat web dengan cara terbaik yang Anda bisa dan cobalah untuk mengingat pengguna. Itu semacam mantra saya dan saya berharap buku ini bisa sedikit menguatkannya.