Smashing Podcast Episode 21 Dengan Chris Ferdinandi: Apakah Praktik Terbaik Modern Buruk Untuk Web?

Hari ini, kami bertanya apakah praktik terbaik modern buruk untuk web? Apakah kerangka kerja modern membawa kita ke jalan yang salah? Saya berbicara dengan pakar Lean Web Chris Ferdinandi untuk mencari tahu.

Tampilkan Catatan

• Halaman Chris dengan tautan dan catatan untuk podcast
• Buku Web Lean
• Chris Ferdinandi di web
• Chris di Twitter
• Podcast JavaScript Vanila

Update mingguan

• “Menerjemahkan Desain Wireframes Menjadi HTML/CSS yang Dapat Diakses”
  oleh Harris Schneiderman
• “Membangun Aplikasi Desktop Dengan Electron Dan Vue”
  oleh Timi Omoyeni
• “Teknik CSS Modern Untuk Meningkatkan Keterbacaan”
  oleh Edoardo Cavazza
• “Cara Menggunakan Komponen Bergaya di React”
  oleh Adebiyi Adedotun Lukman
• “Cara Membuat Porsche 911 Dengan Sketsa”
  oleh Nikola Lazarevic

Salinan

Drew McLellan: Dia adalah penulis Seri Panduan Saku Vanilla JS, pencipta Program Pelatihan Akademi Vanilla JS, dan pembawa acara Podcast Vanilla JS. Dia mengembangkan buletin Tips, yang dibaca oleh hampir 10.000 pengembang setiap hari kerja. Dia mengajar pengembang di organisasi seperti Chobani dan The Boston Globe. Dan plugin JavaScript-nya telah digunakan oleh organisasi seperti Apple dan Harvard Business School. Yang terpenting, dia suka membantu orang mempelajari JavaScript Vanilla. Jadi kita tahu dia lebih suka memilih Vanilla JavaScript daripada kerangka kerja, tetapi tahukah Anda bahwa dia pernah dipilih dalam barisan polisi sebagai orang yang paling tidak mungkin melakukan kejahatan? Teman-teman Smashing saya, tolong sambut Chris Ferdinandi. Halo, Kris. Apa kabar?

Chris Ferdinandi: Oh, saya hebat. Terima kasih telah memilikiku.

Drew: Saya ingin berbicara dengan Anda hari ini tentang konsep Web Lean ini, yang merupakan sesuatu yang menarik bagi Anda, bukan?

Chris: Ya, sangat banyak.

Drew: Mengapa Anda tidak mengatur adegan untuk kami? Ketika kita berbicara tentang Lean Web, masalah apa yang ingin kita pecahkan?

Chris: Ya, pertanyaan bagus. Sama seperti peringatan untuk semua pendengar, episode ini mungkin membuat seorang lelaki tua berteriak di awan. Saya akan mencoba untuk menghindari itu. Saat saya melihat cara kami membangun web hari ini, rasanya sedikit seperti kekacauan rekayasa yang berlebihan. Saya menjadi percaya bahwa banyak dari apa yang kita anggap sebagai praktik terbaik saat ini sebenarnya dapat memperburuk web.

Chris: The Lean Web adalah pendekatan pengembangan web yang berfokus pada kesederhanaan, kinerja, dan pengalaman pengembang lebih… Maaf, bukan pengalaman pengembang. Pengalaman pengguna lebih dari pengalaman pengembang, dan kemudahan membangun sesuatu dari perspektif tim, itulah yang menurut saya di mana kami menaruh banyak fokus hari ini dan seperti yang mungkin akan kami bahas dalam percakapan kami.

Chris: Saya benar-benar menemukan bahwa banyak hal yang kami anggap sebagai peningkatan pengalaman pengembang melakukannya untuk sebagian pengembang, tetapi tidak harus semua orang yang mengerjakan hal yang Anda bangun. Jadi ada banyak masalah dengan itu juga, yang bisa kita gali. Tapi sungguh, Lean Web adalah tentang berfokus pada kesederhanaan dan kinerja bagi pengguna dan benar-benar memprioritaskan atau menempatkan fokus pada orang-orang yang menggunakan barang-barang yang kami buat daripada kami, orang-orang yang membuatnya.

Drew: Seiring berkembangnya web sebagai platform pengembangan, tampaknya ada dorongan yang semakin meningkat menuju spesialisasi.

Kris: Ya.

Drew: Orang yang dulunya cover Full Stack, lalu kita bagi menjadi front-end dan back-end. Dan kemudian front-end itu dibagi menjadi orang-orang yang melakukan pengembangan CSS atau JavaScript. Dan kemudian semakin dalam JavaScript, itu menjadi lebih terspesialisasi. Seseorang mungkin menganggap diri mereka dan memasarkan diri mereka sebagai pengembang React atau pengembang Angular, dan seluruh identitas dan pandangan mereka didasarkan pada kerangka kerja tertentu yang sangat mereka kuasai. Apakah ketergantungan ini pada kerangka kerja, inti dari pekerjaan kami di web, sesuatu yang buruk?

Chris: Ini bernuansa. Saya dulu sangat kuat dalam ya, selalu berkemah. Saya pikir secara umum, saya masih merasa ya, obsesi kami sebagai industri dengan kerangka kerja dan alat secara umum sebenarnya, berpotensi sedikit merugikan kami. Saya tidak berpikir kerangka kerja pada dasarnya buruk. Saya pikir mereka berguna untuk subset kasus penggunaan yang sangat sempit. Dan kami akhirnya menggunakannya untuk hampir semua hal, termasuk banyak situasi di mana mereka benar-benar belum tentu merupakan pilihan terbaik untuk Anda atau untuk proyek.

Chris: Ketika saya memikirkan banyak masalah yang kita miliki di web hari ini, inti dari masalah tersebut benar-benar dimulai dengan ketergantungan kita yang berlebihan pada kerangka kerja. Segala sesuatu yang datang setelah itu dalam banyak hal, karena kami membuang begitu banyak tidak hanya kerangka kerja yang JavaScript pada umumnya, di web. Saya mengatakan itu sebagai seseorang yang secara profesional mengajari orang cara menulis dan menggunakan JavaScript. Begitulah cara saya menghasilkan uang. Dan saya di sini mengatakan bahwa saya pikir kita menggunakan terlalu banyak JavaScript, yang terkadang sedikit aneh.

Drew: Sebelum kerangka kerja besar muncul, kami biasa membangun antarmuka pengguna dan berbagai hal dengan jQuery atau apa pun. Dan kemudian kerangka kerja muncul dan mereka memberi kami lebih banyak konsep UI berbasis negara ini.

Kris: Ya.

