Smashing Podcast Episode 32: Ulasan Tahun Ini 2020

Dalam episode ini, kita melihat kembali tahun 2020. Dengan siapa kita berbicara di episode tahun ini, dan apa yang kita pelajari? Mari kita dengarkan kembali beberapa klip untuk mengetahuinya.

Tampilkan Catatan

Anda dapat menemukan semua episode kami sebelumnya, termasuk transkrip lengkap setiap wawancara di podcast.smashingmagazine.com.

Sampai jumpa di tahun 2021, semuanya!

Salinan

Drew McLellan: Pada bulan Januari, saya berbicara dengan Amy Hupe tentang pekerjaannya pada sistem desain pemerintah Inggris, dan khususnya, bagaimana tim meningkatkan adopsi sistem oleh organisasi yang lebih luas dengan mendorong kontribusi. Ini Amy.

Amy Hupe: Kami mulai sangat awal. Jadi jauh sebelum kami memiliki semacam sistem desain publik, kami mulai terlibat dengan orang-orang yang kami pikir akan menjadi kontributor yang tertarik. Saya harus menyebutkan di sini kami memiliki desainer layanan yang brilian di tim. Dia bergabung dengan kami di ... Saya tidak akan mendapatkan tanggal yang benar dengan cara apa pun saat ini, tapi saya pikir dia bekerja dengan kami sepanjang tahun 2018, dan namanya Ignacia. Dia baru saja melakukan pekerjaan yang fantastis dengan berkeliling dan melibatkan orang-orang. Jadi salah satu hal yang dia lakukan adalah pergi dan mengidentifikasi semua pola yang berbeda dalam pemerintahan dan semua jenis variasi dari pola tersebut. Jadi pergi keluar dan berkata, “Oke. Ada 10 cara berbeda untuk meminta alamat di pemerintahan. Mari kita lihat semuanya bersama-sama dan putuskan pendekatan mana yang menurut kami paling tepat. Bagaimana kita bisa menggabungkan ini menjadi satu?”

Amy Hupe: Dia menjalankan lokakarya besar untuk mencoba dan membuat orang-orang melihatnya dan melakukan konsolidasi semacam itu sebagai sebuah tim. Saya pikir pasti pendekatannya untuk membangun kolaborasi sebelum kami benar-benar merilis sesuatu ke publik sangat membantu karena itu berarti bahwa orang-orang sudah memiliki kesadaran seperti itu, dan banyak orang telah berkontribusi dalam beberapa cara atau lain sebelum kita benar-benar membawanya ke publik. Jadi kami agak melewati beberapa langkah di depan. Jadi saya pikir itu sangat penting dan hanya kegigihan, banyak kegigihan dari seluruh tim dalam membantu orang untuk berkontribusi.

Amy Hupe: Saya pikir ada ide bahwa jika Anda membuat orang berkontribusi pada sistem desain, itu adalah pertunjukan yang cukup manis, karena Anda bisa membuat orang melakukan semua pekerjaan untuk Anda, dan Anda hanya duduk di sana, dan Anda membuat perbaikan kode kecil Anda, dan semua orang benar-benar memberi Anda semua hal yang baik. Tetapi sebenarnya, seperti yang diketahui oleh siapa pun yang bekerja pada sistem desain, ini sangat kompleks. Sangat sulit untuk membuat solusi terpusat yang bekerja untuk beberapa tim yang berbeda.

Amy Hupe: Sungguh, kecuali Anda telah bekerja pada sistem desain, tidak masuk akal untuk mengharapkan siapa pun untuk benar-benar memahami apa yang diperlukan. Jadi ada banyak jenis pegangan tangan. Ada banyak pekerjaan yang terlibat dalam mendukung kontributor untuk berkontribusi. Saya pikir saya telah mengatakan ini sebelumnya, tetapi mungkin membutuhkan waktu lebih lama, saya pikir, untuk membantu seseorang berkontribusi pada sistem desain daripada hanya membuatnya sendiri dan tim terpusat. Tapi saya pikir mengenali nilai yang dibawanya dan gigih dalam upaya Anda untuk membuat orang sadar akan kontribusi, membantu mereka melakukannya, membantu mereka merasa termotivasi untuk melakukannya, saya pikir ya, ketekunan itu benar-benar kunci untuk keberhasilan kami di bidang itu.

Drew: Kami bergabung dengan Stephanie Stimac dan Aaron Gustafson dari Microsoft untuk membicarakan tentang Edge yang mengadopsi Chromium sebagai mesin renderingnya. Saya bertanya kepada Aaron tentang lanskap persaingan antara browser dan di mana beberapa browser yang bergabung pada mesin rendering yang sama akan menghapus persaingan yang sehat itu dan karenanya berdampak buruk bagi web terbuka.

Aaron Gustafson: Ini adalah sesuatu yang telah lama saya perjuangkan dengan standar web. Saya benar-benar mendapatkan pembenaran bisnis untuk itu. Dari sudut pandang Microsoft, itu sangat masuk akal. Dari perspektif pengembang ujung depan, menyenangkan untuk tidak harus melayani banyak mesin yang berbeda. Maksud saya, secara keseluruhan, kita yang telah lama bekerja di web pasti telah melihat banyak konvergensi dalam hal rendering. Kami tidak memiliki banyak masalah seperti yang kami alami, katakanlah kembali di Netscape selama tujuh hari, di mana kami baru saja seperti ... Saya tahu perusahaan yang membuat lembar gaya unik untuk setiap browser yang berbeda, yang tidak dapat dipertahankan.

Aaron Gustafson: Tapi saya pikir apa yang agak berbeda sekarang adalah bahwa pada perang browser asli, Anda memiliki semua mesin berpemilik ini, dan semua orang menyukai permainan satu keunggulan dalam hal mencoba mengirimkan fitur platform baru dan fitur JavaScript baru atau dalam kasus Microsoft reverse engineering JavaScript untuk membuat JScript dan mencoba mencari cara untuk menyesuaikan semuanya.

Aaron Gustafson: Tapi sekarang kami memiliki kemampuan untuk benar-benar bekerja sama dalam proyek open source dan masih berdialog dan masih… Saya tidak tahu. Fight bukanlah kata yang tepat, tetapi untuk melakukan diskusi serius tentang dampak dari pendekatan yang berbeda dan untuk tidak setuju satu sama lain dan untuk benar-benar berupaya membuat spesifikasi menjadi sangat bagus dan juga memiliki pendekatan yang bersaing untuk kode yang mendasari dalam konteks, katakanlah Chromium project atau WebKit atau semacamnya atau Missoula di ruang Firefox.

Aaron Gustafson: Jadi ya. Di satu sisi, kami kehilangan mesin rendering lain, dan saya merasakan sakit yang sama ketika opera memutuskan untuk beralih ke Chromium. Tetapi saya merasa agak berbesar hati berada di dalam Microsoft dan melihat betapa berkomitmennya kami untuk benar-benar berpartisipasi dalam proyek Chromium dengan cara yang berarti dan tidak hanya duduk dan menerima segala sesuatu yang berasal dari hilir Chromium, tetapi sebenarnya semacam memeriksa apa yang terjadi platform dan berpartisipasi di dalamnya ... Ya.

Aaron Gustafson: Jadi saya sedikit berbesar hati dengan itu dan merasa seperti kami tidak hanya di sana untuk mengambil dari proyek itu dan hanya menerima apa pun yang diturunkan oleh semua orang berbeda yang memiliki kepentingan dalam proyek itu, tetapi untuk benar-benar akan berkolaborasi di sana juga.