Drew: Nah, itu adalah teknik yang cukup rumit yang harus Anda lakukan. Apakah bekerja dengan lebih sedikit JavaScript mengecualikan menggunakan sesuatu seperti itu, atau apakah Anda harus mengimplementasikannya kembali sendiri? Apakah Anda baru saja membuat boilerplate yang dimuat?

Chris: Banyak tergantung pada apa yang Anda lakukan. Jika Anda memiliki antarmuka yang tidak berubah, Anda dapat membangun UI berbasis negara dengan… Saya tidak tahu, mungkin sekitar selusin baris kode. Jika Anda memiliki antarmuka yang tidak berubah, sejujurnya saya mungkin akan mengatakan UI berbasis negara. Ini belum tentu merupakan pendekatan yang tepat. Mungkin ada hal lain yang bisa Anda lakukan sebagai gantinya. Pikirkan generator situs statis, beberapa markup yang telah dirender sebelumnya, bahkan situs berbasis WordPress atau PHP jadul.

Chris: Tapi di mana ini mulai menarik adalah ketika Anda masuk ke antarmuka yang lebih dinamis dan interaktif. Bukan hanya aplikasi. Saya tahu orang suka menarik garis antara situs web dan aplikasi, dan saya pikir ada perpaduan aneh antara keduanya dan garisnya tidak selalu jelas. Ketika Anda mulai masuk ke lebih banyak pengguna melakukan sesuatu, sesuatu berubah. UI berbasis negara menjadi sedikit lebih penting. Tetapi Anda masih tidak memerlukan banyak kode untuk mewujudkannya.

Chris: Saya melihat sesuatu seperti React atau Vue, yang merupakan bagian rekayasa yang benar-benar menakjubkan. Saya tidak ingin mengambil dari orang-orang yang mengerjakannya. Saya berakhir sebagai latihan pembelajaran, membangun kerangka kerja mini saya sendiri hanya untuk mendapatkan pemahaman yang lebih baik tentang bagaimana hal-hal ini bekerja di bawah tenda. Sangat sulit untuk menjelaskan semua bagian yang bergerak. Jadi saya sangat menghormati orang-orang yang membuat dan mengerjakan alat ini. Tapi React dan Vue keduanya sekitar 30 kilobyte setelah minifying dan gzip. Jadi begitu Anda membongkarnya, ukurannya jauh lebih besar dari itu.

Chris: Tidak semuanya, tetapi sebagian besar dari bobot itu dikhususkan untuk hal yang disebut DOM virtual. Ada alternatif yang menggunakan API atau pendekatan serupa. Untuk React, Anda memiliki Preact, yaitu 2,5 kilobyte atau sekitar 3 kilobyte, bukan 30. Ukurannya sepersepuluh. Untuk Vue, Anda memiliki Alpine JS sebagai gantinya, yaitu sekitar 7 kilobyte. Namun, secara substansial lebih kecil. Perbedaan besar antara mereka dan rekan-rekan kakak mereka, adalah bahwa mereka telah melepaskan DOM virtual. Mereka mungkin menjatuhkan satu atau dua metode. Tetapi secara umum, ini adalah pendekatan yang sama dan jenis API yang sama dalam cara bekerja dengan kode, dan mereka jauh lebih kecil.

Chris: Saya pikir banyak alat yang kami gunakan berpotensi dikalahkan untuk hal-hal yang kami coba lakukan. Jika Anda memerlukan UI berbasis status dan Anda memerlukan data reaktif dan antarmuka dinamis ini, itu bagus. Saya pikir salah satu hal besar yang saya coba dan bicarakan hari ini adalah tidak… tidak pernah menggunakan alat. Bagi saya, Vanilla JS tidak Anda menulis tangan setiap baris kode dan setiap proyek yang Anda lakukan. Itu kegilaan. Saya tidak bisa melakukan itu, saya tidak melakukan itu. Tapi itu menjadi lebih selektif tentang alat yang kami gunakan. Kami selalu menggunakan multi-alat, pisau Swiss Army yang memiliki semua hal ini di dalamnya. Dan terkadang, yang Anda butuhkan hanyalah gunting. Anda tidak membutuhkan semua barang lain, tetapi kami memilikinya.

Chris: Yang merupakan jalan yang sangat panjang untuk... Maaf, menjawab pertanyaan Anda. Yang terkadang lebih banyak kode daripada yang Anda bisa atau ingin Anda tulis sendiri, tetapi kode itu tidak sebanyak yang saya pikir kami butuhkan. Ketika saya mengatakan Anda tidak memerlukan kerangka kerja, saya mendapat banyak penolakan seputar gagasan bahwa, "Yah, jika Anda tidak menggunakan kerangka kerja, pada dasarnya Anda sedang menulis kerangka kerja Anda sendiri." Kemudian itu datang dengan masalahnya sendiri. Saya pikir ada tempat di antara menggunakan React atau Vue dan menulis kerangka kerja Anda sendiri, dan mungkin memilih sesuatu yang sedikit lebih kecil. Terkadang ada alasan di mana menulis kerangka kerja Anda sendiri mungkin merupakan panggilan yang tepat, tergantung pada apa yang Anda coba lakukan. Semuanya sangat cair dan subjektif.

Drew: Cukup menarik bahwa sebagai latihan pembelajaran, Anda menerapkan kerangka kerja berbasis negara Anda sendiri. Saya ingat di masa lalu, saya selalu berpikir bahwa setiap kali saya mencapai perpustakaan atau sesuatu, saya suka berpikir bahwa saya dapat menerapkannya sendiri.

Kris: Tentu, tentu.

Drew: Tapi meraih perpustakaan menyelamatkan saya dari kerumitan melakukan itu. Saya tahu jika saya harus menulis kode ini sendiri, saya tahu pendekatan apa yang akan saya ambil untuk melakukannya. Dan itu benar sampai menggunakan hal-hal seperti jQuery dan lainnya. Hari-hari ini, saya pikir jika saya harus menulis versi Vue atau React saya sendiri, saya hampir tidak tahu apa yang terjadi sekarang di perpustakaan itu, di semua kode itu.

Drew: Bagi kita yang tidak terbiasa, ketika Anda mengatakan sesuatu seperti Preact menjatuhkan DOM virtual dan membuat semuanya jauh lebih kecil, apa yang diberikan DOM virtual itu kepada kita?

Chris: Untuk menjawab pertanyaan itu, saya ingin mundur sedikit. Salah satu hal terbaik yang diberikan oleh kerangka kerja dan perpustakaan berbasis negara lainnya adalah pembedaan DOM. Jika Anda tidak benar-benar memperbarui UI sebanyak itu, Anda bisa mengatakan, “Berikut adalah rangkaian tampilan markup yang seharusnya. Dalam HTML, saya hanya akan meletakkan semua markup ini di elemen ini.” Ketika Anda perlu mengubah sesuatu, Anda melakukannya lagi. Itu sedikit mahal untuk browser, karena memicu pengecatan ulang.