Drew: Pada bulan Februari, saya berbicara dengan Stephanie Walter tentang bekerja dengan kerangka kerja UI seperti Bootstrap dan teman-teman dan menyeimbangkannya dengan kebutuhan khusus dari antarmuka yang dapat digunakan. Saya bertanya kepada Stephanie apakah mungkin untuk membuat UI yang sangat berguna saat menggunakan kerangka kerja yang siap pakai atau apakah itu akan selalu menjadi kompromi yang canggung.

Stephanie Walter: Ya. Aku rasa ini. Tapi itu juga tergantung pada tingkat kompromi yang ingin Anda lakukan, dan kompromi ini di kedua sisi. Saat ini, saya mengorbankan banyak tombol, misalnya, karena Anda memiliki beberapa tombol yang sangat spesifik di UI material. Saya tidak terlalu suka efek riak pada tombol. Saya pikir ini berfungsi dengan baik di seluler karena di seluler, Anda memerlukan semacam umpan balik yang besar ketika pengguna mengklik atau menyentuh tombol. Tapi kemudian mereka menginjak efek riak semacam ini yang berlangsung sepanjang tombol. Ini sedikit berlebihan, terutama ketika ada banyak tombol. Tapi tetap saja kita akan mempertahankan efek riak ini karena akan sangat rumit untuk menghapusnya karena ini dibangun di dalam kerangka kerja React dan untuk memiliki efek melayang lain pada tombol ini, sesuatu yang lebih halus yang tidak akan menjadi hal yang rimbun seperti ini. di sini. Ini akan menjadi sangat kompleks. Jadi ini adalah jenis kompromi yang Anda lakukan.

Drew: Desain etis adalah subjek percakapan saya dengan Trina Felber dan Martin Michael Fredrickson. Saya bertanya apakah mengambil pendekatan etis untuk merancang dan menghindari pola gelap adalah kasus berpikir jangka panjang tentang kesehatan dan pertumbuhan bisnis daripada hanya tujuan penjualan jangka pendek. Ini Martin.

Martin Michael Fredrickson: Itu benar sekali. Saya pikir Anda harus melihat bisnis yang Anda lakukan secara online seolah-olah Anda memiliki toko di jalan utama di kota berukuran sedang, di mana Anda harus menjaga reputasi Anda tetap utuh. Jika Anda tidak memperlakukan pelanggan Anda dengan baik, maka jika Anda tidak memperlakukan pelanggan Anda dengan baik, dalam jangka panjang, Anda akan kehabisan bisnis karena orang-orang, mereka akan pergi ke toko lain, atau mereka akan membeli dari online. Jadi apa pun yang Anda lakukan secara online, Anda benar-benar harus berpikir bahwa ada efek jangka panjangnya, dan juga, ada biaya tersembunyi dalam melakukan hal-hal yang rumit atau hal-hal yang memanipulasi. Jika Anda mendeklarasikan, seperti kata Trina, akan ada penghematan jangka panjang, dan itu tidak pernah dihitung ketika Anda berbicara tentang model bisnis. Anda selalu berbicara tentang berapa banyak uang yang dapat Anda hasilkan. Anda tidak pernah berbicara tentang biaya menghasilkan uang sebanyak itu.

Drew: Pada bulan Maret, saya berbicara dengan Eduardo Boucas tentang alat sumber terbuka yang disebut Sourcebit yang mengumpulkan konten dari sumber yang berbeda dan membuatnya tersedia untuk generator situs statis Anda. Saya bertanya kepada Eduardo apakah ini dapat meningkatkan pengalaman pengguna dalam mengotorisasi SSG dengan mengaktifkan integrasi dengan alat seperti CMS tanpa kepala.

Eduardo Boucas: Tepat sekali. Ya. Cara yang bisa… Saya melihat dua cara berbeda dalam menggunakan alat yang dapat membantu pengembang. Salah satunya adalah menjadikan Sourcebit sebagai bagian dari rutinitas penerapan Anda. Jadi jika Anda menggunakan platform hosting, seperti Netlify, misalnya, dan Anda mengonfigurasi perintah penerapan Anda menjadi, saya tidak tahu, build Hugo, apakah itu, perintah build untuk Hugo atau semacamnya, jenis perintah yang menghasilkan file statis untuk Hugo. Anda juga akan memiliki perintah lain sebagai bagian dari rutinitas itu. Itu akan menjadi sesuatu seperti Sourcebit fetch. Jadi pada waktu pembuatan, Sourcebit akan menarik semua data lainnya, menghasilkan semua file yang dibutuhkan Hugo, dan kemudian seluruh penerapan akan menggunakan file tersebut dan menyebarkan semua konten yang berasal dari CMS.

Eduardo Boucas: Jadi itu salah satu kemungkinan kasus penggunaan untuk Sourcebit. Yang lainnya adalah menggunakan Sourcebit sebagai pengembangan lokal dalam alur kerja pengembangan lokal. Jadi Anda dapat menjalankan Sourcebit dengan sesuatu yang kami sebut mode tontonan. Jadi Sourcebit terus mencari perubahan di sumber data jarak jauh, jadi dalam hal ini, CMS tanpa kepala. Jadi, setiap kali Anda menerbitkan artikel atau Anda mengubah entri ke CMS, Sourcebit akan mengakuinya, dan itu akan membuat ulang semua file untuk Anda secara lokal.

Eduardo Boucas: Jadi apa artinya bagi pengembang yang bekerja secara lokal adalah Anda dapat membuat jendela CMS Anda di sebelah situs Hugo Anda berjalan secara lokal, dan kemudian Anda dapat melihat perubahan yang terjadi secara real time. Anda mengubah sesuatu di CMS, dan kemudian Anda dapat melihat perubahan itu tercermin di situs lokal, yang menurut saya sangat berguna. Jadi itulah dua cara Anda dapat menggunakan Sourcebit.

Drew: Pengoptimalan konversi adalah topik hari ini. Ketika saya berbicara dengan podcaster dan konsultan veteran, Paul Boag. Kami berbicara tentang beberapa teknik yang digunakan situs untuk mengubah pengunjung menjadi pelanggan. Tapi saya ingin bertanya kepada Paul bagaimana Anda mengukur dampak dari perubahan yang Anda buat. Paulus menjelaskan.

Paul Boag: Ya. Sangat. Saya pikir, sekali lagi, ini adalah sesuatu yang sangat buruk bagi banyak organisasi untuk menjadi jelas tentang bagaimana mereka akan mengukur kesuksesan. Sekarang, ya, tingkat konversi Anda adalah satu metrik. Anda harus benar-benar mengikuti. Tetapi bahkan dengan konversi, Anda harus sedikit lebih canggih daripada berapa banyak orang yang membeli. Anda juga perlu memperhatikan nilai pesanan rata-rata. Anda perlu memberi perhatian khusus pada nilai seumur hidup, bukan? Jadi berapa nilai pelanggan selama hidup mereka, karena Anda mungkin menemukan bahwa Anda mendapatkan pelanggan yang cukup tinggi, jika Anda menggunakan pola gelap dan hal-hal seperti itu. Tapi sungguh, konversi seharusnya hanya salah satu metrik yang Anda ukur.

Paul Boag: Ada juga hal-hal seperti Anda perlu memperhatikan keterlibatan, seberapa terlibat orang-orang dengan konten Anda, karena itu membuat perbedaan besar apakah mereka pada akhirnya akan berkonversi. Jadi, Anda melihat hal-hal seperti, berapa banyak video Anda, apakah mereka menonton, berapa lama mereka menghabiskan waktu di situs Anda, dan apa yang mereka lihat saat melakukannya? Apakah mereka terlibat di media sosial dan hal-hal semacam itu? Kemudian aspek terakhir jelas kegunaan. Anda perlu mengukur seberapa cepat seseorang dapat menyelesaikan tugas tertentu di situs web mereka dan seberapa mudah mereka menemukan sistem yang digunakan dan berbagai kriteria berbeda lainnya.

Paul Boag: Ada banyak mekanisme yang dapat Anda gunakan untuk mengukur hal-hal yang berbeda itu. Ada beberapa alat hebat di luar sana dan juga beberapa metrik bagus yang bisa Anda adopsi. Jadi misalnya, dengan kegunaan, ada sesuatu yang disebut skala kegunaan sistem yang bisa menjadi metrik yang sangat berguna untuk diukur. Namun demikian, ada alat seperti maze.design adalah salah satu yang sering saya gunakan, yang akan mengukur berapa lama waktu yang dibutuhkan seseorang untuk melakukan pembelian, misalnya, melewati kasir. Jadi ya. Memiliki rentang metrik yang luas seperti itu, Anda tidak hanya berfokus pada, berapa banyak penjualan yang kami lakukan pada kuartal ini? Anda harus melihat gambaran yang lebih besar.

Drew: Pada bulan April, saya mengobrol dengan Laura Kalbag dari Better Blocker tentang privasi online. Kami berbicara tentang batas yang semakin menipis antara apa yang dianggap publik dan apa yang pribadi dan bagaimana hal-hal yang kami anggap pribadi mungkin tidak terlihat seperti itu oleh perusahaan tempat kami mempercayakan data kami. Ini Laura.

Laura Kalbag: Saya punya contoh klasik tentang hal ini yang terjadi pada saya beberapa tahun yang lalu. Jadi saya ada di Facebook, dan ibu saya baru saja meninggal, dan saya mendapatkan iklan untuk direktur pemakaman. Saya pikir itu benar-benar aneh karena tidak ada keluarga saya yang mengatakan apa pun di platform media sosial pada saat itu. Tak satu pun dari keluarga saya yang mengatakan apa pun di Facebook karena kami telah sepakat bahwa tidak ada yang ingin mengetahui hal semacam itu tentang seorang teman atau anggota keluarga melalui Facebook. Jadi kami tidak mengatakannya.

Laura Kalbag: Jadi saya bertanya kepada saudara-saudara saya, “Oh, apakah ada yang mengatakan sesuatu di Facebook yang mungkin menyebabkan hal aneh ini.” Karena saya biasanya hanya mendapatkan iklan untuk makeup dan gaun dan tes kehamilan dan semua hal menyenangkan yang mereka suka bicarakan. Ini adalah wanita dengan usia tertentu. Sebaliknya, saudara perempuan saya kembali kepada saya. Dia berkata, “Yah, ya. Teman saya tinggal di Australia.” Jadi saya mengiriminya pesan di Facebook Messenger dan mengatakan kepadanya bahwa ibu kami telah meninggal. Tentu saja, Facebook tahu bahwa kami bersaudara. Ini memiliki koneksi hubungan yang dapat Anda pilih untuk ditambahkan di sana. Maksudku, itu mungkin bisa menebak kami adalah saudara perempuan, berdasarkan lokasi yang pernah kami kunjungi bersama, fakta bahwa kami berbagi nama keluarga dan memutuskan, "Oh, itu iklan yang tepat untuk dipasang di kakinya."

Drew: Sungguh serius, bukan, untuk berpikir bahwa teknologi membuat keputusan ini untuk kita, yang sebenarnya mempengaruhi orang-orang yang berpotensi dalam contoh ini waktu yang cukup sensitif atau rentan?

Laura Kalbag: Ya. Kami mengatakan itu menyeramkan. Sering kali orang berkata, “Oh, hampir seperti mikrofon di ponsel atau laptop saya mendengarkan saya karena saya baru saja melakukan percakapan tentang produk ini, dan tiba-tiba muncul di feed saya di mana-mana.” Saya pikir apa yang sebenarnya menakutkan adalah kenyataan bahwa kebanyakan dari mereka tidak memiliki akses ke mikrofon Anda. Tetapi fakta bahwa perilaku Anda yang lain, pencarian Anda, fakta bahwa ia mengetahui dengan siapa Anda berbicara karena kedekatan Anda satu sama lain dan lokasi Anda di perangkat Anda. Itu dapat menghubungkan semua hal yang mungkin tidak kita hubungkan bersama hanya untuk mengatakan, "Oh, mungkin mereka akan tertarik dengan produk ini karena mereka mungkin berpikir, membicarakannya."

Drew: Ketika pandemi virus corona melanda, dan banyak negara melakukan penguncian, saya berbicara dengan Rachel Andrew tentang bagaimana Smashing mengadaptasi konferensi tatap muka yang dijadwalkan untuk dilakukan secara online. Baru saja harus menunda konferensi Smashing, San Francisco, saya bertanya kepada Rachel apa rencananya untuk memindahkan konferensi dan lokakarya yang akan datang ke dalam domain virtual.

Rachel An Drew: Sangat, sangat cepat, begitu kami menyadari bahwa kami harus menunda San Francisco, tentu saja, kami memiliki bengkel, baik saya sendiri maupun Vitaly menjalankan bengkel di smash dan comp, dan semuanya terjual habis di San Francisco, keduanya bengkel kami. Jelas, kami memiliki banyak orang lain yang datang dan menjalankan lokakarya untuk kami, orang-orang yang telah bekerja dengan kami untuk waktu yang lama, dan mereka menemukan bahwa semua lokakarya mereka, dan bagi kami yang melakukan lokakarya, mereka sebenarnya memiliki bagian penting dari pendapatan kita.

Rachel An Drew: Berbicara di depan umum, Anda tidak mendapatkan banyak uang dengan pergi dan berbicara di depan umum. Kebanyakan orang tidak dibayar banyak, tidak jika Anda mempertimbangkan jumlah waktu yang dibutuhkan untuk menulis ceramah dan sebagainya. Lokakarya cenderung menjadi cara yang bagus bagi orang-orang yang pandai mengajarkan hal ini untuk mendapatkan uang. Jadi mereka mewakili pendapatan masyarakat. Jadi bukan hanya saya sendiri dan Vitaly yang sempat kehilangan bengkel kami di awal tahun ini. Kami juga menyadari bahwa banyak pembicara Smashing kami juga bergantung pada lokakarya tersebut.

Rachel An Drew: Jadi kami berpikir, “Mengapa tidak membawanya secara online saja?” Sangat, sangat cepat, benar-benar dalam beberapa hari setelah itu terjadi, kami memutuskan bahwa saya dan Vitaly akan menjadi yang pertama untuk tetap berpegang pada kekuasaan, tetapi mengingat itu adalah kami, dan kami dapat menemukan cara untuk melakukannya. Kami juga memiliki bengkel yang sangat berbeda. Vitaly jauh lebih kolaboratif. Dia memiliki kegiatan kelompok dan hal-hal. Saya mengajar gaya kelas. Jadi di antara kami, kami berpikir, "Yah, kami semacam menutupi semua pangkalan." Jadi kami berpikir, “Ayo lakukan saja. Mari kita lihat apakah itu berhasil.” Jadi kami mengiklankannya. Kami mencari tahu berapa lama masing-masing, dan kemudian kami duduk dan berkata, “Yah, seperti apa sebenarnya lokakarya online itu? Apa ini?"