Chris: Tapi saya pikir berpotensi lebih penting dari itu, salah satu masalah dengan melakukan itu adalah Anda memiliki elemen interaktif apa pun di sana, bidang formulir, tautan yang menjadi fokus seseorang. Fokus itu hilang karena elemen… meskipun Anda memiliki hal baru yang terlihat serupa, itu bukan elemen literal yang sama. Jadi, jika fokus hilang, hal itu dapat menimbulkan kebingungan bagi orang yang menggunakan pembaca layar. Hanya ada banyak masalah dengan itu.

Chris: Hal UI berbasis negara bagian apa pun yang sepadan dengan bobotnya akan menerapkan beberapa perbedaan DOM, di mana mereka berkata, “Seperti inilah tampilan UI. Inilah yang tampak seperti sekarang di DOM. Apa yang berbeda?” Dan itu akan pergi dan mengubah hal-hal itu. Ini secara efektif melakukan hal-hal yang akan Anda lakukan hanya secara manual memperbarui UI sendiri, tetapi melakukannya untuk Anda di bawah tenda. Jadi Anda bisa mengatakan, "Inilah yang saya inginkan." Dan kemudian perpustakaan atau kerangka kerja mengetahuinya.

Chris: Hal-hal yang lebih kecil seperti Preact atau Alpine, mereka benar-benar melakukannya secara langsung. Mereka mengonversi string yang Anda berikan kepada mereka tentang tampilan UI yang seharusnya menjadi elemen HTML. Dan kemudian mereka membandingkan setiap elemen dengan bagiannya yang sesuai di DOM literal. Saat Anda berakhir dengan UI yang semakin besar dan semakin besar, itu dapat memiliki implikasi kinerja karena menanyakan DOM berulang kali menjadi mahal. Jika Anda ingin memahami jenis antarmuka yang menjadi masalah, klik kanan dan periksa elemen pada tombol "Favorit" di Twitter, atau tombol "Suka" di Facebook. Dan lihat sarang div yang membawa Anda ke elemen itu. Ini sangat, sangat dalam. Ini seperti selusin atau lebih div, bersarang satu di dalam yang lain hanya untuk satu tweet itu.

Chris: Saat Anda mulai menurunkan banyak lapisan, itu mulai benar-benar memengaruhi kinerja. Apa yang dilakukan DOM virtual adalah alih-alih memeriksa DOM asli setiap saat, ini membuat peta berbasis objek dari tampilan UI di JavaScript. Dan kemudian lakukan hal yang sama untuk UI yang ingin Anda ganti dengan yang sudah ada, dan membandingkan keduanya. Itu jauh lebih banyak kinerja secara teori, daripada melakukannya di DOM yang sebenarnya. Setelah mendapat daftar hal-hal yang perlu diubah, itu hanya berjalan dan membuat perubahan itu. Tapi itu hanya perlu menyerang DOM sekali. Itu tidak memeriksa setiap elemen, setiap saat. Jika Anda memiliki antarmuka seperti Twitter atau Facebook atau QuickBooks atau semacamnya, DOM virtual mungkin sangat masuk akal.

Chris: Tantangannya adalah… perbedaan antara Preact dan React adalah 27 kilobyte sebelum Anda membongkar semuanya ke dalam codewave yang sebenarnya. Waktu pengunduhan mentah dan pembongkaran dan kompilasi pada itu saja dapat menambahkan sedikit latensi ke pemuatan awal pada UI. Itu menjadi lebih jelas jika pengguna Anda tidak menggunakan perangkat terbaru dari Apple. Bahkan perangkat Android dari beberapa tahun yang lalu atau ponsel berfitur, atau jika Anda memiliki orang di negara berkembang, hanya saja… waktu untuk memulai lebih lambat. Dan selain itu, waktu interaktif yang sebenarnya lebih lambat karena abstraksi ekstra.

Chris: Jadi bukan hanya Anda memuatnya dan kecepatannya sebanding. Setiap interaksi mikro yang dilakukan seseorang dan perubahan yang perlu terjadi juga bisa sedikit lebih lambat hanya karena semua kode tambahan di sana. Jika Anda memiliki UI yang sangat, sangat kompleks dengan banyak elemen bersarang dan banyak data, maka kinerja DOM virtual meningkat lebih besar daripada bobot kode tambahan itu. Tetapi setiap UI khas untuk aplikasi khas yang sebagian besar dari apa yang saya lihat pengembang menggunakan React atau Vue, manfaat yang Anda dapatkan dari DOM virtual tidak ada dan mereka akan lebih baik. Bahkan jika Anda ingin menjaga kenyamanan React yang sama, gunakan Preact. Ini adalah sebagian kecil dari ukuran, itu akan bekerja dengan cara yang persis sama, dan akan lebih berkinerja. Ini adalah hal yang cenderung saya perdebatkan.

Chris: Kita harus lebih baik dalam memilih alat yang tepat untuk pekerjaan itu. Jika Anda menggunakan pendekatan seperti itu, jika Anda mencapai titik di mana DOM virtual benar-benar masuk akal, jauh lebih mudah untuk mem-port Preact ke React daripada jika Anda menggulung sendiri. Itulah situasinya. Jika Anda benar-benar khawatir tentang itu, Anda juga mendapatkan beberapa pemeriksaan masa depan.

Drew: Beberapa orang mungkin mengatakan, mereka mungkin membuat argumen bahwa kerangka kerja ini, hal-hal seperti Vue, React sangat dioptimalkan untuk kinerja sehingga Anda mendapatkan begitu banyak manfaat di sana yang pasti hanya memasangkannya dengan manajer paket di bundler untuk memastikan Anda ' kembali hanya mengirimkan kode yang Anda inginkan. Tentunya, Anda sudah jauh di depan hanya dengan melakukan itu?

Kris: Ya. Saya tidak setuju. Saya tidak punya banyak hal untuk dijelaskan selain… Saya kira mungkin, tapi tidak juga. Bahkan dengan bundler, Anda masih membutuhkan inti React itu. Bahkan dengan bundling, itu masih akan lebih besar daripada menggunakan sesuatu seperti Preact.

Chris: Drew, saya sangat menghargai Anda memimpin pertanyaan ini. Karena salah satu hal lain yang saya bicarakan dalam buku saya, The Lean Web, dan pembicaraan saya dengan nama yang sama, adalah bagaimana alat-alat ini… Anda menyebutkan bundling, misalnya. Salah satu hal yang kami lakukan untuk menyiasati pencapaian kinerja yang kami ambil dari penggunaan semua JavaScript ini adalah kami menambahkan lebih banyak JavaScript di front-end untuk memperhitungkannya. Salah satu cara yang kami lakukan adalah manajer paket dan bundler modul.