Drew: Saya pikir dari perspektif teknis sebagai pengembang web yang langsung berpikir, bagaimana kami akan memberikan sesuatu seperti itu, maksud saya, harus ada banyak platform berbeda yang Anda lihat. Apa saja hal berbeda yang Anda lihat dan apa yang akhirnya datang dengan Smashing?

Rachel An Drew: Jadi kami telah melihat banyak hal, dan kami masih dalam proses melakukan itu. Kami menggunakan Zoom saat ini. Alasan kami menggunakan Zoom adalah aksesibilitas. Itu adalah platform yang paling mudah diakses. Jelas, kami tidak ingin memotong orang karena platform yang kami pilih. Saya pikir platform lain menjadi lebih baik dan orang-orang… Saya pikir banyak platform telah membuat orang datang kepada mereka dan berkata, “Ya, Anda terlihat hebat. Tetapi kami membutuhkan Anda untuk dapat diakses.” Jadi zoom adalah yang paling mudah digunakan orang saat ini.” Jadi itu sebabnya kami akhirnya menggunakannya. Saya tidak tahu apakah kita akan melakukannya selamanya. Tapi itulah yang kami gunakan saat ini, dan itu bekerja cukup baik sebagai cara untuk melakukan hal ini.

Drew: Ketika Zoom mulai lelah dan dunia mulai menyesuaikan diri dengan apa yang dengan cepat disebut normal baru, saya berbicara dengan Phil Smith tentang bagaimana teknologi dapat membantu kita merespons situasi seperti COVID-19. Membangun aplikasi React Native, CardMedic hanya dalam 10 hari. Saya bertanya kepada Phil bagaimana dia menyeimbangkan memilih teknologi terbaik untuk pekerjaan versus teknologi yang dia kenal dan dapat bekerja dengan cepat.

Phil Smith: Itu pertanyaan yang bagus. Saya pikir begitu proyek itu disebutkan kepada saya, saya pikir saya tahu persis bagaimana saya akan membangun semua ini. Jika saya tidak punya anak dan saya duduk di ruangan yang gelap, saya pikir saya mungkin bisa membalikkan semuanya dalam waktu sekitar lima hari jika saya mengerjakannya dengan solid, solid, solid karena persyaratannya sangat banyak. sejalan dengan pengalaman saya membangun aplikasi. Saya telah membangun hal serupa, di mana ia memanggil API, menyimpan hasilnya dalam status dan menyajikannya. Saya sekarang berada pada posisi di mana ada beberapa hal di mana saya seperti, "Oke, saya harus kembali dan memperbaikinya."

Phil Smith: Saya telah berbicara tentang mengetik timah, tetapi sebenarnya jenisnya bisa sangat longgar di aplikasi, dan itu perlu diperketat. Di bagian belakang, tidak banyak tes dan sekarang kami mulai meluncurkan bagian belakang karena banyak orang telah maju dan berkata, “Sebenarnya, ini adalah sumber yang bagus. Saya ingin menawarkan layanan saya untuk menerjemahkan ini ke dalam bahasa ibu saya.” Bagian belakangnya digunakan oleh lebih banyak orang, jadi saya hanya berpikir, "Tunggu, saya perlu beberapa tes lagi di sini untuk memastikan tidak ada yang rusak karena ada orang yang menggunakan ini dalam produksi sekarang." Saya pikir saya menjawab pertanyaan Anda. Pada dasarnya, tidak ada pengambilan keputusan. Saya hanya harus mengeluarkannya secepat mungkin.

Drew: Karena tempat kerja tutup dan banyak dari kita yang beradaptasi untuk bekerja di rumah, saya berbicara dengan Ben Frain tentang mengoptimalkan ruang kerja di rumah Anda menjadi tempat yang nyaman dan produktif tidak akan mengakibatkan masalah kesehatan fisik jangka panjang. Dengan anggaran terbatas yang tersedia untuk menyiapkan di rumah, saya bertanya kepada Ben apakah kursi yang bagus adalah tempat terbaik untuk memulai.

Ben Frain: Itu saran saya. Ya. Maksud saya, saya tidak bisa mengaku sebagai otoritas dalam hal-hal ini, tetapi tampaknya itu mungkin satu-satunya hal terpenting yang dapat Anda lakukan untuk membuat diri Anda nyaman sepanjang hari. Anda bisa mulai dengan sesuatu yang cukup mahal. Saya melakukan kesalahan yang sama, dan akhirnya saya mendapatkan kursi kantor seberat 45 pon dari Amazon, dan saya tidak menyadari bahwa kursi itu tidak memiliki kemiringan ke depan, apa pun kata yang tepat untuk benda itu, pada porosnya. Jadi apa yang saya temukan adalah itu menggali ke bagian bawah paha saya, semacam di belakang lutut saya, dan saya berpikir, "Mengapa kaki saya mati setelah 45 menit duduk di benda itu?"

Ben Frain: Saya pikir terutama jika Anda bekerja untuk perusahaan yang menyediakan kursi kantor yang layak, Anda hanya menerimanya begitu saja, dan baru setelah Anda melihat merek dan merek tertentu Anda akan berkata, “Ya Tuhan, ini kursi $700.” Ketika Anda menyadari hal itu, orang-orang telah memikirkan hal ini dan melakukan banyak hal untuk Anda, dan kemudian jelas Anda datang ke lingkungan rumah Anda dan Anda berpikir, "Mengapa tidak menghabiskan X ratus dolar untuk kursi?" Tapi mungkin itu sepadan. Terutama jika Anda berada di sini untuk jangka panjang.

Drew: Dan jangka panjang adalah apa yang kami dapatkan. Hal lain yang ada untuk jangka panjang adalah Drupal. Pada bulan Juni, saya berbicara dengan Angie Byron tentang perubahan Drupal 9. 20 tahun sejak rilis pertama, Drupal telah menempuh perjalanan panjang. Saya bertanya kepada Angie seperti apa proses memutakhirkan situs Drupal yang ada saat pindah ke Drupal 9 dan apakah itu mungkin menjadi beban besar bagi mereka yang memiliki situs yang sudah berjalan lama.

Angie Byron: Saya pikir pada dasarnya ada tiga skenario. Jadi salah satunya adalah jika Anda menjalankan Drupal 8, dan setiap kali rilis minor baru Drupal 8 keluar, Anda segera memutakhirkannya, dan Anda mulai memanfaatkan hal-hal baru. Jalan Anda pada dasarnya tidak ada apa-apanya. Anda sudah melakukan semua pekerjaan dan Anda baik-baik saja. Jika Anda pindah ke Drupal 8 beberapa waktu lalu dan Anda belum mengikuti perubahan BC, ada sedikit pekerjaan untuk Anda.

Angie Byron: Ini jelas merupakan peningkatan termudah dalam lebih dari satu dekade perangkat lunak kami, dan kami memiliki banyak alat berbeda untuk membantu Anda. Ada dasbor yang menunjukkan semua modul yang dikontribusikan dan situasi Drupal 9 mereka. Ada alat otomatis untuk memeriksa dan memeriksa kode Anda dan menandai setiap fungsi usang yang Anda miliki, dan ada alat untuk naik secara otomatis dan menemukan, “Oh, ini adalah versi terbaru dari modul Anda, dan Drupal 9 sudah siap? Anda harus mengunduhnya, ”hal-hal semacam itu.