Chris: Seperti yang Anda singgung… bagi Anda yang belum tahu, ini adalah alat yang akan… mereka akan mengkompilasi semua bit JavaScript kecil Anda menjadi satu file besar. Yang lebih baru dan lebih… Saya tidak ingin menyebut mereka bijaksana. Tetapi yang lebih baru akan menggunakan fitur yang disebut goyangan pohon, di mana mereka menyingkirkan kode apa pun yang sebenarnya tidak diperlukan. Jika kode itu memiliki beberapa dependensi yang tidak digunakan untuk hal yang sebenarnya telah Anda lakukan, mereka akan menghapus sebagian dari hal itu untuk membuat paket Anda sekecil mungkin. Ini sebenarnya bukan ide yang buruk, tetapi ini menghasilkan hal yang biasanya saya sebut kesehatan ketergantungan di mana Anda memiliki rumah kartu dependensi yang sangat rumit di atas dependensi di atas dependensi.

Chris: Menyiapkan proses Anda membutuhkan waktu. Dan siapa pun yang pernah menjalankan instalasi NPM dan kemudian menemukan bahwa banyak dependensi kedaluwarsa dan harus menghabiskan satu jam mencoba mencari tahu mana yang perlu diperbaiki dan oh, itu sebenarnya ketergantungan dalam ketergantungan dan Anda tidak 't memiliki kemampuan untuk pergi memperbaikinya sendiri. Ini adalah hal yang utuh. Mungkin itu berhasil untuk Anda, tetapi saya lebih suka menghabiskan waktu saya untuk tidak main-main mencoba menyatukan dependensi saya.

Chris: Saya mulai mengumpulkan tweet dari orang-orang yang mengeluh tentang waktu yang terbuang untuk alur kerja mereka. Salah satu favorit saya, Brad Frost beberapa tahun yang lalu, berbicara tentang kesadaran yang menyedihkan bahwa hal yang telah Anda lakukan dengan susah payah di JS modern dapat membawa Anda 10 menit di jQuery. Saya sebenarnya bukan penggemar jQuery, tetapi saya merasa sakit ketika harus bekerja dengan kerangka kerja.

Chris: Masalah lain dengan banyak alat ini adalah mereka mulai menjadi penjaga gerbang. Saya tidak tahu seberapa besar Anda benar-benar ingin menyelami ini atau tidak, Drew. Tapi salah satu dorongan besar saya terhadap JS, semua hal dalam alur kerja. Terutama ketika Anda mulai berkata, “Nah, jika kita sudah menggunakan JS untuk HTML, mengapa tidak menggunakannya untuk CSS juga?” Anda mulai mengecualikan banyak orang yang benar-benar berbakat dari proses pengembangan. Ini hanya kerugian yang sangat besar bagi proyek bagi masyarakat secara keseluruhan.

Drew: Ya, tentu saja… Saya mulai mempelajari React pada awal tahun 2020, menambahkannya ke keahlian saya. Saya sudah melakukannya sekarang selama hampir tujuh bulan. Saya harus mengatakan satu bagian yang paling tidak saya percayai adalah menyiapkan peralatan untuk memulai proyek.

Drew: Sepertinya ada banyak sekali pekerjaan untuk mendapatkan sesuatu ke Hello World, dan ada lebih banyak lagi yang harus Anda ketahui untuk membuatnya siap produksi. Itu harus membuat pengembangan lebih sulit untuk memulai jika ini diajukan sebagai apa yang harus Anda lakukan pada tahun 2020 untuk belajar menjadi pengembang web. Seseorang yang baru datang akan memiliki masalah yang nyata. Ini akan menjadi penghalang nyata untuk masuk, bukan?

Kris: Tentu saja. Bagian lainnya di sini adalah bahwa pengembang JavaScript tidak selalu menjadi satu-satunya orang yang bekerja pada basis kode atau berkontribusi dengan cara yang berarti pada basis kode tersebut. Semakin kita mengetahui JavaScript sebagai persyaratan untuk bekerja dengan basis kode, semakin kecil kemungkinan orang-orang tersebut untuk benar-benar berpartisipasi dalam proyek.

Chris: Contohnya, yang ingin saya bicarakan adalah WordPress, yang baru-baru ini… Saya seharusnya tidak mengatakannya baru-baru ini. Sudah beberapa tahun sekarang. Tetapi mereka telah semakin menggeser tumpukan back-end mereka ke JavaScript, jauh dari PHP, yang pada dasarnya bukanlah hal yang buruk. Editor baru mereka, Gutenburg, dibangun di atas React.

Chris: Pada tahun 2018, konsultan aksesibilitas utama WordPress, Rian Rietveld, yang namanya hampir pasti saya bunuh… dia secara terbuka mengundurkan diri dari posisinya dan mendokumentasikan alasannya dalam artikel yang sangat terperinci. Inti masalahnya adalah dia dan timnya ditugaskan untuk mengaudit editor ini untuk memastikan bahwa editor ini dapat diakses. WordPress terdiri sekarang 30% dari web. Tujuan mereka adalah untuk mendemokratisasikan penerbitan, jadi aksesibilitas adalah bagian yang sangat penting dari itu. Ini harus menjadi bagian penting dari setiap proyek web. Tetapi bagi mereka khususnya, ini sangat penting. Seluruh tugas timnya adalah memastikan… seluruh tugas timnya adalah memastikan bahwa editor ini dapat diakses. Tetapi karena baik dia maupun siapa pun di timnya tidak memiliki pengalaman React dan karena mereka tidak dapat menemukan sukarelawan di komunitas aksesibilitas dengan pengalaman tersebut, hal itu membuat dia dan timnya sangat sulit untuk melakukan pekerjaan mereka.

Chris: Secara historis, mereka dapat mengidentifikasi kesalahan dan kemudian masuk dan memperbaikinya. Tetapi dengan alur kerja berbasis React yang baru, mereka direduksi menjadi mengidentifikasi bug dan kemudian mengajukan tiket. Mereka ditambahkan ke backlog bersama dengan semua permintaan pengembangan fitur lainnya yang sedang dikerjakan oleh pengembang JavaScript. Banyak hal yang bisa diperbaiki dengan mudah tidak berhasil masuk ke rilis pertama.

Chris: Pada Mei 2019, sekitar setahun setelah Rian mengundurkan diri, ada audit aksesibilitas terperinci yang dilakukan di Gutenburg. Laporan lengkapnya adalah 329 halaman. Ringkasan eksekutif saja adalah 34 halaman. Ini mendokumentasikan 91 bug terkait aksesibilitas dengan cukup detail. Banyak dari ini yang benar-benar… Saya tidak ingin menyebutnya sebagai buah yang menggantung rendah, tetapi banyak dari mereka adalah hal-hal dasar yang dapat diperbaiki oleh tim Rian dan itu akan membebaskan para pengembang untuk fokus pada pengembangan fitur. Pada akhirnya itulah yang tampaknya mereka lakukan, menghabiskan banyak waktu untuk pengembangan fitur dan mendorong hal ini sampai nanti. Tetapi tim itu sangat penting bagi proyek, dan mereka tiba-tiba terkunci dari proses karena pilihan teknis.

Chris: Alex Russell adalah pengembang di tim Chrome. Dia menulis artikel ini beberapa tahun yang lalu berjudul The Developer Bait and Switch, di mana dia berbicara tentang argumen kerangka kerja manusia jerami. Gagasan bahwa alat ini memungkinkan Anda bergerak lebih cepat dan karena itu, Anda dapat mengulangi lebih cepat dan memberikan pengalaman yang lebih baik. Ini adalah gagasan bahwa pengalaman pengembang yang lebih baik berarti pengalaman pengguna yang lebih baik. Saya pikir ini adalah contoh yang sangat jelas tentang bagaimana argumen itu tidak selalu berjalan seperti yang diyakini orang. Ini adalah pengalaman yang lebih baik untuk beberapa orang, bukan untuk semua orang.

Chris: Pengembang CSS, orang yang bekerja pada sistem desain, kemampuan mereka untuk membuat alat yang dapat digunakan orang lain terkadang juga dibatasi oleh pilihan alat ini. Dalam pengalaman saya, saya dulu lebih baik di CSS. Itu banyak berubah dalam beberapa tahun terakhir dan saya tidak sebaik dulu. Dalam pengalaman saya, orang-orang yang benar-benar merupakan pengembang CSS tingkat lanjut… dan maksud saya dalam arti yang sebenarnya. Orang yang bekerja di CSS adalah pengembang web yang tepat yang mengerjakan bahasa pemrograman. Ini adalah hal yang sangat istimewa, atau bisa menjadi hal yang sangat khusus. Orang-orang yang sangat pandai dalam hal itu, menurut pengalaman saya, tidak selalu juga sangat baik dalam JavaScript karena Anda akhirnya menyelam sangat dalam ke satu hal dan Anda menggeser sedikit pada beberapa hal lainnya. Kemampuan mereka untuk bekerja dengan teknologi ini juga terhambat, yang terlalu buruk karena dulu tidak demikian.

Chris: Ketika tumpukan lebih sederhana, lebih mudah bagi orang-orang dari berbagai disiplin ilmu untuk berpartisipasi dalam proses pengembangan. Saya pikir itu merugikan hal-hal yang kami bangun dan komunitas pada umumnya, ketika itu tidak lagi terjadi.

Drew: Saya menemukan baru-baru ini dalam sebuah proyek yang meneliti cara untuk menangani beberapa masalah CSS, masalah alur kerja, kami memiliki banyak pekerjaan pada proyek dan ukuran bundel meningkat dan CSS lama tidak pernah dihapus. Itu adalah proyek React, jadi kami melihat beberapa CSS ini dalam pendekatan JavaScript untuk melihat apa yang terbaik untuk kami gunakan untuk memecahkan masalah yang kami miliki. Apa yang menjadi sangat cepat terlihat adalah tidak hanya ada satu solusi untuk melakukan ini. Ada lusinan cara berbeda yang bisa Anda lakukan.

Drew: CSS di JS adalah pendekatan umum, tetapi Anda mungkin beralih dari satu proyek ke proyek berikutnya dan itu sepenuhnya dipengaruhi dengan cara yang sama sekali berbeda. Bahkan jika Anda adalah orang CSS dan Anda mempelajari pendekatan tertentu pada suatu proyek, keterampilan tersebut mungkin tidak dapat dialihkan. Sangat sulit untuk melihat bagaimana seseorang harus menginvestasikan terlalu banyak waktu untuk mempelajarinya jika mereka tidak terlalu nyaman dengan JavaScript.

Kris: Ya. Hal menarik lainnya yang saya pikir Anda baru saja keluar sedikit adalah ketika saya berbicara tentang ini, salah satu bagian terbesar dari push-back yang saya dapatkan adalah bahwa kerangka kerja menegakkan konvensi. Anda akan menggunakan JavaScript Vanilla, Anda memiliki langit biru lapangan hijau ini, Anda dapat melakukan apa pun yang Anda inginkan jenis proyek. Dengan React, ada cara React untuk melakukan sesuatu.

Chris: Tapi salah satu hal yang saya temukan adalah bahwa ada pendekatan Reacty, tapi tidak ada satu cara yang tepat untuk melakukan sesuatu dengan React. Itu salah satu hal yang disukai orang. Ini sedikit lebih fleksibel, Anda dapat melakukan berbagai hal dengan beberapa cara berbeda jika Anda mau. Sama dengan Vue. Anda dapat menggunakan hal berbasis HTML di mana Anda memiliki properti Anda tepat di HTML dan Vue menggantikannya, tetapi Anda juga dapat menggunakan jenis sintaks templating yang lebih mirip JSX jika Anda mau.

Chris: Saya telah mendengar banyak orang mengeluh tentang ketika mereka belajar React, salah satu masalah besar adalah Anda Google bagaimana melakukan X di React dan Anda mendapatkan selusin artikel yang memberi tahu Anda selusin cara berbeda untuk melakukan hal itu. Itu tidak berarti mereka tidak memasang pagar pembatas pada sebuah proyek. Saya tidak berpikir itu sejelas, “Saya telah memilih kerangka kerja. Sekarang inilah cara saya membangunnya.” Sejujurnya, saya tidak tahu bahwa itu juga sesuatu yang saya inginkan. Saya tidak berpikir Anda ingin mereka terkurung dengan ketat ... beberapa orang, mungkin. Tetapi jika Anda menggembar-gemborkan itu sebagai manfaat, saya rasa itu tidak terlalu menonjol seperti yang kadang-kadang dipikirkan orang.

Chris: Anda masuk ke hal yang menarik meskipun hanya di sana, di mana Anda menyebutkan CSS yang tidak lagi diperlukan. Saya pikir itu adalah salah satu hal menarik yang sah bahwa sesuatu seperti CSS dan JS… atau mengikat CSS Anda ke komponen JavaScript dengan cara tertentu dapat membuat Anda kehilangan komponen itu, CSS juga secara teori, hilang begitu saja. Banyak dari ini bagi saya terasa seperti melemparkan rekayasa pada masalah orang. Selalu, Anda masih bergantung pada orang-orang di suatu tempat di sepanjang garis. Itu tidak berarti tidak pernah menggunakan pendekatan itu, tetapi itu jelas bukan satu-satunya cara untuk mengatasi masalah ini.