Angie Byron: Jadi dari Drupal 8 hingga 9, saya akan mengatakan bahwa bagian itu sudah tercakup dengan cukup baik. Jika Anda berasal dari Drupal versi sebelumnya, katakanlah Drupal 7 atau lebih rendah ke Drupal 9, itu mulai terlihat sedikit lebih rumit. Di antara perubahan yang kami buat di Drupal 8, di mana misalnya, kami pindah sepenuhnya ke PHP berorientasi objek, dan kami mulai menggunakan pola desain yang ditemukan di proyek perangkat lunak lain, yang merupakan hal yang sangat cerdas untuk dilakukan secara arsitektural, tetapi tidak berarti jika Anda memiliki banyak kode khusus di kehidupan lama Anda, di Drupal 9, Anda perlu mencari alternatif untuk itu.

Angie Byron: Jadi Acquia adalah produk dan pengembangan yang disebut Acquia Migration Accelerator yang bertujuan untuk memecahkan masalah itu, di mana kami membuat aplikasi terdefinisi React yang bagus, yang membaca data Drupal 7 lama Anda, membuat data Drupal 8 yang setara untuk Anda bersama dengan semua modul yang Anda perlukan untuk memetakan ke modul Drupal 7 lama Anda jika memungkinkan untuk mencoba dan mempercepat proses itu sedikit karena kami ingin memastikan bahwa semua orang yang menggunakan versi lama masih dapat melanjutkan ke tatanan dunia baru, di mana semua orang menggunakan versi yang sama, dan kita semua bekerja bersama.

Angie Byron: Selain itu, kami juga telah memperluas Drupal 7… Komunitas open source Drupal, akhir hidupnya di Drupal 7 pada November tahun depan. Saat ini, bagaimanapun, kita perlu mendiskusikan apakah COVID berdampak atau tidak. Tetapi ada sejumlah perusahaan yang berbeda, dan Acquia adalah salah satu dari mereka yang menawarkan dukungan tambahan untuk Drupal 7 lebih dari itu, setidaknya hingga 2024. Jadi semacam itu membuatnya sehingga orang yang memiliki peningkatan mudah memiliki waktu satu setengah tahun untuk menyelesaikannya, orang memiliki peningkatan yang kurang mudah, berpotensi tiga setengah tahun untuk menyelesaikannya atau lebih lama jika mereka perlu, dan kami berusaha sangat keras untuk memungkinkan semua orang berpindah dan kemudian membangun alat seperti Acquia Migrate Accelerator untuk membantu mempercepat prosesnya.

Drew: Belajar Bereaksi adalah subjek percakapan dengan Mina Markham. Mina dan aku sama-sama berada dalam posisi belajar React untuk pertama kalinya. Merefleksikan seberapa banyak beban kerangka kerja seperti React yang diletakkan di browser, saya bertanya kepada Mina apakah menempatkan begitu banyak kendali di tangan klien adalah sebuah kesalahan.

Mina Markham: Saya ingin mengatakan ya dengan peringatan, sekali lagi, pengalaman saya sangat banyak terkandung di sebagian besar situs web statis. Saya tidak melakukan banyak pengembangan produk. Jadi mungkin di ranah itu, ini lebih masuk akal. Tapi dari sudut pandang saya, saya merasa kita sering menggunakan kapak ketika kita hanya membutuhkan pisau mentega. Saya tidak tahu mengapa kami perlu meletakkan semua ini di browser, memberikan begitu banyak pekerjaan dan begitu banyak tekanan pada klien ketika kami dapat melakukan banyak hal… Saya merasa kami dapat melakukan ini dengan lebih sederhana. Salah satu hal yang selalu membuat saya sedikit ragu untuk menggunakan React, atau saya katakan ragu-ragu, tetapi yang saya maksud ketika itu membuat saya sangat marah dan saya secara aktif menentangnya adalah ketika saya akan pergi ke sebuah situs web, dan secara harfiah tidak ada yang akan merender karena ada satu kesalahan atau sesuatu seperti benar-benar seluruh halaman rusak karena satu fungsi rusak.

Mina Markham: Itu hanya membuat saya kesal karena sering kali, itu adalah pendekatan semua atau tidak sama sekali. Salah satu pembicaraan yang saya berikan di AEA di masa lalu dan tempat-tempat lain di masa lalu adalah semacam pembicaraan tentang bagaimana memasukkan peningkatan progresif dan bukan hanya pengembangan Anda, tetapi juga arah seni dan desain situs yang lebih besar. Saya akan menunjukkan secara khusus contoh situs web yang tidak melakukan peningkatan progresif atau segala jenis degradasi yang anggun. Entah Anda menjalankan JavaScript di browser, atau Anda sama sekali tidak mendapatkan apa-apa. Ini hanya sebuah situs sederhana yang menyajikan informasi tentang sejarah desain web, yang merupakan salah satu situs yang benar-benar dibicarakan, sejarah desain web dari tahun 1990 hingga sekarang. Itu adalah situs web yang indah dengan banyak garis waktu, animasi berbagai hal. Tapi itu juga bisa dirender secara statis hanya dengan daftar. Ada langkah-langkah di antara tidak menunjukkan apa-apa dan menunjukkan pengalaman yang disempurnakan dengan indah yang menurut saya hilang karena cara kita mendekati pengembangan web modern sekarang.

Drew: Saya berbicara dengan Andy Bell tentang CUBE CSS, metodologi penataan dengan cara BEM, SMACSS, dan OOCSS. Banyak pendekatan CSS mencoba bekerja melawan sifat alami CSS seperti kaskade. CUBE sangat merangkul perilaku itu. Inilah Andy.

Andy Bell: Analogi yang bagus untuk ini adalah SCSS, seperti Sass, adalah perpanjangan dari bahasa CSS alami, bukan? Anda masih cukup benar dalam CSS. Jadi CUBE CSS seperti itu. Jadi ini adalah perpanjangan dari CSS. Jadi kita tetap harus menulis CSS, sebagaimana CSS seharusnya… yah, itu seharusnya ditulis. Jujur saja, begitulah seharusnya ditulis. Namanya memberikannya begitu saja, Cascading Style Sheets. Jadi saya merangkulnya lagi karena apa yang saya temukan adalah bahwa saya telah turun ke tingkat optimasi mikro. Saya telah menyusuri jalan yang saya lihat banyak orang turun baru-baru ini di mana… Saya telah menyebutkan ini di artikel juga, di mana saya dapat melihat… Ada beberapa bukti baru-baru ini. Saya telah melihat orang-orang telah membuat komponen spacer dan hal-hal seperti itu, dan saya memahami masalah itu. Saya pernah berada dalam situasi itu.

Andy Bell: Cara saya memperbaikinya, alih-alih menelusuri dan mencoba mengoptimalkan mikro, saya sebenarnya mulai memikirkan hal-hal pada tingkat komposisi karena tidak masalah seberapa kecil komponen Anda. Pada titik tertentu mereka akan menjadi halaman. Mereka akan menjadi pemandangan. Anda tidak dapat menghindari itu. Begitulah yang akan terjadi. Jadi, alih-alih mencoba mengatakan, "Benar, saya membutuhkan pembantu kecil ini untuk melakukan tata letak ini," Anda berkata, "Benar, saya memiliki tampilan halaman kontak atau tampilan halaman produk, dan itu adalah komposisi tata letak kerangka. Kemudian di dalamnya, saya dapat memasukkan komponen apa pun yang saya inginkan di sana.”