Chris: Ada alat yang dapat Anda gunakan untuk mengaudit HTML Anda dan mengeluarkan gaya yang tidak digunakan bahkan tanpa menggunakan CSS dan JavaScript. Anda dapat menulis CSS "cara kuno" dan masih melakukan linting gaya yang tidak digunakan. Ada pendekatan authoring untuk CSS yang memberi Anda CSS dalam output seperti JS dan menjaga agar style sheet Anda tetap kecil tanpa mengeluarkan nama kelas manusia yang tidak terbaca yang terkadang Anda dapatkan dengan CSS dan JS. Seperti X2354ABC, atau hanya kata-kata tidak masuk akal yang dimuntahkan.

Chris: Di sinilah saya mulai benar-benar tertarik pada orang tua yang berteriak pada awan. Saya benar-benar menunjukkan usia pengembang saya di sini. Tapi ya, belum tentu hal-hal ini buruk, dan itu dibuat untuk memecahkan masalah yang sah. Kadang-kadang saya merasa seperti ada sedikit ... jika itu cukup baik untuk Facebook, itu cukup baik untuk kita seperti hal yang terjadi dengan ini. Nah, Facebook menggunakan alat ini. Jika kita benar-benar program rekayasa… tim, departemen, organisasi, kita juga harus demikian. Saya tidak selalu berpikir itu cara yang tepat untuk memikirkannya. Itu karena Facebook menangani masalah yang tidak Anda tangani, dan sebaliknya. Ukuran dan skala dari apa yang mereka kerjakan hanya berbeda, dan tidak apa-apa.

Drew: Tepat sekali. Saya melihat beberapa hal seperti CSS dan JavaScript hampir seperti polyfill. Kami memiliki masalah yang sah, kami membutuhkan cara untuk menyelesaikannya. Teknologi belum memberi kita cara untuk menyelesaikannya. Mungkin sementara kita menunggu platform web berkembang dan untuk mengatasi masalah itu, hal yang kita lakukan sekarang dengan jenis JavaScript ini akan membantu kita dan kita akan baik-baik saja. Kami tahu itu buruk. Kami tahu ini bukan solusi yang bagus, tetapi ini membantu kami saat ini. Dan semoga sementara ini kita bisa menariknya keluar dan menggunakan solusi asli.

Chris: Ini benar-benar lucu Anda membawa ini. Karena secara harfiah tadi malam, saya menonton ceramah dari Jeremy Keith dari tahun lalu tentang aplikasi web progresif. Tapi dia berbicara tentang bagaimana beberapa dekade yang lalu, dia mencoba meyakinkan orang untuk menggunakan JavaScript. Yang tampaknya konyol pada saat itu, tetapi JavaScript adalah hal baru ini. Dia menunjukkan kepada orang-orang bagaimana Anda dapat melakukan hal-hal keren seperti mengubah warna tautan saat melayang dengan yang baru ini… Tampaknya tidak masuk akal bahwa Anda memerlukan JavaScript untuk itu sekarang, karena itulah yang dilakukan CSS untuk Anda. Tetapi hal-hal seperti atribut fokus atau properti tidak ada pada saat itu.

Chris: Salah satu hal yang dia katakan dalam pembicaraan yang menurut saya benar-benar beresonansi dengan saya adalah bahwa JavaScript dalam banyak hal, membuka jalan sapi itu. Bahasa yang sangat fleksibel dan terbuka inilah yang dapat kita gunakan untuk membuat atau menggabungkan fitur yang belum ada. Dan akhirnya, browser mengejar dan mengimplementasikan fitur-fitur ini dengan cara yang lebih asli. Tapi butuh waktu. Saya benar-benar mengerti apa yang Anda katakan tentang ini. Ini bukan solusi sempurna, tapi itulah yang kami miliki saat ini.

Chris: Bagi saya, perbedaan terbesar antara polyfill dan beberapa solusi ini adalah polyfill dirancang untuk dirobek. Jika saya memiliki fitur yang ingin saya terapkan yang belum didukung oleh browser, tetapi ada semacam spesifikasi untuk itu dan saya menulis polyfill… setelah browser mengejar, saya dapat merobek polyfill itu dan saya tidak perlu melakukannya mengubah apa pun. Tetapi ketika Anda menggunakan beberapa alat ini, merobeknya berarti menulis ulang seluruh basis kode Anda. Itu sangat mahal dan bermasalah. Itu tidak berarti jangan pernah menggunakannya, tetapi saya merasa sangat yakin bahwa kita harus mempertimbangkan untuk memilih alat yang dapat dengan mudah ditarik nanti. Jika kita tidak lagi membutuhkannya atau platform mengejar, itu tidak memerlukan penulisan ulang yang besar untuk menariknya keluar.

Chris: Jadi untuk mengetahui bahwa kami memiliki banyak gaya yang tidak lagi kami gunakan, itu sebabnya saya pribadi lebih menyukai teknologi alat build yang mengaudit CSS Anda terhadap markup yang diberikan dan mengeluarkan hal-hal yang tidak Anda perlukan. Karena di ujung jalan jika sebuah platform menyusul, Anda dapat menarik bagian dari alat pembangunan itu tanpa harus mengubah segalanya. Itu hanya menambah apa yang sudah Anda miliki, sedangkan CSS dan JS tidak memberi Anda manfaat yang sama. Saya hanya memilih yang itu, tetapi saya memikirkan banyak teknologi ini secara lebih luas.

Chris: Saya merasa hal-hal seperti React atau Vue mungkin membuka beberapa jalur sapi yang pada akhirnya akan diikuti oleh browser dan mungkin menggunakan pendekatan serupa jika tidak sama, jadi mungkin ada lebih sedikit penulisan ulang yang terlibat di sana. Banyak hal ekosistem yang terpasang di sekitar yang mungkin kurang begitu.

Drew: Saya pikir itu benar, bukan, bahwa platform web bergerak perlahan dan hati-hati. Anda pikir jika lima tahun yang lalu, kita semua menempatkan Carousel JavaScript di halaman kita. Mereka ada di mana-mana. Semua orang mengimplementasikan JavaScript Carousel. Jika platform web telah melompat dan mengimplementasikan solusi Carousel untuk memenuhi kebutuhan itu, itu tidak akan ada tanpa ada yang menggunakannya karena orang tidak melakukannya dengan Carousel lagi. Karena itu hanya iseng-iseng, tren desain. Untuk mengatasi itu dan menghentikan platform itu sendiri menjadi membengkak dan menjadi masalah yang perlu dipecahkan, platform itu harus bergerak dengan kecepatan yang jauh lebih stabil. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it's related to the framework conversation. But it's the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you're getting all this benefit because you're not reloading the entire page framework. I feel like they don't always make good on those performance promises. Apakah Anda setuju dengan itu?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don't think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who's unfamiliar with those. When a single-page app, instead of having separate HTML files or if you're using something like a database driven site like WordPress, even though you don't have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That's what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don't have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that's slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they're not confused about where they are or what's going on. Because they can't see the change that's happening, they're hearing it announced. If you don't actually shift focus anywhere, that announcement doesn't happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don't necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website's being built, it doesn't always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you're going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it's not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it's being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Sangat. Sangat. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that's already there. So there's no reloading, they don't lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It's again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you'd have just a rectangle embedded in an HTML page which is your Flash Player, and you'd build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we're putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn't exist, I spell article like arcitle instead of article and the browser runs across that, it's going to be like, “Oh, I don't know what this is. Whatever, I'll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let's say I forget the B in bold, so I write old instead, font way old. The browser's going to be, “I don't know what this is. Whatever, we'll just keep going.” Your thing won't be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn't exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn't complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn't work at all.

Chris: There's an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don't disable it and most people are using devices that can actually handle modern JavaScript. That's true, but that's not the only reason why JavaScript doesn't work right, even if you have a linter there for example and you catch bugs ahead of time and things. There's plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we're recording this… a bad deploy took down Cloudflare. Interestingly as we're recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They're an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you'd like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn't part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone's in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it's probably even more now. That's a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There's just all sorts of reasons why JavaScript can fail and when it does, it's so catastrophic.

Chris: And so we built this web that should be faster than ever. It's 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn't have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I've hammered on this a couple times. I'm not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn't mean obsolete. It doesn't mean never embrace new stuff, but don't be so quick to just jump on all the shiny new stuff just because it's there. I know it's one of the things that keeps this industry really exciting and makes it fun to work in, there's always something new to learn. But when you pick these new things, do it because it's the right tool for the job and not just because it's the shiny new thing.

Chris: Salah satu hal lain yang tidak kami bahas sebanyak yang saya inginkan, tapi menurut saya sangat penting, adalah platform ini telah berkembang pesat dalam beberapa tahun terakhir. Merangkul itu sebanyak mungkin akan menghasilkan pengalaman web bagi orang-orang yang lebih cepat, tidak rapuh, yang lebih mudah bagi Anda untuk membangun dan memelihara karena memerlukan lebih sedikit ketergantungan seperti menggunakan apa yang diberikan browser kepada Anda. -kotak. Kami dulu membutuhkan jQuery untuk memilih hal-hal seperti kelas. Sekarang browser memiliki cara asli untuk melakukan itu. Orang-orang menyukai JSX karena memungkinkan Anda untuk menulis HTML dalam JavaScript dengan cara yang lebih mulus. Tetapi kami juga memiliki literal templat di JavaScript Vanilla yang memberi Anda tingkat kemudahan yang sama tanpa ketergantungan tambahan. HTML sendiri sekarang dapat menggantikan banyak hal yang dulu membutuhkan JavaScript, yang benar-benar menakjubkan.

Chris: Kami berbicara sedikit tentang ... ini adalah hal CSS, tetapi mengarahkan pada link dan bagaimana dulu membutuhkan JavaScript. Tetapi menggunakan hal-hal seperti detail dan elemen ringkasan, Anda dapat membuat pengungkapan, seperti memperluas dan menciutkan atau elemen akordeon secara asli tanpa memerlukan skrip. Anda dapat melakukan input pelengkapan otomatis hanya dengan menggunakan... Saya seharusnya tidak mengatakan adil, saya benci kata itu. Tetapi menggunakan elemen input sederhana dan kemudian elemen daftar data yang terkait dengannya, dengan beberapa opsi. Jika Anda ingin tahu tentang bagaimana semua hal ini bekerja di vanillajstoolkit.com, saya memiliki banyak hal JavaScript yang diberikan platform kepada Anda. Tetapi saya juga memiliki beberapa yang dulu membutuhkan JavaScript dan sekarang tidak ada hal-hal yang mungkin menarik juga jika Anda ingin beberapa contoh kode untuk mengikuti ini.

Chris: Di sisi CSS, plugin Vanilla JS saya yang paling populer adalah pustaka ini yang memungkinkan Anda menganimasikan pengguliran ke bawah ke tautan jangkar. Ini sangat besar. Ini adalah bagian tersulit dari kode yang pernah saya tulis. Dan sekarang sepenuhnya diganti dengan satu baris CSS, perilaku gulir halus. Ini lebih berkinerja. Lebih mudah untuk menulis. Lebih mudah untuk mengubah perilakunya. Ini hanya solusi keseluruhan yang lebih baik.

Chris: Salah satu hal lain yang saya harap kami lakukan lebih banyak adalah bersandar pada aplikasi multi-halaman. Saya merasa sedikit dibenarkan di sini, karena baru-baru ini saya melihat artikel dari seseorang di Google yang benar-benar mendorong pendekatan ini sekarang juga. Saya pikir itu cukup menarik, mengingat kerangka sudut dan kemudian yang sangat besar ini ... semua hal, boom, yang dimulai Google beberapa tahun yang lalu. Agak keren melihat mereka kembali ke sini. Menggunakan hal-hal seperti generator situs statis dan layanan luar biasa seperti Netlify dan caching CDN, Anda dapat membuat pengalaman web yang sangat cepat untuk orang-orang yang menggunakan file HTML individual untuk semua tampilan Anda yang berbeda. Jadi agak bersandar pada beberapa hal out-of-the-box ini.

Chris: Dalam situasi di mana itu tidak realistis untuk Anda, di mana Anda membutuhkan lebih banyak JavaScript, Anda memang memerlukan semacam perpustakaan, mungkin melihat pendekatan yang lebih kecil dan lebih modular terlebih dahulu daripada hanya pergi untuk raksasa industri. Alih-alih Bereaksi, apakah Preact akan berfungsi? Alih-alih bersudut… Maksud saya, alih-alih Vue, apakah Alpine JS akan berfungsi? Ada juga pra-kompiler yang sangat menarik di luar sana yang sekarang disebut Svelt, yang memberi Anda pengalaman seperti kerangka kerja dan kemudian mengkompilasi semua kode Anda ke dalam JavaScript Vanilla. Jadi Anda mendapatkan bundel yang sangat kecil ini yang hanya memiliki apa yang Anda butuhkan dan tidak ada yang lain. Alih-alih CSS dan JavaScript, bisakah Anda memasang beberapa linter CSS pihak ketiga yang akan membandingkan HTML Anda dengan CSS Anda dan mengeluarkan barang-barang yang tertinggal di sana secara tidak sengaja? Apakah cara berbeda untuk membuat CSS Anda, seperti CSS berorientasi objek oleh Nicole Sullivan, berfungsi? Kami tidak benar-benar membicarakannya, tapi itu adalah hal yang sangat keren yang harus dilihat orang.