Andy Bell: Kami memiliki hal-hal seperti Grid dan Flexbox sekarang yang membuatnya jauh lebih dapat dicapai, dan pada dasarnya Anda dapat meletakkan apa pun yang Anda inginkan di dalam tata letak kerangka. Tidak masalah. Kemudian komponen harus, pada saat itu, berperilaku seperti yang Anda inginkan, dengan atau tanpa kueri penampung.

Drew: Gatsby adalah subjek obrolan saya dengan Marcy Sutton. Sementara sebagian besar generator situs statis adalah agnostik kode front-end, Gatsby menggunakan React, dan karena itu Anda berakhir dengan kode Gatsby berjalan sebagai bagian dari pengalaman web terakhir Anda. Saya bertanya kepada Marcy apa kode itu dan fungsionalitas apa yang disediakannya.

Marcy Sutton: Ya. Saya akan mengatakan bagian terbesar dari itu adalah perutean sisi klien. Jadi Gatsby sekarang menggunakan vulkanisir di bawah tenda. Itu hanya semacam implementasinya sendiri. Tapi itu adalah bagian ketika Anda memuat situs statis Anda untuk pertama kalinya, ada file HTML di sana. Jadi jika pengguna mematikan JavaScript karena alasan tertentu, situs Anda seharusnya tetap ada, masih memiliki konten. Tetapi jika JavaScript diaktifkan, saat itulah langkah hidrasi ini terjadi, di mana ketika Anda menggunakan tautan di situs Gatsby Anda, itu akan mengambil sumber daya terlebih dahulu dari halaman itu. Jadi loadingnya lebih cepat. Jadi itu semua diaktifkan dengan lapisan JavaScript yang diberikan Gatsby ini kepada Anda.

Marcy Sutton: Jadi di luar itu, itu benar-benar tergantung jenis apa yang Anda gunakan di situs Anda, apa yang akan berakhir di bundel JavaScript itu. Tetapi untuk hal-hal yang menggunakan banyak interaktivitas, seperti antarmuka yang dapat diakses, itu adalah tempat yang baik. Bagi saya, saya sangat menikmati JavaScript tersedia untuk saya setiap saat dan markup saya berada di tempat yang bagus. Saya tahu ini masalah preferensi, apakah Anda ingin HTML dan JavaScript dan CSS Anda, semua jenis digabungkan dengan rapi, dan ada ruang untuk variasi dalam membangun Gatsby. Anda tidak selalu harus menggunakan sesuatu seperti CSS dan JS. Tapi ini benar-benar tentang mendapatkan kekuatan lapisan JavaScript dinamis yang tersedia untuk Anda saat Anda sedang menulis situs web Anda. Ini tidak seperti pengaya ini dalam file terpisah.

Drew: Ketika saya memikirkan bagaimana generator situs statis biasanya bekerja, saya berpikir tentang konten yang mungkin berupa file penurunan harga dan generator menjalankan konten tersebut dan menggabungkannya dengan template dan membuat puluhan, ratusan, ribuan file HTML, yang merupakan halaman situs web Anda. Ketika saya memikirkan situs atau aplikasi React, saya lebih memikirkan pengalaman satu halaman, di mana antarmuka dibuat oleh React dengan cepat. Jadi maksudmu Gatsby melakukan keduanya? Itu membuat semua halaman dan juga meningkatkannya dengan JavaScript?

Marcy Sutton: Ya, ya. Gatsby akan menggunakan Node.js pada waktu pembuatan, ia akan memeriksa komponen React Anda dan mengompilasinya ke dalam file HTML, yang sejujurnya, pertama kali saya melihat Gatsby, saya tidak akan mematikan JavaScript dan berkata, “Baiklah, apakah ada halaman lain di sini? Apa ini?" Saya sangat senang bahwa Gatsby bekerja seperti itu secara default. Ini akan membuat file bawaan dari komponen React Anda, yang luar biasa.

Marcy Sutton: Saya telah menjelajahi pendekatan peningkatan yang lebih progresif karena ada dalam JavaScript, seperti, bagaimana jika Anda ingin menampilkan sesuatu yang ditingkatkan secara progresif untuk pengguna, di mana jika mereka menonaktifkan JavaScript, Anda tidak ingin semua kode rusak yang mengasumsikan JavaScript disana. Jadi ada beberapa keanehan dengan itu. Tetapi Anda dapat mengatasi hal semacam itu, setidaknya untuk aliran pengguna inti Anda di mana Anda ingin seseorang tetap dapat membeli sesuatu. Anda mungkin perlu menambahkan beberapa dukungan dan untuk kasus penggunaan tersebut. Tapi saya sangat terkejut bahwa cara Gatsby meluncurkannya secara default.

Marcy Sutton: Jadi itu adalah pilihan yang mereka buat untuk membangun situs seperti itu, dan kami selalu mengevaluasi, apakah itu masih cara terbaik? Apa yang perlu kami lakukan untuk memberikan apa yang diminta pengguna kami? Jadi kami melakukan beberapa eksplorasi internal, berkelanjutan hanya untuk memastikan Gatsby melakukan pekerjaan terbaiknya dalam membangun situs web, jadi menjaga ukuran bundel tetap kecil dan memastikan bahwa untuk membuat trade-off untuk apa yang kami katakan adalah kode berkinerja dengan pra -mengambil, apakah kita memiliki data untuk mendukungnya? Hal seperti itu sebagai advokat pengembang yang sangat saya minati, adalah memastikan bahwa apa yang kami kemas dan bundling di situs web benar-benar dibutuhkan dan akan benar-benar membuat situs Gatsby terbaik yang dapat dibuatnya.

Drew: Berbicara dengan Chris Ferdinandi pada bulan Juli, saya bertanya apakah praktik terbaik modern buruk untuk web. Chris mendukung gerakan yang dikenal sebagai Lean Web, dan saya bertanya kepadanya apa yang dimaksud dengan itu. Here's Chris.

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. Saya menjadi percaya bahwa banyak dari apa yang kita anggap sebagai praktik terbaik saat ini sebenarnya dapat memperburuk web. The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? Tetapi Anda juga dapat memilih bahasa pra-prosesor. Katakanlah Anda menyukai Sass. Anda mengaktifkan Sass di CSS, dan Anda menulis Sass. Nah, sesuatu harus memproses Sass. Hari-hari ini, Sass ditulis dalam Dart atau semacamnya. Theoretically, you could do that in the client. Tetapi perpustakaan yang melakukan pra-pemrosesan ini cukup besar. Saya tidak berpikir saya ingin mengirimkan seluruh perpustakaan Sass kepada Anda, hanya untuk menjalankan hal itu. aku tidak mau. That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. Tapi begini cara kerjanya sekarang, apakah ada lambda. Ini memproses Sass. Ia memiliki satu pekerjaan kecil, kecil, kecil, kecil. You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. Anda tidak perlu khawatir tentang skala. You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. I don't know what that is. I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. Tapi ada satu untuk Sass. Ada satu untuk Kurang. Ada satu untuk Babbel. Ada satu untuk TypeScript. Ada satu untuk… Semua itu adalah lambda individual yang kami jalankan. Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. Tapi kami menggunakannya untuk lebih dari itu, bahkan baru-baru ini.

Chris Coyier: Here's an example. Setiap Pena di CodePen memiliki tangkapan layar. Itu agak keren, kan? So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Jika Anda membagikannya di Slack, Anda mendapatkan sedikit pratinjaunya. We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? Lagipula itu bukan animasi. Hanya peningkatan kinerja seperti itu.

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. Ini adalah pekerja. So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. Sajikan sebagai dimensi ini.” Saya tidak perlu membuat gambar dalam dimensi tersebut. You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. Itu menjadi titik masuk ke aplikasi Anda yang dapat Anda bagikan melalui semua jenis media.

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js juga, yang sangat, sangat bagus, secara otomatis mengambil lebih dulu sisa halaman yang terhubung ke titik masuk itu, sehingga terasa seperti aplikasi satu halaman. So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. Jadi pertama-tama, ada motivasi untuk mengubah reaktivitas. Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. Tapi oke. Kami akan tetap mengajarimu.

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. Itu TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

Natalia Tepluhina: Jadi ini adalah bagian besar lagi. Yang terakhir adalah kami agak melewatkan fungsionalitas ke logika abstrak, dalam hal bukan komponen, tetapi bagian logika yang dapat dikomposisi, seperti fungsi pembantu dan sebagainya, tetapi mereka harus dapat menyertakan aktivitas Vue juga. Contoh yang bagus di sini adalah React Hooks, bukan? Mereka memungkinkan Anda mengabstraksi bagian-bagian dari fungsionalitas, dan ini jelas tidak ada di Vue. Saya tahu bahwa saat ini kedengarannya seperti, "Anda mencuri fitur dari React." Sebenarnya tidak. Saya percaya bahwa ide penyerbukan silang adalah bagian besar dan bagus dalam ekosistem kami, dan juga membantu pengembang untuk beralih di antara favorit, bukan? Jadi kami sedang mengerjakan fitur utama ini untuk membuat Vue 3 sebagai versi utama.

Drew: Setelah itu kami menyelami TypeScript dengan Stefan Baumgartner untuk mengetahui bagaimana itu dapat membantu kami menulis kode yang lebih baik dengan lebih sedikit bug. Mengamati tren organisasi untuk memindahkan basis kode mereka sepenuhnya ke JavaScript, saya bertanya kepada Stefan apakah TypeScript adalah sesuatu yang lebih bermanfaat bagi tim yang lebih besar daripada individu.

Stefan Baumgartner: Jadi saya saat ini dalam transisi yang sama. Jadi kami memiliki banyak pengembang Java dan C++ yang akan menulis banyak JavaScript di masa mendatang. TypeScript dapat menjadi semacam panduan untuk area menakutkan dari bahasa pemrograman baru. JavaScript memiliki banyak kebiasaan, banyak sejarah, dan banyak prasangka jika Anda berasal dari bahasa pemrograman yang berbeda. Jadi TypeScript bisa menjadi panduan karena ada beberapa konsep yang Anda kenal dalam sistem tipe.

Stefan Baumgartner: Tapi juga, saya pikir, terutama ketika Anda memiliki banyak orang yang bekerja di basis kode yang sama atau banyak orang yang perlu bekerja dengan satu sama lain, ini bisa menjadi lapisan panduan tambahan dalam proyek Anda, di mana Anda tidak' t memiliki kejutan buruk pada akhirnya. Jadi tentu saja, teknologi tidak menyelesaikan masalah komunikasi apa pun. Ini bukan tujuan TypeScript. Tapi itu bisa lebih rendah, atau bisa memberi lebih banyak ruang untuk diskusi yang tepat maka jika Anda tidak perlu membicarakannya, apa yang Anda harapkan dari saya dalam kode Anda, melainkan, apa yang harus dilakukan kode Anda, atau apa yang harus Anda lakukan? perpustakaan lakukan?

Stefan Baumgartner: Saya selalu mengatakan bahwa jika Anda pernah menulis kode untuk orang lain atau jika Anda menulis kode dengan banyak orang atau jika Anda hanya menulis kode untuk diri sendiri, Anda harus mengunjungi kembali keesokan harinya, pertimbangkan TypeScript karena mungkin membantu Anda dalam jangka panjang. Ini bukan hanya investasi untuk proyek minggu depan, tetapi lebih untuk orang yang mengatakan, oke, terutama jika Anda memiliki proyek yang tahan lama selama sebulan, dua, atau tahun, pasti menawarkan itu. Anda tidak akan pernah tahu apa yang Anda pikirkan ketika Anda menulis potongan kecil kode satu tahun yang lalu, tetapi tipe dapat memberi Anda petunjuk tentang apa yang Anda maksud.

Drew: Pada bulan November, saya mengobrol dengan David Darnes tentang generator situs statis, Eleventy. Kami berbicara tentang templating dan berapa banyak generator situs statis yang cukup banyak berpendapat tentang jenis templat apa yang harus Anda gunakan. Aku bertanya-tanya apakah Eleventy memiliki keyakinan kuat yang sama. Ini Dave.

David Darnes: Tidak, saya harus mengatakan itu sedekat mungkin dengan pendapat Anda. Sedikit pandangan pribadi, tetapi saya berjuang untuk melihat kerangka kerja atau apa pun yang tidak dapat dipikirkan karena, untuk membuat sesuatu, Anda harus memiliki pendapat tentang bagaimana Anda ingin melakukan sesuatu. Ini semacam oksimoron. Saya yakin orang bisa mengoreksi saya tentang itu. Tapi ya. Anda dapat beralih ke bahasa templat apa pun yang menurut Anda paling nyaman. Maksud saya, kami baru saja berbicara tentang bahasa yang Anda sukai. Sebelas menarik untuk itu dalam arti dengan bahasa templat apa yang digunakan di dalam HTML Anda, atau bahkan CSS Anda, jika Anda mau.

David Darnes: Bagi saya, saya langsung menuju ke nunjucks karena nunjucks adalah bahasa templat default di dalam Eleventy. Itu berarti saya dapat menggunakan ekstensi dot HTML dan membiarkannya apa adanya. Sekarang, saya hanya akan membuat orang lebih bingung lagi dan berkata, “Kamu bisa menamainya sesukamu. Anda bisa benar-benar bersenang-senang dengannya. ” Tapi Anda bisa menggunakan setang. Saya pikir Anda bisa menggunakan templating JavaScript biasa dan mengulanginya seperti itu. Setang cukup populer dan Liquid juga. Saya tidak dapat memikirkan semuanya dari atas kepala saya, tetapi jika Anda mengatur semuanya dalam konfigurasi, Anda dapat memilih sesuka Anda.

David Darnes: Saya akan mengatakan bahwa saya adalah penggemar berat template bahasa secara umum. Belum lama berselang ketika saya mengetahui bahwa Anda dapat menggunakan ranting di dalam WordPress, dan hal itu mengejutkan saya. Saya seperti, “Oh, syukurlah. Saya tidak harus menangani perulangan for di dalam PHP.” Sekali lagi, saya pikir sesuatu yang sedikit lebih nyaman dan dapat dimengerti, lebih mudah dibaca juga. Jadi ya. Eleventy memiliki banyak pilihan templat yang berbeda, dan itu harus menarik bagi orang-orang yang merasa nyaman dengan yang berbeda itu.

Drew: Saya berbicara dengan Leslie Cohn-Wein tentang bagaimana Netlify menggunakan platformnya sendiri untuk membangun Netlify dan bagaimana fungsionalitas Deploy Preview mereka menjadi platform pementasan yang efektif untuk perubahan front-end.

Leslie Cohn-Wein: Mungkin bagian favorit saya dari keseluruhan proses itu adalah keajaiban Deploy Previews, yang kami dapatkan melalui Netlify. Jadi yang terjadi adalah Anda bekerja di GitHub, Anda meningkatkan PR Anda. Jadi Anda membuka PR Anda di GitHub, dan itu akan secara otomatis membuat build Pratinjau Deploy aplikasi Anda. Jadi kami benar-benar menggunakan Pratinjau Deploy aplikasi itu sendiri untuk menguji, untuk memastikan semuanya berfungsi sebagaimana mestinya. Kami menjalankan pengujian kami. Itulah yang kami gunakan untuk memverifikasi secara manual selama peninjauan kode. Jadi kami memiliki semacam semua penerapan berkelanjutan yang disiapkan langsung dari GitHub.