Chris: Dan kemudian saya pikir mungkin bagian ketiga dan paling penting di sini, meskipun pendekatannya kurang spesifik dan lebih dari itu, saya ingin lebih banyak orang diingat, adalah bahwa web adalah untuk semua orang. Banyak alat yang kita gunakan saat ini berfungsi untuk orang-orang yang memiliki koneksi internet yang baik dan perangkat yang kuat. Tetapi mereka tidak bekerja untuk orang-orang yang menggunakan perangkat yang lebih tua, memiliki koneksi internet yang buruk. Ini bukan hanya orang-orang di daerah berkembang. Ini juga orang-orang di Inggris, di beberapa bagian AS di mana kami memiliki koneksi internet yang sangat buruk. Di tengah negara kita memiliki internet yang sangat lambat. Saya tahu ada tempat di bagian London yang tidak dapat menyambungkan broadband baru karena alasan historis, jadi Anda memiliki koneksi internet lama yang sangat buruk ini. Ada tempat-tempat seperti itu di seluruh dunia. Terakhir kali saya berada di Italia, hal yang sama. Internet di sana sangat mengerikan. Saya tidak tahu apakah itu berubah sejak saat itu.

Chris: Hal-hal yang kami bangun hari ini tidak selalu berhasil untuk semua orang, dan itu terlalu buruk. Karena visi web, hal yang saya sukai darinya, adalah platform untuk semua orang.

Drew: Jika pendengar ingin mengetahui lebih banyak tentang pendekatan ini, Anda telah membahasnya secara mendetail dalam buku Anda, The Lean Web. Dan itu tersedia secara online. Buku fisik atau buku digital?

Chris: Ini sedikit dari keduanya. Yah, tidak. Ini jelas bukan buku fisik. Anda pergi ke leanweb.dev. Anda dapat membaca semuanya secara online gratis. Anda juga bisa jika Anda mau, ada versi EPUB dan PDF yang tersedia dengan jumlah uang yang sangat kecil, saya lupa berapa sekarang. Aku sudah lama tidak melihatnya. Semuanya gratis online jika Anda menginginkannya. Anda juga dapat menonton ceramah tentang topik ini di mana saya akan membahas lebih detail jika Anda mau.

Chris: Tapi saya juga membuat halaman khusus hanya untuk pendengar Smashing Podcast di gomakethings.com/smashingpodcast, karena saya sangat kreatif dalam menamai sesuatu. Itu termasuk banyak sumber selain buku, seputar hal-hal yang kita bicarakan hari ini. Ini menautkan ke banyak teknik berbeda yang kami bahas, artikel lain yang saya tulis yang membahas lebih dalam beberapa topik ini dan sedikit memperluas pemikiran saya. Jika orang ingin belajar lebih banyak, itu mungkin tempat terbaik untuk memulai.

Drew: Itu hebat. Terima kasih. Saya telah mempelajari semua tentang Lean Web. Apa yang telah kamu pelajari akhir-akhir ini, Chris?

Chris: Ya, beberapa hal. Saya menyinggung ini sedikit sebelumnya dengan menonton video Jeremy di aplikasi web progresif. Saya telah menunda belajar bagaimana benar-benar menulis aplikasi web progresif saya sendiri selama beberapa tahun karena saya tidak memiliki kebutuhan khusus pada apa pun yang sedang saya kerjakan. Saya baru-baru ini mengetahui dari salah satu siswa saya yang berada di Afrika Selatan, bahwa mereka telah berurusan dengan pemadaman bergilir karena beberapa hal yang mereka alami di sana. Akibatnya, dia tidak dapat mengerjakan beberapa proyek yang telah kami lakukan bersama secara teratur, karena listrik padam dan dia tidak dapat mengakses portal pembelajaran dan mengikuti.

Chris: Bagi saya, sekarang membangun sebuah pengalaman di mana ia bekerja bahkan jika seseorang tidak memiliki internet telah menjadi prioritas yang lebih tinggi daripada… Saya menyadari bahwa mungkin itu sebelumnya, jadi saya mulai menggalinya dan berharap untuk menyatukannya beberapa minggu ke depan. Kita lihat saja nanti. Sumber daya Jeremy Keith dalam hal ini telah menjadi penyelamat mutlak. Saya senang mereka ada.

Chris: Saya tahu, Drew, Anda menyebutkan salah satu alasan Anda suka mengajukan pertanyaan ini adalah untuk menunjukkan bahwa orang tidak peduli seberapa berpengalaman mereka, selalu belajar. Hanya sedikit anekdot terkait. Saya telah menjadi pengembang web selama saya pikir, sekitar delapan tahun sekarang. Saya masih harus menggunakan Google properti CSS untuk membuat hal-hal miring, secara harfiah setiap kali saya menggunakannya. Untuk beberapa alasan, otak saya default ke dekorasi teks meskipun itu tidak benar. Saya akan mencoba beberapa kombinasi dari hal-hal yang berbeda, dan saya selalu memiliki satu kata yang salah setiap kali. Saya juga terkadang menulis miring alih-alih miring. Ya. Jika ada orang yang pernah merasa seperti, oh, saya tidak akan pernah mempelajari hal ini… ketahuilah bahwa tidak peduli seberapa berpengalaman Anda, selalu ada beberapa hal mendasar yang Anda cari di Google berulang kali.

Drew: Saya telah menjadi pengembang web selama 22, 23 tahun, dan saya masih harus mencari properti yang berbeda untuk Flexbox di Google, setiap saat. Meskipun saya telah menggunakannya selama 23 tahun. Tapi ya, beberapa hal hanya… mungkin akan ada lebih banyak lagi seiring bertambahnya usia.

Kris: Ya. Sejujurnya, saya akhirnya membangun seluruh situs web dari hal-hal yang saya Google lagi dan lagi, hanya untuk memiliki referensi salin-tempel yang lebih mudah karena itu lebih mudah daripada Googling.

Drew: Itu bukan ide yang buruk.

Chris: Itu jenis pemalas saya. Saya akan membangun seluruh situs web untuk menyelamatkan diri seperti tiga detik dari Googling.

Drew: Jika Anda pendengar ingin mendengar lebih banyak dari Chris, Anda dapat menemukan bukunya di web di leanweb.dev, dan buletin Kiat pengembangnya dan lebih banyak lagi di gomakethings.com. Chris ada di Twitter di Chris Ferdinandi. Dan Anda dapat melihat podcastnya di vanillajspodcast.com atau di mana pun Anda biasanya mendapatkan podcast Anda. Terima kasih telah bergabung dengan kami hari ini, Chris. Apakah Anda memiliki kata-kata perpisahan?

Chris: Tidak. Terima kasih banyak telah menerima saya, Drew. Saya memiliki waktu yang benar-benar hebat. Ini sangat menyenangkan. Saya sangat menghargai kesempatan untuk datang mengobrol.