Leslie Cohn-Wein: Kemudian salah satu hal keren lainnya yang telah kami siapkan adalah bahwa kami sebenarnya memiliki beberapa situs Netlify berbeda yang mengambil dari repositori yang sama tempat aplikasi kami berada. Jadi kami memiliki kedua aplikasi kami. Kami memiliki instance Storybook yang memiliki semacam komponen UI kami untuk aplikasi. Jadi kami memiliki kedua aplikasi kami sendiri. Kami memiliki komponen UI Buku Cerita, dan pada dasarnya kami memiliki situs Netlify yang menunjukkan UI Buku Cerita kami, dan kemudian kami juga memiliki situs ketiga yang menjalankan penganalisis bundel webpack. Jadi ini semacam UI visual yang memberi Anda visualisasi peta pohon dari semua bundel aplikasi, dan kami dapat mengurutkan ukuran mereka, dan ini hanya pengingat bagi kami untuk memeriksa ulang setiap kali penerapan aplikasi berjalan. keluar, kami dapat memeriksa dan memastikan kami tidak melakukan sesuatu yang aneh dengan ukuran bundel kami di sana.

Leslie Cohn-Wein: Jadi ketiga situs tersebut dihasilkan dalam satu permintaan tarik aplikasi. Jadi, Anda akan mendapatkan tautan ke pratinjau, Pratinjau Deploy Anda pada dasarnya, dari Buku Cerita aplikasi dan ke profil aplikasi itu untuk kami periksa.

Drew: Pada bulan Desember, saya berbicara dengan Chris Murphy tentang desain produk dan apa artinya bagi bisnis untuk dirancang dengan fokus. Kami membahas jika seorang pendiri individu berfokus pada desain, apakah itu bocor ke dalam bisnis, dan jika suatu produk secara alami merupakan perpanjangan dari orang yang menciptakannya.

Chris Murphy: Saya pikir itu pertanyaan yang sangat bagus, Drew, dan saya pikir jawabannya tergantung. Saya pikir itu tergantung pada orang itu, dan itu tergantung pada skala perusahaan. Jika Anda melihat Hiut Denim, dan saya banyak menggunakan Hiut dalam pengajaran saya, ini adalah contoh yang sangat bagus dari sebuah perusahaan yang melakukan satu hal dengan baik, dan itu adalah jenis jeans strapline mereka. Saya pikir jika Anda melihat David sebelumnya ... David dan Clare, karena mereka adalah pasangan. Jika Anda melihat perusahaan David Hieatt dan Clare Hieatt sebelumnya, yaitu Howies, perusahaan itu telah tumbuh begitu besar, ada begitu banyak orang yang terlibat.

Chris Murphy: Begitu skala mulai merayap, mulai menjadi sangat sulit untuk mengawasi semua titik kontak kecil yang penting dalam perjalanan pelanggan. Saya pikir itu benar-benar mengatakan bahwa ketika mereka meninggalkan Howies, karena Howies telah dibeli oleh ... Ini rumit. Ayo baca di internet. Tapi itu Timberland, dan Timberland dibeli, dan ada semua cerita ini.

Chris Murphy: Saya pikir sangat menarik bahwa apa yang mereka fokuskan sekarang adalah jeans. Itu dia. Mereka menceritakan kisah yang luar biasa bagus seputar jeans. Mereka juga mengemas semuanya dengan sangat, sangat baik, dan jeans seperti kendaraan untuk cerita, sungguh. Ini adalah sesuatu yang saya pikir, Drew, akan menjadi lebih penting saat kita keluar dari ujung lain COVID, yang saya harap kita keluar dari ujung yang lain. Setiap orang yang membuat jeans itu dibayar dengan upah yang layak. Salah satu masalah yang saya miliki saat saya melihat dunia adalah tidak semua orang dibayar dengan upah yang layak, dan saya menemukan itu sedikit mengkhawatirkan, sebagai seseorang… Lihat, saya 51 tahun. Anak saya 25, 24 , 25, sesuatu seperti itu. Ini mengerikan. Aku harus tahu semua hal ini. Dia seorang fotografer pernikahan. Dia telah menjadi fotografer pernikahan selama kurang lebih satu tahun. Bisnisnya benar-benar hancur karena tidak ada yang benar-benar menikah saat ini karena itu hanya sulit. Dia tidak memiliki gaji karena dia tidak memiliki cukup buku wiraswasta untuk mendapatkan dukungan.

Chris Murphy: Dia jatuh melalui celah-celah, dan ada banyak orang lain yang telah jatuh melalui celah-celah. Saya berpendapat itu masalah desain, bahwa kita perlu melihatnya sebagai masalah desain. Tetapi jika saya juga melihat masalah COVID yang lebih luas dan pemerintah dan semua hal ini tanpa terlalu politis, saya membaca artikel di Guardian kemarin tentang tetangga Matt Hancock, dan siapa pun yang mendengarkan yang bukan dari Inggris, Matt Hancock adalah Sekretaris Kesehatan. Tetangganya, yang menjalankan bisnis, mengirim sms kepadanya dan meminta saran tentang, "Bagaimana cara saya memasok produk untuk hal COVID ini?" Ada banyak keributan di sekitar chumocracy, begitulah surat kabar menyebutnya, teman teman menteri pemerintah yang tampaknya mendapatkan pekerjaan karena mereka mengenal orang yang tepat.

Chris Murphy: Saya mengerti bahwa kita akan sampai ke ujung lain dari ini dan melihat ini… Orang-orang melihat itu, dan mereka berpikir, “Nah, ke mana perginya uang ini, dan apakah orang-orang dibayar dengan layak? Berapa harga kaos satu pon dari toko X ini?” Saya tidak ingin menyebut merek apa pun. Tapi semuanya harus dibayar, dan semua yang dibuat, orang harus dibayar untuk membuatnya. Saya pikir orang semakin tertarik, apakah orang dibayar dengan adil?

Drew: GraphQL adalah topik terakhir kami, episode penuh tahun ini, dan saya mengobrol dengan Eve Porcello dan bertanya di mana GraphQL cocok dengan tumpukan pengembangan.

Eve Porcello: Ya. GraphQL cocok antara ujung depan dan ujung belakang. Jadi ini seperti hidup di tengah-tengah antara keduanya dan memberikan banyak manfaat bagi pengembang front-end dan pengembang backend. Jika Anda seorang pengembang front-end, Anda dapat menentukan semua persyaratan data front-end Anda. Jadi, jika Anda memiliki daftar besar komponen React, misalnya, Anda bisa menulis kueri, dan itu akan menentukan semua bidang yang Anda perlukan untuk mengisi data untuk halaman itu.

Eve Porcello: Sekarang, dengan bagian backend, itu benar-benar milik sendiri, karena kami dapat mengumpulkan banyak data dari banyak sumber yang berbeda. Jadi kami memiliki data di REST API dan database dan semua tempat yang berbeda ini, dan GraphQL memberi kami lapisan orkestrasi kecil yang bagus ini untuk benar-benar memahami kekacauan di mana semua data kami berada. Jadi ini benar-benar berguna untuk jenis semua orang di seluruh tumpukan.